The Lightning Network (LN) is a payment system for Bitcoin and other blockchains that support similar capabilities as Bitcoin.
It is a second layer protocol on top of Bitcoin that defines rules and contracts which enable fast, secure, private, trustless and permissionless transfer of Bitcoin.
Users of the LN are able to transfer Bitcoin among each other at virtually no cost and in real time.
Users who transact on the LN are not required to wait for block confirmations for payments.
Once a payment arrives, it is final and cannot be reversed.
Like a standard Bitcoin transaction, a payment on the LN can only be refunded by the recipient.
While all Bitcoin transactions are stored in the blockchain where they can be tracked, the payments on the LN are off-chain and offer more privacy than on-chain Bitcoin transactions.
The Lightning Network (LN) is a "second layer" protocol on top of Bitcoin and other blockchains that enables fast, secure, private, trustless and permissionless payments.
Users of the LN are able to route payments to each other at virtually no cost and in real time.
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.
Due to the use of onion routing, an anonymous communication protocol used by The Onion Router (TOR) privacy network, even the nodes involved in a transaction are incapable of identifying the recipient.
=== Motivation for the Lightning Network
// TODO
=== Lightning Network Basic Concepts
// TODO Introduce and briefly explain the basic concepts of the LN
=== Lightning Network Uses, Users, and Their Stories
As an electronic cash system it preserves the 3 most important properties of money (medium of exchange, store of value, and unit of account).
As an electronic cash system Bitcoin preserves the 3 most important properties of money (medium of exchange, store of value, and unit of account).
The invention of money (and in particular Bitcoin) was primarily made to facilitate trade and enable the exchange of value between people.
However, without the LN, Bitcoin is hard to be used concurrently by millions of people.
Therefore, in order to fully understand the uses of the LN, we'll examine it from the perspective of people using it.
@ -151,49 +156,39 @@ They usually pay fees for using point of sales services and several payment meth
This directly decreases the margin on which merchants operate.
A merchant will be happy to get an additional payment method which is virtually for free to the merchant.
An example of a merchant is Silke.
Silke runs a small coffee shop in an upmarket street in Berlin.
She knows about Bitcoin and wants to accept it in her shop, but has been reluctant to do so because she knows that Bitcoin payments take approx. 10 minutes to be confirmed into her account.
However with the LN, she knows that her regular clients, such as Joerg can pay for their coffee at her shop, quickly and with negligible fees.
Additionally, by using the LN, Silke has all funds deposited instantly to her wallet and with usually smaller fees on her side as well.
Ultimately this allows her to provide a better service or to offer better pricing for her products.
=== Getting Started
// TODO intro paragraph - no empty headings!
In this section we will start by choosing the right software to demonstrate the LN and learn by example. We will examine the choices of two users who represent a common use-case for the LN. 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 payment over the LN.
==== 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 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.
==== Choosing a Lightning Network Wallet
==== Lightning Wallets
* full nodes (c-lightning, eclair, lnd) + remote controls
* phone / desktop wallets (SPV clients)
* custodial services / wallets?
// Mastering bitcoin also had a section about custodial web wallets. So it might be fair to include them.
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.
==== Quick Start
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.
* We start with a mobile wallet like eclair
* Verify the authenticity of the software (e.g. App store / Acinq website / github)
** discuss that a general phishing scheme might consist of tricking you to download a similar looking software
Here are the three broad categories of lightning wallets and the relative degree of control they offer to the user:
[[getting_first_bitcoin]]
==== Getting Your First Bitcoin on the Lightning Network
* Trade fiat for Bitcoin (as in Mastering Bitcoin)
[[using_own_bitcoin]]
==== Process for people who already own Bitcoin ====
Lightning wallets can be installed on a variety of devices, including laptops, servers and mobile devices. To run an LN node and an authoritative 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. On a laptop or mobile device you can run a LN node that relies on a third-party Bitcoin node for access to the blockchain.
* send bitcoin to lightning wallet (1 on-chain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoins to the lightning network wallet first)
* find a node to open a channel with (Node explorer / Autopilots / ...)
* open a connection
* open a channel
* wait confirmations for the channel to become operational
Here are some current examples of LN node and wallet applications for different types of devices:
[[sending_receiving]]
==== Sending and Receiving Bitcoin on the Lightning Network
* have the person who helps onboarding open a payment channel (As complex as a bitcoin transaction)
* showcase how the funds now can be send back and forth
** create invoice
** decode invoice (do always before paying!)
** pay an invoice
* showcase how an arbitrary invoice can be paid e.g. https://voting.ln.rene-pickhardt.de
* full nodes (c-lightning, eclair, lnd) + remote controls
* phone / desktop wallets (SPV clients)
* custodial services / wallets?
// Mastering bitcoin also had a section about custodial web wallets. So it might be fair to include them.
==== Quick Start
* We start with a mobile wallet like eclair
* Verify the authenticity of the software (e.g. App store / Acinq website / github)
** discuss that a general phising scheme might consist of tricking you to download a similar looking software
[[getting_first_bitcoin]]
==== Getting Your First Bitcoin on the Lightning Network
* Trade fiat for Bitcoin (as in Mastering Bitcoin)
[[using_own_bitcoin]]
==== Process for people who already own Bitcoin ====
* send bitcoin to lightning wallet (1 onchain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoins to the lightning network wallet first)
* find a node to open a channel with (Node explorer / Autopilots / ...)
* open a connection
* open a channel
* wait confirmations for the channel to become operational
[[sending_receiving]]
==== Sending and Receiving Bitcoin on the Lightning Network
* have the person who helps onbording open a payment channel (As complex as a bitcoin transaction)
* showcase how the funds now can be send back and forth
** create invoice
** decode invoice (do always before paying!)
** pay an invoice
* showcase how an arbitrary invoice can be paid e.g. https://voting.ln.rene-pickhardt.de
After you have had your first hand experiences with the lightning network and learnt about its most important properties we now want to give you a high level overview of the components that are used to build the lightning network.
After you have had your first hand experiences with the Lightning Network and learnt about its most important properties we now want to give you a high level overview of the components that are used to build the Lightning Network.
This overview will not contain all the technical details.
Our goal is rather to help you to become aware of the most imporant concepts and building blocks.
Our goal is rather to help you to become aware of the most important concepts and building blocks.
If you have a lot of experience in computer science, cryptography, Bitcoin and protocol development this chapter should probably be enough for you to be able to fill out the connecting details by yourself.
If you are less experienced this chapter shall give you a good overview so that after reading it you will most likely have a much easier time reading through the rather formal protocol specification which is known as BOLTs (Basics of Lightning Technology)
In case you are a beginner this chapter shall help you to read get a better access to the more technical chapters of the book.
Tha being said we are aware of the fact that some readers might have a hard time following high level descriptions without explaining all the details.
If you are less experienced this chapter shall give you a good overview so that after reading it you will most likely have a much easier time reading through the rather formal protocol specification which is known as BOLTs (Basics of Lightning Technology).
In case you are a beginner this chapter shall help you to get a better access to the more technical chapters of the book.
That being said we are aware of the fact that some readers might have a hard time following high level descriptions without explaining all the details.
If you are one of those you might very well want to skip this chapter.
Let us start with a one sentence definition of what the Lightning Network (LN) is and break this down in the remainder of this chapter.
@ -15,81 +15,81 @@ Please do not get frustrated if this one sentence does not make sense to you rig
**The Lightning Network (LN) is a network of payment channels on top of the Bitcoin protocol together with a communication protocol that defines how participants set up and execute the smart contracts that enable the Lightning Network**
We will see that payment channels are nothing else than a 2 out of 2 multisignature address on the Bitcoin Network for which you hold a key and your channel partner hold the other key.
We will see that payment channels are nothing else than a 2 out of 2 multisignature address on the Bitcoin Network for which you hold a key and your channel partner holds the other key.
This multisignature address comes together with a cryptographic protocol that is established by creating a sequence of transactions that spend from this address.
Those transactions will be negotiated between you and your partner in secret and are attempts to double spend from that multisignature address.
The latest transaction of that sequence encodes the balance of your channel and defines how the funds of the multisig address are to be divided between you and your partner.
The latest transaction of that sequence encodes the balance of your channel and defines how the funds of the multisignature address are to be divided between you and your partner.
The transactions in this sequence make use of the scripting language in Bitcoin.
The design will discourage you and your channel partner from publishing an old (outdated) state about your channel.
Thus collaboratively adding a new transaction to this sequence is equivalent to moving ownership of funds without the bitcoin network being aware of it.
Thus collaboratively adding a new transaction to this sequence is equivalent to moving ownership of funds without the Bitcoin network being aware of it.
Since this construction or protocol is an agreement between you and your partner you could call it a contract.
As it is a rather smart construction people might call it a smart contract.
[NOTE]
====
When someone says they own Bitcoin they would usually mean that they know the private key of a bitcoin address that has some unspent transaction outputs (UTXOs).
The private key allows the owner to produce a signature for a transaction that spends the Bitcoin by sending it to a different address.
Thus one can define ownership of Bitcoin as the ability to spend them.
If you have an unpublished but signed transaction from a 2-2 multisignature address where some outputs are send to an address that you controll and additionally you own one of the private keys of the 2-2 multisig address you effectively own the bitcoins of that output.
Without your help no other transaction from the 2-2 multisig address can be produced.
However without the help of anybody else you can transfer the funds to an address which you control.
On the Lightning Network ownership of your finds is almost always encoded with you having a pre-signed transaction spending from a 2-2 multisig address.
When someone says they own bitcoin they would usually mean that they know the private key of a bitcoin address that has some unspent transaction outputs (UTXOs).
The private key allows the owner to produce a signature for a transaction that spends the bitcoin by sending it to a different address.
Thus one can define ownership of bitcoin as the ability to spend them.
If you have an unpublished but signed transaction from a 2-2 multisignature address where some outputs are send to an address that you control and additionally you own one of the private keys of the 2-2 multisignature address you effectively own the bitcoin of that output.
Without your help no other transaction from the 2-2 multisignature address can be produced.
However without the help of anybody else you can transfer the funds to an address which you control.
On the Lightning Network ownership of your funds is almost always encoded with you having a pre-signed transaction spending from a 2-2 multisignature address.
====
Additionally these contracts have the option to connect channels in a way that one can forward payments from one channel to another.
So Alice can send money to Bob if Alice had a channel with Mallory and Mallory had a channel with Bob.
Surprisingly it is possible to extend the smart contracts which operate the channel so that Mallory has no way of stealing the funds that are being routed through her.
Not only does the construction of the payment channel work for the partners without the neccessity to trust each other but the entire network works without the neccessity to trust any other participant.
Since the channels are funds on a multisig 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!
Surprisingly, it is possible to extend the smart contracts which operate the channel so that Mallory has no way of stealing the funds that are being routed through her.
Not only does the construction of the payment channel work for the partners without the necessity to trust each other but the entire network works without the necessity to trust any other participant.
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 lead to the the LN protocol.
The aforementioned innovations are certainly the major breakthrough that lead to the the LN protocol.
However the LN is so much more than the cryptographic protocols on top of the Bitcoin scripting language.
It is a full communication protocol which consists of a peer protocol that defines how peers 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.
It is a full communication protocol which consists of a peer protocol that defines how peers 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.
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 and you do not need to believe what we just mentioned.
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 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.
=== Payment channels
As you have seen in the last chapter in order to use the LN you had to ask your wallet software to establish a payment channel with at least one other participant of the network.
From a computer science perspective a payment channel is cryptographic communication protocol between you and your channel partner.
As you have seen in the last chapter, in order to use the LN you had to ask your wallet software to establish a payment channel with at least one other participant of the network.
From a computer science perspective a payment channel is a cryptographic communication protocol between you and your channel partner.
It allows the both of you to send funds back and forth as often as you wish.
The channel is only limited by two things:
First, the time it takes for the internet to transfer the few bytes of data that the protocol requires to make a payment between you and your partner.
Second, the capacity of the channel, which is the term for the funds that have been assigned to the channel.
Payment channels have a couple of very interesting and useful properties.
* 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 in a way that there is little to no trust involved between you and your channel partner. If your partner becomes unresponsive or tries to cheat on you, you can ask the bitcoin network to act as a court system resolving the conflict according to the rules that you and your partner have agreed previously agreed upon.
* The capacity of the channel will be split between you and your partner. In that sense you will already at that level gain more privacy as in comparison to the Bitcoin Network where every transaction is public. Within a payment channels the amount and values of payments are kept secretely between you and your partner. Only the final balance which is the agreegate of all payments in that channel will become visible on the Bitcoin blockchain if the payment channel is closed.
* As the time to update the channel is only bound by the time it takes to transmite a couple Bytes making a payment within a payment channel is almost instant.
* 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 in a way that there is little to no trust involved between you and your channel partner. If your partner becomes unresponsive or tries to cheat on you, you can ask the Bitcoin network to act as a court system resolving the conflict according to the rules that you and your partner have agreed previously agreed upon.
* The capacity of the channel will be split between you and your partner. In that sense at that level you will have already gained more privacy as in comparison to the Bitcoin Network where every transaction is public. Within payment channels the amount and values of payments are secretely kept between you and your partner. Only the final balance which is the aggregate of all payments in that channel will become visible on the Bitcoin blockchain if the payment channel is closed.
* As the time to update the channel is the only bound, making a payment within a payment channel is almost instant.
Bitcoin had to be about 5 years old until talented developers figured out how payment channels could be constructed and by now there are at least 3 differnt constructions known.
Bitcoin had to be about 5 years old until talented developers figured out how payment channels could be constructed and by now there are at least 3 different constructions known.
This chapter will only focus on the "Poon, Drayja" - Construction since it is actually being used in the Lightning Network and was first described in the Lightning Network whitepaper.
The other two constructions are the Duplex Micropayment channels which have been introduced by Christian Decker around the same time as the "Poon, Drayja" - channels and the "eltoo" - channels which have been introduced in 2018 by Christian Decker, Rusty Russel and our co-author Olaoluwa Osuntokun.
The later seem much easier to implement and to have a couple of nicer properties.
However they need a new OP_CODE to the Bitcoin scripting language and can currently not be implemented on top of the bitcoin mainnet.
==== Multisig addresses
Payment channels are a smart contract that builds on top of a 2-2 multisignature addresses which will by spent by Segwit transactions.
Knowing the properties of Multisignature addresses you will be able to understand the exact construction of payment channels.
Payment channels are smart contracts that build on top of 2-2 multisignature addresses which will be spent by Segwit transactions.
By knowing the properties of multisignature addresses you will be able to understand the exact construction of payment channels.
Thus at this point we will not review all the technical details about multisignature addresses and Segwit but just stick to the properties.
If you know Bitcoin so well that you are familiar with those topics feel free to skip this section.
[TIP]
====
A deep dive into the topic discussed here is presented in chapter 7 of Mastering Bitcoin which can be found at: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc.
In case you are not familiar with P2PKH addresses and the basic format and scripting language of Bitcoin we encourage you to study chapter 6 of Mastering Bitcoin.
There is also a video on Rene's youtube channel which disects the Bits and Bytes of a transaction spending from a P2PKH output at: https://youtu.be/1n4g3eYX1UI
====
A deep dive into the topic discussed here is presented in chapter 7 of Mastering Bitcoin which can be found at: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc.
Also, in case you are not familiar with P2PKH addresses and the basic format and scripting language of Bitcoin we encourage you to study chapter 6 of Mastering Bitcoin which can be found at: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc.
There is also a video on Rene's youtube channel which dissects the Bits and Bytes of a transaction spending from a P2PKH output at: https://youtu.be/1n4g3eYX1UI
====
To allow escrow services and complex ownership constalations between several stakeholders the bitcoin scripting language provided multisignature addresses.
To allow escrow services and complex ownership configurations between several stakeholders, the Bitcoin scripting language provides multisignature addresses.
The general form of a locking script setting an M-of-N multisignature condition is:
----
@ -117,10 +117,10 @@ The two scripts together would form the combined validation script:
----
==== Funding Transaction
You already learnt that one of the most important building blocks of a payment channel is a 2-2 multisig address.
To open a payment channel one must send Bitcoins to that address.
The Bitcoin transaction - which will be included to the Bitcoin Blockchain - that sends the Bitcoin to that 2-2 multisignature address is called the funding transaction.
While there is the possability for 2 participants of the Lightning Network to open a private payment channel this transaction will always be publically visible to the bitcoin network.
You already learnt that one of the most important building blocks of a payment channel is a 2-2 multisignature address.
To open a payment channel one must send bitcoins to that address.
The Bitcoin transaction - which will be included to the Bitcoin Blockchain - that sends the bitcoin to that 2-2 multisignature address is called the funding transaction.
While there is the possibility for 2 participants of the Lightning Network to open a private payment channel, this transaction will always be publicly visible to the Bitcoin network.
The amount of Bitcoin sent to the multisignature address is called the capacity of the channel.
Two channel partners will never be able to conduct larger payments on that channel than the channel capacity.
What cannot publicly be seen from the funding transaction is how the funds in that open channel are being distributed between the two channel partners.
@ -128,66 +128,66 @@ What cannot publicly be seen from the funding transaction is how the funds in th
[Note]
====
You will often hear that people complain about bitcoins being locked to the lightning network which can't move freely.
You will often hear that people complain about bitcoin being locked to the Lightning Network which can't move freely.
This is obviously a lie.
One can use the bitcon network to send bitcoin from a P2PKH address as well as sending Bitconi from a 2-2 Multisignature address with a P2WSH transaction.
In both cases transfer of ownership might be expensive in Bitcoin fees if there is a lot of demand from people to utilize the Bitcoin Network.
However once the Bitcoins are used to open a payment channel they can freely flow within the lightning network from one participant to another one.
If a channel partner should not respond one will always have the chance to fall back to the onchain transactions without the necessity for the channel partner to help to do so.
Due to the potentially high fees and confirmation times Bitcoins on the Bitcoin Network are way more rigid and harder to move than Bitcoins on the Lightning Network.
One can use the Bitcoin network to send bitcoin from a P2PKH address as well as sending bitcoin from a 2-2 multisignature address with a P2WSH transaction.
In both cases transfer of ownership might be expensive in bitcoin fees if there is a lot of demand from people to utilize the Bitcoin Network.
However once the Bitcoins are used to open a payment channel they can freely flow within the Lightning Network from one participant to another one.
If a channel partner should not respond, one will always have the chance to fall back to the onchain transactions without the necessity for the channel partner to help to do so.
Due to the potentially high fees and confirmation times, bitcoin on the Bitcoin Network are way more rigid and harder to move than bitcoin on the Lightning Network.
====
===== Example of a poor channel opening procedure
Alice wants to open a payment channel with Mallory but she is not yet fully aware of the Lightning Network Protocol.
She creates a new private and corresponding public key and talks to Mallory who does the same and sends her public key to Alice.
Now Alice prepares a Bitcoin Transaction sending a few mBTC to the Multisignature address that was created from Alice's and Mallory's key.
Now Alice prepares a Bitcoin Transaction sending a few mBTC to the multisignature address that was created from Alice's and Mallory's key.
As Alice wasn't aware of the protocol to open the channel she now has to trust Mallory.
Mallory on the other side has the chance to execute a blackmail attack on Alice.
Alice needs a signature from Mallory to send Alice's funds from the multisignature address back to an address controlled by Alice.
In order to prevent Mallory from committing such an attack Alice will need to create a spend from the funding transaction and have that transaction signed from Mallory before she broadcasts her funding transaction to the Bitcoin network.
In order to prevent Mallory from committing such an attack Alice will need to create a spend transaction from the funding transaction and have that transaction signed from Mallory before she broadcasts her funding transaction to the Bitcoin network.
The transaction protecting Alice is called Commitment transaction and we will study it now.
==== Commitment Transaction
You have just learnt that a payment channel needs to be opened by preparing a funding transaction which sends the capacity of the payment channel to a 2-2 multisignature address.
From the example in the last secion you learnt that more ingreedients are necessary to open and operate a payment channel that does not rely on trusting the channel partner.
One such ingredient are the commitment transactions.
They are used to make sure that everyone on the channel is able to get the funds back that they own in case the channel partner becomes unresponsive or even worse if the channel partner deliberately or by accident tries to cheat with the execution of theprotocol.
From the example in the last section you learnt that more ingredients are necessary to open and operate a payment channel that does not rely on trusting the channel partner.
These such ingredients are the commitment transactions.
They are used to make sure that everyone on the channel is able to get their own funds back in case the channel partner becomes unresponsive or, even worse, if the channel partner deliberately or by accident tries to cheat with the execution of theprotocol.
The commitment transactions also encode the balance of the payment channel.
The balance of the payment channel is an agreement of the channel partners of how the capacity is split among the partners.
Let us assume Alice opens a channel with a capacity of 10 mBTC with Bob.
Naturally one would assume that Alice should still be in the possession of the 10 mBTC.
This can actually easily be achieved with the following construction:
This can actually be easily achieved with the following construction:
. Alice creates a new private / public key pair and informs Bob that she wishes to open a channel.
. Bob also creates a new private / public key pair and agrees to Alice to accept a channel from Alice by while sending his public key to Alice.
. Alice now creates a funding transaction from her wallet that sends 10 mBTC to the Multisig address with a locking script `2 <Public Key A> <Public Key B> 2 CHECKMULTISIG`.
. Bob also creates a new private / public key pair and agrees to Alice to accept a channel from Alice while sending his public key to Alice.
. Alice now creates a funding transaction from her wallet that sends 10 mBTC to the multisignature address with a locking script `2 <Public Key A> <Public Key B> 2 CHECKMULTISIG`.
. Alice does not broadcast the funding transaction but informs Bob about the transaction id of the funding transaction.
. Both Alice and Bob create their version of a commitment transaction. This Transaction will spend from the funding transaction and send all the Bitcoin back to an Adress controlled by Alice.
. Alice provides a signature for Bob's Commitmen Transaction and Bob provides a signature for Alice's Commitment Transaction.
. Both Alice and Bob create their version of a commitment transaction. This Transaction will spend from the funding transaction and send all the bitcoin back to an address controlled by Alice.
. Alice provides a signature for Bob's Commitment Transaction and Bob provides a signature for Alice's Commitment Transaction.
. Only after signatures have been exchanged Alice will broadcast the funding transaction to the bitcoin network.
With this protocol Alice did not give up ownership of her 10 mBTC even though the funds have been sent to a 2-2 multisignature wallet for which Alice only controlls one key.
If Bob stops responding to Alice she will be able to broadcast her commitment transaction and receive her fundsback.
She will only have lost a the fees for the two on chain transactions which is - as long as she follows the protocol and has her node secured - her only risk when opening a channel.
With this protocol Alice did not give up ownership of her 10 mBTC even though the funds have been sent to a 2-2 multisignature wallet for which Alice controls only one key.
If Bob stops responding to Alice she will be able to broadcast her commitment transaction and receive her fundsback.
She will only have lost the fees for the two on chain transactions. As long as she follows the protocol and has her node secured this is her only risk when opening a channel.
The commitment transactions will not only serve the perpose of Allowing Alice to withdraw her funds directly after opening the channel in case Bob does not Anser.
More commitment transactions are created during the lifetime of the channel to encode the balance between Alice an Bob.
If Alice wanted to send 3 mBTC to Bob to pay him for a service he offered both would create a new version of their commitment transaction which would now send 7mBTC to Alice and 3 mBTC to Bob and share signatures with each other.
The commitment transactions will not only serve the purpose of allowing Alice to withdraw her funds directly after opening the channel in case Bob does not answer.
More commitment transactions are created during the lifetime of the channel to encode the balance between Alice and Bob.
If Alice wanted to send 3 mBTC to Bob to pay him for a service he offered, both would create a new version of their commitment transaction which would now send 7mBTC to Alice and 3 mBTC to Bob and share signatures with each other.
However you will probably have realized that there is a major flaw with this particular design.
**Do you see any way how Alice could cheat on Bob?**
We hope you recognize that with the so far described system nothing could stop Alice from publishing her old or even initial commitment transaction which grants her 10 mBTC.
Since that commitment transaction has previously been signed by Bob he can't prevent Alice from doing so.
Obviously Alice could tell Bob that she has deleted the old commitment transaction but as we mentioned several times the lightning netork does operate without trust so a smarter mechanism is needed to prevent Alice from publishing an old commitment transaction.
As Bitcoin is censorship resistant noone can prevent a participant from the lightning network to publish an old commitment transaction.
however the commitment transactions can be modified slightly so that publishing an outdated commitment transaction is deincentiviced by a rather high punishment.
Obviously Alice could tell Bob that she has deleted the old commitment transaction but as we mentioned several times the Lightning Network does operate without trust so a smarter mechanism is needed to prevent Alice from publishing an old commitment transaction.
As Bitcoin is censorship resistant no one can prevent a participant from the Lightning Network to publish an old commitment transaction.
However the commitment transactions can be slightly modified so that publishing an outdated commitment transaction is discouraged by a rather high punishment.
The penalty for broadcasting an old commitment transaction is to give the other channel partner the ability to claim the funds that belonged to the broadcaster of the transaction.
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 loose her remaining funds in the channel.
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]
====
@ -195,91 +195,90 @@ 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 pentality 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.
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.
The timelock prevents the owner of the output to spend it directly once the commitment transaction was included to a block.
The timelock is usually measured in blocktimes and can be up to 2016 which is statistically speaking two weeks (assuming a blocktime of 10 minutes which is the target for the Bitcoin Network)
The timelock is usually measured in blocktime and can be up to 2016 which is statistically speaking two weeks (assuming a blocktime of 10 minutes which is the target for the Bitcoin Network).
Within the timelock anyone who knows a revocation secret can spend the output even well before the timelock was over.
Alice and Bob know only one half of the revocation secret but if they share their half with the other party the other party knows the full secret.
In order to update the balance and receive a signature from Bob Alice will have to share her half of the revocation secret of the current commitment transaction with Bob.
Alice and Bob know only one half of the revocation secret but if they share their half with the other party, the other party knows the full secret.
In order to update the balance and receive a signature from Bob, Alice will have to share her half of the revocation secret of the current commitment transaction with Bob.
Obviously for every new update of the channel balance new revocation secretes have to be created and the old ones all need to be saved.
Luckily the secretes are rather small and it is only the channel partners who need to do that not the entire network.
Still managing the revocation secretes is one of the more tricky parts of lighning nodes that hinders node operators to maintain backups.
Watchtower services or switching to the aformentiond eltoo channels might be future strategies to mitigate those problems.
Obviously for every new update of the channel balance new revocation secrets have to be created and the old ones all need to be saved.
Luckily the secrets are rather small and it is only the channel partners who need to do that, not the entire network.
Still managing the revocation secrets is one of the more tricky parts of Lightning nodes that hinders node operators to maintain backups.
Watchtower services or switching to the aforementioned eltoo channels might be future strategies to mitigate these problems.
==== Announcing the channel
Channel partners can agree to publicly announce the channel over the gossip protocol that comes with the lightning network.
This is usefull as other nodes will then be able to utilize this channel to route payments to other participants of the network.
Note that even for private channels which are not announced over the gossip protocol the funding transaction is always publicly stored in the bitcoin blockchain.
However as it is just a regular transaction to a 2-2 multisignature address participants of the Bitcoin Network do not know if this particular transaction is used to maintain a payment channel.
If a channel and its capacity is publically announced on the Gossip protocol the chanel partners will also be able to announce some meta data about the channel.
This meta data includes the routing fees a node charges to forward payments on that channel, information about what kind and how many Hashed time locked contracts (HTLCs) will be accpeted.
Channel partners can agree to publicly announce the channel over the Gossip protocol that comes with the Lightning Network.
This is useful as other nodes will then be able to utilize this channel to route payments to other participants of the network.
Note that even for private channels which are not announced over the Gossip protocol, the funding transaction is always publicly stored in the Bitcoin blockchain.
However as it is just a regular transaction to a 2-2 multisignature address, participants of the Bitcoin Network do not know if this particular transaction is used to maintain a payment channel.
If a channel and its capacity is publicly announced on the Gossip protocol, the channel partners will also be able to announce some meta data about the channel.
This meta data includes the routing fees a node charges to forward payments on that channel, information about what kind and how many Hash Time-Locked Contracts (HTLCs) will be accepted.
As we have not discussed HTLCs yet we will just mention that they are additional conditional outputs in the commitment transactions used for routing payments and for updating the channel balance.
We will later investigate HTLCs in more detail.
When new participants join the lightning network they will be able to download the information propagated via the gossip protocol from their peers.
Peers can only omit messages but as every message is signed by the node that originally send out the message the information on the gossip protocol cannot be modified to trick other participants.
When new participants join the Lightning Network they will be able to download the information propagated via the Gossip protocol from their peers.
Peers can only omit messages but as every message is signed by the node that originally sent out the message the information on the Gossip protocol cannot be modified to trick other participants.
==== Closing the channel
The main goal of people using the lightning network is to keep their channels open as long as possible.
Opening and closing payment channels will result in Bitcoin fees and in transactions that need to be stored in the Bitcoin Blockchain.
An open channel on the other side allows you to make an arbitrary amount of payments on the lightning network (as long as you have funds and are liquid)
However somtimes there is the necessity that you have to close a channel. For example:
The main goal of people using the Lightning Network is to keep their channels open as long as possible.
Opening and closing payment channels will result in bitcoin fees and in transactions that need to be stored in the Bitcoin Blockchain.
An open channel on the other side allows you to make an arbitrary amount of payments on the Lightning Network (as long as you have funds and they are liquid).
However sometimes there is the necessity that you have to close a channel. For example:
* You have become aware of the fact that your computer got compromized and you want to secure your funds by sending them to a cold storage.
* You have become aware of the fact that your computer got compromised and you want to secure your funds by sending them to cold storage.
* Your channel partner might be offline for too much time so that you cannot utilize the funds in that channel.
* After analyzing your routing statistics as well as the network topology you might have come to the conclusion that it might be better to close some channels and open some new ones.
* After analyzing your routing statistics, as well as the network topology, you might have come to the conclusion that it might be better to close some channels and open some new ones.
There are 3 ways to close a payment channel:
There are 3 ways to close a payment channel:
* the good way - mutal close
* the good way - mutual close
* the bad way - force close
* the ugly way - protocol breach
Not all ways are possible to choose for each of the above mentioned reasons.
Not all ways could be chosen for each of the above mentioned reasons.
For example if your channel partner is offline you will not be able to engage in the good way to do a mutual close.
The good news for you is that you lightning networksoftware will mostlikely automatically select the best closing mechanism that can currently be used if you ask the software to close the channel or if the software discovers an issue with your channel partner and follows the protocol specification which in most of such cases state that the channel shall be closed.
The good news for you is that you Lightning Network software will most likely automatically select the best closing mechanism that can currently be used if you ask the software to close the channel or if the software discovers an issue with your channel partner and follows the protocol specification which in most of such cases state that the channel shall be closed.
===== Examining the mutual close
The prefered and good way to close a channel is the mutual close.
When you decide that you want to close the channel your lightning network node will inform your channel partner about your intend.
The preferred and good way to close a channel is the mutual close.
When you decide that you want to close the channel, your Lightning Network node will inform your channel partner about your intention.
Now the channel will be prepared for shutting down.
No new routing attempts will be accepted from either channel partner and the ongoing routing attempts will be settled or removed after they timed out.
Once no further routing attempts are pending the closing transaction is prepared.
Once no further routing attempts are pending, the closing transaction is prepared.
This transaction is similar to the commitment transaction.
It has the same balance as the commitment transaction but no outputs are encumbered with a time lock.
As the finnish up of the routing attempts could take some time a mutual close can also take some time.
As the finish up of the routing attempts could take some time, a mutual close can also take some time.
The on chain transaction fees of the shutdown transaction for closing the channel in a mutual way are being paid by the party who opened the channel and not as many people think by the person who initiated the closing procedure.
As both nodes sign the shutdown transaction they have the chance to pay small fees for the bitcoin transaction by using their onchain fee estimator.
As both nodes sign the shutdown transaction they have the chance to pay small fees for the Bitcoin transaction by using their onchain fee estimator.
Even though there is is a potential waiting time this type of channel close is usually faster than the bad way.
===== Examining the force close
In case your node cannot engage to a mutal close (most likely because your channel partner is either offline or not responding) you will have to do a force close.
In case your node cannot engage to a mutual close (most likely because your channel partner is either offline or not responding) you will have to do a force close.
This is done by publishing the latest commitment transaction that your node has.
As discussed before the bitcoin network has no way of knowing if this was the most recent commitment transaction or an old one which you might have published for a financial gain.
As discussed before the Bitcoin network has no way of knowing if this was the most recent commitment transaction or an old one which you might have published for a financial gain.
Thus after that transaction was mined you will have to wait for the timelock of your output to expire until you can spend your own funds.
Also the onchain fees will be much higher for several reasons.
The most obvious reason is that when the commitment transaction was negotiated you and your channel partner would not know how high the on chain fees might be at the time the force close is taking place.
As the fees cannot be changed without reasigning outputs of the commitment transaction whch needs to signatures and as the furce close usually should happen in an urgent situation the protocol developer decided to be very generouse with the fee rate for the commitment transactions.
It can be up to 5 times higher thanthe fee estimators would suggest at the time the commitment transaction is negotiated.
As the fees cannot be changed without reasigning outputs of the commitment transaction which needs to signatures and as the force close usually should happen in an urgent situation the protocol developer decided to be very generouse with the fee rate for the commitment transactions.
It can be up to 5 times higher thanthe fee estimators would suggest at the time the commitment transaction is negotiated.
There are more reasons for the more expensive fees.
The pending routing attements in the commitment transaction are encoded as additional outputs which take up more space and will also hit the chain.
The pending routing attempts in the commitment transaction are encoded as additional outputs which take up more space and will also hit the chain.
In particular those routing attempts will have to be resolved on chain by additional spends.
These additional spends don't have to overestimate the fees but it still adds to the bill.
In general you should not do a force close unless it is absolutely necessary.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Also you might have to pay onchain fees to abort or settle routing attempts - even if you haven't opened the channel.
Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Also you might have to pay onchain fees to abort or settle routing attempts - even if you haven't opened the channel.
===== Examining the ugly way to close a channel
In case you channl partner tries to cheat you - weather deliberate or not - by publishing and outdated you will be able to catch their cheating attempt and collect on their outputs by using the revocation secret you had previously recieved to negotate a newer state of the channel.
In case you channel partner tries to cheat you - weather deliberate or not - by publishing an outdated state, you will be able to catch this cheating attempt and collect on the outputs by using the revocation secret you had previously received to negotiate a newer state of the channel.
This close can actually go in two ways.
First if you catch your partner in time you will claim their funds. In that case the closing will be rather fast. Also you will have to pay the on chain fees which could be really high if there is a lot of demand for transactions going on at that time.
This should not bother you as you just gained the entire channel capacity.
Second if you did not catch the cheating attempt then your channel partner will be able to collect their outputs after the time lock expired.
In that case the fees of the commitment transaction are again paid by the partner who opened the channel and the fees for collecting the outputs are paid by the person who comitted the closing operation.
In that case the fees of the commitment transaction are again paid by the partner who opened the channel and the fees for collecting the outputs are paid by the person who committed the closing operation.
Also all the routing attempts will have to be resolved just as in the force close.
While this method could be fully executed faster than the good and the bad way to close the channel it is obviously never recommended to engage in this channel closing protocol.
While this method could be fully executed faster than the good and the bad way to close the channel, it is obviously never recommended to engage in this channel closing protocol.
=== Invoices
@ -335,12 +334,12 @@ An alternative structure for the subsections of the invoice section (while cover
* Lightning Messages
=== Thoughts about Trust
As long as a person follows the protocol and has their node secured there is no principle risk of loosing funds when participating with the lightning network.
As long as a person follows the protocol and has their node secured, there is no principle risk of losing funds when participating with the Lightning Network.
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 Lightnig Network at any time and that she can earn Bitcoin by forwarding other payments.
Alice decided 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.
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.
Nodes should aim to have balanced channels with similar inbound and outbound capicities.
bech32::
A Base-32 + checksum bitcoin address format that is native to segregated witness. Also known as "bc1" address by starting letters. Specified in BIP-0173.
A checksummed base32 address format. It is native to segregated (BIP173). Also referred to as "bc1" because of the starting values of each address. Transactions made using bech32 are smaller in most cases, and therefore, may only require a lower fee.
bip::
Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP-21 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.
bitcoin::
The name of the currency unit (the coin), the network, and the software.
Depending on context, bitcoin could refer to the name of the currency unit (the coin), the network, or the underlying enabling protocol.
Bitcoin Mining::
Bitcoin mining serves two purposes.
@ -52,10 +52,7 @@ Blockchain::
New blocks have a statistical probability of being produced every ten minutes.
BOLT::
BOLT is an acronym for Basics Of Lightning Technology.
The formal specification of the Lightning Network Protocol is called Basics Of Lightning Technology.
It is located at https://github.com/lightningnetwork/lightning-rfc .
This is different to Bitcoin where the reference implementation bitcoin core serves the purpose of being the specification.
BOLT, or Basics Of Lightning Technology, is the formal specification of the Lightning Network Protocol. It serves only as such without delving into implementation, unlike bitcoin, in which both are one and the same. It is available in its entirety on the lightning network's github page, in the lightning-rfc repository.
Breach Remedy Transaction::
A transaction claiming the outputs of a Revocable Sequence Maturity Contract with the help of the revocation key.
@ -182,6 +182,7 @@ Following is an alphabetically sorted list of all the GitHub contributors, inclu
* Eduardo Lima III (@elima-iii)
* Hatim Boufnichel (@boufni95)
* Ricardo Marques (@RicardoM17)
* Simone Bovi (@SimoneBovi)
* Omega X. Last (@omega_github_id)
Without the help offered by everyone listed above, this book would not have been possible. Your contributions demonstrate the power of open source and open culture, and we are eternally grateful for your help.
Rene Pickhardt
5 years ago