How does the Lightning Network work (2)?

Source: Byte Yuan CKB

In the previous article "How does the Lightning Network work (1)", we discussed the operating principle of the Lightning Network and the security-related technologies of the two-way payment channel. In this article today, we will continue to introduce the Lightning Network and explain the relevant principles and technologies for expanding the two-way payment channel into the Lightning Network.

Expanding the two-way payment channel into the Lightning Network: Multi-hop routing technology

We also use Alice and Bob to establish a channel as the basic background, but what if other people in the world besides Alice and Bob also want to access the Lightning Network? Is there a way to connect everyone to the network and ensure that payments can be made to anyone in the network? To solve this problem, we need to expand the two-way payment channel into the Lightning Network and use multi-hop routing technology. "Routing" literally means "finding a path", and in the Lightning Network, it means finding a path that connects the channels to a specific object. For example, Alice pays David 2000 satoshis. Assume that there is no payment channel between them, but there are payment channels between Alice and Bob, between Bob and Carol, and between Carol and David. In this case, Alice can transfer the money to Bob first, then Bob transfers it to Carol, and finally Carol transfers it to David. In this way, it seems that a payment channel from Alice to David has been realized, with Bob and Carol acting as routing nodes in the network. If payment channels are also established between Alice and Eva, and between Eva and David, Alice can also choose to transfer the money to Eva first, and then Eva transfers it to David.

From the path point of view, it is obvious that Alice transferring money to David through Eva is the shortest path, but in actual operation, the shortest path is not always the best choice, because other factors need to be considered, such as the capacity of the channel, the charging standards of the routing nodes, whether the routing nodes are online, etc.

Currently, mainstream Bitcoin Lightning Network implementations (clients), such as LND developed by Lightning Labs and CLN (Core Lightning) developed by Blockstream, use a variant of the Dijkstra algorithm in their routing algorithms. The Lightning Network Fiber Network launched by Nervos CKB also uses the Dijkstra algorithm to find the optimal routing path.

Ensuring Routing Security: From HTLC to PTLC

In the above example where Alice wants to pay David, how can we ensure that the intermediate routing nodes will not cheat and maliciously withhold funds? Traditional financial systems usually rely on the credit guarantees of large and well-known financial intermediaries, but the Lightning Network is a P2P network, and there is no such third party independent of the trader to provide credit guarantees. We need a different mechanism to ensure transaction security. This is where HTLC (Hash Time Lock Contract) comes in.

HTLC consists of two parts: hash verification and expiration verification. Let's take Alice to pay David 2000 Satoshis, and choose Bob and Carol to act as routing nodes in the network as an example to understand how HTLC works:

1. First, David generates a secret value R, any word or any number can serve as this secret value, and then calculates its hash value H and sends it to Alice. This hash value H will be placed in the locking script of the transaction output. Only those who know the secret value R corresponding to H can use this output, and R is called the "preimage" in the lightning network. If the secret value R is not disclosed in time, the payment cannot be used and the sender will get all the funds back.

2. Alice then creates an HTLC using the received hash value H, with a time lock set to 5 blocks in the future, and an output amount of 2020 satoshis, of which 20 satoshis are the handling fee for the routing node Bob. In plain language, Alice will pay Bob 2020 satoshis as long as he can provide the secret value R within 5 blocks, otherwise the money will be returned to Alice.

3. Bob creates an HTLC in his channel with Carol using the same hash value H provided by Alice, with a time lock set to 4 blocks in the future, and an output amount of 2010 satoshis, of which 10 satoshis are the handling fee for the routing node Carol. To put it in plain language, Bob will pay Carol 2010 satoshis as long as he can provide the secret value R within 4 blocks, otherwise the money will be returned to Bob.

4. Carol uses the same hash value H to create an HTLC in her channel with David, with a time lock set to 3 blocks in the future and an output amount of 2000 satoshis. To put it in plain language, Carol will pay David 2000 satoshis as long as he can provide the secret value R within 3 blocks, otherwise the money will be returned to Carol.

5. David unlocks the HTLC set by Carol with the secret value R and takes away the 2000 satoshis.

6. After David takes the funds, Carol also knows the secret value R, and he uses R to unlock the HTLC set by Bob and takes away 2010 satoshis.

7. After Carol takes the funds, Bob also gets the secret value R, and he uses R to unlock the HTLC set by Alice and takes away 2020 satoshis.

Through this mechanism, Alice successfully pays 2000 satoshis to David without directly establishing a payment channel. Throughout the process, the parties do not need to trust each other, and the routing node also receives the due handling fees. Even if the payment is interrupted at some stage, due to the existence of the time lock mechanism, the parties will not suffer losses, and the funds will be automatically returned after the lock time.

However, HTLC also has a potential privacy issue: The entire path uses the same secret value (preimage). If an entity controls multiple nodes on the payment path, it may be possible to infer the complete transaction information by comparing the inputs and outputs of different nodes, or even guess the payer and the payee, which weakens the privacy protection achieved by the Lightning Network through onion routing.

To solve this problem, the Bitcoin community proposed PTLC (Point Time Lock Contract). In the PTLC scheme, each hop in the path uses a different secret value, so that the privacy achieved through onion routing is protected. The Lightning Network Fiber Network launched by Nervos CKB plans to introduce PTLC in the future to further enhance the privacy protection capabilities of the Lightning Network.

Conclusion

With the continuous advancement of technology, the Lightning Network is still being optimized and improved. From LN-Penalty to eltoo to Daric, from HTLC to PTLC, we have seen the continuous improvement of the Lightning Network in terms of security and privacy protection. In the future, with the application of more innovative technologies and the improvement of the ecosystem, the Lightning Network is expected to become a key infrastructure to promote the popularization of cryptocurrency and contribute to the realization of a true P2P economy.

References

• https://www.btcstudy.org/2021/09/15/lightning-network-in-depth-part-1-payment-channels/

• https://www.btcstu dy.org/2021/09/15/lightning-network-in-depth-part-2-htlc-and-payment-routing/

• https://www.btcstudy.org/2022/01/27/breaking-down-the-bitcoin-lightning-network-eltoo/

• https://www.btcstudy.org/2024/02/07/lightning-network-technology-improvement-and-users-experience-part-2/

• https://www.btcstudy.org/2024/02/23/lightning-network-technology-improvement-and-users-experience-part-3/

• https://www.btcstudy.org/2022/08/19/what-are-ptlc/