Welcome to Mastering the Lightning Network or "LN" as we'll call it throughout the book!
The LN is a protocol for using Bitcoin in a smart and non obvious way.
Welcome to Mastering the Lightning Network (LN)!
The Lightning Network is a protocol for using Bitcoin in a smart and non obvious way.
Thus it is a second layer technology on top of Bitcoin.
It is changing the way people exchange value online and it's one of the most exciting advancements to happen to the Bitcoin network over the past few years. Right now, LN is in its infancy. In concept it's about 5 years old, in implementation about 3 years old. We're only beginning to see the opportunities LN provides including improved privacy, speed, and scale. With core knowledge of LN, you can help shape the future of the network while building opportunities for yourself as well. Some basic knowledge about Bitcoin is assumed but can be readily acquired by reading the first two chapters of _Mastering Bitcoin_ which are available for free online.
@ -11,7 +12,11 @@ While the bulk of this book is written for programmers, the first two chapters a
=== Motivation for the Lightning Network
As Bitcoin grows, and the demand for transactions grows, the number of transactions in each block will increase until eventually hitting the block size limit. When blocks are full, excess transactions are left to wait in a queue. Many users increase the fees they're willing to pay in order to buy space for their transaction in the next block. At the same time an increasing number of users are left behind. Their transactions, e.g. microtransactions such as common small spendings, are not economically qualified to be on the network. However, simply increasing block size does not solve the problem because it has the undesirable effect of centralizing the network. Because blockchains are gossip protocols, each node is required to know and validate every single transaction that occurs on the network. As such, the greater the block size, the greater the processing and storage requirements for each individual node. The greater the requirements, the fewer the nodes that will ultimately be run. But what if each node wasn't required to know and validate every single transaction? What if there was a way to have scalable off-chain transactions, without losing the security of the Bitcoin network?
As Bitcoin grows, and the demand for transactions grows, the number of transactions in each block will increase until eventually hitting the block size limit. When blocks are full, excess transactions are left to wait in a queue. Many users increase the fees they're willing to pay in order to buy space for their transaction in the next block. At the same time an increasing number of users are left behind. Their transactions, e.g. microtransactions such as common small spendings, are not economically qualified to be on the network. However, increasing block size simply shifts the problem to node operators, where each increase is multiplied by an order of magnitude.
Because blockchains are gossip protocols, each node is required to know and validate every single transaction that occurs on the network. Furthermore, once validated, each transaction and block must be propagated to the node's "neighbors", multiplying the bandwidth requirements. As such, the greater the block size, the greater the bandwidth, processing, and storage requirements for each individual nodes, effectively limiting the amount of scaling that can be done this way. Furthermore, scaling in this way has an undesirable side effect of centralizing the network by reducing the number of nodes and node operators. Since node operators are not compensated for running nodes, if nodes are very expensive to run, only a few well funded node operators will continue to run nodes.
But what if each node wasn't required to know and validate every single transaction? What if there was a way to have scalable off-chain transactions, without losing the security of the Bitcoin network?
In February 2015, Joseph Poon and Thaddeus Dryja proposed a possible solution to the Bitcoin Scalability Problem, with the publication of _"The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments"_ footnote:[Joseph Poon, Thaddeus Dryja - "The Bitcoin Lightning Network:
Scalable Off-Chain Instant Payments" (https://lightning.network/lightning-network-paper.pdf).] In the meanwhile outdated whitepaper, Poon and Dryja estimate that in order for Bitcoin to reach the 47,000 transactions per second processed at peak by Visa, it would require 8 GB blocks. This would make running a node completely untenable for anyone but large scale enterprises and industrial grade operations. The result would be a network in which only a few users can actually validate the state of the ledger, which ultimately breaks the trust model of Bitcoin.
The Lightning Network proposes a new network, a "second layer", where users can make payments to each other peer-to-peer, without the necessity to publish a transaction to the Bitcoin blockchain every time.
Users may pay each other on the Lightning Network as many times as they want, making use of the Bitcoin blockchain only in order to load bitcoin onto the network initially and to "settle", that is: remove bitcoin from the Lightning Network.
The result is that many more Bitcoin payments can take place "off-chain", with only the initial loading and final settlement transactions needing to be validated and stored by Bitcoin nodes.
Aside from reducing the burden on nodes, payments on the LN will be cheaper for users as they do not need to pay blockchain fees, and more private for users as they are not published to all participants of the network.
Aside from reducing the burden on nodes, payments on the Lightning Network will be cheaper for users as they do not need to pay blockchain fees, and more private for users as they are not published to all participants of the network.
While the Lightning Network was initially conceived for Bitcoin, it can be implemented on any blockchain that meets its technical requirements.
@ -27,17 +32,17 @@ While the Lightning Network was initially conceived for Bitcoin, it can be imple
As we start exploring the Lightning Network, we will encounter some technical terminology that might, at first, be confusing and a bit difficult to understand. While all of these concepts and terms will be explained in detail as we progress through the book, and are defined in the glossary, we need some basic explanations to get started. Here are some of the concepts you will encounter in the first two chapters of this book:
Node:: A computer that participates in a network. A LN node is a computer that participates in the Lightning Network. A Bitcoin node is a computer that participates in the Bitcoin Network. Typically a Lightning Network user will run a LN node and a Bitcoin node.
Node:: A computer that participates in a network. A Lightning node is a computer that participates in the Lightning Network. A Bitcoin node is a computer that participates in the Bitcoin Network. Typically a Lightning Network user will run a Lightning node and a Bitcoin node.
Blockchain:: A distributed transaction ledger, produced by a network of computers. Bitcoin, for example, is a system that produces a blockchain. The Lightning Network is not itself a blockchain, nor does it produce a blockchain, it is a network that relies on existing blockchains for its security.
Blockchain:: A distributed transaction ledger, produced by a network of computers. Bitcoin, for example, is a system that produces a blockchain. The Lightning Network is not itself a blockchain, nor does it produce a blockchain, it is a network that relies on an existing blockchain for its security.
Transaction:: A data structure that records the transfer of control over some funds (e.g. some bitcoin). The Lightning Network relies on Bitcoin transactions (or those of another blockchain), to track control of funds.
Payment:: When value is exchanged on the LN we call this a payment as the term Transaction is the technical term for entries on the Bitcoin Blockchain.
Payment:: When value is exchanged on the Lightning Network we call this a payment as the term Transaction is the technical term for entries on the Bitcoin Blockchain.
Payment Channel:: A _financial relationship_ between two nodes on the Lightning Network, typically implemented by multi-signature Bitcoin transactions that share control over bitcoin between the two LN nodes.
Payment Channel:: A _financial relationship_ between two nodes on the Lightning Network, typically implemented by multi-signature Bitcoin transactions that share control over bitcoin between the two Lightning nodes.
On-Chain/Off-Chain:: A payment is "on-chain" if it is recorded as a transaction on the Bitcoin (or other underlying) blockchain. Payments sent via payment channels between LN nodes, and which are not visible in the underlying blockchain, are called "off-chain" payments.
On-Chain/Off-Chain:: A payment is "on-chain" if it is recorded as a transaction on the Bitcoin (or other underlying) blockchain. Payments sent via payment channels between Lightning nodes, and which are not visible in the underlying blockchain, are called "off-chain" payments.
More detailed definitions of these and many other terms can be found in the <<glossary>>. Throughout this book we will explain what these concepts mean and how these technologies actually work.
@ -87,4 +92,4 @@ Wei is an entrepreneur who sells information services related to the Lightning N
=== Chapter Summary
In this chapter we looked at the history of the Lightning Network and the motivations behind second layer scaling solutions for Bitcoin and other blockchain based networks. We learned basic terminology including node, payment channel, on-chain transactions and off-chain payments. Finally, we met Alice, Bob, Saanvi, John, Gloria, Farel, and Wei who we'll be following throughout the rest of the book. In the next chapter we'll meet Alice and walk through her thought process as she selects an LN wallet and prepares to make her first LN payment, to buy a cup of coffee from Bob's Cafe.
In this chapter we looked at the history of the Lightning Network and the motivations behind second layer scaling solutions for Bitcoin and other blockchain based networks. We learned basic terminology including node, payment channel, on-chain transactions and off-chain payments. Finally, we met Alice, Bob, Saanvi, John, Gloria, Farel, and Wei who we'll be following throughout the rest of the book. In the next chapter we'll meet Alice and walk through her thought process as she selects a Lightning wallet and prepares to make her first LN payment, to buy a cup of coffee from Bob's Cafe.
In this chapter, we will begin where most people start when encountering the Lightning Network for the first time - choosing software. We will examine the choices of two users who represent a common use-case for the Lightning Network and learn by example. Alice, a coffee shop customer, will be using a LN wallet on her mobile device to buy coffee from Bob's Cafe. Bob, a merchant, will be using a LN node and wallet to run a point-of-sale system at his cafe so he can accept payments over the Lightning Network.
In this chapter, we will begin where most people start when encountering the Lightning Network for the first time - choosing software. We will examine the choices of two users who represent a common use-case for the Lightning Network and learn by example. Alice, a coffee shop customer, will be using a Lightning wallet on her mobile device to buy coffee from Bob's Cafe. Bob, a merchant, will be using a Lightning node and wallet to run a point-of-sale system at his cafe so he can accept payments over the Lightning Network.
=== Lightning Nodes
The Lightning Network is accessed via software applications that can speak the Lightning Network protocol. A _Lightning Network Node_ (or simply "node") is a software application that has three important characteristics. First, nodes must communicate on a peer-to-peer basis with other LN nodes. This communication forms the Lightning _Network_ itself. Nodes also include "wallet" functionality, so they can send and receive payments over the Lightning Network and on the Bitcoin network. Finally, LN nodes also need access to the Bitcoin blockchain (or other blockchains for other cryptocurrencies).
The Lightning Network is accessed via software applications that can speak the Lightning Network protocol. A _Lightning Network Node_ (or simply "node") is a software application that has three important characteristics. First, nodes must communicate on a peer-to-peer basis with other Lightning nodes. Nodes also include "wallet" functionality, so they can send and receive payments over the Lightning Network and on the Bitcoin network. Finally, Lightning nodes also need access to the Bitcoin blockchain (or other blockchains for other cryptocurrencies).
Users have the highest degree of control by running their own Bitcoin node and LN node. However, LN nodes can also use a lightweight Bitcoin client (commonly referred to as Simplified Payment Verification (SPV)) to partially validate the correctness of their blockchain.
While Bitcoin nodes need quite some hardware to be able to operate smoothly LN nodes can run with tiny hardware requirements on cellphones or on a Raspberry Pi.
////
but there is no "SPV" functionality in the LN peer to peer communication right? they have to have full funcionality?
c.f.: https://github.com/lnbook/lnbook/issues/135
////
Users have the highest degree of control by running their own Bitcoin node and Lightning node. However, Lightning nodes can also use a lightweight Bitcoin client (commonly referred to as Simplified Payment Verification (SPV)) to partially validate the correctness of their blockchain.
=== Lightning Wallets
The term "Lightning Wallet" is somewhat ambiguous, as it can describe a broad variety of components combined with some user interface. The most common components of lightning wallet software include:
* A keystore that holds secrets, such as private keys.
* A Lightning Network node that communicates on the Peer-to-Peer network, as described previously.
* A Lightning Network node (Lightning node) that communicates on the Peer-to-Peer network, as described previously.
* A Bitcoin node that stores blockchain data and communicates with other Bitcoin nodes.
* A database "map" of nodes and channels that are announced on the Lightning network
* A "gossip" participant that learns about nodes and channels on the network to construct the "map" of the network.
* A channel data store containing state about channels on the Lightning Network as well as signatures to settle them.
* A channel manager that can open and close Lightning Network channels.
* A path-finding system that can identify a path of connected channels from payment source to payment destination.
@ -52,9 +47,9 @@ In <<lnwallet-categories>> we see the three broad categories of lightning wallet
Lightning wallets can be installed on a variety of devices, including laptops, servers, and mobile devices. To run an LN node and a Bitcoin node, you will need to use a server or desktop computer, as mobile devices and laptops are usually not powerful enough in terms of capacity, processing, battery life, and connectivity.
Lightning wallets can be installed on a variety of devices, including laptops, servers, and mobile devices. To run an full Lightning node (one that participates in "gossip" and creates its own map of the network for path finding and routing) you will need to use a server or desktop computer, as mobile devices and laptops are usually not powerful enough in terms of capacity, processing, battery life, and connectivity.
In <<lnwallet-examples>> we see some examples of currently popular LN node and wallet applications for different types of devices.
In <<lnwallet-examples>> we see some examples of currently popular Lightning node and wallet applications for different types of devices.
// TODO: Add a lot more wallet/node examples, confirm the details for correctness
[[lnwallet-examples]]
@ -75,15 +70,15 @@ In <<lnwallet-examples>> we see some examples of currently popular LN node and w
Lightning wallets have to strike a careful balance between complexity and user control. Those that give the user the most control over their funds, the highest degree of privacy, and the greatest independence from third party services are necessarily more complex and difficult to operate. As the technology advances, some of these trade-offs will become less stark, and users may be able to get more control without more complexity. However, for now, different companies and projects are exploring different positions along this control-complexity spectrum and hoping to find the "sweet spot" for the users they are targeting.
When selecting a wallet, keep in mind that even if you don't see these trade-offs, they still exist. For example, many wallets will attempt to remove the burden of channel management from its users. To do so, they introduce central "hub" nodes that their wallets all connect to automatically. While this trade-off simplifies the user interface and user experience, it introduces a Single Point of Failure (SPoF) and a potential privacy compromise, as these "hub nodes" become indispensable and can see all the user's transactions.
When selecting a wallet, keep in mind that even if you don't see these trade-offs, they still exist. For example, many wallets will attempt to remove the burden of channel management from its users. To do so, they introduce central "hub" nodes that their wallets all connect to automatically. While this trade-off simplifies the user interface and user experience, it introduces a Single Point of Failure (SPoF) as these "hub nodes" become indispensable for the wallet operation. Furthermore, relying on a "hub" like this can reduce user privacy, since the hub knows the sender and potentially (if constructing the payment route on behalf of the user) also the recipient of each payment made by the user's wallet.
In the next section, we will introduce our first user and walk through their first LN wallet setup. We have chosen a wallet that is more sophisticated than the easier custodial wallets. This is because we want to show some of the underlying complexity and introduce some of the inner workings of the wallet during our example. You may find that your first ideal wallet is further towards "ease of use", by accepting some of the control and privacy trade-offs. Or perhaps you are more of a "power user" and want to run your own LN and Bitcoin nodes as part of your wallet solution.
In the next section, we will introduce our first user and walk through their first Lightning wallet setup. We have chosen a wallet that is more sophisticated than the easier custodial wallets. This is because we want to show some of the underlying complexity and introduce some of the inner workings of the wallet during our example. You may find that your first ideal wallet is further towards "ease of use", by accepting some of the control and privacy trade-offs. Or perhaps you are more of a "power user" and want to run your own LN and Bitcoin nodes as part of your wallet solution.
=== Alice's First LN Wallet
Alice is a long time Bitcoin user. We first met Alice in Chapter 1 of _"Mastering Bitcoin"_ footnote:["Mastering Bitcoin 2nd Edition, Chapter 1" Andreas M. Antonopoulos (https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch01.asciidoc).], when she bought a cup of coffee from Bob's cafe, using a bitcoin transaction. Now, Alice is eager to learn about and experiment with the Lightning Network. First, she has to select a LN wallet that meets her needs.
Alice is a long time Bitcoin user. We first met Alice in Chapter 1 of _"Mastering Bitcoin"_ footnote:["Mastering Bitcoin 2nd Edition, Chapter 1" Andreas M. Antonopoulos (https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch01.asciidoc).], when she bought a cup of coffee from Bob's cafe, using a bitcoin transaction. Now, Alice is eager to learn about and experiment with the Lightning Network. First, she has to select a Lightning wallet that meets her needs.
Alice does not want to entrust custody of her bitcoin to third parties. She has learned enough about cryptocurrency to know how to use a wallet. She also wants a mobile wallet so that she can use it for small payments on-the-go, so she chooses the _Eclair_ wallet, a popular non-custodial mobile LN wallet.
Alice does not want to entrust custody of her bitcoin to third parties. She has learned enough about cryptocurrency to know how to use a wallet. She also wants a mobile wallet so that she can use it for small payments on-the-go, so she chooses the _Eclair_ wallet, a popular non-custodial mobile Lightning wallet.
==== Downloading and Installing a LN Wallet
@ -97,7 +92,7 @@ Alice uses an Android device and will use the Google Play Store to download and
.Eclair Mobile in the Google Play Store
image:images/eclair-playstore.png["Eclair wallet in the Google Play Store"]
Alice notices a few different elements on this page, that help her ascertain that this is, most likely, the correct "Eclair Mobile" wallet she is looking for. Firstly, the organization "ACINQ" footnote:[ACINQ: Developers of the Eclair Mobile LN wallet (https://acinq.io/).] is listed as the developer of this mobile wallet, which Alice knows from her research is the correct developer. Secondly, the wallet has been installed "10,000+" times and has more than 320 positive reviews. It is unlikely this is a rogue app that has snuck into the Play Store. Satisfied by these findings, Alice installs the Eclair app on her mobile device.
Alice notices a few different elements on this page, that help her ascertain that this is, most likely, the correct "Eclair Mobile" wallet she is looking for. Firstly, the organization "ACINQ" footnote:[ACINQ: Developers of the Eclair Mobile Lightning wallet (https://acinq.io/).] is listed as the developer of this mobile wallet, which Alice knows from her research is the correct developer. Secondly, the wallet has been installed "10,000+" times and has more than 320 positive reviews. It is unlikely this is a rogue app that has snuck into the Play Store. Satisfied by these findings, Alice installs the Eclair app on her mobile device.
[WARNING]
====
@ -152,7 +147,7 @@ After Alice initializes her Eclair Mobile wallet, she will see a brief tutorial
=== Loading Bitcoin Into the Wallet
Alice now has a LN wallet. But, it's empty! She now faces one of the more challenging aspects of this experiment: she has to find a way to acquire some bitcoin and load it onto her Eclair wallet.
Alice now has a Lightning wallet. But, it's empty! She now faces one of the more challenging aspects of this experiment: she has to find a way to acquire some bitcoin and load it onto her Eclair wallet.
[[acquiring-bitcoin]]
==== Acquiring Bitcoin
@ -175,7 +170,7 @@ Let's assume Alice has found a local Bitcoin ATM and has decided to buy some bit
.A Lamassu Bitcoin ATM
image:images/bitcoin-atm.png[]
To receive the bitcoin in her Eclair LN wallet, Alice will need to present a _Bitcoin Address_ from the Eclair LN wallet to the ATM. The ATM can then send Alice's newly acquired bitcoin to this bitcoin address.
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.
@ -214,19 +209,19 @@ Finally, if Alice bought bitcoin from a crypto-currency exchange, she could (and
Alice's bitcoin is now controlled by her Eclair wallet and has been recorded on the Bitcoin Blockchain. At this point, Alice's bitcoin is "on-chain," meaning that the transaction has been broadcast to the entire Bitcoin network, verified by all Bitcoin nodes, and "mined" (recorded) onto the Bitcoin blockchain.
So far, the Eclair Mobile wallet has behaved only as a Bitcoin wallet, and Alice hasn't used the Lightning Network features of Eclair. As is the case with many LN wallets, Eclair bridges Bitcoin and the Lightning Network by acting as both a Bitcoin wallet and a Lightning wallet.
So far, the Eclair Mobile wallet has behaved only as a Bitcoin wallet, and Alice hasn't used the Lightning Network features of Eclair. As is the case with many Lightning wallets, Eclair bridges Bitcoin and the Lightning Network by acting as both a Bitcoin wallet and a Lightning wallet.
Now, Alice is ready to start using the Lightning Network by taking her bitcoin "off-chain," so she can take advantage of the fast, cheap, and private payments that the Lightning Network offers.
==== Lightning Network Channels
Swiping right, Alice accesses the "LIGHTNING CHANNELS" section of Eclair. Here she can manage the LN channels that will connect her wallet to the Lightning Network.
Swiping right, Alice accesses the "LIGHTNING CHANNELS" section of Eclair. Here she can manage the channels that will connect her wallet to the Lightning Network.
Let's review the definition of a "Lightning Network Channel" at this point, to make things a bit clearer. Firstly, the word "channel" is a metaphor for a _financial relationship_ between Alice's LN wallet and another LN wallet. We call it a channel because it is a means for Alice's wallet and this other wallet to exchange many payments with each other on the Lightning Network (off-chain), without committing transactions to the Bitcoin Blockchain (on-chain).
Let's review the definition of a "Lightning Network Channel" at this point, to make things a bit clearer. Firstly, the word "channel" is a metaphor for a _financial relationship_ between Alice's Lightning wallet and another Lightning wallet. We call it a channel because it is a means for Alice's wallet and this other wallet to exchange many payments with each other on the Lightning Network (off-chain), without committing transactions to the Bitcoin Blockchain (on-chain).
The wallet or _node_ that Alice opens a channel to is called her _channel peer_. Once "opened," a channel can be used to send many payments back and forth between Alice's wallet and her channel peer.
Furthermore, Alice's channel peer can _forward_ payments via other channels further into the Lightning Network. This way, Alice can _route_ a payment to any wallet (e.g. Bob's LN wallet) as long as Alice's wallet can find a _path_ made by hopping from channel to channel, all the way to Bob's wallet.
Furthermore, Alice's channel peer can _forward_ payments via other channels further into the Lightning Network. This way, Alice can _route_ a payment to any wallet (e.g. Bob's Lightning wallet) as long as Alice's wallet can find a _path_ made by hopping from channel to channel, all the way to Bob's wallet.
All this to say: Alice needs one or more channels that connects her to one or more other nodes on the Lightning Network. She doesn't need a channel to connect her wallet directly to Bob's Cafe in order to send Bob a payment, though she can choose to open a direct channel too. Any well-connected node in the Lightning Network can be used for Alice's first channel. In this example, since we want to also demonstrate payment routing, we won't have Alice open a channel directly to Bob's wallet. Instead, we will have Alice open a channel to a well-connected node and then later use that node to forward her payment, routing it through any other nodes as necessary to reach Bob.
@ -243,7 +238,7 @@ Alice presses the plus symbol and is presented with four possible ways to open a
* Random node
* ACINQ node
A "node URI" is a Universal Resource Identifier (URI) that identifies a specific LN node. Alice can either paste such a URI from her clipboard or scan a QR code containing that same information. An example of a node URI is shown as a QR code in <<node-URI-QR>> and below it as a text string:
A "node URI" is a Universal Resource Identifier (URI) that identifies a specific Lightning node. Alice can either paste such a URI from her clipboard or scan a QR code containing that same information. An example of a node URI is shown as a QR code in <<node-URI-QR>> and below it as a text string:
While Alice could select a specific LN node, or use the "Random node" option to have the Eclair wallet select a node at random, she will select the "ACINQ Node" option to connect to one of ACINQ's well-connected LN nodes.
While Alice could select a specific Lightning node, or use the "Random node" option to have the Eclair wallet select a node at random, she will select the "ACINQ Node" option to connect to one of ACINQ's well-connected Lightning nodes.
Choosing the ACINQ node will slightly reduce Alice's privacy, as it will give ACINQ the ability to see all of Alice's transactions. It will also create a Single Point of Failure, since Alice will only have one channel, and if the ACINQ node is not available, Alice will not be able to make payments. To keep things simple at first, we will accept these trade-offs. In subsequent chapters we will gradually learn how to gain more independence and make fewer trade-offs!
@ -294,7 +289,7 @@ Did you notice that the channel amount seems to have changed? It hasn't: the cha
Alice now has everything ready to start using the Lightning Network. As you can see, it took a bit of work and a bit of time waiting for confirmations. However, now things get very fast and easy. The Lightning Network enables payments without having to wait for confirmations, as funds get settled in seconds.
Alice grabs her mobile device and runs to Bob's Cafe in her neighborhood. She is excited to try her new LN wallet and use it to buy something!
Alice grabs her mobile device and runs to Bob's Cafe in her neighborhood. She is excited to try her new Lightning wallet and use it to buy something!
==== Bob's Cafe
@ -336,4 +331,4 @@ Alice presses "PAY," and a second later, Bob's tablet shows a successful payment
=== Conclusion
In this chapter, we followed Alice as she downloaded and installed her first LN wallet, acquired and transferred some bitcoin, opened her first LN channel, and bought a cup of coffee by making her first payment on the Lightning Network. In the following chapters, we will look "under the covers" at how each component in the Lightning Network works, and how Alice's payment reached Bob's Cafe.
In this chapter, we followed Alice as she downloaded and installed her first Lightning wallet, acquired and transferred some bitcoin, opened her first LN channel, and bought a cup of coffee by making her first payment on the Lightning Network. In the following chapters, we will look "under the covers" at how each component in the Lightning Network works, and how Alice's payment reached Bob's Cafe.
@ -43,17 +43,17 @@ Not only does the construction of the payment channel work for the partners with
Since the channels are funds on a multisignature addresses and as the contracts are unpublished but presigned 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 allow the creation of the Lightning Network.
However the LN is so much more than the cryptographic protocols on top of the Bitcoin scripting language.
However the Lightning Network is so much more than the cryptographic protocols on top of the Bitcoin scripting language.
It is a full communication protocol that allows peers to communicate with each other via Lightning messages to achieve the transfer of bitcoin.
The communication protocol also defines how Lightning messages are being encrypted and exchanged.
A gossip protocol is part of the specification that is used to share public information about the topology of the network with the other participants.
This information is needed for Alice to be aware of the fact that Mallory has a channel with Bob so that she can decide to send a payment via Mallory to Bob.
Last but not least it is important to understand that the LN is nothing else than Bitcoin.
Last but not least it is important to understand that the Lightning Network is nothing else than Bitcoin.
We emphasize this as you might find people who will try to spread misinformation and create an artificial barrier between the "real" Bitcoin and the Lightning Network or even use terms like the Lightning Network coin.
We hope that as soon as you have studied the remainder of this book you do not need to believe what we just mentioned.
We rather hope that this book enables you to critically do your own research so that you are able to understand and verify the following (instead of trusting us):
Besides all the technical primitives, the LN protocol is a creative way to get most use out of Bitcoin by allowing an arbitrary amount of instant payments with instant settlements without the necessity to trust anyone else but the Bitcoin network.
Besides all the technical primitives, the Lightning Network protocol is a creative way to get most use out of Bitcoin by allowing an arbitrary amount of instant payments with instant settlements without the necessity to trust anyone else but the Bitcoin network.
=== Payment channels
@ -369,7 +369,7 @@ For instance, a user making a payment of 1 BTC can use a single output with valu
On Lightning, payments do not require inputs to be consumed but rather for the channel balance to be updated.
This is done by finding a path of channels with sufficient capacity from the sender to the receiver.
As many paths may exist, the choice of path to the LN payer is somewhat analogous to the choice of UTXO to the Bitcoin payer.
As many paths may exist, the choice of path to the Lightning Network payer is somewhat analogous to the choice of UTXO to the Bitcoin payer.
==== Change Outputs on Bitcoin vs No Change on Lightning
// The following is a working draft and suggested mile stones in the history of the LN.
// The following is a working draft and suggested mile stones in the history of the Lightning Network.
The history of the LN is nearly as old as the history of Bitcoin.
The history of the Lightning Network is nearly as old as the history of Bitcoin.
The first response to Satoshi Nakamoto's initial publication of the Bitcoin whitepaper on the metzdowd cryptography mailing list discussed the issue of scaling.
[quote, James A. Donald, First Response to the Bitcoin whitepaper https://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html ]
@ -59,7 +59,7 @@ In the worst case, this could be exploited by an attacker to prevent a party fro
Also as a payment channel this system was not too useful as the channel could only at total send the total amount of provided bitcoin in the funding transaction.
Once the timelock was over or all bitcoin were sent to B the channel would have to be closed.
The obvious idea of opening two channels one from A to B and one from B to A would not have helped as each of those channels would have to be closed and reestablished once it ran dry.
The core breakthrough for the LN to become a reality was the ability to create payment channels which technically can live forever and can send money back and forth as often as the peers wish to in combination with routing payments among several channels.
The core breakthrough for the Lightning Network to become a reality was the ability to create payment channels which technically can live forever and can send money back and forth as often as the peers wish to in combination with routing payments among several channels.
[TIP]
====
@ -67,7 +67,7 @@ You can watch a video explaining the construction and operation of unidirectiona
====
Surprisingly both properties took quite some while until the community figured them out.
Technically speaking the unidirectional payment channel has all the important ingredients (funding transaction to a 2-2 multisignature wallet, a transaction spending from the wallet encoding the balance, a timelock to allow refunding if the other side becomes unresponsive, off chain communication and the fact that no additional trust other than the one in the bitcoin network) of modern payment channels which are used in the LN.
Technically speaking the unidirectional payment channel has all the important ingredients (funding transaction to a 2-2 multisignature wallet, a transaction spending from the wallet encoding the balance, a timelock to allow refunding if the other side becomes unresponsive, off chain communication and the fact that no additional trust other than the one in the bitcoin network) of modern payment channels which are used in the Lightning Network.
Despite being widely used in today's world, we will study the unidirectional payment channel in more depth in this book as it is an easy to understand educational example to approach the construction of today's payment channels.
This setup has one safety issue as transactions have been malleable without the segwit upgrade.
A problem that needed to be solved for any payment channel construction that we know up till today and which has been fixed in August 2017.
@ -88,7 +88,7 @@ The next day, probably in response to Gavin's blogpost, Meni Rosenfeld started a
As Hashed Timelocked Contracts have neither been invented nor seen to solve the issue of trustless routing, Rosenfeld imagined trusted routing nodes.
Without mentioning the term network or routing of payments the idea of connecting payment channels and being able to send funds from anyone to anyone else even if there was no direct channel was born.
In Rosenfelds solution payment providers would be the ultraservers and they would settle the transactions among themselves based on trust.
It took us another 3 years until the LN whitepaper emerged which had solved all the bits and bolts necessary to get rid of the trust in Rosenfelds solution.
It took us another 3 years until the Lightning Network whitepaper emerged which had solved all the bits and bolts necessary to get rid of the trust in Rosenfelds solution.
It was 2013 that Bitcoin developer Mike Hearn referred to Meni Rosenfelds proposal and suggesting to reactivate the `nSequence` field which Satoshi previously had deactivated.footnote:HearnBitcoinDev[]
Also Hearn referred to a section on the contracts article talking about the case of micropayment channels with the help of `nSequence`.
The paper can be found at https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
Submarine Swaps::
Submarine Swaps enable transfers between on-chain addresses and off-chain locations, like the LN. Just as standard LN transfers chain payments by means of HTLCs that make the final claim on funds conditional on the recipient revealing a secret to all links in the chain, Submarine Swaps use the same logic and procedure to transfer funds across the on-chain/off-chain barrier with minimal trust. They can also be used to enable transfers from another chain, say Litecoin, to an off-chain LN address. Reverse Submarine Swaps allow bitcoin transfers in the opposite direction that is, from an off-chain LN location to an on-chain address.
Submarine Swaps enable transfers between on-chain addresses and off-chain locations, like the Lightning Network. Just as standard LN transfers chain payments by means of HTLCs that make the final claim on funds conditional on the recipient revealing a secret to all links in the chain, Submarine Swaps use the same logic and procedure to transfer funds across the on-chain/off-chain barrier with minimal trust. They can also be used to enable transfers from another chain, say Litecoin, to an off-chain LN address. Reverse Submarine Swaps allow bitcoin transfers in the opposite direction that is, from an off-chain LN location to an on-chain address.
timelocks::
A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts.
Rene Pichardt
4 years ago