Feedback-ID: i525146e8:Fastmail
Date: Fri, 20 Oct 2023 10:31:03 +0000
From: Peter Todd <pete@petertodd.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZTJW59wQ/4WLZt2h@petertodd.org>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
 <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="+mk2Sy32npezIUMt"
Content-Disposition: inline
In-Reply-To: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
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"
Precedence: list


--+mk2Sy32npezIUMt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 17, 2023 at 10:34:04AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Antoine et al.,
>=20
> Let me try to rephrase the core of the attack.
>=20
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, =
`=3D=3D` are channels):
>=20
>     A =3D=3D=3D=3D=3D B =3D=3D=3D=3D=3D C
>=20
> `A` routes `A->B->C`.
>=20
> The timelocks, for example, could be:
>=20
>    A->B timeelock =3D 144
>    B->C timelock =3D 100
>=20
> The above satisfies the LN BOLT requirements, as long as `B` has a `cltv_=
expiry_delta` of 44 or lower.
>=20
> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the =
signed transactions --- commitment transaction and HTLC-timeout transaction=
s --- are "stuck" at the feerate at the time.
>
> At block height 100, `B` notices the `B->C` HTLC timelock is expired with=
out `C` having claimed it, so `B` forces the `B=3D=3D=3D=3DC` channel oncha=
in.
> However, onchain feerates have risen and the commitment transaction and H=
TLC-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 i=
s 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-signin=
g 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 Lightni=
ng.

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

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

--+mk2Sy32npezIUMt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmUyVtcACgkQLly11TVR
LzeQQA//XLxel/DWTNtDGuounMdKVYginnE2REUq9EUgEqqH9dsQhnY4jLZLIfRQ
vQlCyKOnZ2Fye+4mhh7vDs/yCp3oGxQ+JL1rU4Dq4GO3A6i7lWuJs+G+xcsDRYjN
JLjUVGCnvczqn1S8jfNbX9mndN3mXnBFGbO2plEcQR/GnEJ1QL9DSjZFO8Z7186+
r34Nc2Mpdp5R/tl6w1GlR03Uhg/xXw9PHykMPmFUjH0LNL+Z+tJepEQZ6DzRcLuc
gWU7kC8tqDRfDcfY6+A5d/xh3tpaJwnVhWbaet0WYk7nU/VVlStdHQrwCJjThzL5
8N99cK4UgSugDwwEQCMdSkBqcJ/UuPSheDs826cMfzEO/bu+SBm7I8HWennT6LVC
kDMNQJtrEv+hsZmEfy9/g/XlUDt70lHn+vQmk/C7xtzrfR4qHwMbw22lGWY403uM
9aQW80zPtsndnvfzw1+z3upVF0h6DEuv+PVjK6o9qv/oDglK/+kSY0GtyRgqT1Ki
YbaMBZTUPpjxbineGKjCMGvDOtapP1FsNfaIFCVtiq+AYwfJpgoL9ca+FI9YXIe9
G6RliZzPLN6USCpCWRI4CEcpmS9h6zYCof7kZYhoRtuOlhQRIckqzqlpgvwZ7B1d
OJYlDVJsavH+ywT9TUW+f/B6afzkJ+pZ5eetlAFT175GpMeCxqs=
=l1vV
-----END PGP SIGNATURE-----

--+mk2Sy32npezIUMt--