@ -9,7 +9,7 @@ Users of the LN are able to route payments to each other at virtually no cost an
Users who transact on the LN do not need to wait for block confirmations for payments.
Once a payment on the LN has completed, it is final and cannot be reversed: like a Bitcoin transaction, a payment on the LN can only be refunded by the recipient.
While "on-chain" Bitcoin transactions are broadcast and verified by all nodes in the network, transactions routed on the LN are transmitted between pairs of nodes and not visible to everyone, resulting in much greater privacy.
The LN uses onion routing, similar to the protocol used by The Onion Router (TOR) privacy network, so that even the nodes involved in routing a transaction are incapable of identifying the source, recipient, or route.
The LN uses onion routing, similar to the protocol used by The Onion Router (TOR) privacy network, so that even the nodes involved in routing a transaction are only directly aware of their predecessor and successor in route.
=== Motivation for the Lightning Network
@ -33,17 +33,26 @@ ____
While James A. Donald was probably referring to maintenance of the unspent transaction outputs (UTXOs) database, it quickly became clear that the need for all participants to verify and propagate all transactions in the network would become overly burdensome.
A key requirement for a second layer protocol such as Lightning (which will be described in greater depth later in this book) is the ability to sequence transactions external to the blockchain. In the first versions of Bitcoin, Satoshi Nakamoto recognized this and introduced a data field called `nSequence` into the input transaction data.
A key requirement for a second layer protocol such as Lightning (which will be described in greater depth later in this book) is the ability to sequence transactions external to the blockchain (for deferred settlement). In the first versions of Bitcoin, Satoshi Nakamoto recognized this and introduced a data field called `nSequence` into the input transaction data.
The `nSequence` field was intended to allow users to transmit updated versions of a transaction to the network, changing the outputs of a transaction, effectively creating a payment channel.
Such a payment channel would then be valid as long as the transaction was not mined.
According to a mailing list post in 2013, by early Bitcoin developer Mike Hearn, Satoshi Nakamoto envisioned this construct for high frequency trading.footnote:HearnBitcoinDev[Mike Hearn on Bitcoin-dev - April 16th 2013 - Anti DoS for tx replacement http://web.archive.org/web/20190501234757/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html.]
According to a mailing list post in 2013, by early Bitcoin developer Mike Hearn, Satoshi Nakamoto envisioned this construct for high frequency trading.footnote:HearnBitcoinDev[Mike Hearn on Bitcoin-dev - April 16th 2013 - Anti DoS for tx replacement http://web.archive.org/web/20190501234813/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002417.html.]
However, there were some weaknesses in this initial formulation that limited its potential. Firstly, the payment channel would only be open until the transaction was mined in a block, either limiting the duration of the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number, reducing the utility of this mechanism.
However, there were some weaknesses in this initial formulation that limited its potential. Firstly, the payment channel would only be open until the transaction was mined in a block, either limiting the duration of the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number (to replace the state of the channel in the mempool), reducing the utility of this mechanism.
The Revocable Sequence Maturity Contracts (RSMC), which formed payment channels in the first version of the Lightning Network, reference in their name the fact that they fixed this weakness of the `nSequence` field.
The Revocable Sequence Maturity Contracts (RSMC), which formed payment channels in the first version of the Lightning Network, reference in their name the fact that they leveraged a new upgrade to Bitcoin that re-purposed the `nSequence` number to enforce a delay before an output could be spent.
Using this new feature of the `nSequence` number, the RSMC was able to enforce a novel penalty mechanism: each time a party goes to claim a state on chain (which may or may not be the latest), the other party is given a period of time to challenge that claim (enforced by the `nSequence` number of `OP_CHECKSEQUENCEVERIFY`).
If a participant of the channel is able to present evidence to the blockchain of an intent to claim a revoked state, then the honest party s rewarded with all the funds of the cheating party.
This enforcement of prior revoked states (only the latest channel state is valid) created a very strong economic incentive via the penalty mechanism: if a party attempts to renegade a signed contract, they lose all their funds!
This "challenge period" enforced by the `nSequence` was one of the novel contributions of the RSMC to the payment channel design space: the blockchain was used as a court wherein disputes could be handled objectively.
In the common case, both parties can update their channels off-chain and never need to touch the blockchain. In the rare case the blockchain becomes a court which will objectively pay out funds based on witnesses provided during the challenge period.
This is achieved by creating an economic incentive via a penalty mechanism; otherwise, the most recent transaction or update in the payment channel is published to the Bitcoin network, and becomes enforceable in this way.
// find / add sources for some of the claims
In July of 2011, on the bitcointalk.org forum, a pseudonymous user by the name of _hashcoin_ suggested using Timelocks via the `nLockTime` function of the Bitcoin network to solve the custody problem of exchanges.footnote:[Hashcoin on Bitcoin talk on July 4th 2011 - Instant TX for established business relationships (need replacements/nLockTime) http://web.archive.org/web/20190419103503/https://bitcointalk.org/index.php?topic=25786.0]
@ -62,7 +71,11 @@ Therefore, Bob can securely receive more updates to the channel balance as long
This mechanism would allow two users to engage in several smaller transactions which all happened outside of the Bitcoin network.
While this construction of the unidirectional payment channel would have solved the custody problem of exchanges it has never been widely implemented.
We can only speculate for reasons and guess that the overhead communication would have had to be standardized - as it is nowadays in the LN specification - which might have been too much overhead in the early days of Bitcoin.
A fundamental blocker to deploying payment channels in production was the issue of transaction malleability.
In the worst case, this could be exploited by an attacker to prevent a party from closing the channel on-chain as their settlement transaction had a chance to become invalidated if the funding transaction has it's transaction ID inadvertently changed.
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.
@ -75,7 +88,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.
Despite being rather useless 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.
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 +101,7 @@ Andresen noted that there might be a better construction which would require les
Andresen's work led to many discussions on Bitcointalk forum, and later on the bitcoin-development mailing list. These discussions resulted in the first construction of the first unidirectional payment channels.
To sum this up: Andresen used a similar construction as the unidirectional channel.
They key difference was that a trusted party would have co-signed the spend of the funding transaction.
The key difference was that a trusted party would have co-signed the spend of the funding transaction.
The Ultra Server was not able to steal Bitcoin.
The next day, probably in response to Gavin's blogpost, Meni Rosenfeld started a discussion related to how these ideas could be combined.footnote:[Meni Rosenfeld on Bitcointalk - July 5th 2012 - Trustless, instant, off-the-chain Bitcoin payments http://web.archive.org/web/20190419103457/https://bitcointalk.org/index.php?topic=91732.0]
@ -164,11 +177,13 @@ In this section we will start by choosing the right software to demonstrate the
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 communicates on a peer-to-peer basis with other LN nodes, forming the Lightning _Network_ itself. Nodes also include "wallet" functionality, so they can send and receive payments over the LN and on the Bitcoin network.
Lightning network nodes also need access to the Bitcoin blockchain, or another blockchain such as Litecoin. Users have the highest degree of control by running their own authoritative Bitcoin node and LN node. However, LN nodes can also rely on Bitcoin nodes operated by a third party, by using a lightweight protocol such as _Simplified Payment Verification (SPV)_ or the _Neutrino_ protocol.
Lightning network nodes also need access to the Bitcoin blockchain, or another blockchain such as Litecoin. Users have the highest degree of control by running their own authoritative 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.
==== Lightning Wallets
A fully functional lightning wallet contains a LN node and communicates as a peer on the LN. However, some lightning wallets do not contain an LN node, but rely on an LN node operated by a third party. Furthermore, some "lightning wallets" are _custodial_, meaning that their funds are in the custody of a third party.
A fully functional lightning wallet contains a LN node and communicates as a peer on the LN. However, some lightning wallets do not contain an LN node, but rely on an LN node operated by a third making it _custodial_, meaning that their funds are in the custody of a third party.
Every user must consider their own technical skills before deciding what type of lightning wallet to use. Those with strong technical skills should run their own LN node. Those with less technical skill but a desire to control their funds without any third party custody, should choose a _non-custodial_ lightning wallet which relies on a third-party LN node. Finally, those seeking simplicity and convenience, even at the expense of control and security, may choose a custodial lightning wallet.
@ -193,3 +208,4 @@ Here are some current examples of LN node and wallet applications for different
| eclair | Server | Full Node | Bitcoin Core/Electrum | Full Control |
| Zap Desktop | Desktop | Full Node | Bitcoin Core/btcd | Full Control |
| Eclair Mobile | Mobile | Lightweight | Electrum | Full Control |
@ -189,6 +189,12 @@ The penalty for broadcasting an old commitment transaction is to give the other
This means that Bob would have the ability to claim 10 mBTC from the output that belonged to Alice in her original Commitment transaction if she publishes it after she has agreed to a second commitment transaction in which she would only own 7 mBTC and Bob would own 3 mBTC.
With such a strong penalty mechanism in place Alice should never purposely publish an old state as she would almost always lose her remaining funds in the channel.
[Note]
====
In Mastering Bitcoin Andreas states it very elegantly:
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 souble-spending its inputs with another transaction before it was mined. That's why we used timelocks [...] to ensure that more recent commitments could be spent before older commitments were valid.
====
We will now see how such a penality mechanism can be included to the above construction of the commitment transactions.
Usually the commitment transaction has at least two outputs, one for each partner.
However a channel partner will encumber their own output with a timelock and a revocation secret.
@ -332,9 +338,8 @@ As long as a person follows the protocol and has their node secured, there is no
However there is the risk of paying fees when opening a channel.
Any risk should come with a potential reward.
In our case the reward is that she can send and receive payments of bitcoin on the Lightning Network at any time and that she can earn bitcoin by forwarding other payments.
Alice decides that the reward is enough for her to take the risk of the fees.
As Bob can directly close the channel which costs fees paid by Alice she will have to have a little trust in Bob.
Alice decides that the reward is enough for her to take on the fee risk.
Since Bob can directly close the channel, which costs fees paid by Alice, she will need to have a little trust in Bob.
After you discovered the overview of how the lightning network protocol worked in the last chapter we now want to present a few more details about the actual communication that takes place between the nodes to fulfill the most important tasks like opening a channel, forwarding a payment and closing the channel.
All communication takes place over a secure, encrypted and authenticated connection.
[NOTE]
====
While the specification of how to set up such a connection is part of the lightnig network protocol and can be read upon in BOLT08 we will omit this in the book.
The reason is that BOLT08 mainly follows the handshake patterns from the noise protocol framework which is a standard template system for secure cryptographic handshakes.
This protocol framework is also used by Whatsapp and Wireguard and is very well documented.
If you want to learn more we suggest you check out http://www.noiseprotocol.org/
The Lightning Network is specified in the lightning-rfc by the open source community.
The lightning-rfc is also called Basics of Lightning Technology (BOLT) which is a collection of documents (BOLTs) that specify the components needed for the protocol.
There are several teams who implement the BOLTs as software which you can run on your computer or a server.
All those teams also contribute to the BOLTs.
In this chapter you will learn how to set up each of the software packages for each of the Lightning Network implementations.
We presented them in alphabetical order to emphasize that we generally do not prefer or recommend one over the other.
It will depend on your preferences which of the software packages you might want to work with.
== Running and Maintaining a Lightning Network Node
=== Implications of Configurations
=== Backups
==== Static channel backups
=== Security of your machine
==== Hot wallet risk
==== Watchtowers
=== Channel management
In order to participate on the Lightning Network you need to have payment channels on your Lighting networknode.
It might be confusing to decide with whom to open channels and which parameters to set for the specific channel policies.
An obvious strategy might be to open channels with shops where you want to buy products.
But what happens if those shops do only accept large channels which are beyond your funds or do not accept public channels at all?
Also if you are not a consumer but a vendor you want to receive payments on the Lightning Network.
Therefor you need others to open channels with you or you need to open channels and use submarine swaps and rebalancing techniques to provide yourself with the ability to receive payments.
Both techniques will be discussed later in this chapter.
Andreas M. Antonopoulos
5 years ago
committed by
GitHub