Lightning Channels

The Lightning network is a layer 2 solution allowing for cheap and near-instant bitcoin payments. As with standard ‘on-chain’ transactions, it works in a peer-to-peer fashion without requiring trust in third parties. This network is built up from a collection of connected payment channels between pairs of individuals, each of which operates by exchanging zero-confirmation bitcoin transactions which are not actually submitted for inclusion in the blockchain. This reduces load on the chain, and allows settlement to occur in fractions of a second — much less than the 10 minutes average block production time.

Here, I concentrate on explaining how a single payment channel between two parties operates. The method by which these channels are connected to route payments will be explained in a separate post. I did previously discuss the use of zero-confirmation transactions to speed up payments, and the considerations leading to the idea of Lightning channels. Now, I will give a more detailed description of how this works. For more information, see the Lightning whitepaper. Also, medium.com has a pretty good explanation of how and why payment channels work in the way that they do.

To aid the exposition, let us suppose that two parties named Alice and Bob set up a payment channel between themselves. It is initially funded with 100 coins, with 50 from each of the two parties. At today’s prices, 100 bitcoin would be rather a lot to commit to a channel. I choose this quantity simply for a nice round number, and you can suppose that it is in units of 0.0001 bitcoin or 10,000 Satoshi, for more reasonable values.

Next, Alice and Bob start making payments to each other. As they already have coins locked up in the channel, this can be done by simply updating the quantities of these coins belonging to each party. See figure 1 below where, once the channel is funded, one payment is made on each of four days. They keep a tally of the amount of coins owed to each person, updated after every transaction. After this, the channel is closed and Alice and Bob receive back their current balance of coins.

This is, of course, a much simplified example. In practice, many thousands of payments could be completed before the channel is closed. Also, multiple payments could be made per second, rather than just once per day as here.

Time	Event	Alice	Bob
Start	Channel open	50	50
Day 1	Alice pays Bob 5	45	55
Day 2	Alice pays Bob 7	38	62
Day 3	Bob pays Alice 20	58	42
Day 4	Alice pays Bob 6	52	48
End	Channel close	52	48

How does this look, in terms of transactions actually submitted for inclusion in the blockchain? The situation is shown in figure 2. There are only two on-chain transactions. The first of these is to fund the channel and has two inputs, one from Alice and the other from Bob, so they both must sign for it to be valid. The output is to a multi-sig address requiring both Alice and Bob to sign to release the coins.

Nothing further is done on-chain until the channel is closed. At this time, a single transaction is made from the multi-sig address and paying each of Alice and Bob their closing channel balances. Since it is multi-sig, both Alice and Bob must sign this transaction.

In the example given here, I have set the transaction fees to zero so that the total output of each transaction is equal to its total input. In reality, we would need to set a positive fee, reducing the output sizes, and meaning that Alice and Bob receive slightly less than the balance calculated above. Since there are only two transactions which make it to the blockchain, this is only two bitcoin transaction fees which, when spread across the potentially thousands of payments made in the channel, results in a tiny amount per payment.

If that was all there was to it, things would be very simple. However, it requires Alice and Bob to have a lot of trust in each other. When she wants to close the channel, Alice needs to be able to rely on Bob to sign the closing transaction paying out the correct final balances. If he refused to do this, she would not have access to her coins. In exactly the same way, Bob needs to be able to trust Alice to sign. This state of affairs is unacceptable for a public and trustless payment system. The solution is described below and relies on them exchanging zero-confirmation (i.e., off-chain) transactions after each payment as insurance against the other party becoming uncooperative.

---

Commitment Transactions

The issue of trust in a payment channel is solved by the use of commitment transactions. At any time while the channel is open, Alice holds a valid transaction spending the coins from the multisig account, and paying the correct balances to both herself and to Bob. Then, if she wishes to close the channel but Bob becomes uncooperative, she can broadcast this commitment transaction and unilaterally close it herself. Similarly, Bob holds a commitment transaction for the same purposes in case Alice stops cooperating.

The idea is that, under normal operation, the commitment transactions would not get used. They are merely held and exchanged between the counterparties without being added to the blockchain. Only the cooperatively signed funding and closing transactions would actually be broadcast, as in figure 2. This is similar to a legal contract where, usually, we would expect the other party to honour its terms. It is only if they start breaking their contractual obligations that we would resort to the courts, which is unlikely since they would have nothing to gain from behaving in such a way.

Whenever a payment is made, the channel balances are updated (as in figure 1), so new commitment transactions need to be created. See figure 3 below. When commitment transactions are created, such as at channel open and after each payment, there needs to be an exchange of signatures between the parties. Bob must sign Alice’s commitment and send this to her so that, if she wishes, she can add her own signature and broadcast to the network to spend from the multisig address and unilaterally close the channel. Similarly, Alice must sign Bob’s commitment and send this to him.

There are a few things going on in figure 3, so let me explain. As in figure 1, it is split up into one row for the initial funding, one for each payment, and one for the final channel close. Transactions are represented by block arrows, with blue ones being broadcast to the blockchain. Orange arrows represent transactions which Alice is able to broadcast if she wishes, although she would not do this under normal operation. These include her commitment and Breach Remedy transactions, which I will explain in a moment. Similarly, the purple arrows represent transactions which Bob has the ability to broadcast although, under normal operation, he would not do this. I use arrows pointing left to represent payments to Alice and ones to the right paying to Bob. Transaction outputs are represented by the grey boxes, which include the quantity as well as who is able to spend from the output. When Alice+Bob is listed as being able to spend, this means that it is multisig, so both of them need to sign. Multiple rows are used to represent outputs which can be spent in more than one way, and applies to the commitment transactions as I will explain shortly.

