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.
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.
* 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.
* 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.
* 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.
* 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.
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.
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.
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.
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.
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.
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.
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 possesses one of the needed keys to sign a transaction that spends from this address)
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.
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.
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.
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 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.
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.
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.
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.
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 penalty based revocation system which economically incentivize people maintain the most recent state.
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.
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.
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.
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?
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 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.
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.
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.
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 disincentives channel partners from publish an outdated balances after they have negotiated a new balance.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
