Bitcoin Core PR #35405 proposes removing the BIP125 replace-by-fee (RBF) signal, but any privacy benefit will depend on wallets standardizing around a shared MAX-2 nSequence value.

The proposal, submitted by developer rkrux on June 19, 2026, argues that the legacy opt-in RBF flag is now redundant. With full-RBF firmly established as the default mempool policy, the BIP125 signal no longer serves a functional purpose and instead persists as an unnecessary on-chain identifier.

This is more than a routine cleanup. The change is part of a broader privacy initiative that requires coordination across wallet providers to adopt a single default nSequence value—an issue that is structurally more complex than simply removing a flag.

Under BIP125, transactions signaled replaceability if any input used an nSequence value below 0xffffffff − 1. Introduced in Bitcoin Core 0.12.0 in 2016, this mechanism allowed users to increase fees on unconfirmed transactions while maintaining first-seen mempool behavior.

That signaling became effectively obsolete after Bitcoin Core introduced full-RBF via the mempoolfullrbf option in version 24.0 and later made it the default. As rkrux noted, once full-RBF became standard, the opt-in flag lost its operational relevance. Nodes now replace transactions regardless of nSequence values.

However, retaining the signal creates a privacy drawback. Since the nSequence field is mandatory, wallets cannot omit it. If wallets drop the BIP125 flag without coordinating on a replacement value, they risk generating distinct sequence patterns that can be used to identify wallet behavior on-chain.

As contributor Murch pointed out, eliminating the signal alone does not remove fingerprinting. Every transaction input still requires an nSequence value, making ecosystem-wide coordination essential to avoid introducing new identifiers.

Murch and Electrum developer SomberNight have both supported adopting MAX-2 as the default, a choice reinforced by data showing that roughly 75% of transactions already use this value. Alternatives such as MAX-1 were considered but rejected, as they would create a new, distinguishable pattern rather than blending into the current majority.

There is also a forward-looking rationale. Proposed upgrades involving nVersion=3 transactions and Package RBF may assign specific roles to MAX and MAX-1, making MAX-2 the more practical long-term standard while easing future transitions.

From a user perspective, the ability to bump transaction fees remains unchanged. What changes is the visibility of replaceability within the transaction structure. Merchants who previously relied on the BIP125 flag to assess zero-confirmation risk will now need to assume all unconfirmed transactions are replaceable—an assumption that has effectively held since full-RBF became standard.

If adopted and widely implemented, the proposal could set a precedent for coordinated defaults across the Bitcoin ecosystem. A shift to MAX-2 would mark a relatively unified alignment among wallet developers, in contrast to the slower, fragmented rollout of full-RBF in previous years.