Payment channels: the basis for Lightning

Payment channels make it possible to make a large number of transactions between two parties, without directly burdening the blockchain and without compromising on trust. Payment channels thus serve as the basis for the Lightning Network. In this article we describe how payment channels work.

The problem

When two parties want to make regular payments to each other, it can be beneficial to make these transactions without paying a fee for including each individual transaction in the blockchain. An option would be, for example, to have the two parties jointly keep an account of who owes each other what amount, a kind of WieBetaaltWat . The problem with this approach is that both parties are not assured of actual payment in the future, and both parties must trust each other.

Payment channels have emerged as a solution to this problem. Payment channels use the limited (yet powerful!) resources that Bitcoin offers to make a large number of payments between two parties completely without trust. Payment channels not only ensure that payments remain trustless, but payments are also immediately final: there is no need to wait for confirmation in the blockchain to be sure of receipt. In addition, the payments take place off-chain , so transactions are not directly included in the blockchain. This makes transactions cheap and fast: no fee has to be paid for every transaction and the speed of the internet is the only limitation.

The design

There are two different types of payment channels: unidirectional payment channels and bidirectional payment channels. To build up a good understanding of payment channels, we start with a simple variant of a unidirectional payment channel. That is, a payment channel where payments are only sent from party A to party B. For convenience, in this story we call the two parties who will be making payments to each other Alice (A) and Bob (B).

In a multi-signature transaction, multiple parties can have access to the bitcoins associated with the address. However, the bitcoins can only be spent when 2-of-2 owners sign with their own private key. This could also theoretically be 2-of-3, 5-of-7, or 50-of-100.

In the unidirectional payment channel, payments are only made from Alice to Bob, not the other way around. One ordinary bitcoin transaction is required to set up the payment channel: an initial transaction to provide the payment channel with bitcoins that Alice will pay to Bob. Alice makes this transaction to a multi-signature address that both Alice and Bob have a private key for.

Before Alice makes payments to Bob, Bob signs a transaction for 1 BTC from the multi-signature address back to an address of Alice. This transaction has a nLockTime of 30 days. This transaction serves as a refund transaction: if Bob is no longer available, Alice can always get her 1 BTC back in 30 days. Bob then sends this transaction to Alice.

nLockTime, also known as locktime , is a restriction on a bitcoin transaction that ensures that the transaction can only be spent at a certain time in the future. For example, a time in the future or from a certain block in the future.

The payment channel is now “set up”. Alice can now make payments to Bob. When Alice makes a payment of, for example, 0.1 BTC to Bob, Alice creates a transaction in which she divides the 1 BTC from the multi-signature address between herself and Bob. This transaction contains (in a unidirectional payment channel) no locktime and is signed by Alice. Alice does not send the transaction to the bitcoin network, but sends the transaction off-chain (simply via the internet) to Bob.

At this point, Bob holds a trade worth 0.1 BTC. He could theoretically send this transaction to the bitcoin network to claim his 0.1 BTC. However, Bob will hold off on this for a while, because Alice will be sending him more payments in the future. This prevents the blockchain from being charged for every transaction. Let it be clear that both Alice and Bob do not have to trust each other: should Bob disappear, Alice will get her 1 BTC back after 30 days, and neither party can spend the 1 BTC from the multi-signature address without the digital signature of the other party. Also, Alice cannot undo her payment.

A little later, Alice wants to make another payment to Bob. Again Alice wants to send 0.1 BTC to Bob. The total amount to be sent to Bob is now 0.2 BTC. This is done in the same way as the previous transaction: Alice signs a transaction without locktime and sends it to Bob.

Now Bob decides that he has received enough payments from Alice and he wants to claim his 0.2 BTC. Bob can do this by sending the 0.2 BTC transaction he received from Alice to the bitcoin network. In theory, instead of the transaction for 0.2 BTC, Bob could claim the transaction worth 0.1 BTC. However, it is in Bob’s favor to claim as many bitcoins as possible, so Bob sends the transaction for 0.2 BTC to the bitcoin network. Note that Bob can only claim one of the transactions: once the bitcoins are spent, they cannot be spent again.

With the publication of the transaction to the bitcoin network, the transaction of 0.2 BTC to Bob is completed after it has been confirmed by the miners. In order to make the payments, two regular bitcoin transactions were ultimately necessary: one to set up the payment channel, and one to close the payment channel (Bob claiming the bitcoins).

