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


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

On Thu, Jun 20, 2024 at 04:33:47PM +0000, Peter Todd wrote:
> Libre Relay/RBFR is already mitigating transaction pinning in the real wo=
rld.
> I've personally run into a few cases with LND nodes where anchor outputs =
were
> spent after the 16 block CSV timeout by third parties in a large transact=
ion
> that the LND node was not aware of, leading to LND creating a conflicting=
,
> higher-fee, transaction spending the anchor output and other outputs. Nor=
mally
> the conflict would fail to get mined due to the higher absolute fee pin. =
But in
> each case after propagation via Libre Relay nodes, F2Pool eventually mine=
d the
> higher fee-rate transaction after a few hours; I suspect F2Pool has an un=
usual
> short mempool expiration time. Lightning node operators should consider r=
unning
> Libre Relay for this purpose, as the existing Lightning protocol does hav=
e some
> pinning vulnerabilities.

Here's a real world example of this pinning situation being resolved by RBF=
R,
in a transaction created by someone's LN node. You can see the RBFR replace=
ment
happening on one of my Libre Relay nodes, with the total fees being decreas=
ed
in exchange for a higher fee-rate:

2024-06-20T18:50:33Z [mempool] replacing tx 2bbc326c641fe88101fd7401721c1e8=
a30ce78264e73e3fd67b7803e1fcffe93 (wtxid=3Df873e1e56be6b5ef21f30542a5823e1c=
e75634fcab8143a5e53bf1aae91852ed) with 26aa0ea3b84d31b7ff90e428430a0e9dad68=
ff24ccc87cece05bd7733c7b0e19 (wtxid=3D389a1f9cb2cfc0389bd7aad5037fc1d7fb2f0=
24921b110d8db6a3dba8fb6a134) for -0.00309094 additional fees, -58207 delta =
bytes
2024-06-20T18:50:33Z [mempool] AcceptToMemoryPool: peer=3D41398: accepted 2=
6aa0ea3b84d31b7ff90e428430a0e9dad68ff24ccc87cece05bd7733c7b0e19 (wtxid=3D38=
9a1f9cb2cfc0389bd7aad5037fc1d7fb2f024921b110d8db6a3dba8fb6a134) (poolsz 877=
26 txn, 289021 kB)

Transaction 26aa spent three anchor outputs in a 13.1sat/vB transaction tha=
t
was pinned by tx 2bbc at 5.37sat/vB, broadcast two days prior:

2024-06-18T13:18:50Z [mempool] AcceptToMemoryPool: peer=3D56868: accepted 2=
bbc326c641fe88101fd7401721c1e8a30ce78264e73e3fd67b7803e1fcffe93 (wtxid=3Df8=
73e1e56be6b5ef21f30542a5823e1ce75634fcab8143a5e53bf1aae91852ed) (poolsz 750=
64 txn, 285641 kB)

Fee-rates that low haven't been profitable to mine for months, so F2Pool
profited by mining 26aa instead, even though the total fee was reduced; I a=
lso
checked logs on some non-RBFR nodes, and they never even saw 26aa. I know f=
or a
fact that F2Pool is directly connected to some Libre Relay nodes, so the mo=
st
likely route 26aa got to them was via Libre Relay.


The fact this happened is a good example of how the "free-relay" argument
against RBFR is bogus: tens of thousands of non-RBFR nodes wasted bandwidth
propagating 2bbc, 95kB in size, with 1121 inputs. Yet even though just a do=
zen
or two RBFR nodes exist, the RBFR replacement was able to get to a miner,
eventually getting into a block and invalidating 2bbc while only needing to=
 pay
the cost to spend a single input. The miner in question probably doesn't ev=
en
run RBFR: they just allowed the transaction to eventually expire. Which Bit=
coin
Core does by default anyway after 2 weeks.

--=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/ZnSuSh1FBGSYlPFE%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmZ0rkgACgkQLly11TVR
Lze2XBAAjtTbdzvdDMPgnCVBAls+Qwv3LwFZj0jbjZEA8jvZQO1fXKNURFxlFZa7
reWkz4Csnw9sZ7I6gBtxf/VJ74v4pIMK0QmKbfm3Qubth4zso22E/rBH5YbtlDDN
kOJefFI0Ne3NKrZIvnzr79f6auSBN73P9JZawl5o91RLNja6tkI5t9EUuPT6wIZH
qZmeo6Dws26RUTujUWPmvlQs0QI+uzAC/TwBwXW3ngUSplteE13JN29oDTwv64nj
9Dh44MWP4las9O1TTgoV4PqaEmtpWqu/FpmfXN78YlS7YOPVLPNxc6wFhPDlJHNI
c8GfMBzyC9doL1B5FZEJzxiZaL4gCC8er8LbdE7WohgD0l/L3u11yYGBmeS0Cvtn
Bl9vhlmc2LSmWZFK3lEdJy4nTY27sSTyVncDYxm6dLwIT+SH+I8emewoqnoMTGE/
6TJg1XjS1TqbebVh0hLQxIbMArvwDNuCJ9NQ4gShifrTesMK8L/ms+AvITqAX1WX
J6/XLxdNu7sBO/k7vWE2SMdGYPEsJqXBJB0LxmOcdDHZpR8spWQ4nzxXuupJZjag
eOYJDfG20n5x3yNN3F6V4W/U+FPGHuFWEErLubB2RL0mSYhkPUkaDvCyAebU93hb
0cBNwJXJEcppVKFJ5a+lDSJg6MMYtZrPPji4kG3ateadBsGSqNQ=
=xCAe
-----END PGP SIGNATURE-----

--TgepFErliItSEnjn--