<p>Rule 4 is indeed strictly stronger than rule 3.</p>
<p>It being two rules might be a simple carry-over from BIP125, as it was written from the implementation (and not the other way around). Under this hypothesis it would have been specified as two rules in the BIP is because it's written as two checks in the code. Which makes sense in terms of C++ as you first want to check the replacement's fees are not inferior to the replaced txs' fees to avoid an underflow when then calculating the fee delta. But less so in terms of specification.</p>

CC BY-SA 4.0
2024-07-21T16:44:32.130Z
BIP125 co-author here.  I don't recall all the specifics of writing that document almost 9 years ago, but I can confirm that I went through the checks in the code and turned them into the numbered rules in the document.
David A. Harding
CC BY-SA 4.0
2024-07-11T16:59:47.900Z
2024-07-11T16:59:47.900Z
Antoine Poinsot
<p>The <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md" rel="nofollow noreferrer"><code>mempool-replacements.md</code></a> document states the following rules for RBF:</p>
<blockquote>
<ol start="3">
<li>The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.</li>
</ol>
</blockquote>
<blockquote>
<ol start="4">
<li>The additional fees (difference between absolute fee paid by the replacement transaction and the sum paid by the original transactions) pays for the replacement transaction's bandwidth at or above the rate set by the node's incremental relay feerate. For example, if the incremental relay feerate is 1 satoshi/vB and the replacement transaction is 500 virtual bytes total, then the replacement pays a fee at least 500 satoshis higher than the sum of the original transactions.</li>
</ol>
</blockquote>
<p>Isn't rule #4 strictly stronger than rule #3? I've always seen both stated as independent rules (even in <a href="https://github.com/bitcoin/bitcoin/blob/bd5d1688b4311e21c0e0ff89a3ae02ef7d0543b8/src/policy/rbf.cpp#L160-L185" rel="nofollow noreferrer">code implementations</a>), and this makes me wonder if I'm missing some subtlety here.</p>

<replace-by-fee>
Why does RBF rule #3 exist?
Cosmik Debris
# Why does RBF rule #3 exist?

(Asked by: username_0 on 2024-07-11)

The [`mempool-replacements.md`](https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md) document states the following rules for RBF:

> 3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

> 4. The additional fees (difference between absolute fee paid by the replacement transaction and the sum paid by the original transactions) pays for the replacement transaction's bandwidth at or above the rate set by the node's incremental relay feerate. For example, if the incremental relay feerate is 1 satoshi/vB and the replacement transaction is 500 virtual bytes total, then the replacement pays a fee at least 500 satoshis higher than the sum of the original transactions.

Isn't rule #4 strictly stronger than rule #3? I've always seen both stated as independent rules (even in [code implementations](https://github.com/bitcoin/bitcoin/blob/bd5d1688b4311e21c0e0ff89a3ae02ef7d0543b8/src/policy/rbf.cpp#L160-L185)), and this makes me wonder if I'm missing some subtlety here.

**Tags:** replace-by-fee


---

## 1 answers

### Answer by username_1 on 2024-07-11. Score: 5 | Accepted answer

Rule 4 is indeed strictly stronger than rule 3.

It being two rules might be a simple carry-over from BIP125, as it was written from the implementation (and not the other way around). Under this hypothesis it would have been specified as two rules in the BIP is because it's written as two checks in the code. Which makes sense in terms of C++ as you first want to check the replacement's fees are not inferior to the replaced txs' fees to avoid an underflow when then calculating the fee delta. But less so in terms of specification.

> **Comments:**
> **username_2**: BIP125 co-author here.  I don't recall all the specifics of writing that document almost 9 years ago, but I can confirm that I went through the checks in the code and turned them into the numbered rules in the document.  

---

