RBF vs CPFP: Which Is More Effective for Stuck Transactions?

[L E G E N D A R Y]

So it’s quite normal for people to experience stuck transactions, especially during congestion periods or when you mistakenly or intentionally used a very small fee for the transaction. what do you really do when you find yourself in such situation? do you just wait it out or wish there was actually something you could do but just don’t know what or how and you’re left with no other option than to wait it out. Well there are actually two ways you could facilitate the transaction. Maybe a lot of people already knows it, but I bet there are still some who don’t, so for the benefit of those who don’t.

 1. Replace by Fee (RBF) and  
 2. Child Pays For Parents (CPFP)

Instead of just relying on explanations alone, I had to run some kind of test on both methods so as to know their effectiveness.

EXPERIMENT SETUP

I created two transactions with intentionally underpriced fees
Both remained unconfirmed for a while

Then I applied
  RBF on Transaction A and
  CPFP on Transaction B

The goal of this was to compare confirmation speed and total cost

MY OBSERVATION

 1. Replace By Fee (RBF)

-What this did was to replace the original transaction with a much higher fee
-The new transaction was picked up quickly
-And it got confirmed in the next block

 2. Child Pays For Parent (CPFP)

-I created another transaction spending the stuck output
-And then added a high fee mainly to incentivise miners
-Both parent and child were confirmed together

DIFFERENCE BETWEEN THE BOTH

RBF is a lot more easier to use, cos all you gotta do is just to increase the fee and rebroadcast
CPFP is more flexible, plus you can use even if the original transaction doesn’t support RBF
RBF depends on wallet support
CPFP requires control of the receiving output

FEE COMPARISON

-RBF was only used to pay for the replacement transaction (Which makes  slightly cheaper overall)
-CPFP on the other hand pay a higher combined fee (parent and child)


IMPORTANT INSIGHT

 1. If you are the sender or controlling the sender wallet, then the RBF is ideal for you
 2. But if you’re on the receiving end of the transaction, or if the transaction never the RBF options enabled, then you sure might wanna consider using the CPFP.

CONCLUSION
So in conclusion, both RBF and the CPFP works best but in different situations. RBF is a lot more faster and possibly the best option (if/when available) due to how cost efficient it is. While CPFP can be used as a reliable alternative in a situation whereby the RBF isn’t enabled on your transaction. And really understanding these both method gives you complete control as regards to stuck transaction.

[Charles-Tim]

Are there still recommendable bitcoin wallets that is open source that does not support replace-by-fee? It is highly advisable not to use a wallet that does not support it?

These are bitcoin open source wallets that support replace-by-fee: Bitcoin open source wallets that support replace-by-fee (RBF)

2. But if you’re on the receiving end of the transaction, or if the transaction never the RBF options enabled, then you sure might wanna consider using the CPFP.

You can be the sender and still be able to use child-pay-for-parent if you did not spend all the coins in the unconfirmed transaction, but having it as change in the unconfirmed transaction.

[L E G E N D A R Y]

Are there still recommendable bitcoin wallets that is open source that does not support replace-by-fee? It is highly advisable not to use a wallet that does not support it?

These are bitcoin open source wallets that support replace-by-fee: Bitcoin open source wallets that support replace-by-fee (RBF)

Sure there are. at least I know there are people who still uses Trust wallet, Mycelium wallet, Phoenix wallet and so on, and these wallets doesn't have any RBF features enabled in them. it's not as if the wallets completely unsafe, some of them are pretty good though, but they basically just wanna make users wait out the long period or push them into seeing the CPFP as the only recovery option, or maybe they just wanna limit user's control over transaction management. So yeah, users should put these things into adequate consideration before choosing a wallet.

[Livingleged]

Sure there are. at least I know there are people who still uses Trust wallet, Mycelium wallet, Phoenix wallet and so on, and these wallets doesn't have any RBF features enabled in them.

I think you’re missing it  though your point are valid @charles-Tim was asking about open source wallet that doesn’t support or have the replace-by-fee. trust wallet you mentioned isn’t an open source. Maybe you should check again.

