renaming draft figs

02_getting_started.asciidoc

@@ -178,7 +178,7 @@ Alice uses an Android device and will use the Google Play Store to download and
 
 [[eclair-playstore]]
 .Eclair Mobile in the Google Play Store
-image::images/eclair-playstore.png["Eclair wallet in the Google Play Store"]
+image::images/mtln_0201.png["Eclair wallet in the Google Play Store"]
 
 
 [TIP]
@@ -219,7 +219,7 @@ When Alice chooses to "Create a New Wallet", she will be shown a screen with her
 
 [[eclair-mnemonic]]
 .New Wallet Mnemonic Phrase
-image::images/eclair-mnemonic.png["New Wallet Mnemonic Phrase"]
+image::images/mtln_0202.png["New Wallet Mnemonic Phrase"]
 
 In <<eclair-mnemonic>>, we have purposely obscured part of the mnemonic phrase to prevent readers of this book from reusing the mnemonic.
 
@@ -267,7 +267,7 @@ Let's assume Alice has found a local Bitcoin ATM and has decided to buy some bit
 
 [[bitcoin-atm]]
 .A Lamassu Bitcoin ATM
-image::images/bitcoin-atm.png["Lamassu Bitcoin ATM"]
+image::images/mtln_0203.png["Lamassu Bitcoin ATM"]
 
 To receive the bitcoin in her Eclair Lightning wallet, Alice will need to present a Bitcoin address from the Eclair Lightning wallet to the ATM. The ATM can then send Alice's newly acquired bitcoin to this Bitcoin address.
 
@@ -275,7 +275,7 @@ To see a Bitcoin address on the Eclair wallet, Alice must swipe to the left colu
 
 [[eclair-receive]]
 .Alice's bitcoin address, shown in Eclair
-image::images/eclair-receive.png["Eclair bitcoin address QR code"]
+image::images/mtln_0204.png["Eclair bitcoin address QR code"]
 
 The QR code contains the same string of letters and numbers as shown below it, in an easy to scan format. This way, Alice doesn't have to type the Bitcoin address. In the screenshot <<eclair-receive>>, we have purposely blurred both, to prevent readers from inadvertently sending bitcoin to this address.
 
@@ -288,7 +288,7 @@ Alice can take her mobile device to the ATM and show it to the built-in camera,
 
 [[bitcoin-atm-receive]]
 .Bitcoin ATM scans the QR code.
-image::images/bitcoin-atm-receive.png["Bitcoin ATM scans the QR code"]
+image::images/mtln_0205.png["Bitcoin ATM scans the QR code"]
 
 Alice will see the transaction from the ATM in the "TRANSACTION HISTORY" tab of the Eclair wallet. While Eclair will detect the bitcoin transaction in just a few seconds, it will take approximately one hour for the bitcoin transaction to be "confirmed" on the Bitcoin blockchain. As you can see in <<eclair-tx1>>, Alice's Eclair wallet shows "6+ conf" below the transaction, indicating that the transaction has received the required minimum of six confirmations, and her funds are now ready to use.
 
@@ -300,7 +300,7 @@ The number of "confirmations" on a transaction is the number of blocks mined sin
 
 [[eclair-tx1]]
 .Alice receives bitcoin
-image::images/eclair-tx1-btc.png["Bitcoin transaction received"]
+image::images/mtln_0206.png["Bitcoin transaction received"]
 
 While in this example Alice used an ATM to acquire her first bitcoin, the same basic concepts would apply even if she used one of the other methods in <<acquiring-bitcoin>>. For example, if Alice wanted to sell a product or provide a professional service in exchange for bitcoin, her customers could scan the Bitcoin address with their wallets and pay her in bitcoin.
 
@@ -342,7 +342,7 @@ At first, there are no open channels, so as we see in <<eclair-channels>>, the "
 
 [[eclair-channels]]
 .Lightning Channels Tab
-image::images/eclair-tutorial2.png["Lightning Channels Tab"]
+image::images/mtln_0207.png["Lightning Channels Tab"]
 
 Alice presses the plus symbol and is presented with four possible ways to open a channel:
 
@@ -355,7 +355,7 @@ A "node URI" is a Universal Resource Identifier (URI) that identifies a specific
 
 [[node-URI-QR]]
 .node URI as a QR code
-image::images/node-URI-QR.png["Lightning node URI QR code",width=120]
+image::images/mtln_0208.png["Lightning node URI QR code",width=120]
 
 [[node-URI-example]]
 .node URI
@@ -377,7 +377,7 @@ Alice allocates 0.018BTC of her 0.020 total to her channel and accepts the defau
 
 [[eclair-open-channel]]
 .Opening a Lightning Channel
-image::images/eclair-open-channel-detail.png["Opening a Lightning Channel"]
+image::images/mtln_0209.png["Opening a Lightning Channel"]
 
 Once she clicks "OPEN", her wallet constructs the special Bitcoin transaction that opens a Lightning channel, known as the _funding transaction_. The "on-chain" funding transaction is sent to the Bitcoin Network for confirmation.
 
@@ -385,13 +385,13 @@ Alice now has to wait again (see <<eclair-channel-waiting>>) for the transaction
 
 [[eclair-channel-waiting]]
 .Waiting for the Funding Transaction to Open the Channel
-image::images/eclair-channel-waiting.png["Waiting for the Funding Transaction to Open the Channel"]
+image::images/mtln_0210.png["Waiting for the Funding Transaction to Open the Channel"]
 
 Once the funding transaction is confirmed, Alice's channel to the ACINQ node is open, funded and ready, as shown in <<eclair-channel-open>>:
 
 [[eclair-channel-open]]
 .Channel is Open
-image::images/eclair-channel-open.png["Channel is Open"]
+image::images/mtln_0211.png["Channel is Open"]
 
 [TIP]
 ====
@@ -418,7 +418,7 @@ On the counter at Bob's Cafe, there is a tablet device showing <<bob-cafe-posapp
 
 [[bob-cafe-posapp]]
 .Bob's Point-of-Sale Application
-image::images/bob-cafe-posapp.png["Bob's Point-of-Sale Application"]
+image::images/mtln_0212.png["Bob's Point-of-Sale Application"]
 
 ==== A Lightning invoice
 
@@ -426,13 +426,13 @@ Alice selects the "Cafe Latte" option from the screen and is presented with a _L
 
 [[bob-cafe-invoice]]
 .Lightning Invoice for Alice's latte
-image::images/bob-cafe-invoice.png["BTCPay Server Lightning invoice"]
+image::images/mtln_0213.png["BTCPay Server Lightning invoice"]
 
 To pay the invoice, Alice opens her Eclair wallet and selects the "Send" button (which looks like a right-facing arrow) under the "TRANSACTION HISTORY" tab, as shown in <<alice-send-start>>.
 
 [[alice-send-start]]
 .Alice Send
-image::images/alice-send-start.png["Lightning transaction send",width=300]
+image::images/mtln_0214.png["Lightning transaction send",width=300]
 
 [TIP]
 ====
@@ -443,7 +443,7 @@ Alice selects the option to "scan a payment request" and scans the QR code displ
 
 [[alice-send-detail]]
 .Alice's Send Confirmation
