((("Lightning Network (generally)","mechanism of operation", id="ix_03_how_ln_works-asciidoc0", range="startofrange")))Now that we've followed Alice as she set up a Lightning Wallet and purchased a coffee from Bob, we'll look under the hood and unpack the different components of the Lightning Network involved in that process.
((("Lightning Network (generally)","mechanism of operation", id="ix_03_how_ln_works-asciidoc0", range="startofrange")))Now that we've followed Alice as she set up a Lightning wallet and purchased a coffee from Bob, we'll look under the hood and unpack the different components of the Lightning Network involved in that process.
This chapter will give a high-level overview and will not delve into all the technical details.
The goal is rather to help you to become aware of the most important concepts and building blocks of the Lightning Network.
@ -22,7 +22,7 @@ If you need a refresher on the fundamentals of Bitcoin, you can find a summary r
* Timelocks
* Complex scripts
We'll start with a onesentence definition of what the Lightning Network is and break it down in the remainder of this chapter.
We'll start with a one-sentence definition of what the Lightning Network is and break it down in the remainder of this chapter.
The Lightning Network is a peer-to-peer network of _payment channels_ implemented as smart contracts on the _Bitcoin blockchain_ as well as a communication protocol that defines how participants set up and execute these smart contracts.
@ -37,9 +37,7 @@ A payment channel is a _financial relationship_ between two nodes on the Lightni
The cryptographic protocol is established by the funding of a 2-of-2 _multisignature address_ that requires the two channel partners to cooperate and prevents either channel partner from spending the funds unilaterally.
To summarize:
A payment channel is a financial relationship between nodes, allocating funds from a multisignature address, through a strictly defined cryptographic protocol.
To summarize: a payment channel is a financial relationship between nodes, allocating funds from a multisignature address through a strictly defined cryptographic protocol.
=== Payment Channel Basics
@ -63,17 +61,17 @@ The ability to hold a partially signed transaction, offline and unpublished, wit
=== Routing Payments Across Channels
((("Lightning Network (generally)","routing payments across channels")))((("payment channel","routing payments across channels")))Once several participants have channels from one party to another, payments can also be "forwarded" from payment channel to payment channel, by setting up a _path_ across the network connecting several payment channels together.
((("Lightning Network (generally)","routing payments across channels")))((("payment channel","routing payments across channels")))Once several participants have channels from one party to another, payments can also be "forwarded" from payment channel to payment channel by setting up a _path_ across the network connecting several payment channels together.
For example, Alice can send money to Charlie if Alice has a channel with Bob and Bob has a channel with Charlie.
By the design of the Lightning Network, it is possible to extend the smart contracts which operate the channel so that Bob has no way of stealing the funds that are being forwarded through his channel.
By the design of the Lightning Network, it is possible to extend the smart contracts that operate the channel so that Bob has no way of stealing the funds that are being forwarded through his channel.
In the same way that the smart contract protects the channel partners so they don't need to trust each other, the entire network protects the participants so that they can forward payments without trusting any of the other participants.
Because the channels are constructed from multisignature addresses and the balance update transactions are pre-signed Bitcoin transactions, all the trust that is needed to operate the Lightning Network comes from the trust in the decentralized Bitcoin network!
The aforementioned innovations are certainly the major breakthrough that allowed the creation of the Lightning Network.
The aforementioned innovations are certainly the major breakthroughs that allowed the creation of the Lightning Network.
However, the Lightning Network is so much more than the cryptographic protocols on top of the Bitcoin Script language.
It is a comprehensive communication protocol that allows peers to exchange Lightning messages to achieve the transfer of bitcoin.
The communication protocol defines how Lightning messages are encrypted and exchanged.
@ -103,11 +101,11 @@ As we saw in the previous chapter, Alice used her wallet software to create a pa
* If the channel is open, making a payment does not require the confirmation of Bitcoin blocks. In fact—as long as you and your channel partner follow the protocol—it does not require any interaction with the Bitcoin network or anyone else other than your channel partner.
* The cryptographic protocol is constructed such that there is little to no trust needed between you and your channel partner. If your partner becomes unresponsive or tries to cheat you, you can ask the Bitcoin system to act as a "court" resolving the smart contract you and your partner have previously agreed upon.
* The cryptographic protocol is constructed such that there is little to no trust needed between you and your channel partner. If your partner becomes unresponsive or tries to cheat you, you can ask the Bitcoin system to act as a "court," resolving the smart contract you and your partner have previously agreed upon.
* Payments made in a payment channel are only known to you and your partner. In that sense, you gain privacy compared to Bitcoin, where every transaction is public. Only the final balance, which is the aggregate of all payments in that channel, will become visible on the Bitcoin blockchain.
Bitcoin was about five years old when talented developers first figured out how bi-directional, indefinite lifetime, routable payment channels could be constructed, and by now there are at least three different methods known.
Bitcoin was about five years old when talented developers first figured out how bidirectional, indefinite lifetime, routable payment channels could be constructed, and by now there are at least three different known methods.
This chapter will focus on the channel construction method first described in the https://lightning.network/lightning-network-paper.pdf[Lightning Network whitepaper] by Joseph Poon and Thaddeus Dryja in 2015. ((("Poon-Dryja channels")))These are known as _Poon-Dryja_ channels, and are the channel construction method currently used in the Lightning Network.
The other two proposed methods are _Duplex Micropayment_ channels, introduced by Christian Decker around the same time as the Poon-Dryja channels and _eltoo_ channels, introduced in https://blockstream.com/eltoo.pdf["eltoo: A Simple Layer2 Protocol for Bitcoin"] by Christian Decker, Rusty Russel, and (coauthor of this book) Olaoluwa Osuntokun in 2018.
@ -124,7 +122,7 @@ Multisignature scripts and addresses are explained in more detail in <<multisig>
==== Funding Transaction
((("funding transaction")))((("payment channel","funding transaction")))The fundamental building block of a payment channel is a 2-of-2 multisignature address. One of the two channel partners will fund the payment channel by sending bitcoin to the multisignature address. This transaction is called the _funding transaction_, and is recorded on the Bitcoin blockchain.footnote:[While the original Lightning whitepaper described channels funded by both channel partners, the current specification, as of 2020, assumes that just one partner commits funds to the channel. As of May 2021 dual-funded lightning channels are experimental in the c-lightning LN implementation.]
((("funding transaction")))((("payment channel","funding transaction")))The fundamental building block of a payment channel is a 2-of-2 multisignature address. One of the two channel partners will fund the payment channel by sending bitcoin to the multisignature address. This transaction is called the _funding transaction_, and is recorded on the Bitcoin blockchain.footnote:[While the original Lightning whitepaper described channels funded by both channel partners, the current specification, as of 2020, assumes that just one partner commits funds to the channel. As of May 2021, dual-funded lightning channels are experimental in the c-lightning LN implementation.]
Even though the funding transaction is public, it is not obvious that it is a Lightning payment channel until it is closed unless the channel is publicly advertised. Channels are typically publicly announced by routing nodes that wish to forward payments. However, nonadvertised channels also exist, and are usually created by mobile nodes that don't actively participate in routing. Furthermore, channel payments are still not visible to anyone other than the channel partners, nor is the distribution of the channel balance between them.
@ -133,7 +131,7 @@ Even though the funding transaction is public, it is not obvious that it is a Li
[NOTE]
====
The funds sent to the multisignature address in the funding transaction are sometimes referred to as "locked in a Lightning channel." However, in practice, funds in a Lightning channel are not "locked" but rather "unleashed." Lightning channel funds are more liquid than funds on the Bitcoin blockchain as they can be spent faster, cheaper and more privately. There are some disadvantages to moving funds into the Lightning Network (such as the need to keep them in a "hot" wallet), but the idea of "locking funds" in Lightning is misleading.
The funds sent to the multisignature address in the funding transaction are sometimes referred to as "locked in a Lightning channel." However, in practice, funds in a Lightning channel are not "locked" but rather "unleashed." Lightning channel funds are more liquid than funds on the Bitcoin blockchain, as they can be spent faster, cheaper, and more privately. There are some disadvantages to moving funds into the Lightning Network (such as the need to keep them in a "hot" wallet), but the idea of "locking funds" in Lightning is misleading.
====
===== Example of a poor channel opening procedure
@ -154,9 +152,9 @@ The "refund" transaction that protects Alice is the first of a class of transact
By holding a signed commitment transaction, each channel partner can get their funds even without the cooperation of the other channel partner. This protects them against the other channel partner's disappearance, refusal to cooperate, or attempt to cheat by violating the payment channel protocol.
The commitment transaction that Alice prepared in the previous example was a refund of her initial payment to the multisignature address. More generally however, a commitment transaction splits the funds of the payment channel, paying the two channel partners according to the distribution (balance) they each hold. At first, Alice holds all the balance, so it is a simple refund. But as funds flow from Alice to Bob, they will exchange signatures for new commitment transactions that represent the new balance distribution, with some part of the funds paid to Alice and some paid to Bob.
The commitment transaction that Alice prepared in the previous example was a refund of her initial payment to the multisignature address. More generally, however, a commitment transaction splits the funds of the payment channel, paying the two channel partners according to the distribution (balance) they each hold. At first, Alice holds all the balance, so it is a simple refund. But as funds flow from Alice to Bob, they will exchange signatures for new commitment transactions that represent the new balance distribution, with some part of the funds paid to Alice and some paid to Bob.
Let us assume Alice opens a channel with a capacity of 100,000 satoshi with Bob.
Let's assume that Alice opens a channel with a capacity of 100,000 satoshi with Bob.
Initially, Alice owns 100,000 satoshi, the entirety of the funds in the channel. Here's how the payment channel protocol works:
. Alice creates a new private/public key pair and informs Bob that she wishes to open a channel via the `open_channel` message (a message in the LN protocol).
@ -186,11 +184,11 @@ Now that we understand commitment transactions, let's look at some of the more s
In the channel protocol we have seen so far, nothing stops Alice from publishing a previous commitment transaction. A cheating Alice could publish the commitment transaction that grants her 100k satoshi.
Since that commitment transaction was signed by Bob, he can't prevent Alice from transmitting it.
Some mechanism is needed to prevent Alice from publishing an old commitment transaction. Let us now find out how this can be achieved and how it enables the Lightning Network to operate without requiring any trust between Alice and Bob.
Some mechanism is needed to prevent Alice from publishing an old commitment transaction. Let's now find out how this can be achieved and how it enables the Lightning Network to operate without requiring any trust between Alice and Bob.
Because Bitcoin is censorship resistant, no one can prevent someone from publishing an old commitment transaction. To prevent this form of cheating, commitment transactions are constructed so that if an old one is transmitted, the cheater can be punished. By making the penalty large enough, we create a strong incentive against cheating, and this makes the system secure.
The way the penalty works is by giving the cheated party an opportunity to claim the balance of the cheater. So if someone attempts to cheat by broadcasting an old commitment transaction, in which they are paid a higher balance than they are due, the other party can punish them by taking *both* their own balance and the balance of the cheater. The cheater loses everything.
The way the penalty works is by giving the cheated party an opportunity to claim the balance of the cheater. So if someone attempts to cheat by broadcasting an old commitment transaction, in which they are paid a higher balance than they are due, the other party can punish them by taking _both_ their own balance and the balance of the cheater. The cheater loses everything.
[TIP]
====
@ -211,7 +209,7 @@ With a strong penalty mechanism, Alice is not tempted to cheat by publishing an
[NOTE]
====
In _Mastering Bitcoin_ (2nd edition, O'Reilly), Andreas Antonopoulos (the coauthor of this book) states it as follows:
In Chapter 12 of _Mastering Bitcoin_, Andreas Antonopoulos (the coauthor of this book) states it as follows:
"A key characteristic of Bitcoin is that once a transaction is valid, it remains valid and does not expire. The only way to cancel a transaction is by double-spending its inputs with another transaction before it is mined."
====
@ -229,7 +227,7 @@ In simple terms, Alice signs Bob's new commitment transaction only if Bob offers
With each new commitment, they exchange the necessary "punishment" secret that allows them to effectively _revoke_ the prior commitment transaction by making it unprofitable to transmit. Essentially, they destroy the ability to use old commitments as they sign the new ones. What we mean is that while it is still technically possible to use old commitments, the penalty mechanism makes it economically irrational to do so.
The timelock is set to a number of blocks up to 2,016 (approximately two weeks). If either channel partner publishes a commitment transaction without cooperating with the other partner, they will have to wait for that number of blocks (e.g., 2 weeks) to claim their balance. The other channel partner can claim their own balance at any time. Furthermore, if the commitment they published was previously revoked, the channel partner can _also_ immediately claim the cheating party's balance, bypassing the timelock and punishing the cheater.
The timelock is set to a number of blocks up to 2,016 (approximately two weeks). If either channel partner publishes a commitment transaction without cooperating with the other partner, they will have to wait for that number of blocks (e.g., two weeks) to claim their balance. The other channel partner can claim their own balance at any time. Furthermore, if the commitment they published was previously revoked, the channel partner can _also_ immediately claim the cheating party's balance, bypassing the timelock and punishing the cheater.
The timelock is adjustable and can be negotiated between channel partners. Usually, it is longer for larger capacity channels, and shorter for smaller channels, to align the incentives with the value of the funds.
@ -243,7 +241,7 @@ Technologies such as watchtower services or changing the channel construction pr
====
Alice can close the channel at any time if Bob does not respond, claiming her fair share of the balance.
After publishing the _last_ commitment transaction on-chain, Alice has to wait for the timelock to expire before she can spend her funds from the commitment transaction. As we will see later, there is an easier way to close a channel without waiting, as long as Alice and Bob are both online and cooperate to close the channel with the correct balance allocation. But the commitment transactions stored by each channel partner act as a failsafe, ensuring they do not lose funds if there is a problem with their channel partner.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc2")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc1")))
After publishing the _last_ commitment transaction on-chain, Alice has to wait for the timelock to expire before she can spend her funds from the commitment transaction. As we will see later, there is an easier way to close a channel without waiting, as long as Alice and Bob are both online and cooperate to close the channel with the correct balance allocation. But the commitment transactions stored by each channel partner act as a fail-safe, ensuring they do not lose funds if there is a problem with their channel partner.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc2")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc1")))
==== Announcing the Channel
@ -261,7 +259,7 @@ You may hear the term "private channel" used to describe an unannounced channel.
Unannounced channels are still used to route payments but only by the nodes that are aware of their existence, or given "routing hints" about a path that includes an unannounced channel.
When a channel and its capacity is publicly announced using the gossip protocol, the announcement can also include information about the channel (metadata), such as its routing fees and timelock duration.
When a channel and its capacity are publicly announced using the gossip protocol, the announcement can also include information about the channel (metadata), such as its routing fees and timelock duration.
When new nodes join the Lightning Network, they collect the channel announcements propagated via the gossip protocol from their peers, building an internal map of the Lightning Network. This map can then be used to find paths for payments, connecting channels together end-to-end.
@ -272,7 +270,7 @@ Opening and closing channels requires an on-chain transaction, which will incur
So it's best to keep channels open as long as possible.
You can keep using your channel to make and forward payments, as long as you have sufficient capacity on your end of the channel.
But even if you send all the balance to the other end of the channel, you can then use the channel to receive payments from your channel partner.
This concept of using a channel in one direction and then using it in the opposite direction is called "rebalancing" and we will examine it in more detail in another chapter.
This concept of using a channel in one direction and then using it in the opposite direction is called "rebalancing," and we will examine it in more detail in another chapter.
By rebalancing a channel, it can be kept open almost indefinitely and used for an essentially unlimited number of payments.
@ -289,21 +287,21 @@ There are three ways to close a payment channel:
* Force close (the bad way)
* Protocol breach (the ugly way)
Each of these methods is useful for different circumstances, which we will explore in the next section of this chapter.
For example, if your channel partner is offline you will not be able to follow "the good way" because a mutual close cannot be done without a cooperating partner.
Each of these methods is useful for different circumstances, which we will explore in the next sections of this chapter.
For example, if your channel partner is offline, you will not be able to follow "the good way" because a mutual close cannot be done without a cooperating partner.
Usually, your LN software will automatically select the best closing mechanism available under the circumstances.
===== Mutual close (the good way)
((("closing the channel","mutual close")))((("mutual close")))Mutual close is when both channel partners agree to close a channel and is the preferred method of channel closure.
((("closing the channel","mutual close")))((("mutual close")))Mutual close is when both channel partners agree to close a channel, and is the preferred method of channel closure.
When you decide that you want to close a channel, your LN node will inform your channel partner about your intention.
Now both your node and the channel partner's node work together to close the channel.
No new routing attempts will be accepted from either channel partner and any ongoing routing attempts will be settled or removed after they time out.
No new routing attempts will be accepted from either channel partner, and any ongoing routing attempts will be settled or removed after they time out.
Finalizing the routing attempts takes time, so a mutual close can also take some time to complete.
((("closing transactions")))Once there are no pending routing attempts, the nodes cooperate to prepare a _closing transaction_.
This transaction is similar to the commitment transaction; it encodes the last balance of the channel, but the outputs are NOT encumbered with a timelock.
This transaction is similar to the commitment transaction: it encodes the last balance of the channel, but the outputs are NOT encumbered with a timelock.
The on-chain transaction fees for the closing transaction are paid by the channel partner who opened the channel and not by the one who initiated the closing procedure.
Using the on-chain fee estimator, the channel partners agree on the appropriate fee and both sign the closing transaction.
@ -316,7 +314,7 @@ Despite the waiting time, a mutual close is typically faster than a force close.
((("closing the channel","force close")))((("force close")))A force close is when one channel partner attempts to close a channel without the other channel partner's consent.
This usually happens in the case that one of the channel partners is unreachable, so a mutual close is not possible.
This usually happens when one of the channel partners is unreachable, so a mutual close is not possible.
In this case, you would initiate a force close to unilaterally close the channel and "free" the funds.
To initiate a force close, you can simply publish the last commitment transaction your node has.
@ -330,8 +328,8 @@ In the case that you broadcasted an earlier commitment transaction, the timelock
When publishing a commitment transaction during a force close, the on-chain fees will be higher than a mutual close for several reasons:
. When the commitment transaction was negotiated, the channel partners didn't know how much the on-chain fees would be at the future time the transaction would be broadcast. Since the fees cannot be changed without changing the outputs of the commitment transaction (which needs both signatures) and since the force close happens when a channel partner is not available to sign, the protocol developers decided to be very generous with the fee rate included in the commitment transactions. It can be up to five times higher than the fee estimators suggest at the time the commitment transaction is negotiated.
. The commitment transaction includes additional outputs for any pending routing attempts hash time-locked contracts [HTLCs], which makes the commitment transaction larger (in terms of bytes) than a mutual close transaction. Larger transactions incur more fees.
. When the commitment transaction was negotiated, the channel partners didn't know how much the on-chain fees would be at the future time the transaction would be broadcast. Since the fees cannot be changed without changing the outputs of the commitment transaction (which needs both signatures), and since the force close happens when a channel partner is not available to sign, the protocol developers decided to be very generous with the fee rate included in the commitment transactions. It can be up to five times higher than the fee estimators suggest at the time the commitment transaction is negotiated.
. The commitment transaction includes additional outputs for any pending routing attempts hash time-locked contracts (HTLCs), which makes the commitment transaction larger (in terms of bytes) than a mutual close transaction. Larger transactions incur more fees.
. Any pending routing attempts will have to be resolved on-chain, causing additional on-chain transactions.
[NOTE]
@ -370,10 +368,10 @@ If there is any balance allocated to you, you will have to pay on-chain fees to
As with a force close, all pending routing attempts will also have to be resolved in the commitment transaction.
A protocol breach can be executed faster than a mutual close, because you do not wait to negotiate a close with your partner, and faster than a force close because you do not need to wait for your timelock to expire.
A protocol breach can be executed faster than a mutual close because you do not wait to negotiate a close with your partner, and faster than a force close because you do not need to wait for your timelock to expire.
Game theory predicts that cheating is not an appealing strategy because it is easy to detect a cheater, and the cheater risks losing _all_ of their funds while only standing to gain what they had in an earlier state.
Furthermore, as the Lightning Network matures, and watchtowers become widely available, cheaters will be able to be detected by a third party even if the cheated channel partner is offline.
Furthermore, as the Lightning Network matures, and watchtowers become widely available, cheaters will be detectable by a third party even if the cheated channel partner is offline.
Hence, we do not recommend cheating.
We do, however, recommend that anyone catching a cheater punish them by taking their funds.
@ -388,7 +386,7 @@ This software is one of three types:
Remember that the commitment transaction has a timeout period specified in a given number of blocks, up to a maximum of 2,016 blocks.
As long as you run your Lightning node once before the timeout period is reached, it will catch all cheating attempts.
It is not advisable to take this kind of risk; it is important to keep a well maintained node running continuously (See <<continuous_operation>>).(((range="endofrange", startref="ix_03_how_ln_works-asciidoc4")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc3")))
It is not advisable to take this kind of risk; it is important to keep a well-maintained node running continuously (see <<continuous_operation>>).(((range="endofrange", startref="ix_03_how_ln_works-asciidoc4")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc3")))
=== Invoices
@ -396,41 +394,41 @@ It is not advisable to take this kind of risk; it is important to keep a well ma
[NOTE]
====
There is a way to send an unsolicited payment without an invoice, using a work-around in the protocol called +keysend+. We will examine this in <<keysend>>.
There is a way to send an unsolicited payment without an invoice, using a workaround in the protocol called +keysend+. We will examine this in <<keysend>>.
====
An invoice is a simple payment instruction containing information such as a unique payment identifier (called a payment hash), a recipient, an amount, and an optional text description.
((("payment hash")))The most important part of the invoice is the payment hash, which allows the payment to travel across multiple channels in an _atomic_ way. Atomic, in computer science, means any action or state change that is either completed successfully or not at all—there is no possibility of an intermediate state or partial action. In the Lightning Network that means that the payment either travels the whole path or fails completely. It cannot be partially completed such that an intermediate node on the path can receive the payment and keep it.
((("payment hash")))The most important part of the invoice is the payment hash, which allows the payment to travel across multiple channels in an _atomic_ way. Atomic, in computer science, means any action or state change that is either completed successfully or not at all—there is no possibility of an intermediate state or partial action. In the Lightning Network, that means that the payment either travels the whole path or fails completely. It cannot be partially completed such that an intermediate node on the path can receive the payment and keep it.
There is no such thing as a "partial payment" or "partly successful payment."
Invoices are not communicated over the Lightning Network. Instead, they are communicated "out of band," using any other communication mechanism. This is similar to how Bitcoin addresses are communicated to senders outside the Bitcoin network: as a QR code, over email, or a text message. For example, Bob can present a Lightning invoice to Alice as a QR code, via email, or through any other message channel.
Invoices are usually encoded either as a long __bech32__-encoded string or as a QR code, to be scanned by a smartphone Lightning wallet. The invoice contains the amount of bitcoin that is requested and a signature of the recipient. The sender uses the signature to extract the public key (also known as the node ID) of the recipient so that the sender knows where to send the payment.
((("Bitcoin–Lightning Network comparisons","addresses versus invoices")))Did you notice how this contrasts with Bitcoin and how different terms are used? In Bitcoin, the recipient passes an address to the sender. In Lightning, the recipient creates an invoice and sends an invoice to the sender. In Bitcoin, the sender sends funds to an address. In Lightning, the sender pays an invoice and the payment gets routed to the recipient. Bitcoin is based on the concept of an "address," and Lightning is a payment network based on the concept of an "invoice." In Bitcoin, we create a "transaction" whereas in Lightning we send a "payment."
((("Bitcoin–Lightning Network comparisons","addresses versus invoices")))Did you notice how this contrasts with Bitcoin and how different terms are used? In Bitcoin, the recipient passes an address to the sender. In Lightning, the recipient creates an invoice and sends an invoice to the sender. In Bitcoin, the sender sends funds to an address. In Lightning, the sender pays an invoice and the payment gets routed to the recipient. Bitcoin is based on the concept of an "address," and Lightning is a payment network based on the concept of an "invoice." In Bitcoin, we create a "transaction," whereas in Lightning we send a "payment."
==== Payment Hash and Preimage
((("Lightning invoices","payment hash/preimage")))The most important part of the invoice is the _payment hash_. When constructing the invoice, Bob will make a payment hash as follows:
1. ((("payment secret (preimage)")))((("preimage (payment secret)")))Bob chooses a random number +r+. This random number is called the _preimage_ or _payment secret_.
1. ((("payment secret (preimage)")))((("preimage (payment secret)")))Bob chooses a random number _r_. This random number is called the _preimage_ or _payment secret_.
2. Bob uses SHA-256 to calculate the hash _H_ of _r_ called the _payment hash_: pass:[<br/>]_H_ = SHA-256(_r_).
[NOTE]
====
The term _preimage_ comes from mathematics. In any function _y = f_(_x_), the set of inputs that produce a certain value _y_ are called the preimage of _y_. In this case, the function is the SHA-256 hash algorithm and any value _r_ that produces the hash _H_ is called a preimage.
The term _preimage_ comes from mathematics. In any function _y = f_(_x_), the set of inputs that produce a certain value _y_ are called the preimage of _y_. In this case, the function is the SHA-256 hash algorithm, and any value _r_ that produces the hash _H_ is called a preimage.
====
There is no known way to find the inverse of SHA-256 (i.e., compute a preimage from a hash). Only Bob knows the value _r_, so it is Bob's secret. But once Bob reveals _r_, anyone who has the hash _H_ can check that _r_ is the correct secret, by calculating SHA-256(_r_) and seeing that it matches _H_.
The payment process of the Lightning Network is only secure if +r+ is chosen completely randomly and is not predictable. This security relies on the fact that hash functions cannot be inverted or feasibly brute-forced and, therefore, no one can find _r_ from _H_.
The payment process of the Lightning Network is only secure if _r_ is chosen completely randomly and is not predictable. This security relies on the fact that hash functions cannot be inverted or feasibly brute-forced and, therefore, no one can find _r_ from _H_.
==== Additional Metadata
((("Lightning invoices","additional metadata")))((("metadata, Lightning invoices and")))Invoices can optionally include other useful metadata such as a short text description. If a user has several invoices to pay, the user can read the description and be reminded of what the invoice is about.
((("routing hints")))The invoice can also include some _routing hints_, which allow the sender to use unannounced channels to construct a route to the recipient. Routing hints can also be used to suggest public channels, for example channels known by the recipient to have enough inbound capacity to route the payment.
((("routing hints")))The invoice can also include some _routing hints_, which allow the sender to use unannounced channels to construct a route to the recipient. Routing hints can also be used to suggest public channels, for example, channels known by the recipient to have enough inbound capacity to route the payment.
In case the sender's Lightning node is unable to send the payment over the Lightning Network, invoices can optionally include an on-chain Bitcoin address as a fallback.
@ -440,7 +438,7 @@ While it is always possible to "fall back" to an on-chain Bitcoin transaction, i
====
Lightning invoices contain an expiry date. Since the recipient must keep the preimage +r+ for every invoice issued, it is useful to have invoices expire so that these preimages do not need to be kept forever. Once an invoice expires or is paid, the recipient can discard the preimage.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc5")))
Lightning invoices contain an expiry date. Since the recipient must keep the preimage _r_ for every invoice issued, it is useful to have invoices expire so that these preimages do not need to be kept forever. Once an invoice expires or is paid, the recipient can discard the preimage.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc5")))
=== Delivering the Payment
@ -450,19 +448,19 @@ In the next few sections, we will dive into the ideas and methods that are being
First, let's look at the Lightning Network's communication protocol.
==== The Peer-To-Peer Gossip Protocol
==== The Peer-to-Peer Gossip Protocol
((("gossip protocol","peer-to-peer", id="ix_03_how_ln_works-asciidoc9", range="startofrange")))((("payment delivery","peer-to-peer gossip protocol", id="ix_03_how_ln_works-asciidoc10", range="startofrange")))((("peer-to-peer gossip protocol", id="ix_03_how_ln_works-asciidoc11", range="startofrange")))As we mentioned previously, when a payment channel is constructed, the channel partners have the option of making it public, announcing its existence and details to the whole Lightning Network.
Channel announcements are communicated over a peer-to-peer _gossip protocol_. A peer-to-peer protocol is a communications protocol in which each node connects to a random selection of other nodes in the network, usually over TCP/IP. Each of the nodes that are directly connected (over TCP/IP) to your node are called your _peers_. Your node in turn is one of their peers. Keep in mind, when we say that your node is connected to other peers, we don't mean that you have payment channels, but only that you are connected via the gossip protocol.
Channel announcements are communicated over a peer-to-peer _gossip protocol_. A peer-to-peer protocol is a communications protocol in which each node connects to a random selection of other nodes in the network, usually over TCP/IP. Each of the nodes that are directly connected (over TCP/IP) to your node are called your _peers_. Your node, in turn, is one of their peers. Keep in mind that when we say that your node is connected to other peers, we don't mean that you have payment channels, but only that you are connected via the gossip protocol.
((("channel_announcement message","peer-to-peer gossip protocol and")))After opening a channel, a node may choose to send out an announcement of the channel via the `channel_announcement` message to its peers.
Every peer validates the information from the `channel_announcement` message and verifies that the funding transaction is confirmed on the Bitcoin blockchain.
After verification the node will forward the gossip message to its own peers, and they will forward it to their peers and so on, spreading the announcement across the entire network.
After verification, the node will forward the gossip message to its own peers, and they will forward it to their peers, and so on, spreading the announcement across the entire network.
To avoid excessive communication, the channel announcement is only forwarded by each node if it has not already forwarded that announcement previously.
((("node_announcement message","peer-to-peer gossip protocol and")))The gossip protocol is also used to announce information about known nodes with the `node_announcement` message.
For this message to be forwarded a node has to have at least one public channel announced on the gossip protocol, again to avoid excessive communication traffic.
For this message to be forwarded, a node has to have at least one public channel announced on the gossip protocol, again to avoid excessive communication traffic.
Payment channels have various metadata that are useful for other participants of the network.
This metadata is mainly used for making routing decisions.
@ -479,7 +477,7 @@ Although the Lightning Network could have been designed to share balance informa
* To protect the privacy of the users, it does not shout out every financial transaction and payment. Channel balance updates would reveal that a payment has moved across the channel. This information could be correlated to reveal all payment sources and destinations.
* To scale the amount of payments that can be conducted with the Lightning Network. Remember that the Lightning Network was created in the first place because notifying every participant about every payment does not scale well. Thus, the Lightning Network cannot be designed in a way that shares channels' balance updates among participants.
* To scale the amount of payments that can be conducted with the Lightning Network. Remember that the Lightning Network was created in the first place because notifying every participant about every payment does not scale well. Thus, the Lightning Network cannot be designed in a way that shares channel balance updates among participants.
* The Lightning Network is a dynamic system. It changes constantly and frequently. Nodes are being added, other nodes are being turned off, balances change, etc. Even if everything is always communicated, the information will be valid only for a short amount of time. As a matter of fact, information is often outdated by the time it is received.
@ -498,7 +496,7 @@ This topology information is crucial for delivering payments through the network
A frequent criticism of the Lightning Network is that routing is not solved, or even that it is an "unsolvable" problem. In fact, routing is trivial. Pathfinding, on the other hand, is a difficult problem. The two terms are often confused and need to be clearly defined to identify which problem we are attempting to solve.
====
As we will see next, the Lightning Network currently uses a _source-based_ protocol for pathfinding and an _onionrouted_ protocol for routing payments. Source-based means that the sender of the payment has to find a path through the network to the intended destination. Onion-routed means that the elements of the path are layered (like an onion), with each layer encrypted so that it can only be seen by one node at a time. We will discuss onion routing in the next section.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc8")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc7")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc6")))
As we will see next, the Lightning Network currently uses a _source-based_ protocol for pathfinding and an _onion-routed_ protocol for routing payments. Source-based means that the sender of the payment has to find a path through the network to the intended destination. Onion-routed means that the elements of the path are layered (like an onion), with each layer encrypted so that it can only be seen by one node at a time. We will discuss onion routing in the next section.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc8")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc7")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc6")))
=== Source-Based Pathfinding
@ -510,7 +508,7 @@ With only partial information about the network topology, pathfinding is a real
[NOTE]
====
One common criticism of pathfinding in the Lightning Network is that it is unsolvable because it is equivalent to the NP-complete ((("traveling salesperson problem")))_traveling salesperson problem_, a fundamental problem in computational complexity theory. In fact, pathfinding in Lightning is not equivalent to TSP and falls into a different class of problems. We successfully solve these types of problems (pathfinding in graphs with incomplete information) every time we ask Google to give us driving directions with traffic avoidance. We also successfully solve this problem every time we route a payment on the Lightning Network.
One common criticism of pathfinding in the Lightning Network is that it is unsolvable because it is equivalent to the NP-complete ((("traveling salesperson problem")))_traveling salesperson problem_ (TSP), a fundamental problem in computational complexity theory. In fact, pathfinding in Lightning is not equivalent to TSP and falls into a different class of problems. We successfully solve these types of problems (pathfinding in graphs with incomplete information) every time we ask Google to give us driving directions with traffic avoidance. We also successfully solve this problem every time we route a payment on the Lightning Network.
====
Pathfinding and routing can be implemented in a number of different ways, and multiple pathfinding and routing algorithms can coexist on the Lightning Network, just as multiple pathfinding and routing algorithms exist on the internet. Source-based pathfinding is one of many possible solutions and is successful at the current scale of the Lightning Network.
@ -522,7 +520,7 @@ The user might only realize that probing is taking place if the payment does not
[NOTE]
====
On the internet, we use the Internet Protocol and an IP forwarding algorithm to forward internet packages from the sender to the destination. While these protocols have the nice property of allowing internet hosts to collaboratively find a path for information flow through the internet, we cannot reuse and adopt this protocol for forwarding payments on the Lightning Network. Unlike the internet, Lightning payments have to be _atomic_ and channel balances have to remain _private_. Furthermore, the channel capacity in Lightning changes frequently, unlike the internet where connection capacity is relatively static. These constraints require novel strategies.
On the internet, we use the Internet Protocol and an IP forwarding algorithm to forward internet packages from the sender to the destination. While these protocols have the nice property of allowing internet hosts to collaboratively find a path for information flow through the internet, we cannot reuse and adopt this protocol for forwarding payments on the Lightning Network. Unlike the internet, Lightning payments have to be _atomic_, and channel balances have to remain _private_. Furthermore, the channel capacity in Lightning changes frequently, unlike the internet where connection capacity is relatively static. These constraints require novel strategies.
====
Of course, pathfinding is trivial if we want to pay our direct channel partner and we have enough balance on our side of the channel to do so. In all other cases, our node uses information from the gossip protocol to do pathfinding. This includes currently known public payment channels, known nodes, known topology (how known nodes are connected), known channel capacities, and known fee policies set by the node owners.
@ -530,18 +528,18 @@ Of course, pathfinding is trivial if we want to pay our direct channel partner a
==== Onion Routing
((("onion routing protocol")))((("pathfinding","onion routing protocol")))((("payment delivery","onion routing protocol")))The Lightning Network uses an _onion routing protocol_ similar to the famous Tor (The Onion Router) network.
((("SPHINX Mix Format", seealso="onion routing")))The onion routing protocol used in Lightning is called the _SPHINX Mix Format_, which will be explained in detail in a later chapter.
((("SPHINX Mix Format", seealso="onion routing")))The onion routing protocol used in Lightning is called the _SPHINX Mix Format_,footnote:[George Danezis and Ian Goldberg, "Sphinx: A Compact and Provably Secure Mix Format," _2009 30th IEEE Symposium on Security and Privacy_ (2009): 269-282, http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/sphinx-eprint.pdf[].] which will be explained in detail in a later chapter.
[NOTE]
====
Lightning's onion routing SPHINX Mix Format is only similar to the Tor network routing in concept, but both the protocol and the implementation are entirely different from those used in the Tor network.
====
A payment package used for routing is called an "onion."footnote:[The term "onion" was originally used by the Tor project. Moreover, the Tor network is also called the Onion network and the project uses an onion as its logo. The toplevel domain name used by Tor services on the internet is _onion_.]
A payment package used for routing is called an "onion."footnote:[The term "onion" was originally used by the Tor project. Moreover, the Tor network is also called the Onion network and the project uses an onion as its logo. The top-level domain name used by Tor services on the internet is _onion_.]
Let's use the onion analogy to follow a routed payment. On its route from payment sender (payer) to payment destination (payee) the onion is passed from node to node along the path. The sender constructs the entire onion, from the center out. First, the sender creates the payment information for the (final) recipient of the payment and encrypts it with a layer of encryption that only the recipient can decrypt. Then, the sender wraps that layer with instructions for the node in the path _immediately preceding the final recipient_ and encrypts with a layer that only that node can decrypt.
The layers are built up with instructions working backward until the entire path is encoded in layers. The sender then gives the complete onion to the first node in the path, which can only read the outermost layer. Each node peels a layer, finds instructions inside revealing the next node in the path, and passes the onion on. As each node peels one layer, it can't read the rest of the onion. All it knows is where the onion has just come from and where it is going next, without any indication as to who is the original sender or the ultimate recipient.
The layers are built up with instructions, working backward until the entire path is encoded in layers. The sender then gives the complete onion to the first node in the path, which can only read the outermost layer. Each node peels a layer, finds instructions inside revealing the next node in the path, and passes the onion on. As each node peels one layer, it can't read the rest of the onion. All it knows is where the onion has just come from and where it is going next, without any indication as to who is the original sender or the ultimate recipient.
This continues until the onion reaches the payment destination (payee). Then, the destination node opens the onion and finds there are no further layers to decrypt and can read the payment information inside.
@ -560,11 +558,11 @@ The onion routing protocol used in Lightning has the following properties:
* Onions have an HMAC (hash-based message authentication code) at each layer so that manipulations of onions are prevented and practically impossible.
* Onions can have up to around 26 hops or onion layers if you prefer. This allows for sufficiently long paths. The precise path length available depends on the amount of bytes allocated to the routing payload at each hop.
* Onions can have up to around 26 hops, or onion layers if you prefer. This allows for sufficiently long paths. The precise path length available depends on the amount of bytes allocated to the routing payload at each hop.
* The encryption of the onion for every hop uses different ephemeral encryption keys. Should a key (in particular the private key of a node) leak at some point in time, an attacker cannot decrypt them. In simpler terms, keys are never reused in order to achieve more security.
* The encryption of the onion for every hop uses different ephemeral encryption keys. Should a key (in particular, the private key of a node) leak at some point in time, an attacker cannot decrypt them. In simpler terms, keys are never reused in order to achieve more security.
* Errors can be sent back from the erring node to the original sender, using the same onionrouted protocol. Error onions are indistinguishable from routing onions to external observers and intermediary nodes. Error routing enables the trial-and-error "probing" method used to find a path that has sufficient capacity to successfully route a payment.
* Errors can be sent back from the erring node to the original sender, using the same onion-routed protocol. Error onions are indistinguishable from routing onions to external observers and intermediary nodes. Error routing enables the trial-and-error "probing" method used to find a path that has sufficient capacity to successfully route a payment.
Onion routing will be examined in detail in <<onion_routing>>.
@ -586,15 +584,15 @@ Onion routing will be examined in detail in <<onion_routing>>.
. It works with its channel partner on the outgoing channel to update the channel state.
Of course, these steps are interrupted and aborted if an error is detected and an error message is sent back to the originator of the `update_add_htlc` message. The error message is also formatted as an onion and sent backward on the incoming channel.
Of course, these steps are interrupted and aborted if an error is detected, and an error message is sent back to the originator of the `update_add_htlc` message. The error message is also formatted as an onion and sent backward on the incoming channel.
As the error propagates backward on each channel along the path, the channel partners remove the pending payment, rolling back the payment in the opposite way from which it started.
While the likelihood for a payment failure is high if it does not settle quickly, a node should never initiate another payment attempt along a different path before the onion returns with an error. The sender would pay twice if both payment attempts eventually succeeded.(((range="endofrange", startref="ix_03_how_ln_works-asciidoc14")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc13")))(((range="endofrange", startref="ix_03_how_ln_works-asciidoc12")))
=== Peer-To-Peer Communication Encryption
=== Peer-to-Peer Communication Encryption
((("Lightning Network (generally)","peer-to-peer communication encryption")))((("peer-to-peer communication encryption")))The LN protocol is mainly a peer-to-peer protocol between its participants. As we saw in previous sections, there are two overlapping functions in the network, forming two logical networks that together are _The Lightning Network_:
((("Lightning Network (generally)","peer-to-peer communication encryption")))((("peer-to-peer communication encryption")))The LN protocol is mainly a peer-to-peer protocol between its participants. As we saw in previous sections, there are two overlapping functions in the network, forming two logical networks that together are _the Lightning Network_:
1. A broad peer-to-peer network that uses a gossip protocol to propagate topology information, where peers randomly connect to each other. Peers don't necessarily have payment channels between them, so they are not always channel partners.
@ -602,19 +600,19 @@ While the likelihood for a payment failure is high if it does not settle quickly
All communication between peers is sent via messages called _Lightning messages_. These messages are all encrypted, using a cryptographic communications framework ((("Noise Protocol Framework","Lightning messages and")))called the _Noise Protocol Framework_. The Noise Protocol Framework allows the construction of cryptographic communication protocols that offer authentication, encryption, forward secrecy, and identity privacy. The Noise Protocol Framework is also used in a number of popular end-to-end encrypted communications systems such as WhatsApp, WireGuard, and I2P. More information can be found https://noiseprotocol.org[at the Noise Protocol Framework website].
The use of the Noise Protocol Framework in the Lightning Network ensures that every message on the network is both authenticated and encrypted, increasing the privacy of the network and its resistance to traffic analysis, deep packet inspection, and eavesdropping. However, as a side-effect, this makes protocol development and testing a bit tricky because one can't simply observe the network with a packet capture or network analysis tool such as Wireshark. Instead, developers have to use specialized plug-ins that decrypt the protocol from the perspective of one node, such as the https://github.com/nayutaco/lightning-dissector[_lightning dissector_], a Wireshark plug-in.
The use of the Noise Protocol Framework in the Lightning Network ensures that every message on the network is both authenticated and encrypted, increasing the privacy of the network and its resistance to traffic analysis, deep packet inspection, and eavesdropping. However, as a sideeffect, this makes protocol development and testing a bit tricky because one can't simply observe the network with a packet capture or network analysis tool such as Wireshark. Instead, developers have to use specialized plug-ins that decrypt the protocol from the perspective of one node, such as the https://github.com/nayutaco/lightning-dissector[_lightning dissector_], a Wireshark plug-in.
=== Thoughts About Trust
((("Lightning Network (generally)","trust and")))((("trust, Lightning Network and")))As long as a person follows the protocol and has their node secured, there is no major risk of losing funds when participating in the Lightning Network.
However, there is the cost of paying on-chain fees when opening a channel.
Any cost should come with a corresponding benefit.
In our case the reward for Alice for bearing the cost of opening a channel is that Alice can send and, after moving some the coins to the other end of the channel, receive payments of bitcoin on the Lightning Network at any time and that she can earn fees in bitcoin by forwarding payments for other people.
In our case, the reward for Alice for bearing the cost of opening a channel is that Alice can send and, after moving some of the coins to the other end of the channel, receive payments of bitcoin on the Lightning Network at any time, and that she can earn fees in bitcoin by forwarding payments for other people.
Alice knows that in theory Bob can close the channel immediately after opening, resulting in on-chain closing fees for Alice.
Alice will need to have a small amount of trust in Bob.
Alice has been to Bob's Cafe and clearly Bob is interested in selling her coffee, so Alice can trust Bob in this sense.
There are mutual benefits to both Alice and Bob.
Alice decides that the reward is enough for her to take on the cost of the on-chain fee for creating a channel to Bob.
In contrast, Alice will not open a channel to someone unknown who just uninvitedly sent her an email asking her to open a new channel.
In contrast, Alice will not open a channel to someone unknown who just uninvited sent her an email asking her to open a new channel.
=== Comparison with Bitcoin
@ -622,7 +620,7 @@ In contrast, Alice will not open a channel to someone unknown who just uninvited
Some of these differences are differences in terminology. There are also architectural differences and differences in the user experience. In the next few sections, we will examine the differences and similarities, explain the terminology, and adjust our expectations.
==== Addresses Versus Invoices, Transactions Versus Payments
==== Addresses versus Invoices, Transactions versus Payments
((("Bitcoin–Lightning Network comparisons","addresses versus invoices")))((("Bitcoin–Lightning Network comparisons","transactions versus payments")))In a typical payment using Bitcoin, a user receives a Bitcoin address (e.g., scanning a QR code on a web page, or receiving it in an instant message or email from a friend). They then use their Bitcoin wallet to create a transaction to send funds to this address.
@ -630,30 +628,30 @@ On the Lightning Network, the recipient of a payment creates an invoice. A Light
The sender uses their Lightning wallet to pay the invoice, copying the invoice text or scanning the invoice QR code. A Lightning payment is analogous to a Bitcoin "transaction."
There are some differences in the user experience, however. A Bitcoin address is _reusable_. Bitcoin addresses never expire and if the owner of the address still holds the keys, the funds held within are always accessible. A sender can send any amount of bitcoin to a previously used address, and a recipient can post a single static address to receive many payments. While this goes against the best practices for privacy reasons, it is technically possible and in fact quite common.
There are some differences in the user experience, however. A Bitcoin address is _reusable_. Bitcoin addresses never expire, and if the owner of the address still holds the keys, the funds held within are always accessible. A sender can send any amount of bitcoin to a previously used address, and a recipient can post a single static address to receive many payments. While this goes against the best practices for privacy reasons, it is technically possible and in fact quite common.
In Lightning, however, each invoice can only be used once for a specific payment amount. You cannot pay more or less, you cannot use an invoice again, and the invoice has an expiry time built in. In Lightning, a recipient has to generate a new invoice for each payment, specifying the payment amount in advance. There is an exception to this, a mechanism called _keysend_, which we will examine in <<keysend>>.
==== Selecting Outputs Versus Finding a Path
==== Selecting Outputs versus Finding a Path
((("Bitcoin–Lightning Network comparisons","selecting outputs versus finding a path")))((("unspent transaction outputs (UTXOs)")))((("UTXOs (unspent transaction outputs)")))To make a payment on the Bitcoin network, a sender needs to consume one or more unspent transaction outputs (UTXOs).
If a user has multiple UTXOs, they (or rather their wallet) will need to select which UTXO(s) to send.
For instance, a user making a payment of 1 BTC can use a single output with value 1 BTC, two outputs with value 0.25 BTC and 0.75 BTC, or four outputs with value 0.25 BTC each.
On Lightning, payments do not require inputs to be consumed. Instead, each payment results in an update of the channel balance, redistributing it between the two channel partners. The sender experiences this as "moving" channel balance from their end of a channel to the other end, to their channel partner. Lightning payments use a series of channels to route from sender to recipient. Each of these channels must have sufficient capacity to route the payment.
On Lightning, payments do not require inputs to be consumed. Instead, each payment results in an update of the channel balance, redistributing it between the two channel partners. The sender experiences this as "moving" the channel balance from their end of a channel to the other end, to their channel partner. Lightning payments use a series of channels to route from sender to recipient. Each of these channels must have sufficient capacity to route the payment.
Because many possible channels and paths can be used to make a payment, the Lightning user's choice of channels and paths is somewhat analogous to the Bitcoin user's choice of UTXO.
With technologies such as atomic multipath payments (AMP) and multipart payments (MPP), which we will review in subsequent chapters, several Lightning paths can be aggregated into a single atomic payment, just like several Bitcoin UTXOs can be aggregated into a single atomic Bitcoin transaction.
==== Change Outputs On Bitcoin Versus No Change On Lightning
==== Change Outputs on Bitcoin versus No Change on Lightning
((("Bitcoin–Lightning Network comparisons","change outputs")))To make a payment on the Bitcoin network, the sender needs to consume one or more unspent transaction outputs (UTXOs). UTXOs can only be spent in full; they cannot be divided and partially spent. So if a user wishes to spend 0.8 BTC, but only has a 1 BTC UTXO, then they need to spend the entire 1 BTC UTXO by sending 0.8 BTC to the recipient and 0.2 BTC back to themselves as change. The 0.2 BTC change payment creates a new UTXO called a "change output."
((("Bitcoin–Lightning Network comparisons","change outputs")))To make a payment on the Bitcoin network, the sender needs to consume one or more unspent transaction outputs (UTXOs). UTXOs can only be spent in full; they cannot be divided and partially spent. So if a user wishes to spend 0.8 BTC, but only has a 1 BTC UTXO, they need to spend the entire 1 BTC UTXO by sending 0.8 BTC to the recipient and 0.2 BTC back to themselves as change. The 0.2 BTC change payment creates a new UTXO called a "change output."
On Lightning, the funding transaction spends some Bitcoin UTXO, creating a multisignature UTXO to open the channel. Once the bitcoin is locked within that channel, portions of it can be sent back and forth within the channel, without the need to create any change.
This is because the channel partners simply update the channel balance and only create a new UTXO when the channel is eventually closed using the channel closing transaction.
==== Mining Fees Versus Routing Fees
==== Mining Fees versus Routing Fees
((("Bitcoin–Lightning Network comparisons","mining fees versus routing fees")))On the Bitcoin network, users pay fees to miners to have their transactions included in a block.
These fees are paid to the miner who mines that particular block.
@ -663,28 +661,28 @@ Because miners will typically mine the most profitable transactions first, a use
On the Lightning Network, users pay fees to other (intermediary node) users to route payments through their channels.
To route a payment, an intermediary node will have to move funds in two or more channels they own, as well as transmit the data for the sender's payment. Typically, the routing user will charge the sender based on the _value_ of the payment, having established a minimum ((("base fee")))_base fee_ (a flat fee for each payment) and a ((("fee rate")))_fee rate_ (a prorated fee proportional to the value of the payment). Higher value payments will thus cost more to route, and a market for liquidity is formed, where different users charge different fees for routing through their channels.
==== Varying Fees Depending On Traffic Versus Announced Fees
==== Varying Fees Depending on Traffic versus Announced Fees
((("Bitcoin–Lightning Network comparisons","varying fees versus announced fees")))On the Bitcoin network, miners are profit-seeking and will typically include as many transactions in a block as possible, while staying within the block capacity called the ((("block weight")))_block weight_.
((("Bitcoin–Lightning Network comparisons","varying fees versus announced fees")))On the Bitcoin network, miners are profitseeking and will typically include as many transactions in a block as possible, while staying within the block capacity called the ((("block weight")))_block weight_.
((("transaction weight")))If there are more transactions in the queue (called the mempool) than can fit in a block, they will begin by mining the transactions that pay the highest fees per unit (bytes) of _transaction weight_.
((("transaction weight")))If there are more transactions in the queue (called the _mempool_) than can fit in a block, they will begin by mining the transactions that pay the highest fees per unit (bytes) of _transaction weight_.
Thus, when there are many transactions in the queue, users have to pay a higher fee to be included in the next block, or they have to wait until there are fewer transactions in the queue.
This naturally leads to the emergence of a fee market where users pay based on how urgently they need their transaction included in the next block.
The scarce resource on the Bitcoin network is the space in the blocks. Bitcoin users compete for block space and the Bitcoin fee market is based on available block space. The scarce resources in the Lightning Network are the ((("channel connectivity")))((("channel liquidity")))_channel liquidity_ (capacity of funds available for routing in channels) and _channel connectivity_ (how many well-connected nodes channels can reach). Lightning users compete for capacity and connectivity; therefore, the Lightning fee market is driven by capacity and connectivity.
The scarce resource on the Bitcoin network is the space in the blocks. Bitcoin users compete for block space, and the Bitcoin fee market is based on available block space. The scarce resources in the Lightning Network are the ((("channel connectivity")))((("channel liquidity")))_channel liquidity_ (capacity of funds available for routing in channels) and _channel connectivity_ (how many well-connected nodes channels can reach). Lightning users compete for capacity and connectivity; therefore, the Lightning fee market is driven by capacity and connectivity.
On the Lightning Network, users are paying fees to the users routing their payments. Routing a payment, in economic terms, is nothing more than providing and assigning capacity to the sender. Naturally, routers who charge lower fees for the same capacity will be more attractive to route through. Thus a fee market exists where routers are in competition with each other over the fees they charge to route payments through their channels.
==== Public Bitcoin Transactions Versus Private Lightning Payments
==== Public Bitcoin Transactions versus Private Lightning Payments
((("Bitcoin–Lightning Network comparisons","public Bitcoin transactions versus private Lightning payments")))On the Bitcoin network, every transaction is publicly visible on the Bitcoin blockchain. While the addresses involved are pseudonymous and are not typically tied to an identity, they are still seen and validated by every other user on the network.
In addition, blockchain surveillance companies collect and analyze this data en masse and sell it to interested parties such as private firms, governments, and intelligence agencies.
LN payments, on the other hand, are almost completely private. Typically, only the sender and the recipient are fully aware of the source, destination, and amount transacted in a particular payment. Furthermore, the receiver may not even know the source of the payment. Because payments are onion-routed, the users who route the payment are only aware of the amount of the payment, and they can determine neither the source nor the destination.
LN payments, on the other hand, are almost completely private. Typically, only the sender and the recipient are fully aware of the source, destination, and amount transacted in a particular payment. Furthermore, the receiver may not even know the source of the payment. Because payments are onionrouted, the users who route the payment are only aware of the amount of the payment, and they can determine neither the source nor the destination.
In summary, Bitcoin transactions are broadcast publicly and stored forever. Lightning payments are executed between a few selected peers, and information about them is privately stored only until the channel is closed. Creating mass surveillance and analysis tools equivalent to those used on Bitcoin will be much harder on Lightning.
==== Waiting for Confirmations Versus Instant Settlement
==== Waiting for Confirmations versus Instant Settlement
((("Bitcoin–Lightning Network comparisons","waiting for confirmations versus instant settlement")))On the Bitcoin network, transactions are only settled once they have been included in a block, in which case they are said to be "confirmed" in that block. As more blocks are mined, the transaction acquires more "confirmations" and is considered more secure.
@ -693,7 +691,7 @@ In practical terms, instant settlement means that payments take only a few secon
Finally, when the channel is closed, a transaction is made on the Bitcoin network; once that transaction is confirmed, the channel is considered closed.
==== Sending Arbitrary Amounts Versus Capacity Restrictions
==== Sending Arbitrary Amounts versus Capacity Restrictions
((("Bitcoin–Lightning Network comparisons","sending arbitrary amounts versus capacity restrictions")))On the Bitcoin network, a user can send any amount of bitcoin that they own to another user, without capacity restrictions. A single transaction can theoretically send up to 21 million bitcoin as a payment.
@ -705,20 +703,20 @@ If the payment is routed, every routing node along the routing path must have ch
Hence, capacity and connectivity are critical and scarce resources in the Lightning Network.
==== Incentives for Large Value Payment Versus Small Value Payments
==== Incentives for Large Value Payment versus Small Value Payments
((("Bitcoin–Lightning Network comparisons","fee structures")))((("fees","Bitcoin–Lightning Network comparisons")))The fee structure in Bitcoin is independent of the transaction value.
A $1 million transaction has the same fee as a $1 transaction on Bitcoin, assuming a similar transaction size in bytes (more specifically "virtual" bytes after SegWit [Segregated Witness protocol]).
In Lightning the fee is a fixedbase fee plus a percentage of the transaction value.
A $1 million transaction has the same fee as a $1 transaction on Bitcoin, assuming a similar transaction size, in bytes (more specifically "virtual" bytes after SegWit [Segregated Witness protocol]).
In Lightning the fee is a fixed-base fee plus a percentage of the transaction value.
Therefore, in Lightning the payment fee increases with payment value.
These opposing fee structures create different incentives and lead to different usage in regards to transaction value.
A transaction of greater value will be cheaper on Bitcoin; hence, users will prefer Bitcoin for large value transactions. Similarly, on the other end of the scale, users will prefer Lightning for small value transactions.
==== Using the Blockchain As a Ledger Versus As a Court System
==== Using the Blockchain as a Ledger versus as a Court System
((("Bitcoin–Lightning Network comparisons","blockchain: ledger versus court system")))On the Bitcoin network, every transaction is eventually recorded in a block on the blockchain.
The blockchain thus forms a complete history of every transaction since Bitcoin's creation, and a way to fully audit every bitcoin in existence.
Once a transaction is included in the blockchain it is final.
Once a transaction is included in the blockchain, it is final.
Thus, no disputes can arise and it is unambiguous how much bitcoin is controlled by a particular address at a particular point in the blockchain.
On the Lightning Network, the balance in a channel at a particular time is known only to the two channel partners, and is only made visible to the rest of the network when the channel is closed.
@ -728,7 +726,7 @@ If Alice tries to cheat by submitting the opening state of the channel to the Bi
For the Lightning Network, the Bitcoin blockchain acts as a court system.
Like a robotic judge, Bitcoin records the initial and final balances of each channel and approves penalties if one of the parties tries to cheat.
==== Offline Versus Online, Asynchronous Versus Synchronous
==== Offline versus Online, Asynchronous versus Synchronous
((("Bitcoin–Lightning Network comparisons","minimum payment size: satoshi versus millisatoshi")))((("Bitcoin–Lightning Network comparisons","payment activity: asynchronous versus synchronous")))((("millisatoshi")))((("satoshi")))When a Bitcoin user sends funds to a destination address, they do not need to know anything about the recipient. The recipient might be offline or online, and no interaction between sender and recipient is needed. The interaction is between sender and the Bitcoin blockchain. Receiving bitcoin on the Bitcoin blockchain is a _passive_ and _asynchronous_ activity that does not require any interaction by the recipient or for the recipient to be online at any time. Bitcoin addresses can even be generated offline and are never "registered" with the Bitcoin network. Only spending bitcoin requires interaction.
@ -737,7 +735,7 @@ The recipient must run a node or have someone that runs a node on their behalf (
The synchronous and always-online nature of the Lightning Network is probably the biggest difference in the user experience, and this often confounds users who are accustomed to Bitcoin.
==== Satoshis Versus Millisatoshis
==== Satoshis versus Millisatoshis
On the Bitcoin network, the smallest amount is a _satoshi_, which cannot be divided any further. Lightning is a bit more flexible, and Lightning nodes work with _millisatoshis_ (thousandths of a satoshi). This allows tiny payments to be sent via Lightning. A single millisatoshi payment can be sent across a payment channel, an amount so small it should properly be characterized as a _nanopayment_.
kristen@oreilly.com
3 years ago