Bitcoin Core PR #35405 proposes eliminating the BIP125 replace-by-fee (RBF) signal, though any resulting privacy benefit depends on wallets converging around a shared MAX-2 nSequence default.
Developer rkrux submitted the proposal on June 19, 2026, via the Bitcoin-Dev mailing list, arguing that the legacy opt-in RBF flag has outlived its usefulness. With full-RBF now the default mempool policy, the BIP125 signal no longer serves a meaningful function and instead persists as an unnecessary on-chain identifier.
The proposal is not merely a technical cleanup. It represents a broader push to improve Bitcoin privacy, one that requires coordination across wallet providers to standardize a single nSequence value. This coordination challenge is significantly more complex than simply removing the flag itself.
Under BIP125, transactions signaled replaceability if any input carried an nSequence value below 0xffffffff − 1. Introduced in Bitcoin Core 0.12.0 in 2016, the mechanism enabled users to bump fees on unconfirmed transactions without disrupting the network’s first-seen mempool behavior.
However, the shift to full-RBF—initially introduced through the mempoolfullrbf option in version 24.0 and later made the default—has rendered the signal effectively obsolete. As rkrux explained, once full-RBF became standard, the signaling lost its operational purpose. Today, nodes following default policy will replace transactions regardless of nSequence values.
Retaining the signal now comes with a privacy cost. Because the nSequence field is mandatory, wallets cannot omit it. If wallets remove the BIP125 flag without agreeing on a uniform replacement value, they risk creating distinct transaction patterns that can be used for fingerprinting. This mirrors broader concerns around on-chain metadata leakage, where subtle differences in transaction construction can reveal wallet behavior.
The core issue, as noted by contributor Murch, is that eliminating the signal alone does not remove fingerprinting. Every transaction input still requires an nSequence value, meaning all wallets must align on a common standard to avoid introducing new identifiers.
Murch and Electrum developer SomberNight both support adopting MAX-2 as the default. This preference is reinforced by data indicating that roughly 75% of Bitcoin transactions already use MAX-2, making it the most natural choice for standardization. Alternatives such as MAX-1 were considered but ultimately rejected, as they would create a new, distinguishable pattern rather than blending into existing norms.
There is also a forward-looking consideration. Future upgrades involving nVersion=3 transactions and Package RBF may assign specific roles to MAX and MAX-1, positioning MAX-2 as the more practical long-term default while minimizing future transition friction.
From a practical standpoint, the proposal does not impact users’ ability to increase transaction fees. Instead, it removes visible indicators of replaceability. As a result, merchants who previously relied on the BIP125 flag to evaluate zero-confirmation transaction risk will need to assume all unconfirmed transactions are replaceable—a reality that has effectively been in place since full-RBF became standard.
More broadly, the proposal could establish an important precedent for ecosystem coordination. If adopted and followed by wallet developers, a shift to MAX-2 would mark one of the more unified default alignments in Bitcoin’s development history, contrasting with the slower, fragmented rollout of full-RBF across the ecosystem.
