BIP125 made an unconfirmed payment explicitly replaceable

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A standard for something Bitcoin already allowed

Signatures on separate inputs of a transaction are independent, so nothing in the base protocol ever guaranteed that a node would keep the first version of an unconfirmed transaction it saw; what most nodes did in practice was refuse to replace one. The BIP125 specification, assigned 4 December 2015, addresses that policy directly: many nodes at the time would not replace any mempool transaction with another spending the same inputs, making it difficult for spenders to adjust a payment they had already sent. It defines opt-in signalling: a transaction counts as replaceable if any input carries a sequence number below 0xfffffffe, and any transaction descending from an unconfirmed, signalling ancestor inherits that replaceability.

What shipped, and when

The policy reached users through Bitcoin Core 0.12.0, published 23 February 2016, which made it possible to replace transactions in the memory pool of Bitcoin Core nodes, provided the replacement paid sufficient fee as BIP125 describes. The release notes are precise about a gap at launch: the bundled wallet itself could not yet construct an opt-in transaction, so the immediate practical effect was on relay and mempool policy, with the `gettransaction` and `listtransactions` calls gaining a field to report whether a received transaction was subject to replacement.

What it removed for a merchant

Before this signalling existed, a merchant accepting a zero-confirmation payment was relying on network-wide reluctance to relay a conflicting transaction, not on a rule. The payment processing guide already advised that zero-confirmation transactions should generally not be trusted without risk analysis, and BIP125 sharpens why: an opt-in signalled transaction explicitly tells the network its sender may still change it. The BIP's own guidance to a wallet receiving such a transaction is blunt: do not treat it as payment until it has been confirmed, or flag it as more suspect than an ordinary unconfirmed one. A transaction that never signalled replaceability, and has no signalling ancestor, is unaffected; the change narrows trust rather than eliminating zero-confirmation practice outright.

Questions to carry forward

• Does a point-of-sale system check for BIP125 signalling before accepting a zero-confirmation payment, or ignore the field entirely?
• Is an unconfirmed transaction's ancestor chain also checked for inherited replaceability, not just the transaction itself?
• Has full replace-by-fee, rather than only opt-in signalling, become the relay policy a given source describes, and does that change the calculus again?

BIP125 did not make Bitcoin's transactions less final than they already were before confirmation; it made that lack of finality visible and standardised, which is a different and more useful thing.