Welcome to Mastering the Lightning Network or "LN" as we'll call it throughout the book!
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.
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 +11,7 @@ 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 and many users increase the fees they're willing to pay in order to buy space for their transaction in the next block. 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, 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?
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.
@ -27,7 +27,7 @@ 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. An 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 an LN node and a Bitcoin node.
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.
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.
@ -35,8 +35,8 @@ Blockchains, especially open blockchains like Bitcoin, attempt to minimize or el
Every other component of a lightning wallet brings similar considerations of trust. If all the components are under the control of the user, then the amount of trust in third parties is minimized, bringing maximum power to the user. Of course, this is a direct trade-off, as with that power comes the responsibility to manage complex software.
Every user must consider their own technical skills before deciding what type of lightning wallet to use. Those with strong technical skills should use a lightning wallet that puts all of the components under the direct control of the user. Those with less technical skill but a desire to control their funds, should choose a _non-custodial_ lightning wallet, even if some of the components (other than the keystore) rely on some trusted third parties.
Often the trust in those cases relates to privacy.
Every user must consider their own technical skills before deciding what type of lightning wallet to use. Those with strong technical skills should use a lightning wallet that puts all of the components under the direct control of the user. Those with less technical skill but a desire to control their funds, should choose a _non-custodial_ lightning wallet, even if some of the components (other than the keystore) rely on some trusted third parties.
Often the trust in those cases relates to privacy.
If users decide to outsource some functionality to a third party they usually give up some privacy as the third party will learn some information.
Finally, those seeking simplicity and convenience, even at the expense of control and security, may choose a custodial lightning wallet. This is the least challenging option, but it _undermines the trust model of cryptocurrency_ and should, therefore, be considered only as a stepping stone towards more control and self-reliance.
@ -81,11 +81,11 @@ In the next section, we will introduce our first user and walk through their fir
=== 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 an 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 LN 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.
==== Downloading and Installing an LN Wallet
==== Downloading and Installing a LN Wallet
When looking for a new cryptocurrency wallet, you must be very careful to select a secure source for the software.
@ -152,7 +152,7 @@ After Alice initializes her Eclair Mobile wallet, she will see a brief tutorial
=== Loading Bitcoin Into the Wallet
Alice now has an 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 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.
[[acquiring-bitcoin]]
==== Acquiring Bitcoin
@ -261,17 +261,17 @@ Choosing the ACINQ node will slightly reduce Alice's privacy, as it will give AC
Alice selects "ACINQ Node" and is ready to open her first LN channel.
==== Opening an LN Channel
==== Opening a LN Channel
When Alice selects a node to open a new channel, she is asked to select how much bitcoin she wants to be allocated to this channel. In subsequent chapters, we will discuss the implications of these choices, but for now, Alice will allocate almost all her funds to the channel. Since she will have to pay transaction fees to open the channel, she will select an amount a few dollars (or a few thousandths of a bitcoin) less than her total balance.
Alice allocates 0.018BTC of her 0.020 total to her channel and accepts the default fee rate, as shown in <<eclair-open-channel>>.
[[eclair-open-channel]]
.Opening an LN Channel
.Opening a LN Channel
image:images/eclair-open-channel-detail.png[]
Once she clicks "OPEN", her wallet constructs the special Bitcoin transaction that opens an LN channel, known as the _funding transaction_. The funding transaction is sent to the Bitcoin Network for confirmation.
Once she clicks "OPEN", her wallet constructs the special Bitcoin transaction that opens a LN channel, known as the _funding transaction_. The funding transaction is sent to the Bitcoin Network for confirmation.
Alice now has to wait again (see <<eclair-channel-waiting>>) for the transaction to be recorded on the Bitcoin Blockchain. As with the initial Bitcoin transaction that she used to acquire her bitcoin, she has to wait for six or more confirmations (approximately one hour).
@ -50,9 +50,9 @@ Adjust heading style in each section as follows:
1. Only the chapter/section should be level 2, everything else should be level 3 and below (level 1 is the book title itself). Each asciidoc file should start with a "==" heading.
2. Headings should be all lower case, except for first letter, proper nouns and acronyms. "An introduction to the Lightning Network", "Explaining the physics of fulgurites" etc.
3. Acronyms are spelled out, capitalized, with the acronym in parentheses (eg. "Hash Time-Locked Contract (HTLC)"). Once you have spelled out an acronym in one heading, we can keep it as an acronym only in subsequent headings.
3. Acronyms are spelled out, capitalized, with the acronym in parentheses (e.g. "Hash Time-Locked Contract (HTLC)"). Once you have spelled out an acronym in one heading, we can keep it as an acronym only in subsequent headings.
4. No period at the end of headings. Question mark if it is a question (generally avoid question headings, unless really appropriate)
5. Should include a unique anchor all lower case, underscore separated, within double square brackets (eg. [[intro_to_htlcs]]).
5. Should include a unique anchor all lower case, underscore separated, within double square brackets (e.g. [[intro_to_htlcs]]).
6. Headings should be followed by a blank line.
7. Heading should be followed by a paragraph of text, not a lower-level heading without any text. If you find one like this, add a TODO comment (line of 4 slashes "////", line with "TODO: add paragraph", line of 4 slashes)
8. Often it seems useful to link to a webpage / url. Since the research community figured out that every year about 50% of all outstanding url's become invalid we encourage you to use the wayback machine / Web Archive at: http://web.archive.org and provide a link to a saved copy of the web page.
Andreas M. Antonopoulos
4 years ago
committed by
GitHub