<ol>
<li><p><a href="https://en.bitcoin.it/wiki/Transaction_replacement" rel="nofollow noreferrer">Here</a> you can find a list of all transaction replacement types (no mention of CPFP).</p>
</li>
<li><p>Bitcoin Core today only supports Full RBF and Opt-in RBF. Bitcoin Core also supports CPFP (but that is not a transaction replacement policy).</p>
</li>
</ol>
<p><a href="https://i.sstatic.net/dQb76.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/dQb76.png" alt="enter image description here" /></a></p>
<ol start="3">
<li>By default, Bitcoin Core uses Opt-in RBF.</li>
</ol>

CC BY-SA 4.0
2023-12-04T12:39:13.763Z
CPFP is not a transaction replacement policy (no replacement is involved). It's a quality the mining algorithm has to prioritize parent transactions when the child pays a higher fee. It can be used as an alternative to replacement in dealing with transactions whose fee is too low, but through a completely different mechanism.
Pieter Wuille
CC BY-SA 4.0
2023-12-04T12:40:58.653Z
In your table, what is "Satoshi RBF"?
Pieter Wuille
CC BY-SA 4.0
2023-12-04T12:48:36.613Z
@PieterWuille I took the image/table from [here](https://en.bitcoin.it/wiki/Transaction_replacement).
LeaBit
CC BY-SA 4.0
2023-12-04T12:51:31.173Z
@PieterWuille Are there any additional replacement techniques other than those in the table?
LeaBit
CC BY-SA 4.0
2023-12-04T12:52:19.670Z
None that I know of, no.
Pieter Wuille
CC BY-SA 4.0
2023-12-04T12:57:10.547Z
@PieterWuille Just a question related to CPFP and what you wrote, does bitcoin full node (core) have anything to do with CPFP or that's miner "policy" since he is the one who chooses the transactions for the block, so he will choose the parent transactions whose child transactions pay huge fee?
LeaBit
CC BY-SA 4.0
2023-12-04T13:05:14.953Z
Miners need to get their block template from somewhere, and typically that comes from Bitcoin Core directly or indirectly. The block building feature in Bitcoin Core supports CPFP since version 0.13.0.
Pieter Wuille
CC BY-SA 4.0
2023-12-04T11:46:59.837Z
2023-12-06T02:47:07.983Z
2023-12-06T02:47:07.983Z
LeaBit
<p>The original software release included a mechanism that allowed transactions with a higher sequence on inputs to supersede transactions with a lower sequence. This mechanism was not incentive-compatible and got removed.</p>
<p><em>First-Seen-Safe RBF</em> was a proposal that would only permit a replacement when the replacement transaction replicated all outputs from the original transaction. This would have meant that almost every new replacement transactions would add another change output (whereas only one of the original inputs had to remain, so one or more of the others could have just been swapped out for UTXOs with larger amounts). The protection FSS RBF offered to unconfirmed transactions was also generally considered unreliable. For these reasons and others, the proposal was not popular and the network instead adopted <em>Opt-in Full RBF</em>.</p>
<p>The &quot;opt-in&quot; requires the original transaction to signal <em>replaceability</em>, by having at least one input with a sequence field lower than <code>MAX-1</code>.
&quot;Full RBF&quot; in this context meant that a replacement was permitted to completely supersede the original transaction without preserving any of the payments that the original transaction had announced. The replacement transaction would still need to pay a higher absolute fee as well as a higher feerate.</p>
<p>Full nodes operating under these mempool policies would not permit replacement of transactions that had signaled <em>finality</em>, much like for every transaction before Opt-in Full RBF got adopted.</p>
<p>More recently, Bitcoin Core got a configuration option that allows node operators to permit &quot;Full RBF&quot; replacements per the same rules, without requiring the original transaction to have signaled replaceability.</p>
<p>CPFP is another mechanism to reprioritize a pending payment, but CPFP is not a replacement mechanism. CPFP works by adding a higher feerate transaction as a dependent to an existing transaction. Miners are incentivized to include both the parent and the child in order to collect the attractive fee on the child transaction.</p>

CC BY-SA 4.0
2023-12-04T20:19:23.070Z
Thanks for this comprehensive answer. I have one question related to what you wrote for FSS-RBF. By writing this: "`This would have meant that replacement transactions would have often ended up with two change outputs.`" you meant that since we can't change outputs (we can't just decrease change output value - output that return sats back to us - in order to increase fee) we need to add one additional input and change output, and by that way to increase fee. **The result is that we have at least 2 change outputs (and maybe more if we do FSS-RBF again)** Did I understand you correctly?
LeaBit
CC BY-SA 4.0
2023-12-04T20:30:15.097Z
Yes, you would generally need to add another change output with each replacement, unless your input set for the replacement happens to not need change, but you could keep just one input stable across all replacements and swap out other ones with larger UTXO amounts.
Murch
CC BY-SA 4.0
2023-12-04T20:49:29.843Z
Hmm. So you meant the following. Original transaction: inputs(10 bc, 5bc) - outputs(13bc, 1bc). Second output is change and fee is 1bc. If 1bc is not enough (2bc is), we can make the replacement transaction as follow (**11bc**, 5bc) - outputs(13bc, 1bc). In this case, we just changed one input and outputs stayed as they were (no additional change outputs). However, it is much more realistic for the replacement transaction to look like this: inputs(**14bc**, 5bc) - outputs(13bc, 1bc, **3bc**) or inputs(**12bc**, **3**, 5bc) - outputs(13bc, 1bc, **4bc**).
LeaBit
CC BY-SA 4.0
2023-12-04T20:49:45.183Z
Therefore, the real scenario is actually that the number of inputs stays the same or increases, and we have one additional change output.
LeaBit
CC BY-SA 4.0
2023-12-04T22:05:36.977Z
No, only a single input is necessary to create a conflict with the preceding transactions, therefore the number of inputs can vary freely, but generally would be greater than one after the original, although their total amount must go up with each replacement. So, you might have an input that is present on the original and all subsequent versions of the transaction, but the remainder could for example be two inputs summing to 1 BTC (and two change outputs), then five inputs summing to 2 BTC (and three change outputs), finally a single input worth 3 BTC (and four change outputs).
Murch
CC BY-SA 4.0
2023-12-04T23:06:32.330Z
Yes, thank you. That's exactly what I meant. I just can't agree with this: `...although their total amount must go up with each replacement.`. We can leave all the inputs as they are and just decrease the value of the change output. In this case the total amount in transaction remains the same, but we still increased the fee and the replacement is valid. I hope you agree?
LeaBit
CC BY-SA 4.0
2023-12-04T23:14:42.180Z
No, since you have to replicate all outputs of the previous version of the transaction, the sum of the amounts of the inputs has to strictly go up in order for you to be able to pay more fees.
Murch
CC BY-SA 4.0
2023-12-04T23:28:14.063Z
Yes, you are absolutely right. My fault.
LeaBit
CC BY-SA 4.0
2023-12-04T16:22:33.937Z
2023-12-06T02:48:07.890Z
2023-12-06T02:48:07.890Z
Murch
<p>As far as I know Bitcoin Core knows two types of RBF. These are Full RBF and Opt-in Full RBF. In both cases, the transaction will be replaced if a new one arrives that consumes at least one of the same inputs, is valid and has a higher fee. The only difference is that with Full RBF this applies to every transaction, while with Opt-in Full RBF transactions must signal it (some <code>nSequence</code> smaller than <code>0xffffffff-1</code>).</p>
<ol>
<li>What other types of replacement exist, either &quot;replace by fee&quot; or some other? (I just need the list, I'll research what they are myself)</li>
</ol>
<p><a href="https://bitcoin.stackexchange.com/questions/38320/can-someone-outline-the-full-pros-cons-of-the-various-replace-by-fee-proposals">Here</a> they mention <em>Child-Pays-For-Parent</em> (CPFP), <em>Replace-By-Fee</em> (RBF; <strong>I assume this means both Full RBF/Opt-in RBF; correct me if I'm wrong</strong>) and <em>First-Seen-Safe Replace-By-Fee</em> (FSS RBF). It doesn't mention <em>Opt-in Full RBF</em> but I assume that's what's considered under RBF since it's actually Full RBF where the transaction has to signal replacement, correct me if I'm wrong. <strong>By the way, the answer is from 2015, so I'm interested in whether there are more types of replacement in Bitcoin.</strong></p>
<ol start="2">
<li><p>Does Bitcoin Core support CPFP and FSS RBF, as well as all the types you listed in the answer to question 1?</p>
</li>
<li><p>What type of replacement does Bitcoin Core use by default? I know that it was an Opt-in Full RBF and that there were some indications to switch on Full RBF.</p>
</li>
</ol>
<p>Thanks to all!</p>

<bitcoin-core><replace-by-fee><child-pays-for-parent>
What types of RBF exist and which one does Bitcoin Core support and use by default?
LeaBit
# What types of RBF exist and which one does Bitcoin Core support and use by default?

(Asked by: username_0 on 2023-12-04)

As far as I know Bitcoin Core knows two types of RBF. These are Full RBF and Opt-in Full RBF. In both cases, the transaction will be replaced if a new one arrives that consumes at least one of the same inputs, is valid and has a higher fee. The only difference is that with Full RBF this applies to every transaction, while with Opt-in Full RBF transactions must signal it (some `nSequence` smaller than `0xffffffff-1`).

1. What other types of replacement exist, either "replace by fee" or some other? (I just need the list, I'll research what they are myself)

[Here](https://bitcoin.stackexchange.com/questions/38320/can-someone-outline-the-full-pros-cons-of-the-various-replace-by-fee-proposals) they mention *Child-Pays-For-Parent* (CPFP), *Replace-By-Fee* (RBF; **I assume this means both Full RBF/Opt-in RBF; correct me if I'm wrong**) and *First-Seen-Safe Replace-By-Fee* (FSS RBF). It doesn't mention *Opt-in Full RBF* but I assume that's what's considered under RBF since it's actually Full RBF where the transaction has to signal replacement, correct me if I'm wrong. **By the way, the answer is from 2015, so I'm interested in whether there are more types of replacement in Bitcoin.**

2. Does Bitcoin Core support CPFP and FSS RBF, as well as all the types you listed in the answer to question 1?
3. What type of replacement does Bitcoin Core use by default? I know that it was an Opt-in Full RBF and that there were some indications to switch on Full RBF.

Thanks to all!

**Tags:** bitcoin-core, replace-by-fee, child-pays-for-parent


---

## 2 answers

### Answer by username_2 on 2023-12-04. Score: 5 | Accepted answer

The original software release included a mechanism that allowed transactions with a higher sequence on inputs to supersede transactions with a lower sequence. This mechanism was not incentive-compatible and got removed.

*First-Seen-Safe RBF* was a proposal that would only permit a replacement when the replacement transaction replicated all outputs from the original transaction. This would have meant that almost every new replacement transactions would add another change output (whereas only one of the original inputs had to remain, so one or more of the others could have just been swapped out for UTXOs with larger amounts). The protection FSS RBF offered to unconfirmed transactions was also generally considered unreliable. For these reasons and others, the proposal was not popular and the network instead adopted *Opt-in Full RBF*.

The "opt-in" requires the original transaction to signal *replaceability*, by having at least one input with a sequence field lower than `MAX-1`.
"Full RBF" in this context meant that a replacement was permitted to completely supersede the original transaction without preserving any of the payments that the original transaction had announced. The replacement transaction would still need to pay a higher absolute fee as well as a higher feerate.

Full nodes operating under these mempool policies would not permit replacement of transactions that had signaled *finality*, much like for every transaction before Opt-in Full RBF got adopted.

More recently, Bitcoin Core got a configuration option that allows node operators to permit "Full RBF" replacements per the same rules, without requiring the original transaction to have signaled replaceability.

CPFP is another mechanism to reprioritize a pending payment, but CPFP is not a replacement mechanism. CPFP works by adding a higher feerate transaction as a dependent to an existing transaction. Miners are incentivized to include both the parent and the child in order to collect the attractive fee on the child transaction.

> **Comments:**
> **username_0**: Thanks for this comprehensive answer. I have one question related to what you wrote for FSS-RBF. By writing this: "`This would have meant that replacement transactions would have often ended up with two change outputs.`" you meant that since we can't change outputs (we can't just decrease change output value - output that return sats back to us - in order to increase fee) we need to add one additional input and change output, and by that way to increase fee. **The result is that we have at least 2 change outputs (and maybe more if we do FSS-RBF again)** Did I understand you correctly?  
> **username_2**: Yes, you would generally need to add another change output with each replacement, unless your input set for the replacement happens to not need change, but you could keep just one input stable across all replacements and swap out other ones with larger UTXO amounts.  
> **username_0**: Hmm. So you meant the following. Original transaction: inputs(10 bc, 5bc) - outputs(13bc, 1bc). Second output is change and fee is 1bc. If 1bc is not enough (2bc is), we can make the replacement transaction as follow (**11bc**, 5bc) - outputs(13bc, 1bc). In this case, we just changed one input and outputs stayed as they were (no additional change outputs). However, it is much more realistic for the replacement transaction to look like this: inputs(**14bc**, 5bc) - outputs(13bc, 1bc, **3bc**) or inputs(**12bc**, **3**, 5bc) - outputs(13bc, 1bc, **4bc**).  
> **username_0**: Therefore, the real scenario is actually that the number of inputs stays the same or increases, and we have one additional change output.  
> **username_2**: No, only a single input is necessary to create a conflict with the preceding transactions, therefore the number of inputs can vary freely, but generally would be greater than one after the original, although their total amount must go up with each replacement. So, you might have an input that is present on the original and all subsequent versions of the transaction, but the remainder could for example be two inputs summing to 1 BTC (and two change outputs), then five inputs summing to 2 BTC (and three change outputs), finally a single input worth 3 BTC (and four change outputs).  
> **username_0**: Yes, thank you. That's exactly what I meant. I just can't agree with this: `...although their total amount must go up with each replacement.`. We can leave all the inputs as they are and just decrease the value of the change output. In this case the total amount in transaction remains the same, but we still increased the fee and the replacement is valid. I hope you agree?  
> **username_2**: No, since you have to replicate all outputs of the previous version of the transaction, the sum of the amounts of the inputs has to strictly go up in order for you to be able to pay more fees.  
> **username_0**: Yes, you are absolutely right. My fault.  

---

### Answer by username_0 on 2023-12-04. Score: 0

1. [Here](https://en.bitcoin.it/wiki/Transaction_replacement) you can find a list of all transaction replacement types (no mention of CPFP).
2. Bitcoin Core today only supports Full RBF and Opt-in RBF. Bitcoin Core also supports CPFP (but that is not a transaction replacement policy).

[![enter image description here](https://i.sstatic.net/dQb76.png)](https://i.sstatic.net/dQb76.png)

3. By default, Bitcoin Core uses Opt-in RBF.

> **Comments:**
> **username_1**: CPFP is not a transaction replacement policy (no replacement is involved). It's a quality the mining algorithm has to prioritize parent transactions when the child pays a higher fee. It can be used as an alternative to replacement in dealing with transactions whose fee is too low, but through a completely different mechanism.  
> **username_1**: In your table, what is "Satoshi RBF"?  
> **username_0**: @username_1 I took the image/table from [here](https://en.bitcoin.it/wiki/Transaction_replacement).  
> **username_0**: @username_1 Are there any additional replacement techniques other than those in the table?  
> **username_1**: None that I know of, no.  
> **username_0**: @username_1 Just a question related to CPFP and what you wrote, does bitcoin full node (core) have anything to do with CPFP or that's miner "policy" since he is the one who chooses the transactions for the block, so he will choose the parent transactions whose child transactions pay huge fee?  
> **username_1**: Miners need to get their block template from somewhere, and typically that comes from Bitcoin Core directly or indirectly. The block building feature in Bitcoin Core supports CPFP since version 0.13.0.  

---

