<h2>What restrictions are placed on RBF in the deployed &quot;opt-in RBF&quot; variant?</h2>
<p><strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki" rel="nofollow noreferrer">BIP-125</a>: Opt-in Full Replace-by-Fee (RBF) Signaling</strong> specifies how to declare transactions replaceable until they are confirmed in a block. Replaceability is indicated via the sequence number field which appears in each transaction input. A transaction is replaceable if at least one sequence number in the transaction is smaller than <code>MAX-1</code>.</p>
<p>The meaning of sequence number values:</p>
<ul>
<li><code>MAX</code>: transaction is final</li>
<li><code>MAX-1</code>: transaction uses locktime</li>
<li><code>MAX-2</code> or smaller: transaction is replaceable</li>
</ul>
<p>A spender may overwrite a replaceable transaction with a <strong>transaction of higher feerate</strong> before it is confirmed. The feerate must increase at least by <code>minRelayTxFeeRate</code> (currently 1 sat/vB). If the replaced transaction has descendant transactions, the replacement must pay more fees than all replaced transactions. When a transaction is replaced, the transaction update may opt out of future replacements by setting all sequence numbers to a final value, i.e. <code>MAX-1</code> or <code>MAX</code>.</p>
<p>Bitcoin Core v0.12.0 and later versions will allow replacement under the above description, but will not create opt-in RBF transactions by default. Since v0.16.0 transactions will be labeled as replaceable by default.</p>
<p><strong>How does opt-in RBF interact with unconfirmed transactions?</strong></p>
<ul>
<li>Final (regular) transactions with a sequence number of <code>MAX-1</code> or <code>MAX</code> are not affected. Nodes that implement opt-in RBF treat them exactly as before. Conflicting transactions of final transactions are still treated under the first-seen paradigm and not added to the mempool or relayed even when they pay a higher fee.</li>
<li>Non-final (RBF) transactions explicitly signal that they should not be accepted before confirmation. Bitcoin Core will create final transaction by default.</li>
</ul>
<p><strong>What influence does this have on zero confirmation payment processing?</strong></p>
<p>Users get an additional new type of transaction that explicitly signals that it should not be accepted without confirmation.</p>
<p>Wallet developers should either:</p>
<ul>
<li>Hide RBF transactions before confirmation</li>
<li>Indicate the replaceable status of RBF transactions and warn the user that they are only reliable after confirmation</li>
</ul>
<p>Accepting final transactions (which don't signal replaceability) without confirmations has exactly the same risk considerations as prior to the introduction of opt-in RBF.</p>
<p>Note that since Bitcoin Core v24.0.1, node operators may choose to run <code>mempoolfullrbf=1</code> which will treat all transactions in their mempool as replaceable whether they signaled replaceability or not.</p>
<p>If you want to read more, you may be interested in this <a href="https://bitcoinops.org/en/rbf-in-the-wild/" rel="nofollow noreferrer">study on RBF adoption</a> of various wallets by the Bitcoin Optech Group.</p>

CC BY-SA 4.0
2016-11-07T11:05:58.530Z
2022-12-08T20:02:51.003Z
2022-12-08T20:02:51.003Z
Murch
<p>It is a common meme in some parts of the Bitcoin sphere that RBF erodes the option of accepting zero confirmation transactions. It would be beneficial if the following questions were answered:</p>

<ul>
<li>What restrictions are placed on RBF in the deployed "opt-in RBF" variant?</li>
<li>How does opt-in RBF interact with unconfirmed transactions?</li>
<li>What influence does this have on zero confirmation payment processing?</li>
</ul>

<zero-confirmation><replace-by-fee>
What restrictions are there to the application of opt-in RBF?
Murch
# What restrictions are there to the application of opt-in RBF?

(Asked by: username_0 on 2016-11-07)

It is a common meme in some parts of the Bitcoin sphere that RBF erodes the option of accepting zero confirmation transactions. It would be beneficial if the following questions were answered:

* What restrictions are placed on RBF in the deployed "opt-in RBF" variant?
* How does opt-in RBF interact with unconfirmed transactions?
* What influence does this have on zero confirmation payment processing?

**Tags:** zero-confirmation, replace-by-fee


---

## 1 answers

### Answer by username_0 on 2016-11-07. Score: 4 | Accepted answer

## What restrictions are placed on RBF in the deployed "opt-in RBF" variant?

**[BIP-125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in Full Replace-by-Fee (RBF) Signaling** specifies how to declare transactions replaceable until they are confirmed in a block. Replaceability is indicated via the sequence number field which appears in each transaction input. A transaction is replaceable if at least one sequence number in the transaction is smaller than `MAX-1`.

The meaning of sequence number values:

* `MAX`: transaction is final
* `MAX-1`: transaction uses locktime
* `MAX-2` or smaller: transaction is replaceable

A spender may overwrite a replaceable transaction with a **transaction of higher feerate** before it is confirmed. The feerate must increase at least by `minRelayTxFeeRate` (currently 1 sat/vB). If the replaced transaction has descendant transactions, the replacement must pay more fees than all replaced transactions. When a transaction is replaced, the transaction update may opt out of future replacements by setting all sequence numbers to a final value, i.e. `MAX-1` or `MAX`.

Bitcoin Core v0.12.0 and later versions will allow replacement under the above description, but will not create opt-in RBF transactions by default. Since v0.16.0 transactions will be labeled as replaceable by default.

**How does opt-in RBF interact with unconfirmed transactions?**

* Final (regular) transactions with a sequence number of `MAX-1` or `MAX` are not affected. Nodes that implement opt-in RBF treat them exactly as before. Conflicting transactions of final transactions are still treated under the first-seen paradigm and not added to the mempool or relayed even when they pay a higher fee.
* Non-final (RBF) transactions explicitly signal that they should not be accepted before confirmation. Bitcoin Core will create final transaction by default.

**What influence does this have on zero confirmation payment processing?**

Users get an additional new type of transaction that explicitly signals that it should not be accepted without confirmation.

Wallet developers should either:

* Hide RBF transactions before confirmation
* Indicate the replaceable status of RBF transactions and warn the user that they are only reliable after confirmation

Accepting final transactions (which don't signal replaceability) without confirmations has exactly the same risk considerations as prior to the introduction of opt-in RBF.

Note that since Bitcoin Core v24.0.1, node operators may choose to run `mempoolfullrbf=1` which will treat all transactions in their mempool as replaceable whether they signaled replaceability or not.

If you want to read more, you may be interested in this [study on RBF adoption](https://bitcoinops.org/en/rbf-in-the-wild/) of various wallets by the Bitcoin Optech Group.


---

