From: Peter Todd <pete@petertodd•org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
Date: Mon, 18 Mar 2024 13:21:44 +0000 [thread overview]
Message-ID: <Zfg/6IZyA/iInyMx@petertodd.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 5513 bytes --]
RBF Rule #6 requires that a replacement transaction have a fee-rate higher than
the fee-rate of all conflicting transactions. This rule aligns economic
incentives, as in most circumstances miners earn more money by mining a higher
fee-rate transaction than a lower fee-rate transaction, even if the absolute
fee paid by the replacement is more.
While RBF Rule #6 was implemented as part of my original Full-RBF opt-in
pull-req¹, it was mistakenly left out of BIP-125, which was written later by
Harding. Thus it's often forgotten in analysis of RBF.
Rule #6 creates a path dependency: the order in which replacement transactions
are received determines which transactions are ultimately accepted. This
creates an opportunity for free-relay, as follows:
1. Create two transactions, A and B, where A is a large, low fee-rate, high
absolute fee, transaction, and B is a small, high fee-rate, low absolute fee
transaction.
2. Broadcast A and B to different nodes simultaneously.
3. Nodes that receive A first will not replace A with B, because B pays a lower
fee, violating RBF Rule #3. Notes that receive B first, will not replace B with
A, because A has a lower fee-rate, violating RBF Rule #6.
4. Create A_1, a transaction with the same (large) size as A, but paying a
slightly higher fee (and thus fee-rate). Nodes that received A first will
replace A with A_1, consuming bandwidth. These nodes will also broadcast A_1 to
peers who have B, consuming their bandwidth even though they reject A_1.
5. Repeat until A_n has a fee-rate high enough to have a non-trivial risk of
being mined. Or B is mined, invalidating all A_n.
The marginal cost to an attacker who was planning on broadcasting B anyway is
fairly small, as provided that sufficiently small fee-rates are chosen for A_n,
the probability of A_n being mined is low. The attack does of course require
capital, as the attacker needs to have UTXO's of sufficient size for A_n.
The attack is most effective in cases where fee-rates have a significant slope
to them, with the minimum relay fee being small compared to the competitive fee
to get into the next block. The larger the mempool size limit, the more
effective the attack tends to be. Similarly, the attack is more effective with
a larger size difference between A and B. Finally, the attack is more effective
with a smaller minimum incremental relay fee, as more individual versions of
the transaction can be broadcast for a given fee-delta range.
Of course, this attack can be parallelized, with many non-conflicting A_n
chains at once. Depending on P2P topology, maximum bandwidth may be consumable
by broadcasting multiple _conflicting_ A's to different nodes at once², a
fairly obvious attack that I (and probably others) have already disclosed.
# Mitigations
Replace-by-Fee-Rate mitigates the attack, by limiting the possible range of
fee-rate delta. For example, in Libre Relay, which does replace-by-fee-rate at
a fee-rate ratio of >= 2x, if A starts at 3sat/VB, the attacker can only do 2
cycles of the attack as a B >= 6sat/VB will simply replace A.
The attack itself is arguably an economic exploit: *because* Bitcoin Core
doesn't yet implement replace-by-fee-rate, nodes who accepted A first, are
wasting their bandwidth relaying variations on A that are clearly less
desirable to miners than B. An economically rational miner would just mine B
right now, and the fact that _other_ economically rational miners would mine B
just strengthens the case for mining B now. Indeed, real-world measurements of
replace-by-fee-rate have found that (most likely) due to mempool
inconsistencies, roughly half or more³ of RBFR replacements are mined already.
Requiring replacements to increase the fee-rate by a certain ratio would also
mitigate the attack. However doing so would break a lot of wallet software that
bumps fees by values equal or close to the minimum relay fee.
# Related Attacks
Rule #6 is just one of many ways to achieve the same effect: getting a miner to
invalidate a set of large transactions, wasting bandwidth. For example, miners
who accept payment for guaranteeing that a specific transaction gets mined also
make this kind of attack possible.
# Discussion
Ironically, the existence of this attack is an argument in favor of
replace-by-fee-rate. While RBFR introduces a degree of free-relay, the fact
that Bitcoin Core's existing rules *also* allow for free-relay in this form
makes the difference inconsequential.
# Disclosure
This issue was disclosed to bitcoin-security first. I received no objections to
making it public. All free-relay attacks are mitigated by the requirement to at
least have sufficient funds available to allocate to fees, even if the funds
might not actually be spent.
# References
1) https://github.com/bitcoin/bitcoin/pull/6871
2) https://petertodd.org/2024/one-shot-replace-by-fee-rate#the-status-quo
3) https://petertodd.org/2024/replace-by-fee-rate-success-rate
--
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/Zfg/6IZyA/iInyMx%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2024-03-18 13:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 13:21 Peter Todd [this message]
2024-03-19 12:37 ` Nagaev Boris
2024-03-19 13:46 ` Peter Todd
2024-03-23 0:29 ` Nagaev Boris
2024-03-22 23:18 ` [bitcoindev] " Antoine Riard
2024-03-27 13:04 ` Peter Todd
2024-03-27 19:17 ` Antoine Riard
2024-03-28 14:27 ` Peter Todd
2024-03-28 15:20 ` Peter Todd
2024-03-28 19:13 ` Antoine Riard
2024-03-28 19:47 ` Peter Todd
2024-03-29 20:48 ` Antoine Riard
2024-03-26 18:36 ` [bitcoindev] " David A. Harding
2024-03-27 6:27 ` Antoine Riard
2024-03-27 12:54 ` Peter Todd
2024-03-27 17:18 David A. Harding
2024-03-27 18:04 ` Peter Todd
2024-03-27 19:50 ` David A. Harding
2024-03-27 20:30 ` Peter Todd
2024-03-27 22:05 ` Steve Lee
2024-03-28 18:34 ` Antoine Riard
2024-03-28 19:16 ` 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=Zfg/6IZyA/iInyMx@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