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.
83 lines
6.5 KiB
Plaintext
83 lines
6.5 KiB
Plaintext
Payment channels are the core and most fundamental building block of the Lightning Network.
|
|
Of course, every detail of a technology is exists for a reason but the Lightning Network is literally built around the idea and concept of payment channels.
|
|
In the previous chapters you have already learned about payment channels, what properties they have, and on a high level how they work and how they can be constructed.
|
|
In this chapter we will dig deeper into the protocol details that are needed to open and close payment channels.
|
|
Where necessary some information from the first chapters of this book will be repeated.
|
|
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.
|
|
In this section we will only talk about maintaining and closing a channel.
|
|
The operation of a channel which means either making or forwarding a payment is discussed in our chapter about routing.
|
|
Also other constructions of payment channels are known and being discussed by the developers but as of writing only the channels as described in BOLT 2 are supported by the protocol and the implementations.
|
|
|
|
To repeat what you should already know a payment channel is encoded as an unspent 2 out of 2 multisignature transaction output.
|
|
The capacity of the channel relates to the amount that is bound to the unspent 2 out of 2 multisignature transaction output.
|
|
It is opened wht the help of a funding transaction that sends bitcoin to a 2 out of 2 multisignature output together with a communication protocol that helps to initialize its state.
|
|
The balance of the channel encodes how the capacity is split between the two peers who maintain the channel.
|
|
Technically it is encoded by a the most recent pair of a sequence of pairs of similar (but not equal) presigned commitment transactions.
|
|
Each channel partner has both signatures for on of the commitment transactions from the sequence of pairs.
|
|
The split of the capacity is realized by a `to_local` and a `to_remote` output that is part of every commitment transaction
|
|
The `to_local` output goes to an address that is controlled by the peer that holds this fully signed commitment transaction.
|
|
`to_local` outputs, which also exist in the second stage HTLC transactions, have two spending conditions.
|
|
The `to_local` output can be spent either at any time with the help of a revocation secrete or after a timelock with the secret key that is controlled by the peer holding this commitment transaction.
|
|
The revocation secrete is necessary to economically disincentivice peers to publish previous commitment transactions.
|
|
Addresses and revokation secretes change with every new pair of commitment transactions that are being negotiated.
|
|
The Lightning Network as a protocol defines the communication protocols that are necessary to achieve this.
|
|
|
|
### Opening a payment channel
|
|
Currently payment channels can only be opened by one side.
|
|
This does not mean that only one peer is needed to open a channel.
|
|
It means that only one peer - namingly the one who opens the channel - provides the funds and capacity for the channel.
|
|
Let us assume for the remainder of the section that Alice wants to open a channel with Bob.
|
|
Opening a payment channel is not as easy as sending bitcoins to a 2 out of 2 multisignature output.
|
|
In a fully functional payment channel the bitcoins are being sent to a 2 out of 2 multisignature address to which each owner controlls a key.
|
|
Thus Alice needs to know the public key of Bob which will be part of the 2 out of 2 multisignature address.
|
|
She will do that by sending Bob and `open_channel` message signaling her interest to open a channel.
|
|
|
|
[NOTE]
|
|
====
|
|
The importance of the segwit upgrade.
|
|
|
|
|
|
====
|
|
|
|
|
|
|
|
Chapter overview:
|
|
* describes how channels are put together at the script+transaction level
|
|
* details how a channel if funded in the protocol
|
|
* details how a channel is updated in the protocol
|
|
* 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)
|
|
* Is it possible to commit a
|
|
* 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?
|