Author: ZmnSCPxj 2020-04-16 07:08:59
Published on: 2020-04-16T07:08:59+00:00
The Lightning network has a problem with long timeouts for payment delivery in multi-hop payments. This is because blockchain can only enforce timeouts in entire blocks. Pending payments can be the result of deliberate or accidental griefing attacks, which cause losses for honest participants. Proposed solutions to mitigate the effects of these attacks have limitations. Proof-of-closure is one solution but requires significant changes to the update state machine. However, there is uncertainty about whether griefing is actually a problem. Nonetheless, there are forms of griefing attacks that pose a challenge in preventing funds from being deducted from the intended recipient.One proposed solution to this problem is proof-of-closure where each node advertises a timeout delta in units of 0.1 seconds and each invoice contains a final timeout in addition to a block-based final cltv. The softer timeout is measurable in fractions of a second and only comes into play upon detection of an attack. The Lightning Network has also introduced a new "soft" sidereal-time-based timeout that is not onchain enforceable. This is in addition to the existing "hard" block-based timeout that is enforceable onchain. To prove its willingness to close a channel in case of a protocol violation, a node needs to provide the unilateral close of the channel.The Lightning Network's update mechanisms are complex and can be vulnerable to attacks. The Decker-Russell-Osuntokun protocol proposes a solution by requiring a series of steps that include exclusive access requests, HTLC details exchange, and new state transaction generation before signature exchange and release of the exclusive lock on the shared state. In contrast, the Poon-Dryja mechanism allows the sender (C) to provide proof-of-closure after step 2, allowing for safe return of an `update_fail_htlc`. The Lightning Network is exploring the concept of a "unilateral close" where a channel can be dropped onchain using data that only one of the channel participants holds. To validate the unilateral close, it is only required to validate all the transactions contained in the proof-of-closure and see that the last transaction has an HTLC output. However, the acceptable forms of HTLC would need to be agreed-upon by the entire network, and implementations would need to be able to assess whether a transaction is valid or not.To address privacy concerns, there will not be any HTLCs in the future, but instead a PTLC. Each payment point at each hop will be changed to prevent decorrelation. C needs to provide proofs that an apparent singlesig on the unilateral close output is in fact a PTLC and that the PTLC belongs to the same payment attempt as what B offered to C. While there is a mild privacy loss when this mechanism triggers, as intermediate nodes now know some channel closure related to this payment, proof-of-closure is only propagated in case of violation of the soft timeout. Therefore, for normal non-malicious payments, proof-of-closure does not cause any privacy loss.
Updated on: 2023-06-03T00:41:48.802565+00:00