Proof-of-closure as griefing attack mitigation

Summary:

Contracts on offchain protocols need to be enforceable on-chain as well, so timelocks involved in multi-hop payments are measured in blocks. This leads to very long timeouts for payment delivery, thus multi-hop offchain payment attempts can be, deliberately or accidentally, be in a "pending" state up to the very large timeouts involved. Deliberately setting up a multi-hop payment such that it will be in a "pending" state for long periods of time is colloquially known as a "griefing attack". In this article, various proposed solutions to mitigate the effects of griefing attacks are assessed, and a particular solution, proof-of-closure, is proposed as well, that requires significant changes to the update state machine. Griefing attacks can be performed by intermediate nodes delaying forwarding or failing an incoming HTLC, or a final node delaying claiming an incoming HTLC. An intermediate node has no selfishly-rational motivation to execute a griefing attack on an arbitrary payment attempt. However, things are different when we consider a non-arbitrary payment. Suppose a node were to make a payment attempt to itself, and deliberately delay claiming this self-payment. This lets any single node, who happens to own large liquidity, to lock up the liquidity of other nodes. The motivation to lock up the liquidity of other nodes is to eliminate competition. This demonstrates that griefing attacks will be motivated, such that such attacks will be performed by payers and payees against intermediate nodes. Active griefing attacks are attacks on intermediate nodes, not by intermediate nodes, because there is no economic incentive for intermediate nodes to attack their customers. Previous proposed solutions include time-spent reporting. At each channel along the route, the time spent by a node to handle its forwarding is recorded, and reported upstream in the route. The current onion routing solution for the Lightning Network protects payers from intermediate nodes and payees, but not intermediate nodes from colluding payers and payees. Up-front payment, which requires payers to pay for an attempt rather than just successful completion, erects economic barriers against payer/payee collusions but also against normal payments.The new Proof-of-Closure solution introduces a softer timeout that is distinct from the HTLC block-based timeout, measurable in fractions of a second, and not enforceable on-chain. Each node advertises a timeout delta, and each invoice contains a final timeout in units of 0.1 seconds. If a soft timeout is violated, the channel is dropped on-chain and reported upstream. The major drawback of this solution is that enforcement of the soft timeout is a channel closure, which is generally negative for the network. To prove channel closes, a node needs to prove that it is willing to close a channel due to a violation of the soft timeout and that the channel was involved in the same payment attempt. The article discusses how to prove a willingness to close a channel in the context of Lightning Network. First, it explains that to prove willingness, one can provide the unilateral close of the channel. B, the other party, validates the proof-of-closure by checking if the unilateral close transaction is on-chain or in the mempool. Second, C needs to prove that the channel in question involves the payment attempt and is not some other channel closure to fulfill its own soft timeout.This is achieved by the fact that the unilateral close transaction is proof-of-closure, and B can inspect the transaction outputs to see that one of the outputs is to an HTLC that matches the payment hash. The article also discusses update state shenanigans and how they can be used to make it difficult for C to report willingness to close CE. It explains how the Poon-Dryja update mechanism works and how E, the payee, can claim HTLC from a commitment transaction when it reaches step 2. Until step 4, C cannot safely respond to its own soft timeout.To remove this risk, it suggests a ritual with Decker-Russell-Osuntokun. Prior to step 5, C can simply fail the incoming HTLC from B in case its own soft timeout is near. Even if E performs step 5 after C has already failed the incoming HTLC from B, C can simply not perform step 6 and drop the channel on-chain with the previous update and state transactions.The Lightning Network has proposed a new feature called the "Proof-of-Closure" mechanism, which can be used to provide an alternative to HTLCs (Hash Time-Locked Contracts) for Bitcoin transactions. The Proof-of-Closure mechanism will allow users to close Lightning channels unilaterally by creating a sequence of valid transactions that terminate in a transaction containing an HTLC-like contract in one of its outputs. This will enable users to validate unilateral closes and prevent attackers from creating false proof-of-closures.

Updated on: 2023-06-03T00:34:19.043273+00:00