In the previous article “How the Lightning Network Works (1),” we explored the operational principles of the Lightning Network and the security technologies related to bidirectional payment channels. In today’s article, we will continue to introduce the Lightning Network, clarifying the principles and technologies involved in expanding bidirectional payment channels into the Lightning Network.
Expanding Bidirectional Payment Channels into the Lightning Network: Multi-Hop Routing Technology#
We also use Alice and Bob to establish channels as the basic background, but what if others besides Alice and Bob want to connect to the Lightning Network? Is there a way to connect everyone to the network and ensure that payments can be initiated to anyone in the network?
To solve this problem, we need to expand bidirectional payment channels into the Lightning Network and use multi-hop routing technology. The literal meaning of “routing” is “finding a path,” in the Lightning Network, it means finding a path formed by the connections of channels to make payments to a specific entity.
For example, if Alice wants to pay David 2000 satoshis, and there is no payment channel established between them, but there are payment channels established between Alice and Bob, Bob and Carol, and Carol and David. In this case, Alice can first transfer the money to Bob, then Bob transfers it to Carol, and finally, Carol transfers it to David. This way, it seems to have achieved a payment channel from Alice to David, with Bob and Carol acting as routing nodes in the network. If there are also payment channels established between Alice and Eva, and Eva and David, then Alice can also choose to first transfer the money to Eva, and then Eva transfers it to David.
From the perspective of the path, it is clear that Alice transferring money to David through Eva is the shortest option, but in actual operation, the shortest path does not always represent the best choice, as other factors need to be considered, such as channel capacity, routing node fee standards, whether routing nodes are online, etc.
Currently, mainstream implementations of the Bitcoin Lightning Network (clients), such as LND developed by Lightning Labs and CLN (Core Lightning) developed by Blockstream, use a variant of Dijkstra's algorithm for routing algorithms. The Lightning Network Fiber Network launched by Nervos CKB also uses Dijkstra's algorithm to find optimal routing paths.
Ensuring Routing Security: From HTLC to PTLC#
In the example above where Alice wants to pay David, how do we ensure that the intermediate routing nodes will not act dishonestly and maliciously withhold funds? Traditional financial systems typically rely on the credit guarantees of large, well-known financial intermediaries, but the Lightning Network is a P2P network and does not have such an independent third party to provide credit guarantees; we need a different mechanism to ensure transaction security. This is where HTLC (Hash Time-Locked Contract) comes into play.
HTLC consists of two parts: hash verification and expiration verification. Let’s take the example of Alice wanting to pay David 2000 satoshis, choosing Bob and Carol as routing nodes in the network to understand how HTLC works:
- First, David generates a secret value R, which can be any word or number, 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, and only the person who knows the secret value R corresponding to H can use this output, where R is referred to as the “preimage” in the Lightning Network. If the secret value R is not disclosed in time, the payment becomes unusable, and the sender will reclaim all the funds.
- Then, Alice uses the received hash value H to create an HTLC, setting the time lock to the next 5 blocks, with an output amount of 2020 satoshis, of which 20 satoshis is the fee for routing node Bob. In simple terms, Alice will pay Bob 2020 satoshis as long as he can provide the secret value R within 5 blocks; otherwise, this money will return to Alice.
- Bob, in his channel with Carol, uses the same hash value H provided by Alice to create an HTLC, setting the time lock to the next 4 blocks, with an output amount of 2010 satoshis, of which 10 satoshis is the fee for routing node Carol. In simple terms, Bob will pay Carol 2010 satoshis as long as he can provide the secret value R within 4 blocks; otherwise, this money will return to Bob.
- Carol, in her channel with David, uses the same hash value H to create an HTLC, setting the time lock to the next 3 blocks, with an output amount of 2000 satoshis. In simple terms, Carol will pay David 2000 satoshis as long as he can provide the secret value R within 3 blocks; otherwise, this money will return to Carol.
- David unlocks the HTLC set by Carol using the secret value R and takes 2000 satoshis.
- After David takes the funds, Carol will also know this secret value R, and she uses R to unlock the HTLC set by Bob and takes 2010 satoshis.
- After Carol takes the funds, Bob also obtains the secret value R, and he uses R to unlock the HTLC set by Alice and takes 2020 satoshis.
Through this mechanism, Alice successfully paid David 2000 satoshis without needing to establish a direct payment channel. Throughout the process, the parties do not need to trust each other, and the routing nodes also receive their deserved fees. Even if the payment is interrupted at some point, due to the time-lock mechanism, no party will suffer losses, and the funds will automatically return after the lock time expires.
However, HTLC also has a potential privacy issue: the same secret value (preimage) is used throughout the entire path. If an entity controls multiple nodes along the payment path, it may be able to infer complete transaction information by comparing the inputs and outputs of different nodes, even guessing the payer and payee, which undermines the privacy protection achieved by onion routing in the Lightning Network.
To address this issue, the Bitcoin community proposed PTLC (Point Time-Locked Contract). In the PTLC scheme, each hop in the path uses a different secret value, thus protecting the privacy achieved through onion routing. 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 continuous technological advancements, the Lightning Network is still being optimized and improved. From LN-Penalty to eltoo and then to Daric, from HTLC to PTLC, we have seen the continuous enhancement 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 for promoting the adoption of cryptocurrencies, contributing 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.btcstudy.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/