Published on: 2021-10-21T07:28:42+00:00
The lightning-dev mailing list recently discussed a proposal to improve the Lightning Network's payment latency. Currently, the network shoots an HTLC (Hashed Time-Locked Contract) first and then asks whether it can be resolved. However, the proposal suggests that nodes should ask first before sending the actual transaction. This change would reduce the number of round trips per hop in the event of a failure along a route, replacing them with a single large round trip from the payer to the failure point.While this proposed improvement could potentially enhance payment latency, there are concerns that it may also open up a potential Denial-of-Service (DoS) vector. Any node could trigger network activity by asking random questions of random nodes. To mitigate this risk, the proposal suggests making generating an onion (the encryption scheme used) costly but validating and decrypting it cheap. This means that the sender would use an encryption scheme that is more computationally expensive to encrypt but cheap to decrypt. Alternatively, proof-of-work could be required on the onion, where each unwrapped onion layer must have a hash that is less than a certain threshold.Another suggestion put forward was for nodes to upgrade and accept "no" from any node along the payment path but only accept "yes" from the actual payee. This would provide additional flexibility and security. Additionally, senders could attach a random identifier to a probe, allowing for multi-part probes with the same identifier. Routing nodes would deduct the outstanding probe amounts from the available balance, but only for probes within the same group (with the same id). This approach ensures that each probe (or group) is isolated from everything else that is happening.Overall, the proposed changes have the potential to improve payment latency in the Lightning Network. With fewer failures due to nodes or channels failing along the way, charging for failed actual HTLCs could become more acceptable. However, it is important to note that implementing this proposal would require a whole-network upgrade, and intermediate nodes must also upgrade to support the new mechanism.
Updated on: 2023-07-31T23:49:52.857521+00:00