Skip to content

Commit

Permalink
renaming draft figs
Browse files Browse the repository at this point in the history
  • Loading branch information
@nadamsoreilly
nadamsoreilly committed Sep 23, 2021
1 parent bb687f2 commit ad813f1
Show file tree
Hide file tree
Showing 179 changed files with 117 additions and 117 deletions.
30 changes: 15 additions & 15 deletions 02_getting_started.asciidoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -267,15 +267,15 @@ 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.

To see a Bitcoin address on the Eclair wallet, Alice must swipe to the left column titled "YOUR BITCOIN ADDRESS" (see <<eclair-receive>>), where she will see a square barcode (called a _QR code_) and a string of letters and numbers below.

[[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.

Expand All @@ -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.

Expand All @@ -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.

Expand Down Expand Up @@ -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:

Expand All @@ -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
Expand All @@ -377,21 +377,21 @@ 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.

Alice now has to wait again (see <<eclair-channel-waiting>>) for the transaction to be recorded on the Bitcoin blockchain. As with the initial Bitcoin transaction that she used to acquire her bitcoin, she has to wait for six or more confirmations (approximately one hour).

[[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]
====
Expand All @@ -418,21 +418,21 @@ 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

Alice selects the "Cafe Latte" option from the screen and is presented with a _Lightning Invoice_ (also known as a "payment request") as shown in <<bob-cafe-invoice>>

[[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]
====
Expand All @@ -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.

Expand Down
10 changes: 5 additions & 5 deletions 05_node_operations.asciidoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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!

Expand Down Expand Up @@ -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>>).

Expand Down Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion 06_lightning_architecture.asciidoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down
32 changes: 16 additions & 16 deletions 07_payment_channels.asciidoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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.

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand All @@ -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.

Expand All @@ -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
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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.

Expand All @@ -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.

Expand All @@ -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!

Expand All @@ -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

Expand Down Expand Up @@ -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.

Expand Down
Loading

0 comments on commit ad813f1

Please sign in to comment.