From pete at petertodd.org Fri Oct 20 10:31:03 2023 From: pete at petertodd.org (Peter Todd) Date: Fri, 20 Oct 2023 10:31:03 +0000 Subject: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" In-Reply-To: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com> References: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: