Author: Olaoluwa Osuntokun 2020-04-22 23:05:17
Published on: 2020-04-22T23:05:17+00:00
Laolu Osuntokun proposed a method to mitigate attacks on HTLC transactions using RBF pinning in a discussion on the Bitcoin-dev mailing list. The attack involves a counterparty (C) of a lightning network transaction spending an HTLC with the preimage using a low-fee, non-RBF signaled transaction, leaving the original payer (B) short the HTLC value. Laolu's proposal involves forcing the attacker to spend the output with a non-final sequence number, meaning it must signal RBF. Adding `OP_CHECKSEQUENCEVERIFY` to the hashlock branch would be a low-weight mitigation against this attack.ZmnSCPxj suggested that B can attach a new input+output pair to increase fees and enter into a race with the malicious node to win over the other party if the malicious node uses a non-RBF signaled transaction. If there exists a relay path to a miner running full RBF, then B's higher fee rate spend will win over. ZmnSCPxj mentioned that adding `OP_CHECKSEQUENCEVERIFY` to the hashlock branch in this case includes preventing C from broadcasting a low-fee claim tx. However, there is a vulnerability in the fact that B is using a pre-signed HTLC-timeout, which prevents B from RBF-ing the HTLC-Timeout transaction. To prevent this bidding war from even starting, B should ensure that before L+1, the HTLC-Timeout has been committed on-chain. The issue is that B is using a pre-signed HTLC-timeout, which is needed since it is its commitment tx that was broadcast. Adding an RBF carve-out output to HTLC-Timeout or making the C-side signature SIGHASH_NOINPUT|SIGHASH_SINGLE and allowing B to re-sign the B-side signature for a higher-fee version of HTLC-Timeout can solve the problem. With this solution, B can exponentially increase the fee as L+1 approaches. If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the HTLC value at all, since the UTXO it could steal from has already been spent. However, this only delays the war, and C can bribe a miner to prevent HTLC-Timeout from confirming between L and L+1, leading to a censorship attack. This sets up a bidding war between C requesting miners to censor, vs. B requesting miners to confirm, but that only sets the stage for a second bidding war later between C and B, thus C is at a disadvantage.The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECANPAY`. However, if B notices that the L+1 timeout is approaching, it can fee-bump HTLC-Timeout with some onchain funds, recreating its own signature but reusing the still valid C signature. This has the advantage of not needing a mempool still and can run in `blocksonly`. Costs are pretty low, and no mempool rule changes are needed. The additional output bloats the UTXO set and requires another transaction to claim later. With `SIGHASH_NOINPUT`, Decker-Russell-Osuntokun sidesteps this issue as any timed-out HTLC can be claimed with a fee-bumpable transaction directly without RBF-carve-out. It seems to me that if both nodes support doing so, a Poon-Dryja channel can be upgraded, without on-chain activity, to a Decker-Russell-Osuntokun channel. HTLCs now sidestep the issue under discussion here.
Updated on: 2023-05-20T22:05:29.498943+00:00