In-depth interpretation of Lightning Network (Part 1): Payment Channel

The Lightning Network is a decentralized off-chain technology solution that can support tens of thousands of concurrent transactions per second, which is close to what the Visa system can do (for example). On the current Bitcoin (the most popular cryptocurrency in the world) blockchain, it can only support processing about 7 transactions per second, and it also has to pay high fees and wait a long time for the transaction to take effect. These factors make it almost impossible to send small transactions with Bitcoin. The Lightning Network solved both of these problems .

introduction

The Lightning Network is a payment channel system, no different from common multi-signature wallets. The so-called opening of the channel means that the participant creates a multi-signature wallet and deposits funds into the wallet. The amount of funds received by this wallet becomes the balance of this channel. Then, all subsequent transactions between the participants took place in an environment outside the blockchain . Any participant can close this channel at any time. At this time, the last off-chain transaction (which determines the balance of each participant in the channel) will be sent to the blockchain, and all intermediate transactions will be invalidated at the same time, because All these transactions use the same transaction output. As a result, we only need one transaction to open the channel and one transaction to close the channel. All intermediate transactions in between are sent and received in real time, and do not need to be recorded on the blockchain (so there is no need to wait).

(Translator’s Note: Bitcoin is not the balance in the account, it is a check; all checks are created by a specific transaction; each check is only used once and will be invalidated (that is, it can only be Used in a transaction). The transaction can arbitrarily allocate the value of the checks used to produce any number of new checks.)

A network of such channels allows you to send funds to another participant of the network, even if there is no direct channel between you. The only condition is that a “path” can be formed between you, that is, there is a channel that connects you to the other side. In addition, thanks to a special smart contract (HTLC, Hash Time Lock Contract), you don’t need to trust anyone in the network, the contract will guarantee the safe delivery of the funds you paid.

To understand how the Lightning Network works, the first thing to understand is the operation of the payment channel and the HTLC that forms the basis of the payment channel. These topics are not small, so I divided the article into two parts, starting with explaining the working principle of payment channels.

Payment channel

As mentioned above, the payment channel connecting two participants is essentially an ordinary multi-signature wallet. The first transaction determines the balance of a channel, which we call “recharge transaction” or “anchor transaction”. This transaction needs to be broadcast to the network and recorded on the blockchain to indicate that the channel is open.

After this step is completed, when the balances of both parties in the channel are to be updated, the two parties need to manually exchange the signed “commitment transaction”. These transactions themselves are valid and can be sent to the Bitcoin network at any time, but both parties will temporarily save them and will not broadcast them unless they are ready to close the channel. In this way, the balance status of both parties in the channel can be changed thousands of times in one second. The update speed is only limited by the speed at which both parties create, sign, and send promised transactions to the other party.

Each time the two parties exchange a new commitment transaction, they also invalidate the previous state of the channel; therefore, only the latest commitment transaction can be “executed”. The purpose of this design is to prevent one party from cheating on the other party and close the channel by sending an outdated but beneficial state to the chain. Below I will explain several mechanisms to prevent this kind of fraud.

Finally, the channel can either be closed by unanimous agreement—that is, send a closed transaction (called a “settlement transaction”) to the Bitcoin network—or it can be closed unilaterally, which is to send the last committed transaction to the network. This is to prevent a situation where one party goes offline causing the other party’s balance in the channel to be “locked up” all the time.

During the entire life cycle of the channel, only two transactions were sent to the Bitcoin network and recorded on the Bitcoin blockchain (that is, the recharge transaction and the settlement transaction). Between these two transactions, the two parties can exchange countless committed transactions, and none of these transactions need to be submitted to the blockchain.

In-depth interpretation of Lightning Network (Part 1): Payment Channel

A simple payment channel case

Before explaining the more complex mechanism, let’s consider a simple, one-way channel example. To simplify this explanation, we assume that both parties are honest. Later we will consider mechanisms to help us prevent fraud.

Suppose there are two participants in a channel, Emma and Fabian. Fabian provides paid video streaming services, and viewers use channels to realize micropayments-0.00001 btc per second of viewing, which is equivalent to 0.036 btc per hour. Emma is an ordinary user who wants to watch videos.

In-depth interpretation of Lightning Network (Part 1): Payment Channel

Emma and Fabian use a special program to simultaneously play videos and run payment channels. Emma launches this program in her web browser, and Fabian uses the same program on her server. This program has all the functions of a normal Bitcoin wallet software, it can create and sign transactions. The entire mechanism of the payment channel can be completely hidden. The fact that the user sees is that the video is priced by the second.

