Geekly Articles each Day
📜 ⬆️ ⬇️

Lightning network in depth, part 1: payment channels

Lightning network is a decentralized of-chen technology that allows you to spend tens of thousands of tranzaky per second, as it allows, for example, Visa. At the moment, Bitcoin - the most popular cryptocurrency in the world, is not designed to send more than ~ 7 transactions per second, and high commissions and a long confirmation time negate the possibility of sending microtransactions. Lightning network solves both of these problems .


Lightning network


Table of contents



Introduction


Lightning network is a network of payment channels, which are ordinary multisig wallets. To open the channel, the parties create a multisig wallet and send funds to it. The amount received becomes the channel balance and all further transactions between channel participants are carried out outside the blockchain. The channel can be closed at any time by any party, in which case the last off-transaction, which determines the channel balance, goes to the network, making all previous transactions invalid, since they all spend the same 'exit'. Thus, we need only one transaction to open a channel and another one to close it, and all intermediate transactions are carried out instantly, without writing to the blockchain.


A network of such channels will allow you to send transactions to another member of the network, even if you are not connected to it directly. It’s enough to get a path between you and a chain of channels, and you don’t have to trust any of the participants of this chain, thanks to the special HTC hash-time-lock-contract, which guarantees safe delivery. your funds.


To understand how lightning works, you must first understand how the payment channels work, as well as the HTLC contracts for which it is supposed to work. These are fairly voluminous topics, so we will break this article down into 2 parts and begin by explaining the mechanism of operation of payment channels.


Payment channels


As we said above, the payment channel between two participants in the network is an ordinary multisig wallet. The first transaction, securing the balance of the channel (our multisig wallet), we will call the 'opening' ( funding transaction or an anchor transaction ). This transaction must be sent to the network and mined in order for the channel to be created.


Then the parties exchange signed mutual commit transactions ( commitment transaction ) that change the initial balance of the channel. These transactions are valid and can be sent to the network, but instead are kept out of the network, waiting for the channel to close. Thus, the channel balance state can change thousands of times per second, limited only by how quickly the parties can create, sign, and transfer commit transactions to each other.


Each time, exchanging a new commit-transaction, the parties invalidate the previous state of the channel and thus only the newest commit-transaction can be 'completed'. This is done so that the parties do not try to cheat by sending one of the previous channel conditions to the blockchain, which is more profitable for them. Next, I will look at several mechanisms that allow it to be implemented.


Finally, the channel can be closed both by mutual consent - by sending a “closing” transaction ( settlement transaction ) to the blockchain, and at the initiative of only one and the parties - by sending the last commit transaction to the blockchain. Thus, we prevent the case when one of the parties goes offline and the means of the second end up being 'locked' on the channel.


Throughout the existence of the channel, only two transactions are sent to the network and recorded in the blockchain (opening and closing). Between them, the parties can exchange any number of commit transactions that never fall into the blockchain.



Simple payment channel example


Before turning to more complex implementations, let us consider an example of the operation of a simple one-way channel. In this example, we make the assumption that both parties are honest, so as not to complicate the explanations. Next, consider the mechanisms to prevent any attempt to cheat.


In this example, we have 2 members - Emma and Fabian. Fabian provides video streaming service paid through the channel using micropayments - one second of video costs 0.00001 BTC, which is 0.036 BTC per hour. Emma is a regular user who wants to watch some video.



Emma and Fabian use a special program that allows you to work with the payment channel and with video. Emma runs this program in a browser, Fabian on her server. The program has the functionality of a regular Bitcoin wallet, it can create and sign transactions. The whole mechanism of the payment channel is hidden from the user, all that they see is how the video is paid every second.


Now consider how it will work. To create a channel, Emma and Fabian must create a multisig address with the condition two out of two. On the part of the user, the program creates a P2SH address (multisig wallet) and asks to replenish it with the amount per 1 hour of viewing. Emma puts on her 0.036 BTC and this transaction becomes 'opening'.


As soon as the 'opening' transaction is confirmed and the channel is open, the video streaming begins. At the 1st second, the user side creates and signs a commit transaction that changes the channel balance: 0.00001 BTC to Fabian and 0.03599 Emma. The transaction uses the opening transaction output at 0.36 and contains 2 new ones just described. The program on the service side receives this transaction and also signs it, after which it sends the video back along with the 1st second. The parties now have a commit transaction signed by both parties, representing the last channel condition that they can send to the network if necessary.


At the second second, another commit transaction is created using the same output as the previous one, and the new outputs are now 0.00002 to Fabian and 0.03598 Emma. This transaction is a payment for 2 seconds downloaded video. Then she goes to the second side and so on.


Suppose Emma watched 10 minutes of video and she was tired, she stopped watching. During this time, 600 commit transactions were sent and signed (600 seconds of viewing). The last of them has 2 outputs: 0.03 Emme and 0.006 Fabian. Emma closes the channel, sending this commit-transaction to the network, making it 'closing'. Thus, only 2 transactions hit the blockchain.



Trustless channels


