picture
In the previous article, we explained in detail how payment channels work, and the various ways to ensure that payments happen safely. However, these functions are not enough to support a usable payment channel network: even if we are sure that every participant in each channel is honest and trustworthy, there is no guarantee that payment through multiple channels is also safe. That's why we need "HTLC (Hash-Time Lock-Contract)" smart contracts. In this article, we explain how HTLCs work and use an example to show how multi-hop payments are implemented in the Lightning Network.
Hash Time Lock Contract (HTLC)
The structure of HTLC is not complicated, but it is very efficient. It allows us to create payments with an explicit "expiration time". As you may have guessed, the HTLC contract consists of two parts: hash verification and expiration verification.
H = Hash(R)
Let's start with the hash value (hash). To create a payment transaction with HTLC, you first generate a secret value R and then calculate its hash value. Any word, any number can serve as this secret value, because, to the hash function, they are all combinations of a bunch of data, and there is no difference.
This hash value H will be placed in the locking script of the transaction output. In this way, only those who know the secret value corresponding to H can use this output. And R is the so-called "preimage".
The second part of the HTLC is the verification of the expiration time. If the secret value is not disclosed in time, the payment will not be spent and the sender will get all the funds back.
# Check to see if the original sender of the transaction is requesting the return of funds
Let's consider an HLTC payment transaction to someone:
HASH160
EQUAL IF
# Check if the supplied R is a preimage of H
CHECKSIG ELSE
# Check if the person who disclosed R is the original recipient of the transaction
CHECKLOCKTIMEVERIFY # Check if the timelock has expired
CHECKSIG ENDIF
After the correct R (preimage of the hash value H) is disclosed, we enter the IF process to further verify whether the person who provided R is the payment object at the beginning of the payment transaction. When spending this output, the recipient simply provides a very simple unlocking script:
If the R provided by the unlocking script is wrong, we jump into the ELSE process, and first verify whether the time lock is unlocked or not. If the time lock has been unlocked, the sender can recover all funds. The unlocking script for withdrawing funds is similar, the only difference is that in order to enter the ELSE process, a wrong secret value needs to be provided:
Of course, this is just a very basic implementation of HTLC, representing an ordinary time-locked payment. You can add any number of other conditions in the script, for example, remove the public key verification in the IF process, so that anyone who knows the secret value R can use this output; you can also add multi-signature restrictions to require The signature of multiple preset private keys can be unlocked.CHECKLOCKTIMEVERIFYAs an aside, in this case the opcode we use isCHECKSEQUENCEVERIFY, this opcode uses an absolute value to define the timelock, meaning something like: "this output cannot be tapped until block #546212". In the Lightning Network, another time lock is used, a more "flexible" one:
, which uses relative values, meaning something close to: "This output is unusable for 1000 blocks after the transaction that uses it is on-chain" (Translator's Note: The values here are examples, practice Of course other values can be used).
The Lightning Network Case
picture
image description
picture
image description
- Step by step breakdown of payment routing in the Lightning Network -
Eric generates a secret value R and sends its hash to Alice (he will not reveal R to anyone else)
Alice uses this hash value to create an HTLC, and the time lock is set to the next 10 blocks, and the output amount is 1.003 btc. This extra 0.003 btc is a fee for the middle party of the payment channel chain. So, Alice now locks 1.003 btc with HTLC, and the specific conditions of HTCL are expressed in plain language as follows: "Alice will pay Bob 1.003 btc, as long as he can hand over the secret value R within 10 blocks, otherwise the money will be returned to Alice". The balance of the channel between them will also change because of this commitment transaction. Now Bob has 2 btc in the channel, Alice has 0.997 btc, and 1.003 btc is locked in HTLC
When Bob comes here, he can dispose of Alice's commitment transaction at will (this HTLC transaction is sent through the channel between them). He creates an HTLC output in the channel between himself and Carol, the amount is 1.002, the time lock is set to 9 blocks, and the hash value provided by Alice is used. Bob knows that if Carol wants to get the money, he has to find out the secret value R to unlock this HTLC, and once she does, he will know this R, so he can also unlock Alice's HTLC and get 1.003 btc. If Carol can't find this secret value R, both Bob and Alice can get their money back after the time lock is unlocked. Note that the amount of funds Bob sent was 0.001 btc less than the amount he could get, which is the amount of fees he charged. The balance of Bob and Carol in the channel becomes: Carol owns 2btc, Bob owns 0.998 btc, and 1.002 btc is locked in HTLC
After Carol obtained the commitment transaction sent by Bob, she did the same and created an HTLC in the channel with Diana, using the same hash value as Bob provided, setting the time lock to 8 blocks, and the amount was 1.001 btc. If Diana can reveal the secret value R within 8 blocks, she can unlock the HTLC and get 1.001 btc. Correspondingly, Carol will also know the secret value, unlock the HTLC that Bob gave her, get 1.002 btc, and earn 0.001 btc. The balance in the channel of Carol and Diana becomes: Diana owns 2btc, Carol owns 0.999 btc, and 1.001 btc is locked in HTLC
Finally, when Diana sends an HTLC (using the same hash value as a lock) to Eric through the channel, she sets the value to 1 btc and the time lock to 7 blocks. The channel balance of Diana and Eric becomes: Eric owns 2btc, Diana owns 1 btc, and 1 btc is locked in HTLC
Now, we have come to the end of this chain of payments. Eric owns this secret value R, and the hash value of this R is used in all HTLC commitment transactions. Eric can unlock the HTLC sent to him by Diana and get 1 btc; and after Eric gets back the funds, Diana will also know this R. The channel balance between Diana and Eric will become: Eric owns 3 btc, and Diana owns 1 btc.
After Diana received the secret, she also used it to unlock the HTLC sent to her by Carol, obtaining 1.001 btc and disclosing the secret value to Carol. The balances in their channels become: Diana has 3.001 btc and Carol has 0.999 btc.
After Carol received the secret value R, she unlocked the 1.001 btc sent by Bob, so Bob also knew the secret value. The balances in their channels become: Carol has 3.002 btc and Bob has 0.998 btc
In the end, Bob uses the secret value R to obtain 1.003 btc in the channel with Alice. So the balance in the channel becomes: Bob owns 3.003 btc, Alice owns 0.997.
After such a process, Alice paid Eric 1 btc without opening another direct connection channel between them. In the entire payment chain, no one needs to trust another person, and they also earn 0.001 btc because of intermediary services. Even if the payment gets stuck at some point, no one will suffer losses because the funds are still locked there and can be retrieved after time passes.
clear fault
In our example, the whole process is smooth and unimpeded, but in real life it is like the so-called "Murphy's Law": If something bad can happen, then this bad thing will happen. So we have to consider the "protection" mechanism of the Lightning Network.
From a practical point of view, the longer the payment chain, the greater the probability that the funds will not be delivered in the end: some participants may close the channel, or some nodes will go offline. Let's consider two possible error scenarios.
picture
image description
- Funds cannot be delivered because a channel is closed -
When Diana receives the secret value, she immediately withdraws the funds and reveals the secret value to Carol. Carol also wants to get back the funds from the HTLC sent by Bob, but Bob does not respond. In order to avoid risks, she closes the channel and sends the last committed transaction in her hand (that is, the HTCL output sent by Bob before transaction) broadcast to the Bitcoin network, and, because she knows the secret value, she can get her funds back. At this point, Bob still has three days to get back his money from Alice (because Carol's transaction has been on-chain, Bob can easily know the value of R). Otherwise, Alice can withdraw the funds as soon as the timelock is unlocked.
It can be seen that even if a participant leaves the network for some reason, TA himself is the only one who can lose funds, while everyone else's funds are safe.
rerouting
picture
image description
picture
image description
- Alice if using another path -
picture
image description
- Alice "cancelled" the old payment, the new payment can now be sent safely -
payment amount
You may have also noticed that when Alice "cancelled" her first payment, it is now safe to initiate a new payment, but this does not change the fact that the funds from her first payment are still locked, and she may not have enough money to initiate a second payment. This is why when using the Lightning Network, the amount of funds should be smaller when paying with HTLC. Because the commitment transaction will not be chained, the amount can be divided into multiple small amounts. In this way, whenever a path fails, only a small part of the funds will be frozen (that is, the last one sent).
Transfer Protocol
Another very important feature of the Lightning Network: all information about this path is completely anonymous. It means that for any participant, TA only knows the part related to himself. For example, for Carol, the payment is like Bob transferring money to Diana, and she does not know that Bob will transfer money from Alice. The funds are received, and it is not known that Diana will continue to transfer the funds to Eric.
The Lightning Network uses the Sphinx multi-encryption protocol. When using the Lightning Network, Alice applies a layer of encryption to every part of the network, starting at the end of the payment path. She encrypts the message for Eric using Eric's public key. This encrypted message will be embedded in the message to Diana, and the entire message will be encrypted again with Diana's public key. Then, the message to Diana will be nested in the message to Carol, and the whole message will be encrypted again with Carol's public key. Repeat this repeatedly to get the news that can be handed over to the next person. In this way, Bob can only decrypt the outermost layer of the message, get the content intended for him; then forward the message to Carol; Carol does the same. For each passing person, only the absolutely necessary information is disclosed: the amount paid, the amount of the commission, the content of the time lock, etc.
In order for people not to infer the length of the chain from the length of the message, the length of the message is always the same, always as if there were 20 people participating in the chain. Everyone, including the last one, gets the same size image, thinking there are 20 other people besides themselves.
Benefits and Application Scenarios of Lightning Network
Of course, the benefits of the Lightning Network are not just scalability, as many people think. Let's think about what possibilities the Lightning Network brings.
Instant transactions. When using the Lightning Network, transactions are almost instantaneous. So buying coffee with bitcoin becomes feasible
Exchange arbitrage. Currently, it is inconvenient to transfer funds out of one exchange and into another, waiting 3 to 6 blocks for the transaction to be confirmed. If exchanges can use the Lightning Network, users can transfer funds instantly and participate in arbitrage. Exchanges also no longer need cold wallets to store funds, greatly reducing the risk of theft.
Small payments. Bitcoin blockchain fees are too high for small payments. It's hard to imagine anyone willing to pay 0.001 btc just to transfer the same amount or even less. With the Lightning Network, you can instantly transfer any amount of money, for example, you can pay your network fee by MB.
Financial smart contracts and transactions. Financial contracts are extremely latency sensitive and often require many computations. By moving most of the burden off the blockchain, we have the opportunity to create very complex transactions and contracts without recording them all on the blockchain.
privacy. In the Lightning Network, transactions are more private than on the Bitcoin blockchain, because the participants in the payment chain do not know the origin and destination of the transaction.
in conclusion
(over)
Link
Lightning network in depth, part 1: Payment channels
“Mastering bitcoin” — Andreas M. Antonopoulos
Lightning network whitepaper
Segregated witness for dummies
(over)
Original link:
https://medium.com/softblocks/lightning-network-in-depth-part-2-htlc-and-payment-routing-db46aea445a8
Author: Magomed Aliev
Translation: A Jian
IOS
Android