What restrictions are placed on RBF in the deployed "opt-in RBF" variant?
Opt-in Replace-by-Fee defines a way to mark transactions as replaceable until they are confirmed in a block. This is done by setting the sequence number smaller than
MAX corresponds to standard final transactions and
MAX-1 marks locktimed transactions.)
To replace the transaction before it is confirmed, the authoring user may broadcast an update of the transaction (a doublespend!) with a higher fee. This update version may also set the sequence number to a final value, i.e.
MAX, marking it as non-replaceable.
Bitcoin Core v0.12.0 and following 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 are not affected. Nodes that implement opt-in RBF treat them exactly as before. Doublespends of final transactions are still treated under the first seen paradigm.
- Non-final (RBF) transactions clearly signal that they should not be accepted before confirmation. However, these are not created by default.
What influence does this have on zero confirmation payment processing?
Users get a new type of transactions that should not be accepted without confirmation. Accepting final transactions without confirmation has exactly the same risks as before the introduction of opt-in RBF.