Of course, everything works in this example, but only if both parties are honest. It is easy to come up with a scenario where one of the parties may cheat, gaining an advantage or the channel will not work correctly:



Using timelocks


One solution to these problems is to use timers in commit transactions (transaction-level timelocks (nLocktime)). In order to have a guarantee that her funds are not stuck on the channel, together with the opening transaction, Emma creates a refund transaction, using the outputs of her opening transaction. First, she sends this transaction to Fabian and as soon as he signs it and returns, Emma sends the opening transaction to the network, creating a channel.


The refund transaction becomes the 1st commit transaction and its timer sets the upper limit of channel life. Let's say Emma will set a timer for 30 days (4320 blocks). All of the following commit transactions will have a shorter timer so that they can be sent to the network earlier.


Emma can now easily open the channel, knowing that if Fabian disappears, she will be able to return her funds after 30 days (if it was a bidirectional channel and Fabian introduced some funds, he could create a return transaction in the same way).



Each new commit transaction will have some kind of timer, namely, shorter than its predecessor, so that the most recent commit transaction could be sent to the network first and disable the previous ones, protecting both parties from unfair use of earlier commitments. transactions. If all goes well, then Emma and Fabian can simply send a normal closing transaction, so commit transactions are only used when one of the parties is offline.


For example, if the 1st commit transaction has a timer for 4320 blocks, then the second one can have a timer for 4319 blocks and so on. Transaction # 600 in this case can be sent to the network 600 blocks before transaction # 1 becomes valid.



I think you have already noticed that, although this method helps to prevent the use of earlier commit transactions for the purpose of deception, it nevertheless has 2 serious drawbacks.



Thus, using a timer, we can invalidate earlier commit transactions, as well as guarantee the secure closure of the channel by either side: if both parties agree with the last channel status, they can simply send the closing transaction (essentially the last commit transaction) to the network without any timer and close the channel, and if one of the parties disappeared, the second one just has to wait for the timer of the last commit transaction to expire in order to send it to the network.


Asymmetric Revocable Commitments


Another way to solve the channel trust issues described earlier is to cancel earlier commit commit transactions. In fact, cancellation is not exactly the right word, because in Bitcoin, as soon as a transaction is committed and confirmed, it cannot be canceled. Therefore, you can design it in such a way that it would be unprofitable to use it. This can be done by giving each side a revocation key .


At this time, the channel decided to create Hiteshi and Irene. They both sent 5 bitcoins to the channel, which make up the initial balance of the channel. Now, instead of the standard commit transaction they both need to sign, Hiteshi and Irene create 2 different asymmetric commit transactions.


Hitesi has a 2-out commit transaction signed by Irene. The first output pays 5 Bitcoins Irene instantly, and the second output pays 5 Bitcoins from Hiteshi, but with a delay of 1000 blocks. It looks like this:


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> CHECKSIG

At the same time, Irene also has a 2-out commit transaction signed by Hiteshi. The first output pays 5 Bitcoins to Hitesi instantly, and the second output pays Irene 5 Bitcoins with a delay of 1000 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> CHECKSIG

Thus, each has a commit transaction signed by the other party. At any time, Hiteshi or Irene can sign their commit-transaction and send it to the network, however, in this case, the other party will receive the money instantly, and the sender will have to wait for 1000 blocks, which is not very profitable, but this is obviously still not enough to make both parties play fair.



And now it is time to introduce the final touch - our key of cancellation, which will punish the side that tried to cheat, taking her money.


Each of the commit transactions has one 'pending' exit. Let's make it so that either the sender with a delay of 1000 blocks or the 2nd channel participant could spend it if he has a cancellation key. Thus, when Hiteshi creates a commit transaction for Irena’s signature, he creates a second exit to himself with a delay of 1000 blocks or Irena if she presents the cancel key. Hiteshi will keep this key secret and send Irene only when she wants to update the channel status with a new commit transaction. This transaction will look like this:


 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 CHECKSIG

Let's look at an example of how this works. Suppose Irene wants to send 2 bitcoins to Hiteshi. To do this, they need to update the status of the channel by creating a new commit transaction. They both create asymmetric commit transactions and, before signing them, they exchange cancellation keys from previous commit transactions, thus 'canceling' them. In this case, Hiteshi is interested in the most recent state of channel balance, but for Irene, the previous state is more beneficial. She could try to send her previous commit-transaction to the network, but Hiteshi already has the cancel key from her and if he notices that she’s sent, he will have 1000 blocks to take the entire channel balance (yes, 'cancellation' is not will happen automatically, Hiteshi must notice that Irene sent her commit-transaction to the network and use the key).


Thus, the implementation of channels using asymmetric canceled commit transactions is much more efficient since it does not limit the channel lifetime or the number of transactions that can be sent to it.


Conclusion


This concludes the first article. I think it will take you some time to digest everything, so if you have questions, ask in the comments. In the next part, we will analyze the work of HTLC contracts and finally show how the Lightning Network works.




')

Source: https://habr.com/ru/post/350554/

More articles:


All Articles