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.