Proof-of-closure as griefing attack mitigation

Summary:

The article focuses on the problem of griefing attacks in multi-hop payments using offchain protocols, which can result in significant delays in payment delivery. The use of timelocks measured in blocks makes it challenging to enforce timeouts for payments in units of entire blocks, leading to griefing attacks where a multi-hop payment is intentionally set up in a "pending" state for long periods. Various proposed solutions to mitigate the effects of such attacks are assessed, and proof-of-closure is suggested as a solution that requires significant changes to the update state machine.A griefing attack can be performed when an intermediate node in a multi-hop attempt delays forwarding or failing an incoming HTLC, or when a final node delays claiming an incoming HTLC. Such attacks will most likely be performed by payers and payees against intermediate nodes, not by intermediate nodes themselves. Proposed solutions for protecting intermediate nodes in onion routing have been found inadequate, and new solutions like proof-of-closure are proposed to address these issues.Proof-of-closure has two timeouts: a "hard" block-based timeout that is enforceable on-chain and a "soft" sidereal-time-based timeout that is not on-chain enforceable. The payee with the shortest "hard" and "soft" timeouts delays claiming the payment, violating the "soft" timeout, and triggering a channel closure that disincentivizes E from attacking intermediate nodes. Enforcement of the soft timeout *is* a channel closure, which is generally a negative for the network. C needs to prove that it is willing to close a channel due to a violation of the soft timeout.The Lightning Network protocol may utilize a proof-of-closure mechanism to enable safe and secure payments. The proposed mechanism requires that the sender provides proof of closure before processing the payment, ensuring that the transaction is completed only if both parties have revoked their previous commitment transactions and created new ones. This change requires redesigning the update state machine, increasing communication turnarounds, and creating an incompatibility when transitioning a payment from a hop that knows only the old update state machine to one that knows the new update state machine.To address the risk of an attacking node creating a false proof-of-closure by simulating a Lightning channel, the punishment for providing false proof-of-closure is to force attackers to have their channels closed. The proof-of-closure mechanism can be used for any update mechanism, and acceptable forms of HTLC need to be agreed-upon by the entire network. In the future, there will not be any HTLC, but instead a PTLC, and payment points will be changed at each hop 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. The proof-of-closure mechanism may cause a mild privacy loss, but it only triggers in case of violation of the soft timeout and does not affect normal non-malicious payments.

Updated on: 2023-06-03T00:36:34.880083+00:00