Lightning network in depth, part 1: Payment channels
Learn how to pay for a cup of coffee with bitcoins.
Lightning network is a decentralized off-chain technology, allowing tens of thousands transactions per second, similar to what can be done, for instance, with Visa. Currently the bitcoin, the most popular cryptocurrency in the world, cannot support more than approximately seven transactions per second, and high commission fees together with long confirmation time nullify the possibility to send microtransactions. The Lightning Network solves both problems.
Table of contents
- Introduction
- Payment channels
- Simple payment channel example
- Trustless channels
- Using timelocks
- Asymmetric revocable commitments
- Conclusion
- Links
Introduction
The Lightning network is a system of payment channels which are nothing else than the common multisig wallets. To open a channel, the parties create a multisig wallet and send funds to this wallet. The received amount of money becomes the balance of the channel and all subsequent transactions between the participants of the channel are made outside the blockchain. The channel can be closed at any moment by any party. In this case, the last off-chain transaction, determining the balance of the channel, is sent to the network, and invalidate all intermediate transactions because they all use the same output. As a result, we need only one transaction to open the channel and one more to close it, while all the intermediate transactions are made instantaneously, without a record in the blockchain.
A network of such channels will enable you to send transactions to another participant of the network even if you are not directly connected. The only thing necessary is a possibility to make a ‘path’, a network of channels that connects you to each other. What is more, you are not obliged to trust any participant of the network, thanks to special smart contracts (HTLC hash-time-lock-contract) that guarantee safe delivery of your funds.
To understand how the Lightning network functions, it is necessary first to understand the functioning of the payment channels and of the HTLC contracts that form a base for them. These topics are quite large. This is why we will divide this article in two parts and start with the explanation of the work mechanism of the payment channels.
Payment channels
As we have already said above, a payment channel connecting two participants of the network is nothing else than a common multisig wallet. The first transaction, determining the balance of the channel, is known as the funding transaction or the anchor transaction. This transaction should be sent into the network and mined to create the channel.
Having done that, the parties exchange mutually signed commitment transactions that modify the initial balance of the channel. These transactions are valid and can be sent into the bitcoin network but they are kept outside, waiting for the closure of the channel. In this way, the state of the balance can change thousands of times per second, limited only by the time needed by the parties to create, sign and send each other commitment transactions.
Each time when the parties exchange a new commitment transaction, they invalid the previous state of the channel; therefore, only the most recent commitment transaction can be ‘carried out’. The goal is to prevent fraud by the parties, barring them from sending to the blockchain one of the previous states of the channel, the most advantageous for them. Below I will analyse several mechanisms that make it possible.
Finally, the channel can be closed both by mutual consent — by sending the closing transaction (settlement transaction) to the blockchain — or by the decision of one of the parties, that would send the last commitment transaction to the blockchain. It allows to prevent a case of one party going offline and ‘locking’ the funds of another party on the channel.
During the whole existence of the channel, only two transactions are sent to the bitcoin network and recorded in the blockchain (the funding transaction and the settlement transaction). Between those two, the parties may exchange any number of commitment transactions that would never make it to the blockchain.
Example of a simple payment channel
Before addressing more complicated structures, let us consider an example of a simple one-way channel. In our example, let us make an assumption that both parties are honest, in order to simplify the explanations. Later we will consider the mechanisms that allow to prevent any attempt at cheating.
In our example, we have two participants, Emma and Fabian. Fabian provides a video streaming service paid through the channel by micropayments — one second of the video costs 0.00001 BTC, which amounts to 0.036 BTC per hour. Emma is an ordinary user that wished to watch a video.
Emma and Fabian use a special program that allows working both with the payment channel and the video. Emma launches this program in her Internet browser, Fabian uses it on his server. The program has all the functions of an ordinary bitcoin wallet, can create and sign transactions. The whole mechanism of the payment channel is hidden from the users who see only the fact that video is paid for every second.
Let us now see how it will function. To create a channel, Emma and Fabian have to establish a 2-of-2 multisig address. From the user’s side, the program creates a P2SH address (a multisig wallet) and asks to top-up it with enough funds to pay for one hour. Emma transfers 0.036 BTC to the wallet and this transaction becomes an opening one (a funding transaction).
As soon as the funding transaction is confirmed and the channel is open, the video streaming starts. On the first second, the user’s party creates and signs a commitment transaction that changes the balance of the channel: 0.00001 BTC belongs now to Fabian and 0.03599 to Emma. The transaction uses the output of the funding transaction (0.036) and contains two new outputs that have just been mentioned. On the service’s side, the programme receives this transaction, signs it and sends it back together with the first second of the video. Now both parties have a mutually signed commitment transaction reflecting the latest state of the channel that both can send to the bitcoin network if necessary.
A new commitment transaction is created during the 2nd second, using the same output as the first one, and new outputs are 0.00002 to Fabian and 0.03598 to Emma. This transaction is the payment for two downloaded seconds of the video. It is then sent to the second side etc.
Let us assume that Emma watched 10 minutes of the video and then got tired and stopped watching. Over this period, 600 commitment transaction were sent and signed (for 600 seconds of streaming). The last of them has two outputs: 0.03 to Emma and 0.006 to Fabian. Emma closes the channel, sending this commitment transaction to the bitcoin network as the ‘settlement transaction’. Therefore, only two transactions get into the blockchain.
Trustless channels
Of course, everything functions in this example but only if both parties are honest. It is not difficult to imagine a scenario in which one of the parties may cheat to get an advantage or the channel would not work adequately.
- While the channel is open, Emma needs Fabian’s signature to withdraw the funds because the channel is a 2-of-2 multisig address. If Fabian disappears, Emma’s funds may stay forever locked in the channel.
- While the channel is open, Emma can use any commitment transaction signed by both parties. After watching the video for 10 minutes, she can take the very first commitment transaction and send it to the bitcoin network without Fabian’s consent.
Using timelocks
One of solutions to these problems is the usage of timelocks in the commitment transaction (transaction-level timelocks (nLocktime)). To have a guarantee that the funds will not be locked in the channel, Emma creates accompanies her funding transaction with a refund transaction that uses the outputs of her funding transaction. At first, she sends Fabian this transaction, and as soon as he signs it and sends it back, Emma sends the funding transaction to the bitcoin network, creating the channel.
The refund transaction becomes the first commitment transaction and its timelock sets the upper limit of the channel lifetime. Let us assume that Emma would set the timelock at 30 days (4320 bitcoin blocks). All the next commitment transactions will have shorter timelocks so that they could be sent to the bitcoin network earlier.
Now Emma can open a channel without any worries, knowing that in the case of Fabian’s disappearance, she would be able to retrieve her funds in 30 days (if it were a two-way channel and Fabian also moved some funds to it, he would have been able to create a refund transaction from his side as well).
Every new commitment transaction will have a timelock shorter than the previous one so that the last commitment transaction could be sent to the bitcoin network earlier than the previous ones and invalidate them, defending both parties from the malevolent use of previous commitment transaction. If everything goes well, Emma and Fabian would be able just to send the ordinary settlement transaction, so the use of the commitment transaction is limited to the case of one party going offline.
For instance, if the first commitment transaction has a timelock set at 4,320 blocks, the second may have a timelock set at 4,319 blocks etc. In such a case, the 600th transaction can be sent to the bitcoin network 600 blocks before the 1st transaction becomes valid.
You have probably remarked that this method, while helping to prevent earlier commitment transactions in a fraudulent way, has two important shortcomings:
- The timelock of the first commitment transaction limits the lifetime of the channel.
If the timelock is set for a long time (for instance, a year), the channel can be used for a very long time, without new openings and closures, but in the case of disappearance of one of two parties, the second will have to wait all this time to withdraw the funds from the channel, sending the last commitment transaction to the bitcoin network. - The timelock of the first commitment transaction limits the number of transactions that can be sent to the channel.
In our example of timelock set at 4,320 blocks, only 4,320 transactions can be sent to the channel because every new commitment transaction decreases the timelock by one block. Moreover, using the interval of 1 block (10 minutes), we force the participants of the channel to follow the blocks in order not to miss the right one and to send the last commitment transaction in right time if something goes wrong. Of course, the interval can be increased but in this case the transaction limit on the channel will become even less significant.
Thus, a timelock makes it possible for us to invalidate earlier commitment transactions and guarantee the safe closure of the channel to both parties: if they agree with the last state of the channel, they can simply send a settlement transaction (i. e. the last commitment transaction) without any timelock and close the channel; if one of the parties disappeared, the other has just to wait for the expiration of the timelock of the last commitment transaction to send it to the bitcoin network.
Asymmetric Revocable Commitments
One more way to solve the aforementioned issues of trust that may arise in the channel is the cancellation of earlier commitment transactions. In reality, the word ‘cancellation’ is inexact, because in the case of the bitcoin, a transaction once confirmed and mined can never be cancelled. However, it may be constructed in such a way as to make its use unprofitable. This can be achieved if every party is given a revocation key.
This time, Hitesh and Irene decided to create a channel. Each of them sent 5 bitcoins to the channel, establishing the initial balance of the channel. Now, instead of a standard commitment transaction that both should sign, Hitesh and Irene create two different asymmetric commitment transactions.
Hitesh has a commitment transaction with two outputs, signed by Irene. The first output pays 5 bitcoins to Irene immediately, and the second output pays 5 bitcoins to Hitesh, but with a delay of 1,000 blocks. This is how it looks:
Input: 2-of-2 funding output, signed by Irene
Output 0 <5 bitcoin>:
<Irene’s Public Key> CHECKSIG
Output 1:
<1000 blocks>
CHECKSEQUENCEVERIFY
DROP
<Hitesh’s Public Key> CHECKSIGAt the same time, Irene also has a commitment transaction with two outputs, signed by Hitesh. The first output pays 5 bitcoins to Hitesh immediately, and the second output pays 5 bitcoins to Irene with a delay of 1,000 blocks.
Input: 2-of-2 funding output, signed by Hitesh
Output 0 <5 bitcoin>:
<Hitesh’s Public Key> CHECKSIG
Output 1:
<1000 blocks>
CHECKSEQUENCEVERIFY
DROP
<Irene’s Public Key> CHECKSIGThus, both have a commitment transaction signed by another party. Hitesh or Irene can sign their commitment transaction at any moment and send it to the bitcoin network, but in this case, the other party will get its money immediately while the sender will wait 1,000 blocks which is not very advantageous. However, this is not enough to make both parties play fair.
Time to introduce the last feature, our revocation key that would allow to punish the party that tries to cheat, taking away its money.
Every commitment transaction has one more ‘delayed’ output. Let us make it spendable either by the sender with a delay of 1,000 blocks or by the second participant of the channel if in possession of the revocation key. In this way, when Hitesh creates a commitment transaction to be signed by Irene, he creates a second output for himself with a delay of 1,000 blocks or for Irene if she decides to produce the revocation key.
Hitesh will keep this key secret and send it to Irene only when he decides to update the state of the channel with a new commitment transaction. That is how such a transaction would look:
Input: 2-of-2 funding output, signed by Irene
Output 0 <5 bitcoin>:
<Irene’s Public Key> CHECKSIG
Output 1 <5 bitcoin>:
IF
# Revocation penalty output
<Revocation Public Key>
ELSE
<1000 blocks>
CHECKSEQUENCEVERIFY
DROP
<Hitesh’s Public Key>
ENDIF
CHECKSIGAn example would demonstrate how it works. Let us assume that Irene wishes to send Hitesh 2 bitcoins. In order to be able to do this, they should update the state of the channel, creating a new commitment transaction. Both create asymmetrical commitment transaction and, before signing them, exchange revocation keys from previous commitment transactions, thereby ‘cancelling’ them. In this case, Hitesh is interested in the last balance of the channel while Irene sees the earlier balance as more advantageous. She could try to send her previous commitment transaction to the bitcoin network but its revocation key is already known to Hitesh, and if he notices that the commitment transaction is sent, he will have 1,000 blocks to collect the whole balance of the channel (yes, the ‘cancellation’ will not be automatic, Hitesh must notice that Irene sent her commitment transaction to the network, and use the revocation key).
Thus, the implementation of channels with asymmetric revocable commitments is much more efficient because it does not limit the channel lifetime or the number of transactions that can be sent to the channel.
Conclusion
We will end the first article now. I believe you will need some time to digest all of this so you can ask questions in the comments. In the next part, we will analyse the functioning of HTLC contracts and finally show how the Lightning Network works.
