Proof-of-closure as griefing attack mitigation [combined summary]

• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-16 07:08:59+00:00
• Proof-of-closure as griefing attack mitigation Subhra Mazumdar 2020-04-16 06:09:35+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-16 05:09:21+00:00
• Proof-of-closure as griefing attack mitigation Subhra Mazumdar 2020-04-16 04:23:41+00:00
• Proof-of-closure as griefing attack mitigation Subhra Mazumdar 2020-04-13 03:47:14+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-13 03:42:56+00:00
• Proof-of-closure as griefing attack mitigation Subhra Mazumdar 2020-04-13 03:39:44+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-13 02:50:57+00:00
• Proof-of-closure as griefing attack mitigation Subhra Mazumdar 2020-04-13 02:27:59+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-12 08:30:29+00:00
• Proof-of-closure as griefing attack mitigation Rusty Russell 2020-04-06 01:20:18+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-05 00:54:28+00:00
• Proof-of-closure as griefing attack mitigation David A. Harding 2020-04-04 16:05:46+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-03 02:51:15+00:00
• Proof-of-closure as griefing attack mitigation Nadav Kohen 2020-04-02 14:56:42+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-02 00:43:11+00:00
• Proof-of-closure as griefing attack mitigation Nadav Kohen 2020-04-01 20:07:51+00:00
• Proof-of-closure as griefing attack mitigation Nadav Kohen 2020-04-01 18:07:58+00:00
• Proof-of-closure as griefing attack mitigation ZmnSCPxj 2020-04-01 06:19:03+00:00

Published on: 2020-04-16T07:08:59+00:00

Summary:

The article discusses the issue of griefing attacks in multi-hop offchain payment attempts in the Lightning Network. These attacks can cause payments to be stuck pending for long periods of time due to enforced onchain timelocks. Various proposed solutions have been assessed, including time-spent reporting and up-front payment, but these also have drawbacks.A new solution called proof-of-closure is proposed. It introduces a softer timeout that is measurable in fractions of a second and is not enforceable on-chain. Each node advertises a timeout delta, and each invoice contains a final timeout in units of 0.1 seconds. If the soft timeout is violated, the channel is dropped on-chain and reported upstream.Enforcement of the soft timeout is a channel closure, which is generally negative for the network. To prove willingness to close a channel, a node needs to provide the unilateral close of the channel. The other party validates this proof-of-closure by checking if the unilateral close transaction is on-chain or in the mempool. Additionally, the channel in question must be involved in the same payment attempt.The article also discusses the use of update state mechanisms and how they can make it difficult to report willingness to close a channel. The Poon-Dryja update mechanism is explained, and a ritual with Decker-Russell-Osuntokun is suggested to remove the risk of collusion between nodes.The Lightning Network plans to implement payment points and payment decorrelation to increase privacy. Each hop will have its own unique payment point, which will change at each hop to prevent decorrelation. Proofs will need to be provided to ensure transactions are valid, and the article explains how this can be done.In conclusion, proof-of-closure is presented as a solution to protect intermediate nodes against payer/payee collusions. It has properties that address the issue of griefing attacks but requires careful implementation and consideration of privacy concerns. The proposed solution adds complexity, and there are discussions about the potential privacy loss and the use of up-front payments to further protect against griefing attacks. However, adding more complexity may not be ideal. The Lightning-dev mailing list also discusses privacy implications and concludes that proof-of-closure does not result in any privacy loss.The Lightning Network is also working on implementing payment points and payment decorrelation to enhance privacy during transactions. This involves replacing HTLC with PTLC and changing the payment point at each hop to prevent decorrelation. To validate the apparent singlesig on the unilateral close output as a PTLC and establish its connection to the payment attempt from B to C, certain actions need to be performed by C. Additionally, B must include its own blinding factor with the reported blinding factor to convince A that this is indeed the same payment attempt. These measures aim to address privacy concerns and ensure the validity of transactions within the Lightning Network.Overall, the article provides a comprehensive overview of the proposed proof-of-closure mechanism and its potential benefits and challenges. It highlights the need for further research and analysis to ensure the effectiveness of this solution in mitigating griefing attacks on the Lightning Network.

Updated on: 2023-07-31T22:46:59.752841+00:00