Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

From: Peter Todd <pete@petertodd•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: security@ariard•me,
	"lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
	<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Date: Fri, 20 Oct 2023 10:31:03 +0000	[thread overview]
Message-ID: <ZTJW59wQ/4WLZt2h@petertodd.org> (raw)
In-Reply-To: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]