-image::images/alice-send-detail.png["Lightning transaction send confirmation",width=300]
+image::images/mtln_0215.png["Lightning transaction send confirmation",width=300]
 
 Alice presses "PAY," and a second later, Bob's tablet shows a successful payment. Alice has completed her first Lightning Network payment! It was fast, inexpensive, and easy. Now she can enjoy her latte which was purchased using bitcoin through a payment system that is fast, cheap and decentralized. From now on, Alice can simply select an item on Bob's tablet screen, scan the QR code with her cell phone, click pay, and will be served a coffee, all within seconds and all without an "on-chain" transaction.
 

05_node_operations.asciidoc

@@ -153,7 +153,7 @@ https://github.com/rootzoll/raspiblitz
 
 [[RaspiBlitz]]
 .caption to be written
-image::images/raspiblitz.jpg[]
+image::images/mtln_0501.png[]
 
 In addition to a Bitcoin and Lightning node, RaspiBlitz can install a number of additional services, such as:
 
@@ -192,7 +192,7 @@ There's no need to wait for a rainy day - you can find the project here: https:/
 
 [[umbrel]]
 .caption tbd
-image::images/umbrel.png[]
+image::images/mtln_0502.png[]
 
 In addition to a Bitcoin and Lightning node, Umbrel introduced the Umbrel App Store, where you can easily install additional services, such as:
 
@@ -461,7 +461,7 @@ By default, these services only allow you to check incoming connections to the I
 
 [[ln_port_check]]
 .Checking for incoming port 9735
-image::images/ln_port_check.png[]
+image::images/mtln_0503.png[]
 
 In <<ln_port_check>> you can see the result of checking port 9735 on a server running Lightning, using the +whatismyip.org+ port scanner tool. It shows that the server is accepting incoming connections to the Lightning port. If you see a result like this, you are all set!
 
@@ -921,7 +921,7 @@ A third way to re-balance channels is to purposefully create a _circular route_
 
 [[circular_rebalancing]]
 .Circular route re-balancing
-image::images/circular-rebalancing.png[]
+image::images/mtln_0504.png[]
 
 Circular re-balancing is supported by most Lightning node implementations and can be done on the command line or via one of the web management interfaces such as _Ride the Lightning (RTL)_ (see <<rtl>>).
 
@@ -978,7 +978,7 @@ https://github.com/Ride-The-Lightning/RTL
 Here is an example screenshot of RTL's web interface, as provided on the project repository:
 
 .Example RTL web interface
-image::images/RTL-LND-Dashboard.png[]
+image::images/mtln_0505.png[]
 
 ==== LNDMon
 

06_lightning_architecture.asciidoc

@@ -12,7 +12,7 @@ The architecture diagram shown in <<lightning_network_protocol_suite>> provides
 
 [[lightning_network_protocol_suite]]
 .The Lightning Network Protocol Suite
-image::images/lightning-network-protocol-suite.png[]
+image::images/mtln_0601.png[]
 
 The five layers of the Lightning Network, from the bottom up, are:
 

07_payment_channels.asciidoc

