Lightning Network
At present, Alice and Bob have opened a two-way payment channel and deposited 5btc into the channel respectively. They have completed two transactions back and forth. In the current channel state, Alice and Bob can each retrieve 5btc by terminating the channel.
Now, they want to put a hash time lock contract (HTLC) in the channel to ensure that after Bob exchanges 1btc for Carol’s secret value, Bob can retrieve 1btc from Alice.
Just like the previous steps (see Part 1 for details), Alice and Bob must each create a new commitment transaction. These two commitment transactions are very similar to the previously created commitment transaction, including a normal output, a multi-signature address output with a CSV time lock (relative time lock), and a special hash lock. Then, like the previous step, Alice and Bob exchange the previous secret value to invalidate the previous channel state. Once the secret value has been exchanged, Alice and Bob can sign their respective commitment transactions and send this commitment transaction to the blockchain at any time.
These steps are basically the same as the previous steps, except for one point. Alice and Bob’s newly created commitment transaction contains a new output, and this output is worth 1btc. (Therefore, the btc balance in the payment channel becomes Alice: 4; Bob: 5; the new output: 1.)
This new output is essentially a hashed time-locked contract, and is more interesting than other outputs because there are three ways to unlock it.
The first method is that only when the subsequent transaction contains Bob’s signature and secret value, the new output (contained in Alice and Bob’s commitment transaction) will release btc. Regardless of whether Alice or Bob signs and broadcasts the promised transaction, only Bob can unlock the output-as long as he includes the secret value in the subsequent transaction. However, there is a subtle difference between the two commitment transactions: If Bob terminates the channel, he will be subject to the CSV time lock. At this time, Bob must wait 1000 blocks to get his btc back. (If Alice terminates the channel, Bob can retrieve his btc immediately.)
Why does Bob need to wait for 1000 blocks? The reason is similar to what we explained earlier: if Bob tries to sign and broadcast the expired channel status, Alice can take away 1 btc. This is the second way to unlock the output. If Alice provides Bob’s (latest) secret value, he can “steal” the funds in the channel.
Alice and Bob can play such a game: if Alice tries to broadcast an expired channel state, Bob can use Alice’s secret value to take away the 1 btc (not even need to provide the secret value).
The third method is that, like other hash time lock contracts, these two commitment transactions also include the common CLTV time lock (absolute time lock) timeout return mechanism, that is, if Bob does not return within the deadline (such as two weeks) The secret value is included in the subsequent transaction, and Alice can retrieve her 1btc. In this case, it doesn’t matter whether the person terminating the channel is Alice or Bob.
So, how does it work?
Alice and Bob each hold part of a valid committed transaction. If Alice sends the promised transaction she holds (which is also sent to her by Bob) to the blockchain, 5btc will be sent to Bob immediately. Alice needs to wait 1000 blocks before getting her 4btc back. In addition, Bob has two weeks to provide the secret value to unlock the 1 btc corresponding to the “hash time lock contract output”. (If he does not provide the secret value within two weeks, Alice can retrieve the 1btc.)
At the same time, Bob can put his commitment transaction on the chain at any time and immediately send 4btc to Alice. Then, he must wait for 1000 blocks to take 5 btc from an address. If he provides the secret value within the time limit, he can also unlock the 1 btc corresponding to the “hash time lock contract output”. (If he does not provide the secret value within two weeks, Alice can retrieve the 1btc.)
Of course, if Alice or Bob try to do evil at any time in the future, sign and broadcast the expired channel status, the other party can stop the evil party and steal all the btc in the channel.
Settlement status
At this time, Bob will definitely receive 1btc in exchange for the secret value in his hand (if he has any). All he has to do is sign and broadcast the promised transaction he got from Alice, include the secret value in a subsequent transaction, and then sign and broadcast the subsequent transaction.
Alice knows this. She has no way to deceive Bob’s btc, even if she obtains the secret value through other means.
Therefore, Alice and Bob might as well perform “settlement” outside the payment channel. Bob can give the secret value to Alice, and Alice can agree to update the channel state, so there is no need to hash the time lock contract and expiration date.
Assuming that both Alice and Bob want to keep the channel open, this is also normal: it is much easier than terminating the channel on the chain.
Close the channel
Finally, the real power of Lightning Network:
Almost none of the content described in this series of articles does not actually use the Bitcoin blockchain.
If Alice and Bob want to peacefully close the channel, they can create a transaction to completely cover all the transactions after the channel is opened. They can send their due btc balance to themselves by closing the channel transaction according to the attribution of the btc balance shown in the latest channel status.
Specifically, this means that if Alice wants to close the channel, she can create a transaction to pay herself 4btc and at the same time pay Bob 6btc, and then ask Bob to sign and broadcast the transaction. Bob has no reason not to agree to this request. He will probably cooperate with Alice to close the channel.
In the end, only two transactions will be broadcast to the Bitcoin network and packaged into blocks: open channel transaction and close channel transaction. This is the result even if 1 million transactions occurred between Alice and Bob, thus greatly reducing the burden on the blockchain.
Special thanks to Rusty Russell and JosephPoon for the information and additional feedback.