mirror of https://github.com/lnbook/lnbook
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
384 lines
30 KiB
Plaintext
384 lines
30 KiB
Plaintext
4 years ago
|
After you have learnt about payment channels in the first half of the book and after we explained how they can be connected to a network we want to finally dig down and explain the construction of payment channels in detail.
|
||
4 years ago
|
Of course, every detail of a technology exists for a reason and is important.
|
||
4 years ago
|
But we believe that payment channels are the core and most fundamental building block of the Lightning Network around.
|
||
|
It is literally built around the idea and concept of payment channels.
|
||
4 years ago
|
Thus in order master the Lightning Network you should be able to understand how payment channels will be constructed.
|
||
4 years ago
|
As several methods for channels exist we stress that it is not important to remember all the details of every method.
|
||
|
As with most technologies it is important to understand the core concepts and building blocks which we will try to lay out for you as clearly as possible while still emphasizing on the technical details.
|
||
|
|
||
4 years ago
|
In the previous chapters you have already learned that payment channels
|
||
|
|
||
|
* allow two peers who created it to send and receive Bitcoin up to the amount specified by the capacity of the channel as often as they want to.
|
||
4 years ago
|
* split the capacity of the channel into a balance between the two peers which - as long as the channel is open - is only known by the owners of the channel and increases privacy.
|
||
4 years ago
|
* do not require peers to do any additional onchain transactions other than the one needed to open and - potentially at a later state - to close the channel.
|
||
|
* can stay open for an arbitrary time. Potentially in the best case forever.
|
||
4 years ago
|
* do not require peers to trust each other as any attempt by a peer to cheat would enable the other peer to take all the funds in the channel as a penalty.
|
||
4 years ago
|
* can be connected to a network and allow peers to send money along a path of connected channels without the necessity to trust the intermediary nodes as they do not have the ability to steal the Bitcoin that are being forwarded.
|
||
4 years ago
|
|
||
4 years ago
|
In this chapter we will dig deeper into the protocol details that are needed to open and close payment channels.
|
||
4 years ago
|
Especially with the opening part of a payment channel the ideas for updating a channel should already become clear but we will defer to explain the details how HTLCs are being used in the channel operation chapter which comes directly after this chapter.
|
||
|
Working through this rather technical chapter you will be able to understand how the protocol design achieves the main properties of payment channels.
|
||
4 years ago
|
Where necessary some information from the first chapters of this book will be repeated.
|
||
4 years ago
|
If you are new to the topic we highly encourage you to start there first.
|
||
|
If you however already know a fair share about bitcoin script, OP_CODES and protocol design it might be sufficient to skip the previous chapter and start here with us.
|
||
|
This books follows the construction of payment channels as described in BOLT 02 which is titled `peer protocol` and describes how two peers communicate to open, maintain and close a channel.
|
||
4 years ago
|
As stated we will only discuss opening and closing a channel in this chapter and
|
||
4 years ago
|
the operation and maintenance of a channel which means either attempting to make or forward a payment as well as failing or settling such attempts is the normal operation and will be discussed in the next chapter.
|
||
4 years ago
|
|
||
4 years ago
|
=== Summary of what you (should) know about payment channels and Bitcoin
|
||
|
|
||
|
Let's quickly summarize what you hopefully already know about payment channels on a technical level after reading the book thus far.
|
||
|
Let us emphasize that knowing does not necessarily mean understanding yet.
|
||
4 years ago
|
|
||
4 years ago
|
1. A payment channel is encoded as an unspent 2-of-2 multisignature transaction output.
|
||
|
2. The capacity of the channel relates to the amount that is bound to the unspent 2-of-2 multisignature transaction output.
|
||
|
3. It is opened with the help of a funding transaction that sends bitcoin to a 2-of-2 multisignature output.
|
||
|
4. The funding tx can only be broadcasted to the Bitcoin network if a refund or settlement transaction exist.
|
||
|
5. The channel also consists of a communication protocol that helps to initialize and maintain its state.
|
||
4 years ago
|
6. The balance of the channel encodes how the capacity is split between the two peers who maintain the channel. Technically the balance is encoded by the most recent pair of a sequence of pairs of similar (but not equal) presigned commitment transactions.
|
||
4 years ago
|
7. The commitment transaction will include scripts and contracts that allow owners of the channel to take all funds in case the other party tries breach the protocol
|
||
|
8. There are three ways of closing a channel, the good, the bad and the ugly which refer to the mutual close, forced close and the penalty close respectively.
|
||
4 years ago
|
|
||
|
.Bitcoin, Lightning and "Ownership" of funds
|
||
|
****
|
||
|
When someone says they 'own' bitcoin they typically 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 'ownership' of bitcoin can be defined as the ability to spend that bitcoin.
|
||
|
|
||
4 years ago
|
If you have an unpublished but signed transaction from a 2-of-2 multisignature address, where some outputs are sent to an address you own, and additionally you exclusively know one of the private keys of the multisignature address, then you effectively own the bitcoin of that output.
|
||
4 years ago
|
Without your help no other transaction from the 2-of-2 multisignature address can be produced (as only you possesses one of the needed keys to sign a transaction that spends from this address)
|
||
4 years ago
|
However, without the help of anybody else you can transfer the funds to an address which you control.
|
||
4 years ago
|
You do that by broadcasting the transaction to the bitcoin network which will accept it as it has valid signatures.
|
||
4 years ago
|
As the funds in this transaction go to a regular address for which you control the private key you can again move the funds and thus you effectively own them.
|
||
4 years ago
|
On the Lightning Network ownership of your funds is almost always encoded with you having a pre-signed transaction spending from a 2-of-2 multisignature address.
|
||
4 years ago
|
While your funds on the Lightning Network are called to be "off-chain" they are actually very much on chain and very much owned by you just like you might own other bitcoin.
|
||
4 years ago
|
|
||
4 years ago
|
One thing about the Lightning Network is however messing with this understanding of ownership.
|
||
4 years ago
|
On the Lightning Network there exist several presigned Transactions which allocate some of the bitcoin to you and some to your channel partner.
|
||
3 years ago
|
Without the ability to sequence transaction and invalidate old ones via the penalty based revocation mechanism (or other techniques) we could not define clear ownership as the funds would be distributed among its two owners according to which ever transaction would first be broadcasted and successfully mined.
|
||
4 years ago
|
|
||
|
If the last paragraph of this summary was confusing: No worries! We are getting there now!
|
||
4 years ago
|
****
|
||
|
|
||
4 years ago
|
## Opening a channel
|
||
|
|
||
4 years ago
|
A payment channel needs to be established before it can be utilized to send, receive and route bitcoin.
|
||
|
There is always liquidity tied to the payment channel.
|
||
|
This liquidity is provided by the person who initiates the opening of the channel.
|
||
4 years ago
|
We call that person the funder of the channel.
|
||
4 years ago
|
At the time of writing this book the protocol only supports funding of a payment channel by the peer who initiates the opening of the channel.
|
||
|
The funding of the payment channel happens by a regular on chain transaction.
|
||
|
This funding transaction sends Bitcoin which the funder controlled to a 2-of-2 multisignature output that is controlled by both peers of the channel.
|
||
|
In order to safely do so several things had to be prepared:
|
||
|
|
||
|
. Both peers needed to have a secure communication channel established.
|
||
|
. The funder needs to know the public key that is used by the other peer for their multisig address.
|
||
4 years ago
|
. There needs to be a revokable refund transaction available that sends all the funds back to the funder in case the other peer becomes irresponsive.
|
||
4 years ago
|
|
||
|
We will assume that the secure communication channel has already been established.
|
||
|
You can learn more about this in the chapter about peer connection establishing.
|
||
|
|
||
|
The second and third points are exactly why a channel opening protocol must exist and cannot be as easy as just sending bitcoin to a 2-of-2 multisig output.
|
||
|
Especially the third point makes heavy use of the segwit upgrade but we will come to that.
|
||
|
|
||
|
The entire channel opening protocol requires a 6 - way handshake and is thus considerably more complex than establishing a TCP connection.
|
||
|
The Protocol goes in a sequential way in which every peer sends 3 messages.
|
||
|
We can see an overview in this diagram (which was taken directly from BOLT2 of the Lightning-rfc):
|
||
|
|
||
|
+-------+ +-------+
|
||
|
| |--(1)--- open_channel ----->| |
|
||
|
| |<-(2)-- accept_channel -----| |
|
||
|
| | | |
|
||
|
| A |--(3)-- funding_created --->| B |
|
||
|
| |<-(4)-- funding_signed -----| |
|
||
|
| | | |
|
||
|
| |--(5)--- funding_locked ---->| |
|
||
|
| |<-(6)--- funding_locked -----| |
|
||
|
+-------+ +-------+
|
||
|
|
||
|
|
||
|
### Step1: Signaling the intent to open a channel.
|
||
|
|
||
|
When Alice wishes to open a channel with Bob she sends an `open_channel` message to Bob.
|
||
|
This message tells Bob that Alice wishes to create a channel.
|
||
4 years ago
|
While there is obviously not a unique way of designing a protocol we can think about what kind of information Alice might have to change with Bob, so that they can safely operate a payment channel together.
|
||
4 years ago
|
In order to find a good answer we remind ourselves that in order for Alice and Bob to safely operate the channel each of them needs to control a presigned commitment transaction that spends from the output of the funding transaction.
|
||
4 years ago
|
As the funding transaction will send the funds of the channel to a 2-of-2 multisig output it is very reasonable that Alice needs to tell Bob at some point in the protocol, what her key for that address looks like.
|
||
|
Thus she can already put that information into the `open_channel` message via the `funding_pubkey` field.
|
||
|
While the Lightning Network Protocol was created to scale Bitcoin the principles of the Protocol can be used on top of other blockchains as well.
|
||
|
Thus Alice needs to inform Bob that she will use the Bitcoin Blockchain to secure this channel.
|
||
|
She can do so by putting the hash of the bitcoin genesis block into the `chain_hash` field of the funding transaction.
|
||
|
|
||
|
|
||
|
Obviously Alice needs to share some information with Bob about the channel that she wishes to create.
|
||
4 years ago
|
Thus this message contains
|
||
4 years ago
|
|
||
|
|
||
|
|
||
|
|
||
4 years ago
|
|
||
4 years ago
|
[NOTE]
|
||
4 years ago
|
====
|
||
|
These commitment transactions should never hit the blockchain and serve as a safety net for the participants in case the channel partner becomes unresponsive of disappears.
|
||
|
They are also the reason why the Lightning Network is called an off-chain scaling solution.
|
||
4 years ago
|
Each channel partner has both signatures for one of the commitment transactions from the sequence of pairs.
|
||
4 years ago
|
====
|
||
4 years ago
|
|
||
4 years ago
|
The split of the capacity is realized by a `to_local` and a `to_remote` output that is part of every commitment transaction.
|
||
4 years ago
|
The `to_local` output goes to an address that is controlled by the peer that holds this fully signed commitment transaction.
|
||
4 years ago
|
`to_local` outputs, which also exist in the second stage HTLC transactions - which we discuss in the routing chapter - have two spending conditions.
|
||
4 years ago
|
The `to_local` output can be spent either at any time with the help of a revocation secret or after a timelock with the secret key that is controlled by the peer holding this commitment transaction.
|
||
4 years ago
|
The revocation secret is necessary to economically disincentive peers to publish previous commitment transactions.
|
||
4 years ago
|
Addresses and revocation secretes change with every new pair of commitment transactions that are being negotiated.
|
||
4 years ago
|
The Lightning Network as a protocol defines the communication protocols that are necessary to achieve this.
|
||
|
|
||
4 years ago
|
### Security of a Payment channel
|
||
|
While the BOLTs introduce payment channels directly with the opening protocol we have decided to talk about the security model first.
|
||
|
The security of payment channels come through a penalty based revocation system which help two parties to split the capacity of the payment channel into a balance sheet without the necessity to trust each other.
|
||
|
In this chapter we start from an insecure approach of creating a payment channel and explain why it is insecure.
|
||
4 years ago
|
We will then explain how time locks are being used to create revokable sequence maturity contracts that create the penalty based revocation system which economically incentivize people maintain the most recent state.
|
||
4 years ago
|
After you understood these concepts we will quickly walk you through the technical details of opening and closing a channel.
|
||
|
|
||
4 years ago
|
Any known payment channel construction uses a 2-of-2 multisgnature output as the basis of the payment channel.
|
||
4 years ago
|
We call the amount that is attached to this output the capacity of the channel.
|
||
4 years ago
|
In every case, both channel partners hold 1 secret key of the multisignature address which means that they can only collaboratively control the funds.
|
||
4 years ago
|
|
||
|
#### An example for a highly insecure payment channel construction
|
||
4 years ago
|
Let us assume Alice does not know the details about the Lightning Network and naively tries to open a payment channel in a way that will likely lead to the loss of her funds.
|
||
4 years ago
|
Alice has heard that payment channel are 2-of-2 multisignature outputs.
|
||
|
As she wants to have a channel with Bob and since she knows a public key from Bob she decides to open a channel by sending money to a 2-of-2 multisignature address that comes from Bob's and her key.
|
||
|
We call the transaction that Alices used a **funding transaction** as it is supposed to fund the payment channel.
|
||
4 years ago
|
However signing and broadcasting this funding transaction would be a huge mistake.
|
||
4 years ago
|
As we have discussed the Bitcoins from the resulting UTXO can only be spent if Alice and Bob work together and both provide a signature for a transaction spending those coins.
|
||
4 years ago
|
If Bob would not respond to Alice in future Alice would have lost her Bitcoins forever.
|
||
4 years ago
|
That is because the coins would be stuck in the 2-of-2 multisignature address to which she has just sent them.
|
||
4 years ago
|
|
||
4 years ago
|
Luckily Alice has previously read Mastering Bitcoin and she knows all the properties of Bitcoin script and is aware of the risks that are involved with sending Bitcoins to a 2-of-2 multisignature address to which she does not control both keys.
|
||
4 years ago
|
She is also aware of the "Don't trust. Verify" principle that Bitcoiners follow and doesn't want to trust Bob to help her moving or accessing her coins.
|
||
4 years ago
|
She would much more prefer to keep control over her coins even though they shall be stored in this 2-of-2 multisignature address.
|
||
4 years ago
|
While this seems like an impossible problem, Alice has an idea:
|
||
4 years ago
|
|
||
4 years ago
|
What if she could already prepare a refund transaction (which we call commitment transaction in future) that sends all the bitcoin back to an address that she controls?
|
||
4 years ago
|
|
||
4 years ago
|
Before broadcasting her funding transaction she already prepared and finishes it so that she knows the transaction id.
|
||
4 years ago
|
She can now create the commitment transaction that spends the output of the funding transaction and ask Bob to provide a signature.
|
||
3 years ago
|
At that time Bob has nothing to lose by signing the commitment transaction.
|
||
4 years ago
|
He did not have Coins at the multisig address anyway.
|
||
|
Even if he did Alice intends to spend from an output which Bob never was involved in.
|
||
|
Thus at that point for Bob it is perfectly reasonable to sign the commitment transaction that spends the funding transaction.
|
||
|
On the other side you as a reader might think:
|
||
|
|
||
4 years ago
|
Why would Alice send money to a multisignature address just to prepare a transaction that sends the money back to her?
|
||
4 years ago
|
|
||
|
We really hope you have wondered about this because this is really the point where the innovation begins.
|
||
4 years ago
|
Just because in general people are expected to broadcast a transaction to the bitcoin network as soon as they have signed it no one forces you to do that.
|
||
4 years ago
|
|
||
4 years ago
|
As Alice would loose access of her Bitcoins once she sends it to a 2-of-2 multisignature output for which she only controls one key, she needs to make sure that she will be able to regain access of her coins in case Bob becomes unresponsive.
|
||
4 years ago
|
Thus before Alice publishes the funding transaction she will create another transaction that sends all the bitcoin from the 2-of-2 multisignature output back to an address which she controls.
|
||
4 years ago
|
|
||
|
.The situation can be seen in the following picture
|
||
4 years ago
|
image:images/channel-construction-opening-1.png["Channel construction..."]
|
||
4 years ago
|
Of course for the commitment transaction Alice would need to get a signature from Bob before she can safely broadcast the funding transaction.
|
||
4 years ago
|
After publishing the funding transaction instead of broadcasting the commitment transaction she will keep it in a safe place.
|
||
4 years ago
|
For this to work Alice needs to be sure that the funding transaction could not be published with a different transaction id.
|
||
|
This malleability was possible before the Segwit upgrade of Bitcoin.
|
||
|
We will discuss the details later but didn't want to leave them out here.
|
||
|
|
||
4 years ago
|
|
||
|
[NOTE]
|
||
|
====
|
||
|
This entire process might be surprising (... comparison with HTTP server push and AJAX...)
|
||
|
|
||
|
====
|
||
4 years ago
|
Having Segwit and this first commitment transaction is actually secure for Alice.
|
||
|
We have seen the first of three main properties that commit transactions fulfill:
|
||
|
|
||
|
Commitment Transactions refund channel participants in case the other side becomes irresponsive.
|
||
|
|
||
4 years ago
|
The second purpose was implicitly defined by the first purpose:
|
||
4 years ago
|
|
||
4 years ago
|
Commitment Transactions split the capacity of the channel into a balance which is owned by each partner.
|
||
|
|
||
|
Initially this split means that all the capacity is naturally on the side of the partner who funded the channel.
|
||
|
Of course during the lifetime of the channel the balance could change.
|
||
|
For example Alice might want to send some funds to Bob.
|
||
|
This could happen because she wants to pay Bob or because she wants Bob to forward the funds through a path of channels to another merchant that she wants to pay.
|
||
|
Let us assume as an example that Alice wants to send 30k Satoshi to Bob.
|
||
|
For now we can assume that through some communication protocol Alice and Bob would negotiate a double spent of the funding transaction output of 100k satoshi.
|
||
|
The new commitment transaction for which Alice and Bob would exchange signatures would send 70k satoshi to Alice and 30k Satoshi to Bob.
|
||
4 years ago
|
The situation can be seen in the following picture
|
||
4 years ago
|
image:images/channel-construction-opening-2.png["A new balance in an insecure payment channel"]
|
||
4 years ago
|
Whenever Alice and Bob want to change the balance of the payment channel they will negotiate a new commitment transaction.
|
||
|
Effectively they double spend the funding transaction output.
|
||
|
But as the commitment transactions are not broadcasted - as long as the channel stays open - they will be able to do that.
|
||
|
|
||
|
At this point we want to emphasize that the section was labeled in a way that suggests that this construction is insecure.
|
||
|
So the main question reads:
|
||
4 years ago
|
|
||
4 years ago
|
What can go wrong with the insecure payment channel?
|
||
4 years ago
|
|
||
4 years ago
|
The thing that goes and makes this construction insecure lies within the mechanics of Bitcoin.
|
||
|
The key innovation of Bitcoin was to prevent the double spending problem of electronic coins.
|
||
|
After Alice and Bob have exchanged signatures for the second commitment transaction Bob cannot rely on the fact that he really owns 30k satoshi.
|
||
4 years ago
|
Of course he could close the channel by publishing the second commitment transaction assigning 30k satoshi to an address that he controls.
|
||
|
But similarly Alice could broadcast the first commitment transaction and transfer the entire capacity of the channel back to an address that she controls.
|
||
4 years ago
|
As Bitcoin prevents double spending of the funding transaction miners will include only one of the two commitment transactions.
|
||
|
Thus we need to adapt the idea with the commitment transactions to create the ability to revoke an old commitment transaction.
|
||
4 years ago
|
Regarding the fact that Bob and Alice both have a copy of the transaction and that Bob cannot control the data that Alice has stored on her hardware, it seems pretty hopeless.
|
||
4 years ago
|
Luckily, the scripting language in Bitcoin allows at least for changing commitment transactions in a way that economically disincentives channel partners from publish an outdated balances after they have negotiated a new balance.
|
||
4 years ago
|
|
||
4 years ago
|
#### Secure Payment channels via Revokable Commitment transactions
|
||
4 years ago
|
|
||
|
|
||
|
[NOTE]
|
||
|
====
|
||
4 years ago
|
In summary we can conclude that commitment transactions fulfill three purposes:
|
||
4 years ago
|
1. Refund channel participants in case the other side becomes irresponsive
|
||
|
2. Split the capacity of the channel into the current balance that peers have agreed upon.
|
||
4 years ago
|
3. Allow revocation of old state through the means of a penalty via a revocable sequence maturity contract.
|
||
4 years ago
|
====
|
||
|
|
||
4 years ago
|
We have not yet explained how channel partners actually communicate to negotiate a new balance.
|
||
|
Because it seems pretty amazing that we can make this swap revocation secret for signature atomic.
|
||
|
In order to understand this we first need to understand the general communication of how a channel is opened.
|
||
|
The actual negotiation of the new state is also done with HTLCs.
|
||
|
That is why we only explain this in the routing chapter and ask you to stay patient.
|
||
|
|
||
|
[NOTE]
|
||
|
====
|
||
|
*TODO: Move this note to routing chapter?*
|
||
4 years ago
|
HTLCS fullfil the following purposes:
|
||
4 years ago
|
1. Make a conditional payment.
|
||
|
2. Help to update a new balance in a channel
|
||
|
3. Make payments through a path of channel atomic, meaning that peers along the path cannot steal funds.
|
||
|
====
|
||
4 years ago
|
|
||
4 years ago
|
### Opening a payment channel
|
||
4 years ago
|
We call the process of creating a new payment channel "opening a payment channel".
|
||
|
Currently a payment channel can only exists between exactly two peers.
|
||
4 years ago
|
Therefore you might be surprised to learn that even though two users are owning and maintaining the channel the current construction requires only one user to open the channel.
|
||
4 years ago
|
This does not mean that only one peer is needed to open a channel.
|
||
4 years ago
|
It does however mean that the user who opens the channel also has to provide the bitcoins to fund the channel.
|
||
|
|
||
4 years ago
|
Let us stick to our example where Alice opens a channel with Bob with a capacity of 100k satoshi.
|
||
|
This means that Alice provides 100k satoshi.
|
||
4 years ago
|
Alice will do that by creating a so called funding transaction.
|
||
4 years ago
|
This transaction sends 100k satoshi from an address that she - or her lightning node software controls - to a 2-of-2 multisig address for which she and Bob know 1 secret key each.
|
||
4 years ago
|
The amount of Bitcoin that is sent to the multisig output by Alice is called the capacity of the payment channel.
|
||
4 years ago
|
Thus for the reminder of the chapter in all examples we assume the payment channels that we use as examples already magically exist and the two peers Alice and Bob already have all the necessary data at hand.
|
||
4 years ago
|
|
||
|
[NOTE]
|
||
|
====
|
||
4 years ago
|
Even though Alice and Bob both have a public node key to which they own the private secret opening a payment channel is not as easy as sending bitcoins to the 2 out of 2 multisignature output that belongs to the public keys of Alice and Bob.
|
||
4 years ago
|
Let us assume for a moment that Alice would send 100k Satoshi to the Multisig address resulting from hers and Bob's public node id.
|
||
|
In that case Alice will never be able to maintain her funds back without the help of Bob.
|
||
4 years ago
|
Of course we want our payment channels to work in a way that Alice does not need to trust Bob.
|
||
4 years ago
|
Bob could however refuse to sign a transaction that sends all those outputs back to an address that is controlled by Alice.
|
||
|
He would be able to blackmail Alice to assign a significant amount of those Bitcoin to an output address that is controlled by him.
|
||
4 years ago
|
Thus Bob can't steel the coins from Alice directly but he can threten Alice to have her coins lost forever.
|
||
4 years ago
|
This example shows that unfortunately opening a channel will be a little bit more complex than just sending Bitcoins to a multisignature address.
|
||
4 years ago
|
====
|
||
|
|
||
4 years ago
|
|
||
|
|
||
|
[NOTE]
|
||
|
====
|
||
|
The importance of the segwit upgrade.
|
||
|
|
||
|
|
||
|
====
|
||
|
|
||
|
|
||
|
|
||
4 years ago
|
In order to avoid the reuse of addresses Alice and Bob will generate a new set of keys for the multisig address that they use to open the channel.
|
||
|
Alice needs to inform Bob which key she intends to use for their channel and ask him which key he intends to use.
|
||
4 years ago
|
She will do that by sending Bob and `open_channel` message signaling her interest to open a channel.
|
||
4 years ago
|
This message contains a lot of additional data fields.
|
||
|
Most of them specify meta data which is necessary for the channel operation and can be be safely ignored for now.
|
||
4 years ago
|
We will only look at the following ones:
|
||
4 years ago
|
|
||
|
* [chain_hash:chain_hash]
|
||
|
* [32*byte:temporary_channel_id]
|
||
|
* [u64:funding_satoshis]
|
||
|
* [point:funding_pubkey]
|
||
|
* [point:revocation_basepoint], [point:payment_basepoint], [point:delayed_payment_basepoint], [point:htlc_basepoint], [point:first_per_commitment_point]
|
||
|
|
||
|
With the `chain_hash` Alice signals that she intends to open the channel on the Bitcoin blockchain.
|
||
4 years ago
|
While the Lightning Network was certainly invented to scale the amount of payments that can be conducted on the Bitcoin Network it is interesting to note that the network is designed in a way that allows to build channels over various currencies.
|
||
4 years ago
|
If a node has channels with more than one currency it is even possible to route payments through multi asset channels.
|
||
4 years ago
|
However this turns out to be a little bit tricky in reality as the exchange rate between currencies might change which might lead the forwarding node to wait for a better exchange rate to settle or to abort the payment process.
|
||
|
For the opening process the final channel id cannot be determined yet thus Alice needs to select a random channel id with Bob that she can use to identify the messages for this channel during the opening phase.
|
||
4 years ago
|
This design decision allows multiple channels to exist between two nodes - though currently only LND supports this feature.
|
||
4 years ago
|
Alice tells Bob for how many satoshis she wishes to open the channel.
|
||
|
This information is necessary to construct the commitment transaction ...
|
||
4 years ago
|
|
||
4 years ago
|
|
||
4 years ago
|
Once the channel is open Alice will be able to send 99k satoshi along this channel.
|
||
|
Bob on the other side will be able to receive 99k satoshi along that channel.
|
||
4 years ago
|
This means that initially Alice will not be able to receive Bitcoins on this channel and that Bob initially will not be able to send Bitcoin along that channel.
|
||
4 years ago
|
|
||
4 years ago
|
|
||
4 years ago
|
== Other payment channel constuctions
|
||
4 years ago
|
|
||
4 years ago
|
Other constructions of payment channels are known and being discussed by the developers.
|
||
4 years ago
|
Historically speaking these are the Duplex Micropayment channels introduced by Christian Decker during his time as a PhD student at ETH Zurich and the eltoo channels which where also introduced by Christian Decker.
|
||
|
The eltoo channels are certainly a more elgant and cleaner way of achieving payment channels with the afore mentioned properties.
|
||
4 years ago
|
However they require the activation of BIP 118 and a softfork and are - at the time of writing - a potential future protocol change.
|
||
4 years ago
|
Thus this chapter will only focus on the penalty based channels as described in the Lightning Network Whitepaper and specified in BOLT 02 which are currently supported by the protocol and the implementations.
|
||
4 years ago
|
|
||
4 years ago
|
|
||
4 years ago
|
[NOTE]
|
||
|
====
|
||
4 years ago
|
The Lightning Network does not need consensus of features across it's participants.
|
||
4 years ago
|
If the Bitcoin Softfork related to BIP 118 activates and people implement eltoo channels nodes that support eltoo can create payment channels and the onion routing of payments along a path of channels would work just fine even if some of the channels are the modern eltoo channels or some channels are the legacy channels.
|
||
4 years ago
|
Actually when Lightning Network connections are established nodes signal feature bits of global and local features that they support.
|
||
4 years ago
|
Thus having the ability to create eltoo channels would just be an additional feature bit.
|
||
|
In this sense upgrading the Lightning Network is much easier than upgrading Bitcoin where consensus among all stakeholders is needed.
|
||
4 years ago
|
====
|
||
|
|
||
|
=== Multiparty channels and channel factories
|
||
4 years ago
|
The current construction could be generalized to multiparty channels and channel factories.
|
||
|
However the communication protocol would suffer from increased complexity.
|
||
4 years ago
|
Especially the simplifications in the protocol that might result from eltoo will lead to such features.
|
||
|
A channel factory is a...
|
||
|
A multi party channel is a...
|
||
4 years ago
|
|
||
4 years ago
|
Chapter overview:
|
||
|
* describes how channels are put together at the script+transaction level
|
||
|
* details how a channel if funded in the protocol
|
||
4 years ago
|
** including Key derivation!
|
||
4 years ago
|
* details how a channel is updated in the protocol (moved to routing!)
|
||
4 years ago
|
* describes what needs to happen when a channel is force closed
|
||
|
|
||
|
Relevant questions to answer:
|
||
|
* Channel construction:
|
||
|
* What's the difference between a replace-by-revocation based and a replace-by-versioning commitment format?
|
||
|
* What does the funding output script look like, what security guarantees does it give us?
|
||
|
* What's the difference between CSV and CLTV? How do both of these use the existing fields of the transaction to enforce new behavior?
|
||
|
* How do we implement revocation in our channel format?
|
||
|
* What does the script on the commitment to the broadcaster look like?
|
||
|
* What does the script on the commitment for the party that didn't broadcast look like?
|
||
|
* How are HTLCs constructed? What are second-level HTLCs?
|
||
|
* How has the commitment format in LN changed over time? What are some of the changes to the commitment format that've happened?
|
||
|
* Funding flow and messages:
|
||
|
* What are the messages exchanged to initiate a new channel with another peer?
|
||
|
* What do the parameters such as the max in flight do?
|
||
|
* How should the CSV values and the number of blocks until a channel is considered confirmed change with the size of the channel?
|
||
|
* What are wumbo channels? How are they enabled?
|
||
|
* What is an upfront shutdown address? What security does it offer?
|
||
|
* Is it possible to open multiple channels in a single transaction?
|
||
|
* Channel state machine:
|
||
|
* What does Medium Access Control mean in the context of network protocols?
|
||
|
* At a high level, how does the MAC protocol for 802.11 work?
|
||
|
* What steps need to happen for a new commitment state to be proposed and irrevocably committed for both parties?
|
||
|
* When is it safe for a party to forward a new HTLC to another peer? (may be out of scope for this chapter)
|
||
4 years ago
|
* Is it possible to commit a
|
||
4 years ago
|
* How does the current MAC protocol for the LN work?
|
||
|
* What does an htlc_add message contain?
|
||
|
* How are HTLCs cancelled or settled?
|
||
|
* Can both parties propose updates at the same time?
|
||
|
* Is it possible for a party to add a batch of HTLCs in a single go?
|
||
|
* What constraints exist that both parties need to adhere to?
|
||
|
* How are fees paid in a channel? Who pays which fees? Has this changed with newer commitment formats?
|
||
|
* How would the MAC protocol need to change if we used channels with symmetric state?
|