@ -23,7 +23,7 @@ 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.
As stated we will only discuss opening and closing a channel in this chapter and
the operation and maintainance 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.
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.
=== Summary of what you (should) know about payment channels and Bitcoin
@ -46,16 +46,16 @@ The private key allows the owner to produce a signature for a transaction that s
Thus 'ownership' of bitcoin can be defined as the ability to spend that bitcoin.
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.
Without your help no other transaction from the 2-of-2 multisignature address can be produced (as only you possesess one of the needed keys to sign a transaction that spends from this address)
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)
However, without the help of anybody else you can transfer the funds to an address which you control.
You do that by broadcasting the transaction to the bitcoin network which will accept it as it has valid signatures.
As the funds in this transaction go to a regular address for which you controll the private key you can again move the funds and thus you effectively own them.
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.
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.
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.
One thing about the Lightning Network is however messing with this understanding of ownership.
On the Lightning Network there exist several presigned Transactions which allocate some of the bitcoin to you and some to your channel partner.
Without the 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 succesfully mined.
Without the 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.
If the last paragraph of this summary was confusing: No worries! We are getting there now!
****
@ -65,7 +65,7 @@ If the last paragraph of this summary was confusing: No worries! We are getting
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.
We call that person the funder of the channel.
We call that person the funder of the channel.
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.
@ -73,7 +73,7 @@ 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.
. There needs to be a revokable refund transaction available that sends all the funds back to the funder in case the other peer becomes iresponsive.
. 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.
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.
@ -102,7 +102,7 @@ We can see an overview in this diagram (which was taken directly from BOLT2 of t
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.
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.
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 controll a presigned commitment transaction that spends from the output of the funding transaction.
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.
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.
@ -111,7 +111,7 @@ She can do so by putting the hash of the bitcoin genesis block into the `chain_h
Obviously Alice needs to share some information with Bob about the channel that she wishes to create.
Thus this message contains
Thus this message contains
@ -127,24 +127,24 @@ Each channel partner has both signatures for one of the commitment transactions
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 - which we discuss in the routing chapter - have two spending conditions.
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 controled by the peer holding this commitment transaction.
The revocation secret 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 `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.
The revocation secret is necessary to economically disincentivize peers to publish previous commitment transactions.
Addresses and revocation 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.
### 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.
We will then explain how time locks are being used to create revokable sequence maturity contracts that create the penality based revokation system which economically incentivizes people maintain the most recent state.
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.
After you understood these concepts we will quickly walk you through the technical details of opening and closing a channel.
Any known payment channel constuction uses a 2-of-2 multisgnature output as the basis of the payment channel.
Any known payment channel construction uses a 2-of-2 multisgnature output as the basis of the payment channel.
We call the amount that is attached to this output the capacity of the channel.
In every case, both channel partners hold 1 secret key of the multisignature address which means that they can only collaboratively control the funds.
#### An example for a highly insecure payment channel construction
Let us assume Alice does not know the details about the Lightning Network and naivly tries to open a payment channel in a way that will likely lead to the loss of her funds.
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.
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.
@ -155,7 +155,7 @@ That is because the coins would be stuck in the 2-of-2 multisignature address to
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.
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.
She would much more prefere to keep control over her coins even though they shall be stored in this 2-of-2 multisignature address.
She would much more prefer to keep control over her coins even though they shall be stored in this 2-of-2 multisignature address.
While this seems like an impossible problem, Alice has an idea:
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?
@ -173,13 +173,13 @@ Why would Alice send money to a multisignature address just to prepare a transac
We really hope you have wondered about this because this is really the point where the innovation begins.
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.
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 unresponisive.
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.
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.
.The situation can be seen in the following picture
Of course for the commitment transaction Alice would need to get a signature from Bob before she can safely broadcast the funding transaction.
After publishing the funding transaction instead of braodcasting the commitment transaction she will keep it in a safe place.
After publishing the funding transaction instead of broadcasting the commitment transaction she will keep it in a safe place.
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.
@ -195,7 +195,7 @@ 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.
The second purpose was implicitely defined by the first purpose:
The second purpose was implicitly defined by the first purpose:
Commitment Transactions split the capacity of the channel into a balance which is owned by each partner.
@ -225,7 +225,7 @@ But similarly Alice could broadcast the first commitment transaction and transfe
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.
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.
Luckily, the scripting language in Bitcoin allows at least for changing commitment transactions in a way that economically disincentivises channel partners from publish an outdated balances after they have negotated a new balance.
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.
#### Secure Payment channels via Revokable Commitment transactions
@ -235,7 +235,7 @@ Luckily, the scripting language in Bitcoin allows at least for changing commitme
In summary we can conclude that commitment transactions fulfill three purposes:
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.
3. Allow revocation of old state through the means of a penality via a revocable sequence maturity contract.
3. Allow revocation of old state through the means of a penalty via a revocable sequence maturity contract.
====
We have not yet explained how channel partners actually communicate to negotiate a new balance.
@ -247,7 +247,7 @@ That is why we only explain this in the routing chapter and ask you to stay pati
[NOTE]
====
*TODO: Move this note to routing chapter?*
HTLCS fullfill the following purposes:
HTLCS fullfil the following purposes:
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.
@ -273,10 +273,10 @@ Even though Alice and Bob both have a public node key to which they own the priv
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.
Of course we want our payment channels to work in a way that Alice does not need to trust Bob.
Bob could however refuse to sign a transaction that sends all those outputs back to an address that is controled by Alice.
He would be able to blackmail Alice to assign a significant amount of those Bitcoin to an output address that is controled by him.
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.
Thus Bob can't steel the coins from Alice directly but he can threten Alice to have her coins lost forever.
This example shows that unfortunatelly opening a channel will be a little bit more complex than just sending Bitcoins to a multisignature address.
This example shows that unfortunately opening a channel will be a little bit more complex than just sending Bitcoins to a multisignature address.
====
@ -308,14 +308,14 @@ While the Lightning Network was certainly invented to scale the amount of paymen
If a node has channels with more than one currency it is even possible to route payments through multi asset channels.
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.
This design descision allows multiple channels to exist between two nodes - though currently only LND supports this feature.
This design decision allows multiple channels to exist between two nodes - though currently only LND supports this feature.
Alice tells Bob for how many satoshis she wishes to open the channel.
This information is necessary to construct the commitment transaction ...
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.
This means that initially Alice will not be able to recieve Bitcoins on this channel and that Bob initially will not be able to send Bitcoin along that channel.
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.
== Other payment channel constuctions
@ -324,7 +324,7 @@ Other constructions of payment channels are known and being discussed by the dev
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.
However they require the activation of BIP 118 and a softfork and are - at the time of writing - a potential future protocol change.
Thus this chapter will only focus on the pentalty based channels as described in the Lightning Network Whitepaper and specified in BOLT 02 which are currently supported by the protocol and the implementations.
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.
[NOTE]
@ -332,8 +332,8 @@ Thus this chapter will only focus on the pentalty based channels as described in
The Lightning Network does not need consensus of features across it's participants.
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.
Actually when Lightning Network connections are established nodes signal feature bits of global and local features that they support.
Thus havning the ability to create eltoo channels would just be an additional feature bit.
In this sense upgrading the Lightnign Network is much easier than upgrading Bitcoin where consensus among all stakeholders is needed.
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.
====
=== Multiparty channels and channel factories
@ -346,7 +346,7 @@ A multi party channel is a...
Chapter overview:
* describes how channels are put together at the script+transaction level
* details how a channel if funded in the protocol
** including Key derrivation!
** including Key derivation!
* details how a channel is updated in the protocol (moved to routing!)
* describes what needs to happen when a channel is force closed
Gustavo Silva
3 years ago