2

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.

Improve this question

1 Answer 1

Reset to default
3

First off, note that BIP125 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.

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 would fix this.

Related questions and answers:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.