Libre Relay v27.1 released with lower 1.25x replacement threshold
369 views
Skip to first unread message
Peter Todd
Jun 20, 2024, 12:56:31 PMJun 20
to bitco...@googlegroups.com
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¹
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, the
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 enough
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"² 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¹³⁴ that we inevitably have
without RBFR.
Libre Relay/RBFR is already mitigating transaction pinning in the real world.
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 transaction
that the LND node was not aware of, leading to LND creating a conflicting,
higher-fee, transaction spending the anchor output and other outputs. Normally
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 mined the
higher fee-rate transaction after a few hours; I suspect F2Pool has an unusual
short mempool expiration time. Lightning node operators should consider running
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
--
https://petertodd.org 'peter'[:-1]@petertodd.org
A notable change in this release is I've lowered the replace-by-fee-rate¹
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, the
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 enough
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"² 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¹³⁴ that we inevitably have
without RBFR.
Libre Relay/RBFR is already mitigating transaction pinning in the real world.
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 transaction
that the LND node was not aware of, leading to LND creating a conflicting,
higher-fee, transaction spending the anchor output and other outputs. Normally
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 mined the
higher fee-rate transaction after a few hours; I suspect F2Pool has an unusual
short mempool expiration time. Lightning node operators should consider running
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
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Peter Todd
Jun 20, 2024, 6:52:45 PMJun 20
to bitco...@googlegroups.com
On Thu, Jun 20, 2024 at 04:33:47PM +0000, Peter Todd wrote:
> Libre Relay/RBFR is already mitigating transaction pinning in the real world.
> 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 transaction
> that the LND node was not aware of, leading to LND creating a conflicting,
> higher-fee, transaction spending the anchor output and other outputs. Normally
> 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 mined the
> higher fee-rate transaction after a few hours; I suspect F2Pool has an unusual
> short mempool expiration time. Lightning node operators should consider running
> Libre Relay for this purpose, as the existing Lightning protocol does have some
> pinning vulnerabilities.
Here's a real world example of this pinning situation being resolved by RBFR,
> Libre Relay/RBFR is already mitigating transaction pinning in the real world.
> 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 transaction
> that the LND node was not aware of, leading to LND creating a conflicting,
> higher-fee, transaction spending the anchor output and other outputs. Normally
> 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 mined the
> higher fee-rate transaction after a few hours; I suspect F2Pool has an unusual
> short mempool expiration time. Lightning node operators should consider running
> Libre Relay for this purpose, as the existing Lightning protocol does have some
> pinning vulnerabilities.
in a transaction created by someone's LN node. You can see the RBFR replacement
happening on one of my Libre Relay nodes, with the total fees being decreased
in exchange for a higher fee-rate:
2024-06-20T18:50:33Z [mempool] replacing tx 2bbc326c641fe88101fd7401721c1e8a30ce78264e73e3fd67b7803e1fcffe93 (wtxid=f873e1e56be6b5ef21f30542a5823e1ce75634fcab8143a5e53bf1aae91852ed) with 26aa0ea3b84d31b7ff90e428430a0e9dad68ff24ccc87cece05bd7733c7b0e19 (wtxid=389a1f9cb2cfc0389bd7aad5037fc1d7fb2f024921b110d8db6a3dba8fb6a134) for -0.00309094 additional fees, -58207 delta bytes
2024-06-20T18:50:33Z [mempool] AcceptToMemoryPool: peer=41398: accepted 26aa0ea3b84d31b7ff90e428430a0e9dad68ff24ccc87cece05bd7733c7b0e19 (wtxid=389a1f9cb2cfc0389bd7aad5037fc1d7fb2f024921b110d8db6a3dba8fb6a134) (poolsz 87726 txn, 289021 kB)
Transaction 26aa spent three anchor outputs in a 13.1sat/vB transaction that
was pinned by tx 2bbc at 5.37sat/vB, broadcast two days prior:
2024-06-18T13:18:50Z [mempool] AcceptToMemoryPool: peer=56868: accepted 2bbc326c641fe88101fd7401721c1e8a30ce78264e73e3fd67b7803e1fcffe93 (wtxid=f873e1e56be6b5ef21f30542a5823e1ce75634fcab8143a5e53bf1aae91852ed) (poolsz 75064 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 also
checked logs on some non-RBFR nodes, and they never even saw 26aa. I know for a
fact that F2Pool is directly connected to some Libre Relay nodes, so the most
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 dozen
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 even
run RBFR: they just allowed the transaction to eventually expire. Which Bitcoin
Core does by default anyway after 2 weeks.
Peter Todd
Jun 22, 2024, 10:50:42 AMJun 22
to bitco...@googlegroups.com
On Thu, Jun 20, 2024 at 10:33:46PM +0000, Peter Todd wrote:
> On Thu, Jun 20, 2024 at 04:33:47PM +0000, Peter Todd wrote:
> > Libre Relay/RBFR is already mitigating transaction pinning in the real world.
> > 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 transaction
> > that the LND node was not aware of, leading to LND creating a conflicting,
> > higher-fee, transaction spending the anchor output and other outputs. Normally
> > 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 mined the
> > higher fee-rate transaction after a few hours; I suspect F2Pool has an unusual
> > short mempool expiration time. Lightning node operators should consider running
> > Libre Relay for this purpose, as the existing Lightning protocol does have some
> > pinning vulnerabilities.
>
> Here's a real world example of this pinning situation being resolved by RBFR,
...and we have yet another example of this same pinning situation, involving a
> On Thu, Jun 20, 2024 at 04:33:47PM +0000, Peter Todd wrote:
> > Libre Relay/RBFR is already mitigating transaction pinning in the real world.
> > 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 transaction
> > that the LND node was not aware of, leading to LND creating a conflicting,
> > higher-fee, transaction spending the anchor output and other outputs. Normally
> > 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 mined the
> > higher fee-rate transaction after a few hours; I suspect F2Pool has an unusual
> > short mempool expiration time. Lightning node operators should consider running
> > Libre Relay for this purpose, as the existing Lightning protocol does have some
> > pinning vulnerabilities.
>
> Here's a real world example of this pinning situation being resolved by RBFR,
totally different Lightning node. This time the RBFR transaction was bumped one
more time with RBF before getting mined. But both transactions were still less
total fees than the pin tx:
2024-06-21T19:25:10Z [mempool] replacing tx 68b813b844e4160227e4e73573c23321d77b9fd2b4fe701b6a2a2a12309db020 (wtxid=08950f68152f7890f52a7f4029a89b54b26e7c575dd7c8eb5bf2910b7c13cbcb) with 4664cb8e556b1c673dbea7cbdc77c5ad29cfbf0e9a439d1b51874e2161f3edcc (wtxid=a63305ccd136f2b613f9add2b293c6d4eb20b0eca3271e687445b749aa9b7e69) for -0.0049018 additional fees, -98471 delta bytes
2024-06-21T19:25:10Z [mempool] AcceptToMemoryPool: peer=454: accepted 4664cb8e556b1c673dbea7cbdc77c5ad29cfbf0e9a439d1b51874e2161f3edcc (wtxid=a63305ccd136f2b613f9add2b293c6d4eb20b0eca3271e687445b749aa9b7e69) (poolsz 103582 txn, 283345 kB)
2024-06-21T22:13:09Z [mempool] replacing tx 4664cb8e556b1c673dbea7cbdc77c5ad29cfbf0e9a439d1b51874e2161f3edcc (wtxid=a63305ccd136f2b613f9add2b293c6d4eb20b0eca3271e687445b749aa9b7e69) with 4f6ed6c3fe25571b883a631503ab84cccef450b96d8c9065c712246758e15e6b (wtxid=7a465ba70b8f8d983aad594530751e9c17be77b3dac11275ade213ceccad997e) for 0.00003035 additional fees, 0 delta bytes
2024-06-21T22:13:09Z [mempool] AcceptToMemoryPool: peer=41398: accepted 4f6ed6c3fe25571b883a631503ab84cccef450b96d8c9065c712246758e15e6b (wtxid=7a465ba70b8f8d983aad594530751e9c17be77b3dac11275ade213ceccad997e) (poolsz 92468 txn, 273091 kB)
Again, it was F2Pool that fixed the problem.
Reply all
Reply to author
Forward
0 new messages