@@ -7,7 +7,7 @@ The messages exchanged by Alice and Bob's nodes are defined in https://github.co
 
 [[LN_protocol_channel_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN-protocol-channel-highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_0701.png["The Lightning Network Protocol Suite"]
 
 === A different way of using the Bitcoin system
 
@@ -21,7 +21,7 @@ The Lightning Network is simply a different and creative way of using Bitcoin. I
 
 [[on_off_chain]]
 .Lightning payment channel made of on-chain and off-chain transactions
-image::images/on_off_chain.png["Lightning payment channel made of on-chain and off-chain transactions"]
+image::images/mtln_0702.png["Lightning payment channel made of on-chain and off-chain transactions"]
 
 Lightning is Bitcoin. It's just a different way of using the Bitcoin system.
 
@@ -144,7 +144,7 @@ Channel establishment is achieved by the exchange of six messages between Alice
 
 [[funding_message_flow]]
 .The funding message flow
-image::images/funding_message_flow.png["The funding message flow"]
+image::images/mtln_0703.png["The funding message flow"]
 
 In "<<funding_message_flow>>" Alice and Bob's nodes are represented by the vertical lines "A" and "B" on either side of the diagram. A time-sequence diagram like this shows time flowing downwards, and messages flowing from one side to the other between the two communication peers. The lines are sloped down to represent the elapsed time needed to transmit each message and the direction of the message is shown by an arrow at the end of each line.
 
@@ -275,7 +275,7 @@ Alice's node can now construct a funding transaction, sending the amount agreed
 
 [[A_B_funding_Tx]]
 .Alice constructs the funding transaction
-image::images/A_B_funding_Tx.png["Alice constructs the funding transaction"]
+image::images/mtln_0704.png["Alice constructs the funding transaction"]
 
 Alice *does not broadcast* this transaction, because doing so would put her 140,000 satoshi at risk. Once spent to the 2-of-2 multisig, there is no way for Alice to recover her money without Bob's signature.
 
@@ -304,7 +304,7 @@ In practice, it is a bit more complicated as we will see in subsequent chapters,
 
 [[A_B_fund_refund_Tx]]
 .Alice also constructs the refund transaction
-image::images/A_B_fund_refund_Tx.png["Alice also constructs the refund transaction"]
+image::images/mtln_0705.png["Alice also constructs the refund transaction"]
 
 Later in this chapter we will see how more commitment transactions can be made to distribute the balance of the channel in different amounts.
 
@@ -421,7 +421,7 @@ In <<competing_commitments_1>> we see several commitment transactions:
 
 [[competing_commitments_1]]
 .Multiple commitment transactions
-image::images/competing_commitments_1.png[Multiple commitment transactions]
+image::images/mtln_0706.png[Multiple commitment transactions]
 
 The first commitment transaction shown in <<competing_commitments_1>> is the "refund transaction" that Alice constructed before funding the channel. In the diagram, this is "Commitment #0". After Alice pays Bob 70,000 satoshis, the new commitment transaction ("Commitment #1") has two outputs paying Alice and Bob their respective balance. We have included two subsequent commitment transactions (Commitment #2 and Commitment #3) which represent Alice paying Bob an additional 10,000 satoshis and then 20,000 satoshis respectively.
 
@@ -471,13 +471,13 @@ Alice and Bob hold slightly different commitment transactions. Let's look specif
 
 [[commitment_2]]
 .Commitment Transaction #2
-image::images/commitment_2.png[Commitment Transaction #2]
+image::images/mtln_0707.png[Commitment Transaction #2]
 
 Alice and Bob hold two different variations of this transaction, as shown in <<asymmetric_1>>:
 
 [[asymmetric_1]]
 .Asymmetric commitment transactions
-image::images/asymmetric_1.png[Asymmetric commitment transactions]
+image::images/mtln_0708.png[Asymmetric commitment transactions]
 
 By convention, within the Lightning protocol, we refer to the two channel partners as _self_ (also known as _local_) and _remote_, depending on which side we're looking at. The outputs that pay each channel partner are called _to_local_ and _to_remote_, respectively.
 
@@ -493,7 +493,7 @@ In the commitment transaction held by Alice, for example, the _to_local_ output
 
 [[asymmetric_delayed_1]]
 .Asymmetric and delayed commitment transactions
-image::images/asymmetric_delayed_1.png[Asymmetric and delayed commitment transactions]
+image::images/mtln_0709.png[Asymmetric and delayed commitment transactions]
 
 That means that if Alice closes the channel by broadcasting and confirming the commitment transaction she holds, she cannot spend her balance for 432 blocks, but Bob can claim his balance immediately. If Bob closes the channel using the commitment transaction he holds, he cannot spend his output for 432 blocks while Alice can immediately spend hers.
 
@@ -513,7 +513,7 @@ So, in our example, each side holds a commitment transaction that includes a rev
 
 [[asymmetric_delayed_revocable_1]]
 .Asymmetric, delayed and revocable commitments
-image::images/asymmetric_delayed_revocable_1.png["Asymmetric, delayed and revocable commitments"]
+image::images/mtln_0710.png["Asymmetric, delayed and revocable commitments"]
 
 [[commitment_transaction]]
 === The commitment transaction
@@ -573,7 +573,7 @@ In <<commitment_message_flow>> we see the Alice and Bob exchanging two pairs of
 
 [[commitment_message_flow]]
 .Commitment and revocation message flow
-image::images/commitment_message_flow.png[Commitment and revocation message flow]
+image::images/mtln_0711.png[Commitment and revocation message flow]
 
 ==== The commitment_signed message
 
@@ -649,7 +649,7 @@ Let's review our channel between Alice and Bob and show a specific example of a
 
 [[competing_commitments_2]]
 .Revoked and current commitments
-image::images/competing_commitments_2.png[Revoked and current commitments]
+image::images/mtln_0712.png[Revoked and current commitments]
 
 With each commitment, Alice has revoked the previous (older) commitment. The current state of the channel and the correct balance is represented by Commitment #3. All previous commitments have been revoked and Bob has the keys necessary to issue penalty transactions against them, in case Alice tries to broadcast one of them.
 
@@ -659,7 +659,7 @@ Alice decides to take a huge risk and broadcast the revoked Commitment #1, to st
 
 [[cheating_commitment]]
 .Alice cheating
-image::images/cheating_commitment.png[Alice cheating]
+image::images/mtln_0713.png[Alice cheating]
 
 As you can see, Alice's old commitment has two outputs, one paying herself 70,000 satoshis (to_local output) and one paying Bob 70,000 satoshis. Alice can't yet spend her 70,000 to_local output because it has a 432 block (3 day) timelock. She is now hoping that Bob doesn't notice for three days.
 
@@ -669,7 +669,7 @@ Bob's node will immediately broadcast a penalty transaction. Since this old comm
 
 [[penalty_transaction]]
 .Cheating and penalty
-image::images/penalty_transaction.png[Cheating and penalty]
+image::images/mtln_0714.png[Cheating and penalty]
 
 Bob's penalty transaction pays 140,000 satoshis to his own wallet, taking the entire channel capacity. Alice has not only failed to cheat, she has lost everything in the attempt!
 
@@ -687,7 +687,7 @@ The closing message flow is defined in https://github.com/lightningnetwork/light
 
 [[closing_message_flow]]
 .The channel close message flow
-image::images/closing_message_flow.png[The channel close message flow]
+image::images/mtln_0715.png[The channel close message flow]
 
 ==== The shutdown message
 
@@ -747,7 +747,7 @@ Alice broadcasts a transaction shown in <<closing_transaction>> below to close t
 
 [[closing_transaction]]
 .The cooperative close transaction
-image::images/closing_transaction.png[The cooperative close transaction]
+image::images/mtln_0716.png[The cooperative close transaction]
 
 As soon as this closing transaction is confirmed on the Bitcoin blockchain, the channel is closed. Now, Alice and Bob can spend their outputs as they please.
 

08_routing_htlcs.asciidoc

@@ -7,7 +7,7 @@ In this chapter we will finally unpack how payment channels can be connected to
 
 [[LN_protocol_routing_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN-protocol-routing-highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_0801.png["The Lightning Network Protocol Suite"]
 
 === Routing a payment
 
@@ -20,7 +20,7 @@ In <<dina_routing_diagram>> we see a possible network layout created by various
 
 [[dina_routing_diagram]]
 .Fans connected indirectly to Dina on the Lightning Network
-image::images/dina-routing-diagram.png["Fans connected indirectly to Dina on the Lightning Network"]
+image::images/mtln_0802.png["Fans connected indirectly to Dina on the Lightning Network"]
 
 The nodes along the path from the fan to Dina are intermediaries and called "routing nodes" in the context of routing a payment. There is no functional difference between the "routing nodes" and the nodes operated by Dina's fans. Any Lightning node is capable of routing payments across its payment channels.
 
@@ -58,7 +58,7 @@ As you can see in <<routing_network>>, Alice has an open channel with Bob, the c
 
 [[routing_network]]
 .A network of payment channels between Alice and Dina
-image::images/routing-network.png["A network of payment channels between Alice and Dina"]
+image::images/mtln_0803.png["A network of payment channels between Alice and Dina"]
 
 It's possible to trace a _path_ from Alice to Dina that uses Bob and Chan as intermediary routing nodes.
 Alice can then craft a _route_ from this outlined path, and use it to send a tip of a few thousand satoshis to Dina, with the payment being _forwarded_ by Bob and Chan.
@@ -74,7 +74,7 @@ Assume Alice wants to give 10 gold coins to Dina, but does not have direct acces
 
 [[alice_dina_routing_1]]
 .Alice wants to pay Dina 10 gold coins
-image::images/gold-coins-network1.png[]
+image::images/mtln_0804.png[]
 
 Alice can pay Bob to pay Chan to pay Dina, but how does she make sure that Bob or Chan don't run off with the coins after receiving them?
 In the physical world contracts could be used for safely carrying out a series of payments.
@@ -118,7 +118,7 @@ The difference of 1 gold coin is the fee that Bob will earn for helping out with
 
 [[alice_dina_routing_2]]
 .Alice pays Bob, Bob pays Chan, Chan pays Dina
-image::images/gold-coins-network2.png[]
+image::images/mtln_0805.png[]
 
 As there is still the issue of trust and the risk that either Alice or Bob won't honor the contract, all parties decide to use an escrow service.
 At the start of the exchange, Alice could "lock up" these 12 gold coins in escrow that will only be paid to Bob once he proves that he's paid 11 gold coins to Chan.
@@ -145,7 +145,7 @@ To facilitate Alice's payment, Dina will create the payment secret and the payme
 
 [[alice_dina_routing_3]]
 .Dina sends the hashed secret to Alice
-image::images/gold-coins-network3.png["Dina sends the hashed secret to Alice"]
+image::images/mtln_0806.png["Dina sends the hashed secret to Alice"]
 
 Alice doesn't know the secret but she can rewrite her contract to use the hash of the secret as a proof of payment:
 
@@ -294,7 +294,7 @@ Alice visits Dina's site, enters the amount of 50,000 satoshis in a form and in
 
 [[alice_dina_invoice_1]]
 .Alice requests an invoice from Dina's website
-image::images/alice-dina-invoice-1.png["Alice requests an invoice from Dina's website"]
+image::images/mtln_0807.png["Alice requests an invoice from Dina's website"]
 
 As we saw in previous examples, we assume that Alice does not have a direct payment channel to Dina. Instead, Alice has a channel to Bob, Bob has a channel to Chan and Chan has a channel to Dina. To pay Dina, Alice must find a path that connects her to Dina. We will discuss that step in more detail in <<path_finding>>. For now, let's assume that Alice is able to gather information about available channels and sees that there is a path from her to Dina, via Bob and Chan.
 
@@ -325,7 +325,7 @@ In <<alice_dina_invoice_2>> we see Alice getting a Lightning invoice from Dina.
 
 [[alice_dina_invoice_2]]
 .Alice gets a payment hash from Dina
-image::images/alice-dina-invoice-2.png["Alice gets a payment hash from Dina"]
+image::images/mtln_0808.png["Alice gets a payment hash from Dina"]
 
 In the Lightning Network, Dina's payment pre-image won't be a phrase like "Dina's secret", but a random number generated by Dina's node. Let's call that random number +R+.
 
@@ -422,7 +422,7 @@ Alice will now extend the HTLC across the network so that it reaches Dina.
 
 [[alice_dina_htlc_1]]
 .Propagating the HTLC across the network
-image::images/alice-dina-htlc-1.png["Propagating the HTLC across the network"]
+image::images/mtln_0809.png["Propagating the HTLC across the network"]
 
 In <<alice_dina_htlc_1>> we see the HTLC propagated across the network from Alice to Dina. Alice has given Bob an HTLC for 50,200 satoshi. Bob can now create an HTLC for 50,100 satoshi and give it to Chan.
 
@@ -440,7 +440,7 @@ Once Dina receives a 50,000 HTLC from Chan, she can now get paid. Dina could sim
 
 [[alice_dina_htlc_redeem_1]]
 .Dina settles Chan's HTLC off-chain
-image::images/alice-dina-htlc-redeem-1.png["Dina settles Chan's HTLC off-chain"]
+image::images/mtln_0810.png["Dina settles Chan's HTLC off-chain"]
 
 Notice Dina's channel balance goes from 50,000 satoshi to 100,000 satoshi. Chan's channel balance is reduced from 200,000 satoshi to 150,000 satoshi. The channel capacity hasn't changed, but 50,000 has moved from Chan's side of the channel to Dina's side of the channel.
 
@@ -448,7 +448,7 @@ Chan now has the secret and has paid Dina 50,000 satoshi. He can do this without
 
 [[alice_dina_htlc_redeem_2]]
 .Chan settles Bob's HTLC off-chain
-image::images/alice-dina-htlc-redeem-2.png["Chan settles Bob's HTLC off-chain"]
+image::images/mtln_0811.png["Chan settles Bob's HTLC off-chain"]
 
 Chan has paid Dina 50,000 satoshi, and received 50,100 satoshi from Bob. So Chan has 100 satoshi more in his channel balances, which he earned as a routing fee.
 
@@ -456,7 +456,7 @@ Bob now has the secret too. He can use it to spend Alice's HTLC on-chain. Or, he
 
 [[alice_dina_htlc_redeem_3]]
 .Bob settles Alice's HTLC off-chain
-image::images/alice-dina-htlc-redeem-3.png["Bob settles Alice's HTLC off-chain"]
+image::images/mtln_0812.png["Bob settles Alice's HTLC off-chain"]
 
 Bob has recieved 50,200 satoshi from Alice and paid 50,100 satoshi to Chan, so he has an extra 100 satoshi in his channel balances from routing fees.
 
@@ -466,7 +466,7 @@ The final channel balances reflect Alice's payment to Dina and the routing fees
 
 [[alice_dina_htlc_redeem_4]]
 .Channel balances after the payment
-image::images/alice-dina-htlc-redeem-4.png["Channel balances after the payment"]
+image::images/mtln_0813.png["Channel balances after the payment"]
 
 [[preventing_theft]]
 ==== Signature binding - preventing theft of HTLCs

09_channel_operation.asciidoc

@@ -7,7 +7,7 @@ Specifically, we will be discussing "Adding, Settling, Failing HTLCs" and the "C
 
 [[LN_protocol_channelops_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN_protocol_channelops_highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_0901.png["The Lightning Network Protocol Suite"]
 
 
 === Local (single channel) vs Routed (multiple channels)
@@ -22,7 +22,7 @@ We will revisit our example from <<routing>>, to demonstrate how the HTLCs from
 
 [[alice_dina_htlc_2]]
 .Alice pays Dina with an HTLC routed via Bob and Chan
-image::images/alice-dina-htlc-1.png["Alice pays Dina with an HTLC routed via Bob and Chan"]
+image::images/mtln_0809.png["Alice pays Dina with an HTLC routed via Bob and Chan"]
 
 We will focus on the payment channel between Alice and Bob and review the messages and transactions that they use to process this HTLC.
 
@@ -32,7 +32,7 @@ The message flow between Alice and Bob (and also between any pair of channel par
 
 [[HTLC_commitment_message_flow]]
 .The message flow for HTLC commitment between channel partners
-image::images/HTLC_commitment_message_flow_1.png["The message flow for HTLC commitment between channel partners"]
+image::images/mtln_0903.png["The message flow for HTLC commitment between channel partners"]
 
 We've already seen the +commitment_signed+ and +revoke_and_ack+ in <<payment_channels>>. Now we will see how HTLCs fit into the commitment scheme. The two new messages are +update_add_htlc+ which Alice uses to ask Bob to add an HTLC and +update_fulfill_htlc+ which Bob uses to redeem the HTLC once he has received the payment secret (Dina's secret).
 
@@ -44,7 +44,7 @@ As we saw in <<payment_channels>> this means that Alice and Bob have negotiated
 
 [[alice_bob_commitment_txs_1]]
 .Alice and Bob's initial commitment transactions
-image::images/alice_bob_commitment_txs_1.png["Alice and Bob's initial commitment transactions"]
+image::images/mtln_0904.png["Alice and Bob's initial commitment transactions"]
 
 ==== Adding an HTLC
 
@@ -128,7 +128,7 @@ Bob now has the necessary information to add this HTLC script as an additional o
 
 [[add_commitment_3b]]
 .Bob's new commitment with an HTLC output
-image::images/add_commitment_3b.png["Bob's new commitment with an HTLC output"]
+image::images/mtln_0905.png["Bob's new commitment with an HTLC output"]
 
 ==== Alice commits
 
@@ -159,7 +159,7 @@ Now, Bob has a new signed commitment transaction, as shown in <<signed_commitmen
 
 [[signed_commitment_3b]]
 .Bob has a new signed commitment
-image::images/signed_commitment_3b.png[Bob has a new signed commitment]
+image::images/mtln_0906.png[Bob has a new signed commitment]
 
 ==== Bob acknowledges new commitment and revokes old one
 
@@ -181,7 +181,7 @@ Bob has effectively moved the channel state forward, as shown in <<revoked_commi
 
 [[revoked_commitment_2b]]
 .Bob has revoked the old commitment
-image::images/revoked_commitment_2b.png[Bob has revoked the old commitment]
+image::images/mtln_0907.png[Bob has revoked the old commitment]
 
 Despite the fact that Bob has a new (signed) commitment transaction and an HTLC output inside he cannot consider his HTLC as being set up successfully.
 
@@ -193,7 +193,7 @@ Alice has constructed a mirror-image new commitment transaction containing the n
 
 [[add_commitment_3a]]
 .Alice's new commitment with an HTLC output
-image::images/add_commitment_3a.png["Alice's new commitment with an HTLC output"]
+image::images/mtln_0908.png["Alice's new commitment with an HTLC output"]
 
 As we described in <<payment_channels>>, Alice's commitment is the mirror-image of Bob's, as it contains the asymmetric, delayed, revocable construct for revocation and penalty enforcement of old commitments. Alice's 19,800 satoshi balance (after deducting the HTLC value), is delayed and revocable. Bob's 70,000 satoshi balance is immediately redeemable.
 
@@ -209,7 +209,7 @@ Now Alice has the signature for the new commitment transaction. The state of the
 
 [[signed_commitment_3a]]
 .Alice has a new *signed* commitment
-image::images/signed_commitment_3a.png[Alice has a new *signed* commitment]
+image::images/mtln_0909.png[Alice has a new *signed* commitment]
 
 Alice can now acknowledge the new commitment by revoking the old one. Alice sends the +revoke_and_ack+ message containing the necessary +per_commitment_point+ that will allow Bob to construct a revocation key and penalty transaction. Thus, Alice revokes her old commitment.
 
@@ -217,7 +217,7 @@ The channel state is shown in <<revoked_commitment_2a>> below:
 
 [[revoked_commitment_2a]]
 .Alice has revoked the old commitment
-image::images/revoked_commitment_2a.png[Alice has revoked the old commitment]
+image::images/mtln_0910.png[Alice has revoked the old commitment]
 
 === Multiple HTLCs
 
@@ -283,7 +283,7 @@ The message flow between Alice and Bob is shown in <<htlc_fulfillment_message_fl
 
 [[htlc_fulfillment_message_flow]]
 .The HTLC fulfillment message flow
-image::images/htlc_fulfillment_message_flow.png[The HTLC fulfillment message flow]
+image::images/mtln_0911.png[The HTLC fulfillment message flow]
 
 Both Alice and Bob can now remove the HTLC from the commitment transactions and update their channel balances.
 
@@ -291,19 +291,19 @@ They create new commitments (Commitment #4), as shown in <<htlc_fulfillment_comm
 
 [[htlc_fulfillment_commitments_added]]
 .The HTLC is removed and balances updated in new commitments
-image::images/htlc_fulfillment_commitments_added.png[The HTLC is removed and balances updated in new commitments]
+image::images/mtln_0912.png[The HTLC is removed and balances updated in new commitments]
 
 Next, they complete two rounds of commitment and revocation. First, Alice sends +commitment_signed+ to sign Bob's new commitment transaction. Bob responds with +revoke_and_ack+ to revoke his old commitment. Once Bob has moved the state of the channel forward, the commitments look like we see in <<htlc_fulfillment_commitments_bob_commit>> below:
 
 [[htlc_fulfillment_commitments_bob_commit]]
 .Alice signs Bob's new commitment and Bob revoked the old one
-image::images/htlc_fulfillment_commitments_bob_commit.png[Alice signs Bob's new commitment and Bob revoked the old one]
+image::images/mtln_0913.png[Alice signs Bob's new commitment and Bob revoked the old one]
 
 Finally, Bob signs Alice's commitment by sending Alice a +commitment_signed+ message. Then Alice acknowledges and revokes her old commitment by sending +revoke_and_ack+ to Bob. The end result is that both Alice and Bob have moved their channel state to Commitment #4, have removed the HTLC and have updated their balances. Their current channel state is represented by the commitment transactions that are shown in <<alice_bob_htlc_fulfilled>> below:
 
 [[alice_bob_htlc_fulfilled]]
 .Alice and Bob settle the HTLC and update balances
-image::images/alice_bob_htlc_fulfilled.png[Alice and Bob settle the HTLC and update balances]
+image::images/mtln_0914.png[Alice and Bob settle the HTLC and update balances]
 
 === Removing an HTLC due to error or expiry
 

10_onion_routing.asciidoc

@@ -7,7 +7,7 @@ In this chapter we are focusing on the "Source based Onion Routing (SPHINX)" par
 
 [[LN_protocol_onion_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN-protocol-onion-highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_1001.png["The Lightning Network Protocol Suite"]
 
 Onion routing describes a method of encrypted communication where a message sender builds successive _nested layers of encryption_ that are "peeled" off by each intermediary node, until the innermost layer is delivered to the intended recipient. The name "onion routing" describes this use of layered encryption that is peeled off one layer at a time, like the skin of an onion.
 
@@ -36,7 +36,7 @@ As a reminder, the path selected by Alice is shown in <<alice_dina_path>>, below
 
 [[alice_dina_path]]
 .Path: Alice to Bob to Chan to Dina
-image::images/alice_dina_path.png["Alice to Bob to Chan to Dina"]
+image::images/mtln_1002.png["Alice to Bob to Chan to Dina"]
 
 Let's see how Alice can use this path without revealing information to intermediaries Bob and Chan.
 
@@ -53,25 +53,25 @@ Alice starts by writing a secret letter to Dina.  She then seals the letter insi
 
 [[dina_envelope]]
 .Dina's secret letter, sealed in an envelope
-image::images/dina_envelope.png[Dina's secret letter, sealed in an envelope]
+image::images/mtln_1003.png[Dina's secret letter, sealed in an envelope]
 
 Dina's letter will be delivered to Dina by Chan, who is immediately before Dina in the "path". So, Alice puts Dina's envelope inside an envelope addressed to Chan (see <<chan_envelope>>). The only part that Chan can read is the destination (routing instructions): "To Dina". Sealing this inside an envelope addressed to Chan represents encrypting it with Chan's public key so that only Chan can read the envelope address. Chan still can't open Dina's envelope. All he sees is the instructions on the outside (the address).
 
 [[chan_envelope]]
 .Chan's envelope, containing Dina's sealed envelope
-image::images/chan_envelope.png[Chan's envelope, containing Dina's sealed envelope]
+image::images/mtln_1004.png[Chan's envelope, containing Dina's sealed envelope]
 
 Now, this letter will be delivered to Chan by Bob. So Alice puts it inside an envelope addressed to Bob (see <<bob_envelope>>). As before, the envelope represents a message encrypted to Bob that only Bob can read. Bob can only read the outside of Chan's envelope (the address), so he knows to send it to Chan.
 
 [[bob_envelope]]
 .Bob's envelope, containing Chan's sealed envelope
-image::images/bob_envelope.png[Bob's envelope, containing Chan's sealed envelope]
+image::images/mtln_1005.png[Bob's envelope, containing Chan's sealed envelope]
 
 Now, if we could look through the envelopes (with X-rays!) we would see the envelopes nested one inside the other, as shown in <<nested_envelopes>>, below:
 
 [[nested_envelopes]]
 .Nested envelopes
-image::images/nested_envelopes.png[Nested envelopes]
+image::images/mtln_1006.png[Nested envelopes]
 
 ==== Peeling the layers
 
@@ -79,7 +79,7 @@ Alice now has an envelope that says "To Bob" on the outside. It represents an en
 
 [[sending_nested_envelopes]]
 .Sending the envelopes
-image::images/sending_nested_envelopes.png[Sending the envelopes]
+image::images/mtln_1007.png[Sending the envelopes]
 
 As you can see, Bob receives the envelope from Alice. He knows it came from Alice, but doesn't know if Alice is the original sender or just someone forwarding envelopes. He opens it to find an envelope inside that says "To Chan". Since this is addressed to Chan, Bob can't open it. He doesn't know what's inside it and doesn't know if Chan is getting a letter or another envelope to forward. Bob doesn't know if Chan is the ultimate recipient or not. Bob forwards the envelope to Chan.
 
@@ -109,7 +109,7 @@ From <<routing>> we know that Alice will send a 50,000 satoshi payment to Dina v
 
 [[alice_dina_htlc_path]]
 .Payment path with HTLCs from Alice to Dina
-image::images/alice-dina-htlc.png[Payment path with HTLCs from Alice to Dina]
+image::images/mtln_1008.png[Payment path with HTLCs from Alice to Dina]
 
 As we will see in <<gossip>>, Alice is able to construct this path to Dina because Lightning nodes announce their channels to the entire Lightning Network using the _Lightning Gossip Protocol_. After the initial channel announcement, Bob and Chan each sent out an additional "channel update" message with their routing fee and timelock expectations for payment routing.
 
@@ -127,7 +127,7 @@ This information is used by Alice to identify the nodes, channels, fees, and tim
 
 [[alice_dina_path_detail]]
 .A detailed path constructed from gossiped channel and node information
-image::images/alice_dina_path_detail.png[A path constructed from gossiped channel and node information]
+image::images/mtln_1009.png[A path constructed from gossiped channel and node information]
 
 Alice already knows her own channel to Bob, and therefore doesn't need this info to construct the path. Note also that Alice didn't need a channel update from Dina, because she has the update from Chan for that last channel in the path.
 
@@ -171,7 +171,7 @@ Alice serializes it in TLV format as shown (simplified) <<dina_onion_payload>> b
 
 [[dina_onion_payload]]
 .Dina's payload is constructed by Alice
-image::images/dina_onion_payload.png[Dina's payload is constructed by Alice]
+image::images/mtln_1010.png[Dina's payload is constructed by Alice]
 
 ===== Hop payload for Chan
 
@@ -189,7 +189,7 @@ Alice serializes this payload in TLV format, as shown (simplified) in <<chan_oni
 
 [[chan_onion_payload]]
 .Chan's payload is constructed by Alice
-image::images/chan_onion_payload.png[Chan's payload is constructed by Alice]
+image::images/mtln_1011.png[Chan's payload is constructed by Alice]
 
 ===== Hop payload for Bob
 
@@ -214,7 +214,7 @@ Alice serializes this payload in TLV format, as shown (simplified) in <<bob_onio
 
 [[bob_onion_payload]]
 .Bob's payload is constructed by Alice
-image::images/bob_onion_payload.png[Bob's payload is constructed by Alice]
+image::images/mtln_1012.png[Bob's payload is constructed by Alice]
 
 ===== Finished hop payloads
 
@@ -222,7 +222,7 @@ Alice has now built the three hop payloads that will be wrapped in an onion. A s
 
 [[onion_hop_payloads]]
 .Hop payloads for all the hops
-image::images/onion_hop_payloads.png[Hop payloads for all the hops]
+image::images/mtln_1013.png[Hop payloads for all the hops]
 
 ==== Key generation
 
@@ -258,7 +258,7 @@ The relationship between the various keys and how they are generated is shown in
 
 [[onion_keygen]]
 .Onion Key Generation
-image::images/onion_keygen.png[Onion Key Generation]
+image::images/mtln_1014.png[Onion Key Generation]
 
 [[session_key]]
 ===== Alice's session key
@@ -389,7 +389,7 @@ The onion size is 1366 bytes structured as shown in <<onion_packet>> below:
 
 [[onion_packet]]
 .The onion packet
-image::images/onion_packet.png[]
+image::images/mtln_1015.png[]
 
 * 1 byte: A version byte
 * 33 bytes: A compressed public session key (<<session_key>>) from which the per-hop shared secret (<<shared_secret>>) can be generated without revealing Alice's identity
@@ -455,13 +455,13 @@ This is shown in <<onion_payload_filler>>:
 
 [[onion_payload_filler]]
 .Filling the onion payload with a random byte-stream
-image::images/onion_payload_filler.png[]
+image::images/mtln_1016.png[]
 
 Alice will now insert Dina's hop payload into the left side of the 1300 byte array, shifting the filler to the right and discarding anything that overflows. This is visualized in <<onion_add_dina>>:
 
 [[onion_add_dina]]
 .Adding Dina's hop payload
-image::images/onion_add_dina.png[]
+image::images/mtln_1017.png[]
 
 Another way to look at this is that Alice measures the length of Dina's hop payload, shifts the filler right to create an equal space in the left side of the onion payload and inserts Dina's payload in that space.
 
@@ -473,7 +473,7 @@ To do this, Alice generates a byte-stream using the +rho+ key (which Dina also k
 
 [[onion_obfuscate_dina]]
 .Obfuscating the onion payload
-image::images/onion_obfuscate_dina.png[]
+image::images/mtln_1018.png[]
 
 One of the properties of XOR is that if you do it twice you get back to the original data. As we will see in the "unwrapping" section, if Dina applies the same XOR operation with the byte-stream generated from +rho+, it will reveal the original onion payload.
 
@@ -488,7 +488,7 @@ Finally, Alice calculates a Hash-based Message Authentication Code (HMAC) for Di
 
 [[dina_hop_payload_hmac]]
 .Adding an HMAC integrity checksum to Dina's hop payload
-image::images/dina_hop_payload_hmac.png[]
+image::images/mtln_1019.png[]
 
 ===== Onion Routing Replay Protection & Detection
 
@@ -525,7 +525,7 @@ In <<chan_onion_wrapping>> we see the steps used to wrap Chan's hop payload in t
 
 [[chan_onion_wrapping]]
 .Wrapping the onion for Chan
-image::images/chan_onion_wrapping.png[]
+image::images/mtln_1020.png[]
 
 Alice starts with the 1300 onion payload created for Dina. The first 65 (or less) bytes of this are Dina's payload obfuscated and the rest is filler. Alice must be careful not to overwrite Dina's payload.
 
@@ -552,7 +552,7 @@ All right, by now this is easy!
 
 [[bob_onion_wrapping]]
 .Wrapping the onion for Bob
-image::images/bob_onion_wrapping.png[]
+image::images/mtln_1021.png[]
 
 Start with the onion payload (obfuscated) containing Chan's and Dina's hop payloads.
 
@@ -581,7 +581,7 @@ The result can be seen in <<onion_packet_2>> below:
 
 [[onion_packet_2]]
 .The onion packet
-image::images/onion_packet.png[]
+image::images/mtln_1015.png[]
 
 === Sending the onion
 
@@ -640,7 +640,7 @@ First, Bob *extends* the onion payload by 1300 bytes and filles them with +0+ va
 
 [[bob_extends]]
 .Bob extends the onion payload by 1300 (zero-filled) bytes
-image::images/bob_extends.png[Bob extends the onion payload by 1300 (zero-filled) bytes]
+image::images/mtln_1023.png[Bob extends the onion payload by 1300 (zero-filled) bytes]
 
 This empty space will become obfuscated and turn into "filler", by the same process that Bob uses to deobfuscate his own hop payload. Let's see how that works.
 
@@ -661,7 +661,7 @@ At the same time, applying the +rho+ byte stream to the 1300 zeroes that were ad
 
 [[bob_deobfuscates]]
 .Bob de-obfuscates the onion, obfuscates the filler
-image::images/bob_deobfuscates.png[Bob de-obfuscates the onion, obfuscates the filler]
+image::images/mtln_1024.png[Bob de-obfuscates the onion, obfuscates the filler]
 
 ==== Bob extracts the outer HMAC for the next hop
 
@@ -674,7 +674,7 @@ Now Bob can remove his hop payload from the front of the onion and left-shift th
 
 [[bob_removes_shifts]]
 .Bob removes the hop payload and left-shifts the rest, filling the gap with new filler
-image::images/bob_removes_shifts.png[Bob removes the hop payload and left-shifts the rest, filling the gap with new filler]
+image::images/mtln_1025.png[Bob removes the hop payload and left-shifts the rest, filling the gap with new filler]
 
 Now Bob can keep the first half 1300 bytes, and discard the extended (filler) 1300 bytes.
 

11_gossip_channel_graph.asciidoc

@@ -7,7 +7,7 @@ The gossip protocol and routing information section is highlighted by a double o
 
 [[LN_protocol_gossip_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN_protocol_gossip_highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_1101.png["The Lightning Network Protocol Suite"]
 
 As we've learned already, the Lightning Network uses a source-based onion routing protocol to deliver a payment from a sender to the recipient.
 To do this, the sending node must be able to construct a path of payment channels that connects it with the recipient, as we will see in <<path_finding>>.
@@ -262,7 +262,7 @@ A graph in computer science is a special data structure composed of vertices (ty
 
 [[directed_graph]]
 .A directed graph (Source: Wikimedia Commons)
-image::images/directed_graph.png["A directed graph"]
+image::images/mtln_1102.png["A directed graph"]
 
 In the context of the Lightning Network, our vertices are the Lightning nodes themselves, with our edges being the payment channels connecting these nodes. As we're concerned with _routing payments_, in our model a node with no edges (no payment channels) isn't considered to be a part of the graph as it isn't useful.
 

12_path_finding.asciidoc

@@ -13,7 +13,7 @@ These components are highlighted by a double outline in the protocol suite, show
 
 [[LN_protocol_pathfinding_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN_protocol_pathfinding_highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_1201.png["The Lightning Network Protocol Suite"]
 
 ==== Where is the BOLT?
 
@@ -29,7 +29,7 @@ But, as the Lightning Network has grown explosively, the path finding problem's
 
 [[lngraph]]
 .A visualization of part of the Lightning Network as of July 2021
-image::images/LNGraphJuly2021.png[]
+image::images/mtln_1202.png[]
 
 [NOTE]
 ====
@@ -194,13 +194,13 @@ Selena listens to node_announcement messages and discovers 4 other nodes (in add
 
 [[channel_graph_nodes]]
 .Node announcements
-image::images/channel_graph_nodes.png[]
+image::images/mtln_1203.png[]
 
 Selena also receives seven channel_announcement messages with the corresponding channel capacities, allowing her to construct a basic "map" of the network, shown in <<channel_graph_1>>, below:
 
 [[channel_graph_1]]
 .The channel graph
-image::images/channel_graph_1.png[]
+image::images/mtln_1204.png[]
 
 ===== Uncertainty in the channel graph
 
@@ -210,7 +210,7 @@ But wait: Selena does know *some* channel balances! She knows the balances of th
 
 [[channel_graph_2]]
 .Channel graph with known and unknown balances
-image::images/channel_graph_2.png[]
+image::images/mtln_1205.png[]
 
 While the "?" symbol seems ominous, a lack of certainty is not the same as complete ignorance. We can _quantify_ the uncertainty and _reduce_ it by updating the graph with the successful/failed HTLCs we attempt.
 
@@ -274,7 +274,7 @@ In <<channel_graph_3>> below we see how Selena can update the channel graph base
 
 [[channel_graph_3]]
 .Channel graph fees and other channel metrics
-image::images/channel_graph_3.png[]
+image::images/mtln_1206.png[]
 
 The fee and timelock information are very important not just as path selection metrics. As we saw in <<onion_routing>>, the sender needs to add up fees and timelocks (cltv_expiry_delta) at each hop to make the onion. The process of calculating fees happens from the recipient to the sender *backwards* along the path, because each intermediary hop expects an incoming HTLC with higher amount and expiry timelock than the outgoing HTLC they will send to the next hop. So, for example, if Bob wants 1000 satoshis in fees and 30 blocks of expiry timelock delta, to send a payment to Rashid, then that amount and expiry delta must be added to the HTLC _from Alice_.
 
@@ -321,7 +321,7 @@ Selena attempts the first path (S->A->B->R). She constructs the onion and sends
 
 [[path_1_fail]]
 .Path 1 attempt fails
-image::images/path_1_fail.png[]
+image::images/mtln_1207.png[]
 
 ===== Learning from failure
 
@@ -335,7 +335,7 @@ Fortunately, Selena receives an +update_fulfill_htlc+ message from Alice, indica
 
 [[path_4_success]]
 .Path 4 attempt succeeds
-image::images/path_4_success.png[]
+image::images/mtln_1208.png[]
 
 ===== Learning from success
 
@@ -396,7 +396,7 @@ In our example, Selena's node will attempt to split the 1m satoshi payment into
 
 [[mpp_paths]]
 .Sending two parts of a multi-path payment
-image::images/mpp_paths.png[]
+image::images/mtln_1209.png[]
 
 Because the S->X channel can now be utilized, and (luckily for Selena), the B->R channel has sufficient liquidity for 600k satoshis, the two parts are successful along paths that were previously not possible.
 
@@ -428,7 +428,7 @@ This multi-round example of sending a payment using MPP is shown in <<mpp_rounds
 
 [[mpp_rounds]]
 .Sending a payment in multiple rounds with MPP
-image::images/mpp_rounds.png[]
+image::images/mtln_1210.png[]
 
 In the end, Selena's node used three rounds of path finding to send the 1m satoshis in 30 parts.
 

13_wire_protocol.asciidoc

@@ -15,7 +15,7 @@ The messaging layer, which is detailed in this chapter, consists of _Message Fra
 
 [[LN_protocol_wire_message_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN_protocol_wire_message_highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_1301.png["The Lightning Network Protocol Suite"]
 
 === Wire Framing
 

14_encrypted_transport.asciidoc

@@ -19,7 +19,7 @@ The _Encrypted Transport_ component of the Lightning Network and its several com
 
 [[LN_protocol_encrypted_transport_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN_protocol_encrypted_transport_highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_1401.png["The Lightning Network Protocol Suite"]
 
 === Introduction
 
@@ -548,7 +548,7 @@ The structure of packets on the wire resembles the following:
 
 [[noise_encrypted_packet]]
 .Encrypted Packet Structure
-image::images/noise_encrypted_packet.png["Encrypted Packet Structure"]
+image::images/mtln_1402.png["Encrypted Packet Structure"]
 
 The prefixed message length is encoded as a 2-byte big-endian integer, for a
 total maximum packet length of `2 + 16 + 65535 + 16` = `65569` bytes.

15_payment_requests.asciidoc

@@ -11,7 +11,7 @@ _Payment Requests_, aka _Invoices_ are part of the Payment Layer and are show in
 
 [[LN_payment_request_highlight]]
 .The Lightning Network Protocol Suite
-image::images/LN_payment_request_highlight.png["The Lightning Network Protocol Suite"]
+image::images/mtln_1501.png["The Lightning Network Protocol Suite"]
 
 === Introduction
 

16_security_privacy_ln.asciidoc

@@ -126,7 +126,7 @@ Therefore, the anonymity set of a node in Lightning roughly equals its neighbors
 
 [[anonymity_set]]
 .The anonymity set of Alice and Bob constitutes their neighbors.
-image::images/anon-set.png["The anonymity set of Alice and Bob constitutes their neighbors"]
+image::images/mtln_1601.png["The anonymity set of Alice and Bob constitutes their neighbors"]
 
 Similar logic applies to payment receivers.
 Many users open only a handful of payment channels, therefore, limiting their anonymity sets.
@@ -478,7 +478,7 @@ Its effective diameter is also shrinking; that is, nodes become closer to each o
 
 [[temporal_ln]]
 .The steady growth of the LN in terms of nodes, channels and locked capacity.
-image::images/ln-over-time.png["The steady growth of the LN in terms of nodes, channels and locked capacity"]
+image::images/mtln_1602.png["The steady growth of the LN in terms of nodes, channels and locked capacity"]
 
 In social networks, triangle closing behavior is common.
 Specifically, in a graph where nodes represent people and friendships are represented as edges, it is somewhat expected that triangles will emerge in the graph.
@@ -503,7 +503,7 @@ However, we also note, that over time the central point dominance of the LN grad
 
 [[central_point_dominance_ln]]
 .Central point dominance of the LN, a random graph (ER) and a scale-free graph (BA) of equal size.
-image::images/central-point-dominance.png["Central point dominance of the LN, a random graph (ER) and a scale-free graph (BA) of equal size"]
+image::images/mtln_1603.png["Central point dominance of the LN, a random graph (ER) and a scale-free graph (BA) of equal size"]
 
 In general, our understanding of the dynamic nature of the LN channel graph is rather limited.
 It is fruitful to analyze how protocol changes like multi-part payments can affect the dynamics of the LN.

appendix-bitcoin-fundamentals-review.asciidoc

@@ -51,7 +51,7 @@ A hash function, also known as a _digest function_, is a function that takes arb
 
 [[SHA256]]
 .The SHA-256 cryptographic hash algorithm
-image::images/sha256.png["The SHA-256 cryptographic hash algorithm"]
+image::images/mtln_aa01.png["The SHA-256 cryptographic hash algorithm"]
 
 
 For example, if we use a command-line terminal to feed the text "Mastering the Lightning Network" into the SHA256 function it will produce a fingerprint as follows:
@@ -144,7 +144,7 @@ The fundamental building block of a bitcoin transaction is a transaction output.
 
 [[transaction_structure]]
 .A transaction transfers value from inputs to outputs
-image::images/tx1.png["transaction inputs and outputs"]
+image::images/mtln_aa02.png["transaction inputs and outputs"]
 
 Bitcoin full nodes track all available and spendable outputs, known as _unspent transaction outputs_, or UTXOs. The collection of all UTXOs is known as the UTXO set and currently numbers in the millions of UTXOs. The UTXO set grows as new UTXOs are created and shrinks when UTXOs are consumed. Every transaction represents a change (state transition) in the UTXO set, by consuming one or more UTXOs as _transaction inputs_ and creating one or more UTXOs as its _transaction outputs_.
 
@@ -152,7 +152,7 @@ For example, let's assume that a user Alice has a 100,000 satoshi UTXO that she
 
 [[alice_100ksat_to_bob]]
 .Alice pays 100,000 satoshis to Bob
-image::images/tx2.png["Alice pays 100,000 satoshis to Bob"]
+image::images/mtln_aa03.png["Alice pays 100,000 satoshis to Bob"]
 
 A transaction output can have an arbitrary (integer) value denominated in satoshis. Just as dollars can be divided down to two decimal places as cents, bitcoin can be divided down to eight decimal places as satoshis. Although an output can have any arbitrary value, once created it is indivisible. This is an important characteristic of outputs that needs to be emphasized: outputs are discrete and indivisible units of value, denominated in integer satoshis. An unspent output can only be consumed in its entirety by a transaction.
 
@@ -160,7 +160,7 @@ So what if Alice wants to pay Bob 50,000 satoshi, but only has an indivisible 10
 
 [[alice_50ksat_to_bob_change]]
 .Alice pays 50k sat to Bob and 50k sat to herself as change
-image::images/tx3.png["Alice pays 50,000 satoshis to Bob and 50,000 satoshis to herself as change"]
+image::images/mtln_aa04.png["Alice pays 50,000 satoshis to Bob and 50,000 satoshis to herself as change"]
 
 [TIP]
 ====
@@ -171,7 +171,7 @@ Similarly, if Alice wants to pay Bob 85,000 satoshi but has two 50,000 satoshi U
 
 [[tx_twoin_twoout]]
 .Alice uses two 50k inputs to pay 85k sat to Bob and 50k sat to herself as change
-image::images/tx4.png["Alice uses two 50k inputs to pay 85k sat to Bob and 50k sat to herself as change"]
+image::images/mtln_aa05.png["Alice uses two 50k inputs to pay 85k sat to Bob and 50k sat to herself as change"]
 
 The illustrations and examples above show how a Bitcoin transaction combines (spends) one or more inputs and creates one or more outputs. A transaction can have hundreds or even thousands of inputs and outputs.
 
@@ -186,7 +186,7 @@ Every output can be spent, as an input in a subsequent transaction. So for examp
 
 [[tx_chain]]
 .Alice pays Bob who pays Chan who pays Dina
-image::images/tx5.png["Alice pays Bob who pays Chan who pays Dina"]
+image::images/mtln_aa06.png["Alice pays Bob who pays Chan who pays Dina"]
 
 An output is considered "spent" if it is referenced as an input in another transaction that is recorded on the blockchain. An output is considered "unspent" (and available for spending) if no recorded transaction references it.
 
@@ -232,7 +232,7 @@ Here's the chain of transactions from Alice to Bob to Chan to Dina, this time wi
 
 [[tx_chain_vout]]
 .Transaction inputs refer to outpoints forming a chain
-image::images/tx6.png["Transaction inputs refer to outpoints forming a chain"]
+image::images/mtln_aa07.png["Transaction inputs refer to outpoints forming a chain"]
 
 The input in Bob's transaction references Alice's transaction (by TxID) and the 0 indexed output.
 
@@ -260,7 +260,7 @@ In the diagram below, we see how this script is executed (from left to right):
 
 [[figa08]]
 .Caption here
-image::images/bitcoin-script-example-1.png["Example of Bitcoin Script execution"]
+image::images/mtln_aa08.png["Example of Bitcoin Script execution"]
 
 ==== Locking and Unlocking Scripts
 
@@ -298,7 +298,7 @@ In <<locking_unlocking_chain>> you can see the locking script in Alice's transac
 
 [[locking_unlocking_chain]]
 .A transaction chain showing the locking script (output) and unlocking script (input)
-image::images/locking-unlocking-chain.png["A transaction chain showing the locking script (output) and unlocking script (input)"]
+image::images/mtln_aa09.png["A transaction chain showing the locking script (output) and unlocking script (input)"]
 
 To validate Bob's transaction, a Bitcoin node would do the following: