Delivery-date: Mon, 18 Mar 2024 06:24:20 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 66.111.4.26 as permitted sender) client-ip=66.111.4.26;
Feedback-ID: i525146e8:Fastmail
Date: Mon, 18 Mar 2024 13:21:44 +0000
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
Message-ID: <Zfg/6IZyA/iInyMx@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="1dnJ+e/PJ8Ph9IcQ"
Content-Disposition: inline
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--1dnJ+e/PJ8Ph9IcQ
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 hig=
her
fee-rate transaction than a lower fee-rate transaction, even if the absolut=
e
fee paid by the replacement is more.

While RBF Rule #6 was implemented as part of my original Full-RBF opt-in
pull-req=C2=B9, it was mistakenly left out of BIP-125, which was written la=
ter by
Harding. Thus it's often forgotten in analysis of RBF.

Rule #6 creates a path dependency: the order in which replacement transacti=
ons
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 l=
ower
   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 wil=
l
   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 o=
f
   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 requir=
e
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 sl=
ope
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 w=
ith
a larger size difference between A and B. Finally, the attack is more effec=
tive
with a smaller minimum incremental relay fee, as more individual versions o=
f
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 consum=
able
by broadcasting multiple _conflicting_ A's to different nodes at once=C2=B2=
,	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 >=3D 2x, if A starts at 3sat/VB, the attacker can only =
do 2
cycles of the attack as a B >=3D 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 min=
e 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=C2=B3 of RBFR replacements are mined =
already.

Requiring replacements to increase the fee-rate by a certain ratio would al=
so
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 mine=
r to
invalidate a set of large transactions, wasting bandwidth. For example, min=
ers
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 objection=
s to
making it public. All free-relay attacks are mitigated by the requirement t=
o at
least have sufficient funds available to allocate to fees, even if the fund=
s
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

--=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/Zfg/6IZyA/iInyMx%40petertodd.org.

--1dnJ+e/PJ8Ph9IcQ
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmX4P+IACgkQLly11TVR
LzdBtA/+JTP2hLvTBQts1VVjnK/oltbb6SRxuta8t2yU7fFHHE+e8zYqNVO68dU0
7u9n089abE82m6gYWPvrIsYeJxrA9ySgjNAoVhRl4dRnzY6tlqIRLN4eZIsyf21B
p4fTLHjhbJQaUfiGXDC4Ddxb/r710SsHhhwWkWqRynKkTqdq0Vklw6RhC5TQO2zM
55193abaK/nMyIumBj55X9KNC4OnzxcP4Gu2iR/tGMndsmqU+VYKVWnUVU1IYIla
tF9/NQaySisGiRCMgl7KCb83aq4AM/Qf42OhI+sdKjZLWbdTjRRnPhXbHGbaHcaU
mk10mROyU4p7KeZH/3kcN+6Ui8VFcbkB+ik3Lbz/l6wXyh8OT7/oE16QyIE06JHr
WQ/i2KzgXixH7nLwnOpvaMU4SiJBONGX/UgA5aGtpAxZ5MsyZy2jGTw2KiyyRlqJ
0+KHms29HVHnFlSllcq7oq9VIDxWt82NWsI5xyV7SRCPgX7Uj/gIG2mvQ73i5zO3
dRfIrGenjfP/UZ0y3vY/QTKIMp9qoXtD9ngEE9nFXTMfbIP6oxLzCQoefvykzPFW
D1QMFEOGPJqGBNUxVwSC4ZGkPAaIHNTvbml8FcLVmKqjMLad5R+Y+fNHWPaX1QAS
ukj9kWzVDNDm80T648qn/2LD0NDjBWASiWQ6hrOx7rWxk9q1kGw=
=fpkO
-----END PGP SIGNATURE-----

--1dnJ+e/PJ8Ph9IcQ--