This article is devoted to the consideration of off-chain payment channels: their types, operating principles and application features. The presented material will help to understand why the idea of payment channels is revolutionary in financial accounting systems. We'll talk about payment channels specifically for Bitcoin. This article will be useful to those who are not familiar with the concept of payment channels, and will also give an understanding of the principles of the work of the lightning network.
Payment channels and basic information about them
What is a payment channel?
A payment channel is a method of making multiple payments without adding a transaction to the blockchain. In this case, channel members interact only with each other. No additional validators or third parties are required.
Advantages of the payment channel
What are the advantages of a payment channel over regular transactions?
Within the framework of an already open payment channel, participants have the opportunity to make instant payments. The receiving party performs a quick independent verification and accepts the payment. In the basic version there are no commissions. Accordingly, micropayments have a place to be. It is because of this feature that payment channels are also called micropayment channels.
Another interesting advantage is that the interaction of channel participants can be conducted privately. Accordingly, the details of each micropayment will remain secret from all the others, although the very fact of using a payment channel between specific Bitcoin addresses will be known to all.
Features of the payment channel
This is not to say that payment channels have serious drawbacks compared to regular transactions, but there are some characteristic features.
The payment channel must be opened and, accordingly, sooner or later close. This is done by separate on-chain transactions. Payment of commission is inevitable for them and confirmation is required. For the opening transaction, it is better to wait for full confirmation.
Within a particular channel, payments are available only within a predetermined amount. It is set by the participants themselves, freezing the required amount using a special Bitcoin script.
Payment channels can be unidirectional and bidirectional, mono-directional or bi-directional, respectively. It depends on the very method of channel implementation.
The period of the channel’s existence and the maximum number of payments may or may not be limited. It depends on the technique. Accordingly, the channels may be closed at a certain time or early. And you can close the channel by mutual consent of the participants or at the request of one of them, but with some peculiarities.
In a simplified version, the work of the payment channel can be represented on such a scheme.
There is a bitcoin network. There are two users: Alice and Bob. They have Bitcoin wallets with an additional module for the payment channel to work according to a specific method. These modules exchange data for making payments directly.
Whose idea?
For the first time, the idea of payment channels was described by Satoshi Nakamoto himself in a personal letter to one of the active protocol developers many years ago. At that time, even in Bitcoin, no sufficiently important updates were made to allow designing reliable payment channels. However, later it became possible and in 2013 they returned to this truly promising idea.
About methods of implementing payment channels
We will look at four main ones.
Spillman-style payment channels is the simplest version of a one-way channel with a limited lifetime and an unlimited number of payments.
Later, another improvement of the Bitcoin protocol was adopted and the CLTV-style payment channels became possible, which are an improved previous method.
Poon-Dryja payment channels is a method of bidirectional channels with unlimited operation time. They require several more Bitcoin protocol updates that have recently been accepted. In addition, these channels are used when designing the lightning network.
Decker-Wattenhofer duplex payment channels is a variant of using two unidirectional channels simultaneously, improving their properties due to the formation of not a consistent chain of exchangeable transactions, but of a whole tree of exchangeable transactions. In addition, there may be more than two participants in such channels.
We will focus on the first two methods in more detail, but first we will repeat some features of the Bitcoin protocol operation.
Something from the Bitcoin protocol
nLockTime is a field in the body of each transaction that contains a timestamp or block number. Prior to this time or height of the blockchain, validators are not allowed to include a transaction in a block.
nSequence is a field in each transaction entry that contains a time value during which confirmation of this transaction is not possible. Moreover, time is calculated relative to when the exit was confirmed, which this input is wasting.
MultiSignature allows you to set such conditions at the exit of a transaction, for which you must provide several electronic signatures. These signatures will be verified by certain public keys.
Spillman-style payment channels
So, the Spillman-style payment channels are a method for creating mono-directional payment channels, where there is a sender's role and a recipient's role. The operation time of such a channel is set arbitrarily by the sender, and the recipient can close the channel ahead of time.
Let's take a look at the main steps of this channel in the diagram.
For convenience, let's imagine that there is some service that sells access to the global network via a wi-fi access point, and some client who wants to access the network for a day. The service will cost one bitcoin. Obviously, the client does not trust the service for such an amount and wants to pay for traffic in seconds.
Then they decide to open a payment channel for a day with the amount of one Bitcoin. The service generates a new key pair for electronic signature and sends the public key to the client. The client, in turn, generates a new key pair and uses its public key and the public key of the service to form the 2-of-2 multisignature address. Further, the client forms transaction number one in which it sends one bitcoin to the multisignature address, signs it, but does not distribute it to the Bitcoin network, since the service may substitute the client and refuse to sign any transactions for the further transfer of one bitcoin.
Therefore, the client forms transaction number two, where coins with multisignature addresses are sent to the address that he controls himself. Moreover, it sets the nLockTime field so that the transaction can be confirmed in 24 hours. He does not sign this transaction, but sends it to the service. In turn, the service agrees that the client can take the coin entirely to himself, but not earlier than in a day, and signs the transaction with his key. He hands over the signature to the client, the client checks it. Now he has the opportunity to pre-sign the transaction with his key and guaranteed to take the coin back if the service decides to refuse service.
In the next step, the client distributes transaction number one to the Bitcoin network or sends it to the service for distribution if he does not have the connection himself. After confirmation of the first transaction, the payment channel is considered open.
In this case, transaction number one is called the funding transaction, and the second is the refunding transaction.
How does the interaction in the calculations within the payment channel? Let's look at the following scheme.
To send the first payment, the client requests the address of the service Bitcoin, which he controls independently. Next, the client forms transaction number three, in which the coin with the multisignature address is distributed between two outlets: the first is a payment to the service address for one second of the access point operation, and the second is delivery to the client's own address. The client signs transaction number three with his key and sends it to the service. The service checks the correctness of the transaction and the signature, after which it accepts the payment, because it can pre-sign this transaction with its private key and is guaranteed to receive payment for the first second of the traffic if it does so within 24 hours. But if the service intends to continue to provide service to the client and receive payment within the channel, then it simply saves transaction number three locally until the channel closes.
To send all subsequent payments, the client changes the output values of transaction number three, respectively, re-signs it and sends to the service only the signature and the amount of the change. The service also checks the received data and saves the already new version of transaction number three, since in this version it already receives more coins.
How do you close the channel?
The diagram shows that the service should have time to publish the latest version of transaction number three in the Bitcoin network before the end of the channel operation time. Otherwise, the sender may cheat, pre-sign and publish transaction number two, where he will take the entire amount to his address.
It is worth noting that the client can make public the refund transaction at any time during the channel. The service would consider this behavior fly. Therefore, he constantly monitors the appearance of this transaction on the network and, if he finds it, terminates the contract with the client, closing the channel ahead of time by publishing the latest version of transaction number three.
CLTV-style payment channels
Let's now consider an improved version of this method, namely the CLTV-style payment channels.
This method of payment channels became applicable after a softfork Bitcoin update with the addition of a new script code - OP_CHECKLOCKTIMEVERIF. Its peculiarity lies in the fact that now in the output of a transaction you can set such rules by which coins can be spent only in a transaction with the nLockTime parameter set to not less than the value specified. In fact, this means that, among other conditions, coins can be spent only after a certain period of time. Now, using script branching operations of conditions, namely IF-ELSE, you can set different spending conditions depending on time. The advantage of these payment channels, compared to previous ones, is that you do not need to create a refund transaction. Instead, you can write a double condition for spending coins in the output script of the funding transaction. That is, before the closing time of the channel, coins can be spent according to the multisignature rules, and after closing one signature will suffice.
How are payment channels applied?
There are two options: either in its pure form for making regular payments between previously established parties, or forming a lightning network by switching the channels between themselves. Switching means the possibility of making a payment between users who have not opened a payment channel with each other, but have open channels with other network participants. Then the value will be transmitted through a chain of channels of outside participants, if such exists.
In the case of the lightning network there are additional difficulties and features. This is the development of a common format for channel switching and the protocol of communication between nodes. It is important that wallets from some developers can work with wallets from others. Another difficulty is the issue of routing in this network. The task is such that it is necessary to find the shortest way of transferring the value, taking into account the fact that in each channel there are restrictions on the amount of transfer in each direction.
Network features
In the following diagram, let's look at the features of the functioning of the Bitcoin network and the lightning network.
In Bitcoin network nodes exchange data about transactions and blocks, as well as each other's network addresses. In this case, a consensus is reached and a common database is formed. In addition to the full nodes, there are lightweight nodes in the Bitcoin network that receive only the information necessary for them, without processing and storing the entire history.
In the lightning network, nodes do not exchange ready-made transactions and do not reach consensus. But it is also important for them to update each other’s status information and exchange messages to support the work within the payment channels. It is worth noting that the lightning network will also not be uniform, in the sense that there will be nodes with more and less load, as well as nodes with irregular activity. Most likely, hubs and nodes with a large number of open payment channels will exist on the network, and they will have to cope with a large load. Ordinary users will, at best, open one or two payment channels, and with one of these hubs.
This will happen because to open each payment channel you need to freeze a certain number of coins, then it is possible to accept and send payments only within a limited amount. If a regular user divides his coins into several parts and opens several channels, in fact he will receive a very small window for payment in each channel compared to the original amount. At the same time, large organizations, such as wallet developers, centralized exchanges or popular merchants, will act as hubs. They can afford to maintain a large number of channels that are open for large sums and lengthy periods of time without going offline.
Current issues
Consider frequently asked questions on the topic of payment channels and lightning network.
- How reliable are the payments in channels compared to regular Bitcoin transactions?In terms of reliability, payments in channels can be compared with regular ones, i.e. coins will not be taken away, and payment will not be canceled. But there are a number of features like the need for timely opening and closing of channels, restrictions on the amount inside the channel, the need for constant synchronization with the Bitcoin network, the likelihood of coins freezing for a while.
- Is bandwidth and lightning network bandwidth limited?The fact is that there is no restriction, but there may be delays associated with channel processing, network reconnaissance and route building, which depend on the performance of specific participants. In addition, nodes can go off-line unpredictably, which may have certain limitations in making payments by other participants.
- Should channel members trust each other?No, the mechanism of payment channels provides protection against any malicious actions of the interacting parties.
- What is the use of channels to a person who wants to send only one payment?If a person wants to get rid of the last coins and no longer plans to accept and send payments, then it does not make sense for him to open a channel, you need to send a regular on-chain transaction. In all other cases, opening the channel will be useful.
This topic is also devoted to one of the lectures of the online blockchain course “
Off-chain payment channels ”.