Bitcoin Core PR #35405 aims to remove the BIP125 replace-by-fee (RBF) signaling mechanism, though any meaningful privacy improvement will depend on wallets aligning around a common MAX-2 nSequence default.
Filed by developer rkrux on June 19, 2026, and shared on the Bitcoin-Dev mailing list, the proposal argues that the legacy opt-in RBF flag has become obsolete. With full-RBF now established as the default mempool policy, the BIP125 signal no longer provides functional value and instead remains as an unnecessary on-chain marker.
This proposal goes beyond housekeeping. It is part of a broader privacy effort that hinges on cross-wallet coordination—specifically, agreement on a standardized nSequence value. That requirement introduces a deeper structural challenge than simply removing a legacy flag.
Historically, under BIP125, a transaction signaled replaceability if any of its inputs 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 preserving first-seen mempool behavior.
The transition to full-RBF—first introduced via the mempoolfullrbf option in version 24.0 and later made the default—has effectively neutralized that signaling. As rkrux noted, once full-RBF became standard policy, the opt-in flag lost its operational relevance. Nodes following default rules now replace transactions regardless of nSequence values.
However, removing the signal introduces a secondary concern: wallet fingerprinting. Because the nSequence field is mandatory, wallets cannot omit it. Without coordination on a replacement value, different wallets may produce distinguishable sequence patterns, making them identifiable on-chain. This reflects a broader class of privacy risks tied to metadata leakage in transaction construction.
As highlighted by contributor Murch, the challenge is not simply dropping the signal but ensuring uniformity in what replaces it. Every transaction input still requires an nSequence value, meaning that without ecosystem-wide agreement, new fingerprints could emerge.
Murch and Electrum developer SomberNight have both pointed to MAX-2 as the preferred default. Data suggests that approximately 75% of Bitcoin transactions already use this value, making it the most natural candidate for standardization. Alternatives like MAX-1 were considered but ultimately dismissed, as they would create a new identifiable pattern rather than blending into the current majority.
There is also a forward-looking dimension. Proposed upgrades involving nVersion=3 transactions and Package RBF may assign distinct roles to MAX and MAX-1, positioning MAX-2 as the most practical long-term default while minimizing future migration complexity.
From a user perspective, the proposal does not affect the ability to bump transaction fees. Instead, it removes visible indicators of replaceability. This means merchants who previously relied on the BIP125 flag as a heuristic for zero-confirmation risk will need to assume all unconfirmed transactions are replaceable—an assumption that has already been technically accurate since full-RBF became standard.
More broadly, the proposal could serve as a test case for ecosystem-wide coordination. If adopted and followed by wallet developers, a shift to MAX-2 would represent one of the more cohesive default alignments in Bitcoin’s recent development history, in contrast to the gradual and fragmented rollout of full-RBF across the network.
