Proof-of-closure as griefing attack mitigation

Summary:

The email conversation between Subhra and ZmnSCPxj revolves around the issue of griefing attacks in multi-hop offchain payments. These attacks can cause long delays or pending status for payments, which can be frustrating for users. ZmnSCPxj explains that solutions that require invalidating previous transactions would involve significant amounts of transactions and are difficult to implement due to Bitcoin principles such as a transaction becoming valid and always remaining valid unless double-spent. Additionally, SCRIPT is only able to check the transaction it is executing on. The discussion also touches upon the possibility of a delay in providing a preimage as a form of griefing in HTLC.An article attached to the email explores various proposed solutions to mitigate the effects of griefing attacks and proposes a proof-of-closure solution that requires significant changes to the update state machine. It also delves into the motivations behind griefing attacks and how they can be performed by intermediate or final nodes in a payment attempt. In the Lightning Network, there are "hard" and "soft" timeouts for HTLCs (Hashed Time-Locked Contracts). The hard timeout is enforceable on-chain, while enforcement of the soft timeout is the act of putting the channel state on-chain. Proof-of-closure is presented as a solution that protects intermediate nodes against payer/payee collusions and only comes into play upon detection of an attack. It involves a softer timeout measurable in fractions of a second in addition to the block-based timeout. Each node on the network advertises a `timeout_delta` in units of 0.1 seconds, and each invoice contains a `final_timeout`. This creates two timeouts: a hard block-based timeout that is enforceable on-chain and a new soft sidereal-time-based timeout that is not on-chain enforceable. Enforcement of the soft timeout is generally a negative for the network, but not a remote attack vector since a node can only trigger this closure if it can stall the fulfillment or failure of an HTLC on a channel for its own channels.The article discusses the potential risks and challenges associated with updating Bitcoin transactions through Lightning Network channels. Specifically, it examines how an attacking payee could manipulate the update state machine and make it difficult for the channel participant to report a willingness to close the channel. The Poon-Dryja update mechanism is then analyzed in detail, highlighting the different states of the update process and the potential risks associated with each step.The Lightning Network, which is a layer 2 payment protocol on top of the Bitcoin blockchain, has proposed an update mechanism that involves the concept of "unilateral close". This allows for a channel to be dropped onchain using data that only one participant holds. The unilateral close will involve a sequence of valid transactions, ending in a transaction containing an HTLC-like contract in one of its outputs. To validate the closure, it is required to validate all the transactions in the proof-of-closure and see that the last transaction has an HTLC output.To fix the privacy loss associated with having a single payment hash for the entire payment attempt, Lightning Network intends to use payment points and add a blinding scalar at each hop, also known as payment decorrelation. In the future, there will be no HTLCs, but instead a PTLC, where the payment point at each hop will be changed to prevent decorrelation.Proof-of-closure is only propagated in case of violation of the soft timeout, so for normal non-malicious payments, proof-of-closure does not cause any privacy loss.

Updated on: 2023-06-03T00:28:57.918611+00:00