On Tue, Oct 17, 2023 at 10:34:04AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Antoine et al.,
> 
> Let me try to rephrase the core of the attack.
> 
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==` are channels):
> 
>     A ===== B ===== C
> 
> `A` routes `A->B->C`.
> 
> The timelocks, for example, could be:
> 
>    A->B timeelock = 144
>    B->C timelock = 100
> 
> The above satisfies the LN BOLT requirements, as long as `B` has a `cltv_expiry_delta` of 44 or lower.
> 
> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the signed transactions --- commitment transaction and HTLC-timeout transactions --- are "stuck" at the feerate at the time.
>
> At block height 100, `B` notices the `B->C` HTLC timelock is expired without `C` having claimed it, so `B` forces the `B====C` channel onchain.
> However, onchain feerates have risen and the commitment transaction and HTLC-timeout transaction do not confirm.

The problem here is we're failing to use RBF.

As I have suggested before, the correct way to do pre-signed transactions is to
pre-sign enough *different* transactions to cover all reasonable needs for
bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10
different replacement transactions covers a fee range of 1024x. And you
obviously can improve on this by increasing the multiplier towards the end of
the range.

Increasing per-tx (temporary) storage and bandwidth costs by ~10x or even ~100x
is not a big deal in the context of a highly scalable protocol like Lightning.

There is zero reason why the B->C transactions should be getting stuck. This is
a major failing of the Lightning protocol that should be fixed. And of course,
this fix should be applied to other aspects of the lightning protocol, such as
channel opens, etc.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org