Delivery-date: Thu, 20 Jun 2024 09:56:38 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.157 as permitted sender) client-ip=103.168.172.157;
Feedback-ID: i525146e8:Fastmail
Date: Thu, 20 Jun 2024 16:33:47 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] Libre Relay v27.1 released with lower 1.25x replacement threshold
Message-ID: <ZnRZ6zhON4oT5Sg9@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="oM63tVpmq+z9KtGU"
Content-Disposition: inline
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--oM63tVpmq+z9KtGU
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

https://github.com/petertodd/bitcoin/tree/libre-relay-v27.1

A notable change in this release is I've lowered the replace-by-fee-rate=C2=
=B9
threshold to 1.25x, from the prior 2x. That means if the fee-rate of a
candidate replacement is more than 1.25x higher than the direct conflict, t=
he
replacement can happen. This does two things:

1. Reduces the worst-case cost to defeat transaction pinning.
2. Increases the expected cost of transaction pinning, as 25% is a small en=
ough
   margin that a pin transaction is likely to itself get mined.

Of course, this is a good opportunity for the people who think there are
"massive deficiencies"=C2=B2 in my RBFR proposal to actually prove it with =
an
exploit. Remember that you have to find a DoS attack that is significantly
better than the existing "free" relay attacks=C2=B9=C2=B3=E2=81=B4 that we =
inevitably have
without RBFR.

Libre Relay/RBFR is already mitigating transaction pinning in the real worl=
d.
I've personally run into a few cases with LND nodes where anchor outputs we=
re
spent after the 16 block CSV timeout by third parties in a large transactio=
n
that the LND node was not aware of, leading to LND creating a conflicting,
higher-fee, transaction spending the anchor output and other outputs. Norma=
lly
the conflict would fail to get mined due to the higher absolute fee pin. Bu=
t in
each case after propagation via Libre Relay nodes, F2Pool eventually mined =
the
higher fee-rate transaction after a few hours; I suspect F2Pool has an unus=
ual
short mempool expiration time. Lightning node operators should consider run=
ning
Libre Relay for this purpose, as the existing Lightning protocol does have =
some
pinning vulnerabilities.


1) https://petertodd.org/2024/one-shot-replace-by-fee-rate
2) https://x.com/achow101/status/1767641788192280917
3) https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg/m/iLVre7MYCAAJ
4) https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo/m/2bXhHzylBwAJ

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

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/ZnRZ6zhON4oT5Sg9%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmZ0WeYACgkQLly11TVR
Lzd1Ww/9F8tq0c7thqwQA8Ii8lyL0WNd5Xl3guOL+Cy15uXpuldI1t5IdaYrapTA
8pD2UY8BqUOpMnJvB6Gd6y04HKXrqDIG5PjW7rZ8GjvkbSTsPlO+AGSnnzX3Cgm/
mwFPlLSEmADvxDwJSbTpKRyi8S4psAoaQnMLRbIx7m/FlS6Fq1kzuZAJu/ECcxe3
UYBgx+HVmqyxNE6/bBx4crJ6QyL1jtmjB7X+h+pwUqtfl5DS8VFIEOhGE53VUlYy
ozquo34g8LW1/GIUZjYxhObQwuR53hNQtqIs2mNAoTrcuHw3XmLypjIBm/S0W4CY
9P2bxOS9n/DEfxymqdYr8aHmEcWp3AawxJBoMp2+mwOxjc3ei5RGWH+prpOpU7Ea
EjBnuxcxH6n51pYaJf5sOXyf8+5VZcwFNfnnLHTt/NoKBhKLfiQ4nn0GcNElQqCK
4tXqbx75ev6YzsgSyRwdnKjIhGnZp2ttbkOm8c3i20sCgM4OeseeirbM4g4m6NHO
GUfbz+myHfq+ku4Oj7f5/mbgiwL/sImOtxieiYgxZ9PHrz3CXcx1kiwNzrBJzkSa
XjEnmDM7d4Pu6N6jzeeljw+0sLk4WGMOMLGGPyjSQcSSVTkbpvtbsCFa/qaVWHKY
62FfVnwJnCfmQ/Z0qrX2sVBN3Oz5/JYPmgRZLLXz7dHf3G+2kSA=
=zUfj
-----END PGP SIGNATURE-----

--oM63tVpmq+z9KtGU--