Key Points
- Developer proposes removing legacy opt-in RBF flag as full-RBF is now default.
- Wallet coordination on nSequence aims to reduce fingerprinting risks.
A proposal has been submitted to remove the legacy opt-in Replace-by-Fee (RBF) signal from Bitcoin (BTC) Core wallet transactions.
Developer rkrux introduced PR #35405 on June 19, 2026, stating that the BIP125 signaling flag is no longer necessary because full-RBF has become the default mempool policy across the network.
The proposal frames the change as both a technical update and a privacy-focused adjustment. Removing the flag requires coordination among wallet providers to standardize a single default nSequence value rather than simply deleting code.
Why the Legacy RBF Flag Is Considered Redundant
Under BIP125, transactions signaled opt-in replaceability if any input used an nSequence value below 0xffffffff − 1.
This mechanism, introduced in Bitcoin Core 0.12.0 in 2016, allowed users to voluntarily bump fees for unconfirmed transactions while preserving first-seen mempool behavior.
As full-RBF gradually became standard policy, including through earlier configuration options and later default activation, the explicit opt-in signal lost practical relevance.
According to documentation from Bitcoin Optech’s RBF topic page, nodes following current default policy may replace transactions regardless of nSequence signaling.
Developers argue that keeping the legacy flag now introduces privacy concerns. Since the nSequence field cannot be left empty, differing default values across wallets can create identifiable on-chain patterns.
If some wallets remove the BIP125 signal without aligning on a unified replacement value, their transactions could become distinguishable, increasing the risk of wallet fingerprinting.
Standardizing nSequence and Broader Implications
Community contributors have emphasized that removing signaling does not eliminate the need to select a sequence number for every input.
Participants including Murch and Electrum developer SomberNight have expressed support for adopting MAX-2 as a shared default, noting that it already represents the majority usage pattern in transactions.
Alternative values such as MAX-1 were discussed but viewed as potentially creating a new identifiable pattern rather than blending with existing transaction norms.
There is also consideration of forward compatibility with potential future upgrades involving nVersion=3 transactions and Package RBF semantics, where reserving MAX and MAX-1 for distinct policy behavior could reduce future migration challenges.
The proposed change would not remove users’ ability to fee-bump unconfirmed transactions.
However, merchants relying on visible opt-in RBF signals for zero-confirmation risk assessment would need to treat all unconfirmed transactions as potentially replaceable under current network policy.
If widely adopted, the update could establish a coordinated default across wallet software, reflecting broader alignment within the Bitcoin development ecosystem.
