Bitcoin Dev Pushes to Drop Legacy Privacy Flag, Raising Wallet Tracking Concerns

Here is a clear paraphrased version of your text:

Bitcoin Core PR #35405 suggests removing the BIP125 replace-by-fee (RBF) signaling, though any privacy improvement will hinge on wallets collectively adopting a shared MAX-2 nSequence default.

A developer known as rkrux introduced Bitcoin Core PR #35405 and shared it on the Bitcoin-Dev mailing list on June 19, 2026. The proposal aims to eliminate the legacy opt-in RBF marker from wallet transactions, arguing that the BIP125 signal has become an unnecessary on-chain identifier since full-RBF is now the standard mempool policy.

This change goes beyond routine code maintenance. It represents a broader privacy-focused effort that depends on coordination across wallet providers to standardize a single default nSequence value—an issue far more complex than simply removing a flag.

Under BIP125, a transaction signaled replaceability if any input used an nSequence value lower than 0xffffffff − 1. This mechanism, introduced in Bitcoin Core version 0.12.0 in February 2016, allowed users to increase fees on unconfirmed transactions without disrupting the network’s first-seen mempool behavior.

However, Bitcoin Core’s transition to full-RBF—initially introduced via the mempoolfullrbf option in version 24.0 and later made the default—has rendered this signaling effectively obsolete. As rkrux noted, once full-RBF became standard policy, the signaling no longer served a functional purpose. Today, nodes operating under default settings will replace transactions regardless of their nSequence values.

Keeping the signal, however, introduces privacy drawbacks. Since the nSequence field cannot be left empty, wallets that remove the BIP125 flag without agreeing on a uniform replacement value risk creating identifiable transaction patterns. This opens the door to wallet fingerprinting, similar to how subtle metadata leaks can reveal behavioral patterns in long-term holder analysis.

The key challenge, as highlighted by community contributor Murch, is that removing the signal doesn’t eliminate fingerprinting unless all wallets converge on the same sequence value. Every transaction input still requires an nSequence number, making coordination essential.

Murch and Electrum developer SomberNight both support adopting MAX-2 as the default, a choice backed by data showing that roughly 75% of Bitcoin transactions already use this value. Alternative options like MAX-1 were considered but rejected, as they would introduce a new, distinguishable pattern rather than blending in with existing norms.

There is also a forward-looking benefit. Future proposals involving nVersion=3 transactions and Package RBF may reserve MAX and MAX-1 for specific policy roles, making MAX-2 a more practical long-term standard while easing future transitions.

From an industry perspective, the proposal does not impact users’ ability to increase transaction fees. Instead, it removes visible indicators of replaceability. This means merchants relying on the BIP125 flag to assess zero-confirmation transaction risk will need to assume all unconfirmed transactions are replaceable—a reality that has effectively been true since full-RBF became standard.

More broadly, this effort could set an important precedent for ecosystem-wide coordination. If Bitcoin Core adopts the change and wallets align on MAX-2, it would mark one of the more synchronized default standardizations in Bitcoin’s history—contrasting with the slower, fragmented rollout of full-RBF across wallets in previous years.