The use of commitment transactions does present one vulnerability, where either party can cheat by broadcasting an old version. For example, after day 4 Alice has 52 coins and Bob has 48. Alice’s most recent commitment transaction pays out these quantities, as it should. However, Alice could have retained the commitment from the previous day, which pays her 58 coins. If she broadcast this old version, then it would effectively steal 6 additional coins from Bob. As a transaction is just a block of data, there is nothing Bob can do to stop her keeping old versions hanging around. Bob needs some way of ‘invalidating’ her old commitments. It is impossible to force a valid transaction to become invalid, without spending from the multisig account and effectively closing the channel. Instead, Alice’s transaction is ‘revocable’ so that, if she did broadcast an old version then Bob would be able to claim back all of the coins paid to Alice. This is done by using a Revocable Sequence Maturity Contract (RSMC) in the output paying Alice in her commitment transactions. This is the reason for the multiple spend methods listed in these outputs in figure 3.

RSMC contracts for payments from Alice’s commitment transactions to herself are defined by two separate spend methods:

1. Alice is able to spend the output by herself. This is the expected spend method, since it is supposed to be a payment to her. However, it is encumbered by a relative locktime so that Alice is only able to spend the output in this way after the commitment transaction has already been confirmed in the blockchain for a set period of time (let’s say one day). In figure 3, this time-lock is represented by a clock after Alice’s name.
2. Alice and Bob can spend by both signing (multi-sig). They would choose different keys for this spend method than used elsewhere, Alice’s private key is referred to as the revocation key. Bob is unable to spend using this method unless Alice either agrees to co-sign, or she sends him the revocation key.

If Alice were to close the channel by using her commitment transaction, then the time-lock means that she would have to wait a day before her funds become available. Hence, under normal operation, she would prefer to close out the channel cooperatively with Bob by both signing a transaction to return the correct funds to each party, and available to spend as soon as it is confirmed on the blockchain. It is only if Bob refuses to cooperate that Alice would use her commitment transaction.

The second spend method from the RSMC contract is what allows the transaction to be revoked. This is done by Alice sending her old revocation key to Bob, which stops her from being able to use the old commitment. In theory, she could still broadcast it to the blockchain and it would be added. However, she would need to wait a day to access her funds and, as Bob has her revocation key, he is able to sign using both signatures and take the funds before Alice can access it. This transaction where Bob recovers the funds from an old commitment is known as a Breach Remedy (BR in figure 3). So, although Alice could keep hold of old commitment transactions and try to use them, this would be very bad for her as Bob would take all the funds from the channel leaving her with nothing.

This method of revoking old commitments requires Bob to keep monitoring the blockchain. He needs to be able to see if Alice does broadcast an old commitment in order to apply the remedy and recover funds before the timelock is up. If he does not want to do this, or does not have the ability to be online sufficiently often, then it is possible to outsource this to third parties known as watchtowers. These are people who will monitor the blockchain for outdated commitment transactions and, for a fee, apply the breach remedy.

By symmetry, payments to himself from Bob’s commitment transactions are also encumbered by an RSMC where he has to wait for the relative locktime to elapse before he can spend, but Alice is able to spend immediately if he gives her the revocation key.

---

Channel Updates

Above, I described the state of a lightning channel, and the transactions and information held by Alice and Bob after each payment. However, whenever the channel is updated — at payment times and initial funding — we have to be very careful about the order in which this information is exchanged. For example, suppose that Alice was to sign the funding transaction before Bob signed her initial commitment,. Then, there would be a period of time between these events when Bob is able to pay her funds into the multisig channel address, but Alice has no way of getting them back. If Bob became uncooperative at this moment, then she would stand to lose her funds.

The steps for the initial funding and setup of the channel are performed in the following order.

1. Create the unsigned funding transaction.
2. Create (unsigned) commitment transactions spending from the multisig funding output.
3. Alice signs Bob’s commitment transaction and sends to Bob. Similarly, Bob signs Alice’s commitment transaction and sends to Alice.
4. Alice and Bob both sign the funding transaction, and it is broadcast to the blockchain.

Doing it in this order, Alice only ever sends funds to the channel after she has a commitment transaction in place to be able to withdraw them if needed. Note that, when signing the commitment transactions, the funding transaction to which it refers is still unsigned. However, the commitment input needs to refer to its transaction ID. It is vital, therefore, that the funding transaction ID can be computed even before it has been signed. This is a big problem for legacy Bitcoin script types, since the ID is a hash of the entire transaction including any signatures. For this reason, Alice and Bob need to fund the channel from SegWit addresses since, with these, all signature information is separated out from the transaction when computing its ID.

It is also important that information is transferred in the correct order when updating the channel for a payment. For example, if Alice was to revoke her previous commitment transaction by sending the revocation key to Bob before Bob signs the new commitment, then there would be a period of time during which Alice has no unrevoked commitment. If Bob was to become unresponsive at this moment, then she would lose access to her funds.

1. Alice and Bob create new (unsigned) commitment transactions spending from the multisig funding output.
2. Alice signs Bob’s commitment transaction and sends to Bob. Similarly, Bob signs Alice’s commitment transaction and sends to Alice.
3. Alice sends the revocation key for her previous commitment to Bob. Similarly, Bob sends the revocation key for his previous commitment to Alice.

The important thing here, is that Bob sign’s Alice’s commitment before Alice revokes her previous one by sending its revocation key to Bob. Similarly, Alice signs Bob’s commitment before he revokes his previous one. Beyond that, it is possible to change the order so that, for example, Alice’s new commitment transaction is signed, and the old one revoked, before Bob’s new commitment is signed.

Finally, all that is left is to cooperatively close out the channel at the end. There is no real issue with the order in which this is done. The transaction sending the correct balances from the multisig account to each of Alice and Bob is created, then signed by both of them and broadcast to be added to the blockchain.