4

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?
Improve this question

1 Answer 1

Reset to default
4

What restrictions are placed on RBF in the deployed "opt-in RBF" 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-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 of various wallets by the Bitcoin Optech Group.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.