What restrictions are there to the application of opt-in RBF? 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?
What restrictions are placed on RBF in the deployed &quot;opt-in RBF&quot; variant?
BIP-125: 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-1: 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 transaction, 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.
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.
If you want to read more, you may be interested in this study on RBF adoption of various wallets by the Bitcoin Optech Group.