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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
