From: Peter Todd <pete@petertodd•org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] Libre Relay v27.1 released with lower 1.25x replacement threshold
Date: Thu, 20 Jun 2024 16:33:47 +0000 [thread overview]
Message-ID: <ZnRZ6zhON4oT5Sg9@petertodd.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]
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
--
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/ZnRZ6zhON4oT5Sg9%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2024-06-20 16:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 16:33 Peter Todd [this message]
2024-06-20 22:33 ` Peter Todd
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=ZnRZ6zhON4oT5Sg9@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