Now let’s take a look at the specific workflow of this paid service. In the beginning, Emma and Fabian want to open the channel: establish a 2-2 multi-signature address. From the user’s point of view, this program creates a P2SH address (a multi-signature wallet) and requires the user to deposit enough funds to pay for one hour of video service. Emma transferred 0.036 btc to this address, and this transaction became the so-called recharge transaction.

After the recharge transaction is packaged into a certain block, even if the channel is opened, the video will start to play. In the first second, the user created and signed a commitment transaction, which changed the balance in the channel: now Fabian has 0.00001 btc, and Emma has 0.03599 btc left. This transaction uses the output of the recharge transaction and creates two outputs, the meaning is as we described here. From the perspective of the service provider, the program received this transaction, so it also signed the name and sent it back to Emma along with the first second video. Now both parties have a commitment transaction that is manually signed by the other party and reflects the latest state of the channel; if necessary, either party can send this transaction to the Bitcoin network.

In the second second, Emma’s program created a new commitment transaction, using the same output of the recharge transaction (same as the first transaction). This time, the first output of the commitment transaction was given to Fabian 0.00002. btc, gave 0.03598 to Emma. This transaction is used to pay for the second second video download.

Let’s suppose that Emma watched a 10-minute video and then quit. During this time, she signed and sent 600 promises (600 seconds of video). The last sum has two outputs: 0.03 btc for Emma, ​​and 0.006 for Fabian. Emma closed the channel and broadcast the last promised transaction to the Bitcoin network as a settlement transaction. In this way, only two transactions in this channel are recorded on the blockchain .

In-depth interpretation of Lightning Network (Part 1): Payment Channel

Trust-free channel

Of course, from this example, everything is fine, but this is because both parties are honest. It is not difficult to imagine that one of the parties will deceive the other at some point, and a simple design like the above may not be enough.

  • Although the channel is open, Emma still needs Fabian’s signature to withdraw funds, because this channel is a 2-2 multi-signature address. If Fabian disappears, Emma’s funds may be locked in this channel forever.
  • Although the channel is open, Emma can use any commitment transaction that both parties have signed. After watching the video for 10 minutes, she can take the first promised transaction on the chain without Fabian’s re-approval at all.

Time lock

One solution to these problems is to use time locks (nLocktime at the transaction level) in committed transactions. To ensure that funds will not be locked in the channel forever, Emma uses the output of her recharge transaction to create a refund transaction. She first sent the transaction to Fabian, and after Fabian signed and sent it back, Emma broadcasted the recharge transaction to the Bitcoin network to open their channel.

This refund transaction has also become the first promised transaction, and its time lock sets an upper limit on the existence of the channel. Suppose Emma sets the time lock to 30 days (4320 Bitcoin blocks) (that is, the transaction can only be recorded on the blockchain after 30 days). For all subsequent committed transactions, the set time locks will be shorter than one, so that updated transactions can be broadcast to the network earlier.

Now Emma doesn’t have to worry anymore. She knows that even if Fabian disappears, she can get her funds back in 30 days (if this is a two-way payment channel, that is, Fabian will also deposit money in it, then he will also get it from her own Propose a refund transaction from the perspective).

In-depth interpretation of Lightning Network (Part 1): Payment Channel

The time lock of each new commitment transaction is shorter than the previous one. Therefore, the new commitment transaction can always be chained earlier than the old one and invalidate the old transaction (cannot be chained), so as to prevent Either party maliciously uses the old promised transaction. If all goes well, Emma and Fabian only need to broadcast the common settlement transaction that both parties agree on. Therefore, the time-locked commitment transaction will only come in handy when one party goes offline.

For example, if the time lock of the first commitment transaction is 4320 blocks, then the second commitment transaction can be set to 4319 blocks, and so on. In this way, the 600th commitment transaction can be chained 600 blocks earlier than the first commitment transaction.

In-depth interpretation of Lightning Network (Part 1): Payment Channel

You may have also noticed that although this method helps prevent a party from putting an earlier commitment transaction on the chain (fraud), it has two obvious shortcomings:

  • The time lock of the first committed transaction limits the lifetime of this channel. If the time lock is set too long (for example, 1 year), the channel can exist for a long time, but if one party is missing, the other party will have to wait a long time to broadcast the last promised transaction and retrieve its own funds.
  • The time lock of the first committed transaction also limits the number of transactions that can occur in the channel. In our example, this value is 4320, and only 4320 transactions can occur in this channel, because each new transaction will subtract 1 block from the time lock time. Moreover, taking blocks (10 minutes) as an interval is equivalent to forcing participants to track the blocks of the Bitcoin network so as not to miss anything, and to put the last committed transaction on the chain as soon as possible when the situation is wrong. Of course, this interval can be extended, but the price is that the number of transactions that can be sent in the channel will become less.

Therefore, the time lock allows us to void the old commitment transaction and ensure that both parties of the channel can safely close the channel: if they both agree on the latest state of the channel, they can send a settlement transaction without a time lock (with the last commitment Transaction has the same meaning), close the channel; if one party is not online, the other party can also wait for the last promised time lock to be unlocked, and then broadcast the promised transaction to the Bitcoin network.

Asymmetric revocable commitment

Another way to solve the above-mentioned trust problem is to cancel earlier commitments. In fact, the word “cancellation” is inaccurate, because in the Bitcoin network, a transaction on the chain (a transaction that is confirmed by a block) is never cancelable. However, the special structure can make the promised transaction on the chain unprofitable. Just give each party a “revocation key”.

Suppose Hitesh and Irene decide to open a channel. Both parties have topped up 5 btc into this channel and determined the initial balance of the channel. Now, instead of signing the same standard commitment transaction, both parties create two different, asymmetric commitment transactions.

The transaction signed by Irene received by Hitesh has two outputs. The first output does not have a time lock, and Irene is immediately paid 5 btc, while the second output is time-locked, and 5 btc is paid to Hitesh, but you have to wait ( This output can only be spent after 1000 blocks after the transaction is on the chain. Details are as follows:

6h6CubzDl0EUUhjctuaD5amcY66p5ILi9XLQnhC3.png

At the same time, Irene can also get a promised transaction signed by Hitesh, with two outputs: one immediately pays 5 btc to Hitesh, and the other output pays 5 btc to Irene, but it will only be spent after 1000 blocks. .

Tlfze1D5aQjVVUcbcsOLrH9c6mjO8l8rmGFDNKgX.png

Therefore, both parties received a promised transaction signed by the other party. Both Hitesh and Irene can sign the commitment transaction on their hands and broadcast it at any time. However, once locked like this, the other party will get the money immediately, and they can only get it after 1000 blocks, which is a big disadvantage. . However, this is not enough to make both parties honest and trustworthy.

In-depth interpretation of Lightning Network (Part 1): Payment Channel

This is about our last function, the revocable key, so that if either party tries to defraud, the other party can punish the TA and make it lose his money.

As mentioned above, every commitment transaction has a “postponed” output. We make this output a little more complicated: this output can be used by the sender of the commitment transaction waiting for 1000 blocks, or it can be used by the sender of the commitment transaction. Use by the other party of the channel if the TA holds the revocation key. When Hitesh creates a promised transaction and gives it to Irene, his second output can be used by himself (to wait for 1000 blocks) or Irene, if the latter has the revocation key.

Hitesh will keep this key secretly and will only send it to Irene when he decides to use a new commitment transaction to update the state in the channel. The details of the transaction are as follows:

(Translator’s Note: It will be clearer by looking at the code: the first output is to pay 5 btc to Irene immediately; the second output is conditional, you can use the revocation key to get 5 btc immediately, or 1000 After a block, use Hitesh’s private key to use this output. Note the “IF…ELSE…” condition here, which has the same meaning as we use in other computer programming.)

An example may be easier to understand. Suppose Irene wants to send 2 btc to Hitesh. At this time, they want to update the state of the channel, that is, to create a new commitment transaction. Both parties create an asymmetric commitment transaction and, before signing, first hand over the revocation key of the previous commitment transaction to the other party, thus “revoking” the previous commitment transaction. If Hitesh wants to settle with the final balance of the channel, and Irene looks at it and feels that the older state is more beneficial to her, she can try to sign the last promised transaction in her hand and broadcast it to the network, but this promised transaction is The revocation key has been exposed to Hitesh; if he finds that the promised transaction is on the chain, he has a full 1000 blocks time to take all the money in the channel (the first output will be given to him immediately) , And the second output can be used immediately as long as he provides the revocation key) (Yes, this “cancel” action cannot be automated. Hitesh must pay attention to whether Irene sent the old promise transaction to the network, and then use the revocation Key).

Therefore, this kind of channel using asymmetric revocable commitments is more efficient, because it does not limit the life of the channel, nor does it limit the number of transactions sent.

Concluding remarks

At this point, our first article is over. It is estimated that it will take some time for you to digest it. You can also ask questions in the comments. In the next article, we will explain the functions of HTLC and finally explain how the Lightning Network works.

 

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/in-depth-interpretation-of-lightning-network-part-1-payment-channel/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-09-13 08:34
Next 2021-09-13 08:35

Related articles