From: Peter Todd <pete@petertodd•org>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Libre Relay v27.1 released with lower 1.25x replacement threshold
Date: Thu, 20 Jun 2024 22:33:46 +0000 [thread overview]
Message-ID: <ZnSuSh1FBGSYlPFE@petertodd.org> (raw)
In-Reply-To: <ZnRZ6zhON4oT5Sg9@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3580 bytes --]
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,
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZnSuSh1FBGSYlPFE%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-06-20 22:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 16:33 Peter Todd
2024-06-20 22:33 ` Peter Todd [this message]
2024-06-22 14:29 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZnSuSh1FBGSYlPFE@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox