<p>First off, note that <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="nofollow noreferrer">BIP125</a> does not prescribe any network (&quot;consensus&quot;) rule. A Bitcoin node may not follow this replacement policy. In fact most nodes on the network are running Bitcoin Core, which implements relay rules close to but different from what is described in BIP125 when it comes to replacement, and allows some of those to be configured (for instance see <code>-mempoolfullrbf</code> regarding BIP125 signalling). Part of the policy implemented by Bitcoin Core by default is described <a href="https://github.com/bitcoin/bitcoin/tree/master/doc/policy" rel="nofollow noreferrer">here</a>.</p>
<p>If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is <em>much</em> less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing <em>[0]</em>) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment.</p>
<p>From the perspective of the recipient of a payment, CPFP is the only alternative that doesn't require coordination with the sender.</p>
<p>Your second point seems to assume RBF requires a change in the protocol. It doesn't, it works today. If anything it is going to be made easier to use in the future (through various protocol improvements, and the push for having nodes allow to also replace transactions that didn't explicitly signal for BIP125 beforehand).</p>
<p><em>[0]</em>: <a href="https://bitcoinops.org/en/topics/package-relay/" rel="nofollow noreferrer">package relay</a> would fix this.</p>
<hr />
<p>Related questions and answers:</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/116347/101498">What are the arguments in the <code>mempoolfullrbf</code> debate?</a></li>
<li><a href="https://bitcoin.stackexchange.com/a/114309/101498">What are packages in bitcoin core and what is their use case?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/106708/101498">A question about CPFP relaying policy</a></li>
</ul>

CC BY-SA 4.0
2023-03-26T21:03:34.260Z
2023-03-26T21:08:36.340Z
2023-03-26T21:08:36.340Z
Antoine Poinsot
<p>As far as I understood so far, CPFP and BIP125 are both designed to help spenders to make new transactions using an input of an unconfirmed transaction by paying the cost. The most well known use case of them are when the spender wants his/her transaction confirm faster by raising the transaction fee.
In BIP125 the node accept the new conflicting transaction if the newer one pays enough fee. But  in CPFP method, the spender should construct a new transaction spending an output of the low-fee (parent) transaction, to encourage miners to include both transactions in the block they're mining.</p>
<p>Can someone explain the most important differences between these two approaches? Mentioning pros and cons of each one and which one is now more acceptable in the community.</p>
<p>The differences I can see:</p>
<ul>
<li>I believe BIP125 is easier to implement rather than CPFP. Because calculating overall fee of a chain of transactions, we should see them as packages and I think implementing packages have some challenges.</li>
<li>On the other hand CPFP is not introducing any new rule or alteration in the protocol. I think it doesn't need any change in the protocol, but BIP125 is changing the way nodes are interpreting transactions.</li>
<li>Using BIP125 is more space saving, because it doesn't include 2 transactions (or more), it will throw the older transaction away and replace the new one. But in the CPFP both transactions are consequently included in the blockchain.</li>
</ul>
<p>I appreciate any idea of how these two approaches differentiate each other.</p>

<replace-by-fee><child-pays-for-parent><bip-125-replaceable><bumpfee>
Comparison between CPFP and BIP125 for fee bumping
Amir reza Riahi
# Comparison between CPFP and BIP125 for fee bumping

(Asked by: username_0 on 2023-03-26)

As far as I understood so far, CPFP and BIP125 are both designed to help spenders to make new transactions using an input of an unconfirmed transaction by paying the cost. The most well known use case of them are when the spender wants his/her transaction confirm faster by raising the transaction fee.
In BIP125 the node accept the new conflicting transaction if the newer one pays enough fee. But in CPFP method, the spender should construct a new transaction spending an output of the low-fee (parent) transaction, to encourage miners to include both transactions in the block they're mining.

Can someone explain the most important differences between these two approaches? Mentioning pros and cons of each one and which one is now more acceptable in the community.

The differences I can see:

* I believe BIP125 is easier to implement rather than CPFP. Because calculating overall fee of a chain of transactions, we should see them as packages and I think implementing packages have some challenges.
* On the other hand CPFP is not introducing any new rule or alteration in the protocol. I think it doesn't need any change in the protocol, but BIP125 is changing the way nodes are interpreting transactions.
* Using BIP125 is more space saving, because it doesn't include 2 transactions (or more), it will throw the older transaction away and replace the new one. But in the CPFP both transactions are consequently included in the blockchain.

I appreciate any idea of how these two approaches differentiate each other.

**Tags:** replace-by-fee, child-pays-for-parent, bip-125-replaceable, bumpfee


---

## 1 answers

### Answer by username_1 on 2023-03-26. Score: 4 | Accepted answer

First off, note that [BIP125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) does not prescribe any network ("consensus") rule. A Bitcoin node may not follow this replacement policy. In fact most nodes on the network are running Bitcoin Core, which implements relay rules close to but different from what is described in BIP125 when it comes to replacement, and allows some of those to be configured (for instance see `-mempoolfullrbf` regarding BIP125 signalling). Part of the policy implemented by Bitcoin Core by default is described [here](https://github.com/bitcoin/bitcoin/tree/master/doc/policy).

If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is *much* less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing *[0]*) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment.

From the perspective of the recipient of a payment, CPFP is the only alternative that doesn't require coordination with the sender.

Your second point seems to assume RBF requires a change in the protocol. It doesn't, it works today. If anything it is going to be made easier to use in the future (through various protocol improvements, and the push for having nodes allow to also replace transactions that didn't explicitly signal for BIP125 beforehand).

*[0]*: [package relay](https://bitcoinops.org/en/topics/package-relay/) would fix this.

---

Related questions and answers:

* [What are the arguments in the `mempoolfullrbf` debate?](https://bitcoin.stackexchange.com/q/116347/101498)
* [What are packages in bitcoin core and what is their use case?](https://bitcoin.stackexchange.com/a/114309/101498)
* [A question about CPFP relaying policy](https://bitcoin.stackexchange.com/q/106708/101498)


---

