Proof-of-closure as griefing attack mitigation

Summary:

The article focuses on the issue of griefing attacks on payment channels in the Lightning Network and proposes a solution called "proof-of-closure" to protect intermediate nodes from colluding payers and payees. The proposed solution involves providing a proof of closure for each payment attempt, which can be used to punish any party that delays or fails to deliver an HTLC. However, one potential issue raised is that giving a proof of closure is equivalent to actually closing the channel, making it unsafe to revoke the closure as other parties would have copies of the fully signed commitment transaction and could publish an old state. To address this problem, the article suggests using up-front payments on payments with abnormally high soft timeouts to enable hodl invoices under the proof-of-closure proposal. The authors also explore the motivation behind griefing attacks and demonstrate that active griefing attacks are attacks on intermediate nodes because there is no economic incentive for intermediate nodes to attack their customers.The proposed proof-of-closure mechanism uses a softer timeout in addition to the current hard block-based timeout that is enforceable on-chain. Each node advertises a `timeout_delta` in units of 0.1 seconds in addition to a `cltv_delta`. While the soft timeout is not enforceable on-chain, enforcement of it is the act of putting the channel state on-chain. If a party delays claiming payment and violates the soft timeout, the other party drops the channel on-chain and reports the closing of the channel before its own timeout expires. The article also discusses the potential risks of an attacking payee who can manipulate the update state machine, making it difficult for the other party to report a willingness to close the channel. The article suggests two mechanisms, Decker-Russell-Osuntokun and Poon-Dryja, to eliminate this risk. However, Poon-Dryja requires redesigning the update state machine, creating a subtle incompatibility when transitioning a payment from a hop that knows only the old update state machine to a hop that knows the new update state machine.To validate the unilateral close, it is required to validate all the transactions contained in the proof-of-closure and see that the last transaction has an HTLC output. The article also discusses the issue of privacy loss and suggests using payment decorrelation and payment points in the future to address this problem.Finally, the context explains PTLC and C-to-E PTLC on the unilateral close. The mechanism triggers when the other party needs to propagate the proof-of-closure back to the original payer by adding its own blinding factor to the reported blinding factor, which convinces the payer that it is the same payment attempt. However, this mechanism causes a mild privacy loss as intermediate nodes can determine the exact path that the payment attempt went through until the channel being closed. It is important to note that proof-of-closure is only propagated in case of violation of the soft timeout, so it does not cause any privacy loss for normal non-malicious payments.

Updated on: 2023-06-03T00:17:55.555729+00:00