[Charles-Tim]

Sure there are. at least I know there are people who still uses Trust wallet, Mycelium wallet, Phoenix wallet and so on, and these wallets doesn't have any RBF features enabled in them.

I think you’re missing it  though your point are valid @charles-Tim was asking about open source wallet that doesn’t support or have the replace-by-fee. trust wallet you mentioned isn’t an open source. Maybe you should check again.

Although,  L E G E N D A R Y added good wallets, with bad one like Trustwallet. Example is the Mycelium wallet that is open source, but not having replace-by-fee. I have stopped using the wallet since a long time ago, and many people are finding bug of incorrect balance on the wallet. The most valid one is the Phoenix wallet which is also open source, but has special purpose which is lightning network.

[Sammysmart001]

Great point OP. This your breakdown gives a clear difference in between RBF and CPFP.

What Most of us get wrong about RBF is that it only works when the sender enables it at the first broadcast, if in any way the transactions aren’t flagged with RBF you find out that you can’t be able to use it later, it from here CPFP come in to be the only option, mostly for the receivers.

@Charles-Tim you actually rise a good point about the wallet support, his at point with the open source wallet without RBF that are the limiting user control.

And again about this Mycelium being a open source but not RBF it keeps me surprising.
But have come to ask if this child transactions in this CPFP come to have a low fee than that of the parent. Are miners going to still move on with the prioritize of this package as whole ?

You really did well with the test results. This shows why fee management is very important in Bitcoin usage as whole.

[Charles-Tim]

And again about this Mycelium being a open source but not RBF it keeps me surprising.
But have come to ask if this child transactions in this CPFP come to have a low fee than that of the parent. Are miners going to still move on with

If the child transaction pay less than the parent transaction, that is just a normal transaction and not child-pay-for-parent transaction. The parent transaction (which is not actually a parent transaction because of the lower transaction fee) will get confirmed on its own, while the child transaction will also get confirmed on its own when the mempool is less congested and be able to get a miner include the transaction into a block.

[Sammysmart001]

If the child transaction pay less than the parent transaction, that is just a normal transaction and not child-pay-for-parent transaction. The parent transaction (which is not actually a parent transaction because of the lower transaction fee) will get confirmed on its own, while the child transaction will also get confirmed on its own when the mempool is less congested and be able to get a miner include the transaction into a block.

Okey now I get it, thanks for the breakdown

So now for this CPFP to work out, the child fee has to be higher enough in order to bring for both, an average fee transaction rate for a current transaction pool level . So now if child fee comes out being lower this shows that the two are independent transactions. Noted !!!

[Zaguru12]

CONCLUSION
So in conclusion, both RBF and the CPFP works best but in different situations. RBF is a lot more faster and possibly the best option (if/when available) due to how cost efficient it is. While CPFP can be used as a reliable alternative in a situation whereby the RBF isn’t enabled on your transaction. And really understanding these both method gives you complete control as regards to stuck transaction.

@charlse-Tim has actually made some necessary corrections here, but let me add somethings like, there is nothing like the RBF is actually faster than the CPFP transaction it all depends on the fee you’re paying because miners actually prioritize transactions based on fees, if you actually pay enough for CPFP transaction the transaction will be picked in the next block, in fact it’s possible to have both parent transaction and child transaction in same block.

Then for non-RBF transactions now, for example you send a transaction using trust wallet and which doesn’t have RBF opt-in we now have most nodes actually having full RBF enabled this allows even transactions that are non-RBF to be replaceable, you can easily do that by actually connecting to node or server which enables this. For example just copy your private key and import it into electrum wallet and then start rebroadcasting that transaction, if there is error then the node is not having Full RBF enabled, so you just Manually switch servers until it broadcasts.

To be clear this is not turning that non-RBF transaction to RBF opt-in as a transaction cannot be changed from each of those commands to another.

And again about this Mycelium being a open source but not RBF it keeps me surprising.
But have come to ask if this child transactions in this CPFP come to have a low fee than that of the parent. Are miners going to still move on with the prioritize of this package as whole ?