So in this case it wasn’t quite worth it to make the payments through a payment channel, because Alice could also have made two regular transactions of 0.1 BTC to Bob. However, it is clear that there could also have been hundreds, thousands, or even hundreds of thousands of transactions through the payment channel. Because no fees have to be paid per transaction, amounts of, for example, 0.00000001 BTC can also be sent at a time. When this is done 1 million times, Bob will have received 0.01 BTC, for which he then only needs to send one transaction to the bitcoin network to claim the bitcoins. Real micropayments, in other words, for a fraction of the cost of regular transactions.

The unidirectional payment channel is limited to payments from Alice to Bob. It would be nice if Alice and Bob could make payments back and forth via the same payment channel. This is also possible, but requires a slightly different configuration. The initial setup is the same: Alice sends 1 BTC to a multi-signature address and Bob creates a refund transaction for Alice with 30 days of locktime.

If Alice wants to make a payment of 0.1 BTC to Bob, the transaction Alice gives to Bob will look slightly different. The transaction is again signed by Alice, but this time contains a locktime of 29 days. This locktime guarantees that Bob will be able to claim the transaction from Alice before Alice can claim the refund transaction.

Alice can then send another transaction to Bob to make a second payment, again for 0.2 BTC. This second transaction that Alice makes, increasing the amount sent to Bob from 0.1 BTC to 0.2 BTC, has the same lock time as the first: 29 days. So far the transactions are the same as in the scenario with a unidirectional payment channel, but Bob has not yet made a payment back to Alice.

Bob has now received 0.2 BTC from Alice and can make a payment to Alice with this 0.2 BTC. Now suppose Bob wants to make a payment of 0.1 BTC to Alice. This is possible, and by doing so Bob “changes” the direction of the payment channel. Where previously only Alice sent transactions, Bob will now create a transaction. Bob takes the amount of 0.2 BTC he has already received and deducts the payment Bob wants to make to Alice. So Bob creates a new transaction of 0.1 BTC to himself, and 0.9 BTC to Alice, Bob signs this transaction and sends the transaction to Alice. The difference with previous transactions is that the transaction from Bob to Alice has a locktime of 28 days.

With a locktime of 28 days on the transaction from Bob to Alice, Alice is confident that she will be able to claim this transaction before Bob has a chance to claim the 0.2 BTC transaction – after all, this transaction has a locktime of 29 days. So Bob will have to wait an extra day before he can claim this transaction.

Alice now decides that she wants to close the payment channel and publishes the transaction she received from Bob to the bitcoin network before the 29-day locktime expires on the other transactions. The attentive reader will notice that the transaction Alice publishes has a locktime of 28 days; she cannot spend the bitcoins yet. When closing the payment channel, the participants have the option to cooperate or not. If they do work together, Bob sends Alice a new transaction for the same amount of BTC, but this time without locktime. Alice can now immediately publish this transaction. If Alice and Bob don’t want to work together, Alice will have to wait until the end of the 28-day locktime.

When the payment channel is closed, all transactions are completed. Once again, two normal bitcoin transactions were needed to open and close the payment channel. It is clear that by shortening the lock time, trustless payments can take place in two directions. The amounts of BTC sent and the number of days of locktime from these scenarios have been chosen purely as a convenient example: in reality, the amounts will vary and the locktime on transactions will be less far apart. A payment channel is best suited for smaller amounts, where it is desirable to avoid expensive fees. For sending large amounts, paying the fee for a normal transaction will probably be preferable.

The advantages

  • Transactions are immediately final. When receiving a transaction, Alice and Bob are sure of a payment in the future. There is no need to wait for confirmation in the blockchain.
  • Real micro-payments become possible. It is currently too expensive to send a transaction of 0.00000001 BTC. Payment channels make it possible to do many of these types of transactions without paying high fees. The transactions are simply “saved” and settled once on the blockchain when the payment channel is closed.
  • Despite the benefits, making transactions remains trustless. None of the parties involved need to trust each other. This is an important feature, because the bitcoin network revolves around reducing or eliminating the need for trust as far as possible.

The Lightning Network

Payment channels are the basis for the Lightning Network. It is possible to link a payment channel between Alice (A) and Bob (B) to a payment channel between Bob and Carol (C), which in turn can be linked to a payment channel between Carol and Dave (D). This makes it possible for Alice to make a payment to Carol or Dave, without Alice having a payment channel open with either of them. This is the origin of the Lightning Network. We will explain how payment channels can be extended to the Lightning Network in a subsequent article.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2024 Cryptocoin