Can unconfirmed transactions be automatically cancelled by RBF

[Oshosondy]

I was thinking about unconfirmed transaction and RBF today, this came to my mind after reading a post about it on this forum, I just want to be sure of what will happen.

Assuming I sent bitcoin to a friend that is using electrum wallet, the bitcoin transaction was not yet confirmed and it is taken too long, he decided to create CPFP and use it to send the bitcoin to another address on his electrum wallet. But my friend also mistakenly use low fee too, which makes the child transaction also to be stuck.

If I use RBF during this time for the original transaction, that means the unconfirmed CPFP will be invalidated?
Or I will not be able to create RBF because the transaction already has child transaction?

[hosseinimr93]

If I use RBF during this time for the original transaction, that means the unconfirmed CPFP will be invalidated?

When you bump the fee, you actually replace the transaction with a new one. Since the new transaction has a new hash, all children of the original transaction become invalid.

Or I will not be able to create RBF because the transaction already has child transaction?

Any RBF-enabled transaction can be replaced by a new one if the second transaction pays a higher fee and it spends at least one of inputs of the original transaction.
This can be done even if the original transaction has several children.

[o_e_l_e_o]

hosseinimr93 is right, but one additional clarification:

This can be done even if the original transaction has several children.

Any RBF transaction you broadcast must pay both a higher fee rate and a higher absolute fee than not just the transaction it is replacing, but of all the transactions which would be evicted from the mempool if it were to be accepted. So if an unconfirmed transaction has several unconfirmed children, then you would need to add together the total fee paid by all of them and set your RBF transaction to have a higher fee than that, and not just a higher fee than the parent transaction you are replacing.

[DaveF]

Any RBF transaction you broadcast must pay both a higher fee rate and a higher absolute fee than not just the transaction it is replacing, but of all the transactions which would be evicted from the mempool if it were to be accepted. So if an unconfirmed transaction has several unconfirmed children, then you would need to add together the total fee paid by all of them and set your RBF transaction to have a higher fee than that, and not just a higher fee than the parent transaction you are replacing.

I thought it was just the fee for the inputs that came from the parent transaction. You are saying that it is the fee for the entire child transaction.
Learn something new everyday.
Kind of handy if someone sends you a RBF transaction with a low fee, you can 'lock' it by adding a bunch of dust inputs if you have them and also sending with a low fee so they can't just RBF it without paying to move your dust.

-Dave

[o_e_l_e_o]

You are saying that it is the fee for the entire child transaction.

Correct. It is the combined fee for everything you are ejecting from the mempool, which includes both the parent transaction you are directly replacing and any and all child transactions which stem from that parent transaction.

You can see this in the text of BIP125 (emphasis added):

One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,
...
3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

Kind of handy if someone sends you a RBF transaction with a low fee, you can 'lock' it by adding a bunch of dust inputs if you have them and also sending with a low fee so they can't just RBF it without paying to move your dust.

Also correct. This is known as transaction pinning. See the first bullet point here for the exact scenario you have described: https://bitcoinops.org/en/topics/transaction-pinning/

[nc50lc]

-snip-
If I use RBF during this time for the original transaction, that means the unconfirmed CPFP will be invalidated?
Or I will not be able to create RBF because the transaction already has child transaction?

The previous posts are true based from the RBF rules,
but take note that there are clients that will not let your perform RBF if the transaction has a child.

One big example is Bitcoin Core GUI (bitcoin-qt), once your transaction has an unconfirmed child in your mempool, it wont let you select "increase fee" option.
bumpfee wont also work, but it's still possible to manually create a replacement transaction using commands.

[DannyHamilton]

The previous posts are true based from the RBF rules,
but take note that there are clients that will not let you perform RBF . . .

Also important to bee aware that these are the rules that are implemented in those nodes and miners that happen to be honoring them.  However, there is nothing in the consensus rules that prevents a miner from creating a block with the original transaction and confirming it even if you've broadcast a replacement.  Miners are generally interested in increasing their revenue, and so will typically be more interested in confirming the replacement transaction to increase their revenue, but the possibility still exists that the original transaction could confirm regardless of how big you make the fee on the replacement transaction.

RBF does NOT provide a tool to guarantee cancelation of a previously broadcast transaction, it just provides a method to encourage the mining pools to consider your replacement transaction as an opportunity to increase their profits.

[khaled0111]

It's also important to note that if the original transaction has more than 99 child transactions, it can't be replaced no matter how much fee the replacement transaction pays.

Correct. It is the combined fee for everything you are ejecting from the mempool, which includes both the parent transaction you are directly replacing and any and all child transactions which stem from that parent transaction.

You can see this in the text of BIP125 (emphasis added):

One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,
...
3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

Are you sure the fees paid by child transactions have to be included too? Because, the way I interpreted it, by "original transactions" I believe they mean only the transactions which ,at least, one of their inputs is going to be consumed by the replacement transaction! (=> a replacement transaction can cancel/replace multiple transactions by consuming inputs from each one of them).

[ranochigo]

It's also important to note that if the original transaction has more than 99 child transactions, it can't be replaced no matter how much fee the replacement transaction pays.

Actually, since Bitcoin Core limit the number of ancestor transactions in an unconfirmed chain to 25, the 99 child transaction is quite redundant. You wouldn't be able to do RBF with anything longer than that as the transactions simply wouldn't have even been relayed.

I think the BIP is a bit outdated and the limit was changed after the BIP was drafted.

[khaled0111]

Thank you @ranochigo for the information. So, this rule overrides the RBF third rule mentioned in bip125
This means you can't make CPFP if the parent transaction has more than 25 ancestor, right!

Regarding my question to @o_e_l_e_o, I did a quick research about "transaction pinning" and find out he was right:

BIP125 RBF rule #3 requires a replacement transaction pay a higher absolute fee (not just feerate) than the transaction being replaced and any of its children.

[o_e_l_e_o]

Actually, since Bitcoin Core limit the number of ancestor transactions in an unconfirmed chain to 25, the 99 child transaction is quite redundant.

Not necessarily.

The rule states the total number of transactions evicted from the mempool must not exceed 100 transactions. That does not mean all 100 have to be a single parent to child chain, such as A -> B -> C -> D -> etc. I could create a parent transaction with 2 outputs, create two new unconfirmed transactions - one from each of those outputs - with a further 2 outputs each, create four new unconfirmed transactions from each of those outputs, and so on. I could even just create a single parent transaction with 100 outputs, and then spend each of those outputs. The ancestor count will be well under 25 for all the children, while an RBF on the parent would still have to evict >100 transactions.

[ranochigo]

Not necessarily.

The rule states the total number of transactions evicted from the mempool must not exceed 100 transactions. That does not mean all 100 have to be a single parent to child chain, such as A -> B -> C -> D -> etc. I could create a parent transaction with 2 outputs, create two new unconfirmed transactions - one from each of those outputs - with a further 2 outputs each, create four new unconfirmed transactions from each of those outputs, and so on. I could even just create a single parent transaction with 100 outputs, and then spend each of those outputs. The ancestor count will be well under 25 for all the children, while an RBF on the parent would still have to evict >100 transactions.

Thanks.. I misinterpreted the BIP and thought it was referring to a single transaction chain.