Some wallet usually suggest fees that will make the both parent and child transaction confirms faster if you’re actually doing a CPFP because that’s when the nodes will actually pick the new transaction faster as they will treat at higher priority. But if the fee is small which is usually unlikely then each transaction will confirm base on how the nodes treat the fee as priority

[Sammysmart001]

@Zaguru I love this extra break down
Just a confirmation
So what it stands now is that RBF it speed advantage is not actually automatic. It about it fee rate

So about Full RBF, this show that even if in any way transactions aren’t flagged before. If you connect to a Full RBF this will enable node through Electrum for replacement? This really a good turnaround for us trust wallet users oh.

Didn’t actually know about this Full RBF node. This really a great turn out mostly for people who are stuck with the non RBF wallet. Great information sir

[Mia Chloe]

~snip

Good talk but next time please save us the stress and just use paragraphs don't really fancy long talks and still adding a conclusion with the title "conclusion". Well concerning the RBF and CPFP they have their use cases for just regular send and receive RBF is actually the best option.

CPFP usually comes in when there are multiple low fee transactions and because of their UTXO connection you can make the child pay a bigger fee that will force miners to confirm the parent and the child simultaneously.

[DubemIfedigbo001]

I had a funny case recently when I made a TX with three inputs to a single address, initially when I was adjusting the feeling manually in electrum, there was a warning that I should set acceptable fees, because I wouldn't be able to bump the fee afterwards, I was surprised at the warning, but proceeded to adjusted the feeling to 1.5 sat/vB which was even below the medium priority as at yesterday afternoon. Then after I broadcasted the tx, I went back to verify the RBF and saw that I could bump the fee, so I was surprised why Electrum would issues the warning in the first place.

Anyone noticed that before and why do they issues such warnings, despite knowing RBF is still possible?

[CryptoHeadlineNews]

CONCLUSION
So in conclusion, both RBF and the CPFP works best but in different situations. RBF is a lot more faster and possibly the best option (if/when available) due to how cost efficient it is. While CPFP can be used as a reliable alternative in a situation whereby the RBF isn’t enabled on your transaction. And really understanding these both method gives you complete control as regards to stuck transaction.

I have been in many scenarios where I have to bump my transaction fees before it could be rebroadcasted and possibly confirmed at due time when the Bitcoin network is congested, and the "Replace by Fee (RBF)" has always been the method I use in accomplishing this. And I'm happy you came up with a topic like this as a medium to educate newbies and those forum users who might not have known what to do in a situation like this when they get stuck with an unconfirmed transaction that is yet to be broadcast due to low fees. However, this is just another theory, and I expected it to have been more practical just the way you claimed you did. Because I expected you to have provided the transaction hash of the 2 transactions you made, you tell us the initial amount of Bitcoin that was sent, including the exact number of Satoshis that was used to bump and rebroadcast the transaction again. But you didn't provide anything. 

So I will be glad if you can give us the full practical break down of what you did. Thanks

[Zaguru12]

I had a funny case recently when I made a TX with three inputs to a single address, initially when I was adjusting the feeling manually in electrum, there was a warning that I should set acceptable fees, because I wouldn't be able to bump the fee afterwards, I was surprised at the warning, but proceeded to adjusted the feeling to 1.5 sat/vB which was even below the medium priority as at yesterday afternoon. Then after I broadcasted the tx, I went back to verify the RBF and saw that I could bump the fee, so I was surprised why Electrum would issues the warning in the first place.

Anyone noticed that before and why do they issues such warnings, despite knowing RBF is still possible?

In the past it was actually due to RBF been disabled but from version 4.4.0 and later RBF opt-in is automatically enabled in electrum.

The reason why you saw that was warning was because in that transaction you were sending out everything on that wallet that is there no change left nor there is no other coin to spend from since if you’re coming back for RBF you will simply be adding more to your fees to bump the transaction. So it’s simply warning base on this.

But don’t worry even there is no change or coin remaining you can still bump the fee but this will mean you have to reduce the amount you’re sending to the recipient and add to the fees, this done by changing from Preserve payment into Decrease payment when you use the increase fee option in the wallet