Bitcoin Core V29 Ends Battle Dating Back To Satoshi

Bitcoin Core v29 has just been released, signaling the resolution of a debate within the Bitcoin community that stretches all the way back to the days when Satoshi Nakamoto was still actively discussing new ideas on Bitcointalk. The announcement arrived with a statement in the release notes explaining that, starting with v28.0, the “-mempoolfullrbf” startup option had defaulted to 1 and that, with widespread adoption of the practice, the option was now removed entirely.

The official notes read: “Starting with v28.0, the -mempoolfullrbf startup option was set to default to 1. With widespread adoption of this policy, users no longer benefit from disabling it, so the option has been removed, making full replace-by-fee the standard behavior. (#30592)”

In response to this milestone, longtime Bitcoin developer Peter Todd posted via X, “The battle for Full-RBF is finally over.” He was soon asked by a user how long the struggle had lasted, and Todd replied, “Over a decade… 2013 IIRC. Even longer if you count it from when Satoshi first mentioned RBF in Dec 2010.”

Bitcoin Core v29 Declares Full-RBF The New Standard

Full Replace-by-Fee (Full-RBF) is a policy that allows any unconfirmed transaction sitting in the mempool to be replaced by another transaction that pays a higher fee, regardless of whether the initial transaction signaled replaceability. This policy builds on earlier discussions dating back to December 2010, when Satoshi Nakamoto briefly floated the idea of allowing transaction replacement as a means to prevent network congestion and address stuck transactions. Several years later, in 2013, Peter Todd began advocating more forcefully for RBF as a remedy to the common user complaint that low-fee transactions could remain unconfirmed for hours or days if the network was overloaded.

The debate that developed around Replace-by-Fee, and later Full-RBF, became a flashpoint for broader questions about Bitcoin’s purpose, security, and everyday usability. On one side were those who saw transaction replacement as an inevitable and beneficial evolution of Bitcoin’s transaction-processing logic. They argued that it aligns well with Bitcoin’s fee market incentives—miners naturally choose higher-fee transactions—and that it provides greater reliability for users by allowing them to “bump” a transaction fee after realizing their initial fee might be too low.

The counterargument came mostly from merchants and services that relied on so-called zero-confirmation transactions, often used for small payments such as buying a coffee or making quick point-of-sale purchases. Opponents of Full-RBF argued that enabling any unconfirmed transaction to be replaced would make zero-confirmation payments too risky, as malicious actors could double-spend by broadcasting a conflicting transaction with a higher fee.

This issue of zero-confirmation payments—commonly called 0-conf—was particularly divisive. Some merchants considered 0-conf good enough for low-value transactions because the incentives to cheat were minimal. However, developers in favor of RBF argued that 0-conf was never a sound security assumption in the first place, because double-spends were theoretically possible regardless.

The introduction of opt-in RBF in 2016 (via BIP125 and Bitcoin Core 0.12.0) formalized this debate: transactions could include a flag signaling their willingness to be replaced, but miners and nodes could still choose whether to honor the replacement. Bitcoin Core has steadily moved toward broader RBF use in the years since, culminating with v29 in April 2025, which fully adopts the policy network-wide by default.

The debate also spilled over into other Bitcoin forks and communities. Bitcoin Cash, which emerged in 2017 with a focus on larger block sizes and low fees, largely rejected RBF in favor of preserving zero-confirmation features. Proponents of Bitcoin Cash often saw Full-RBF as a step in the direction of turning Bitcoin into a strictly “store of value” system, rather than a payment network for everyday transactions. Bitcoin Core developers, for their part, tended to argue that Bitcoin’s long-term scaling relied on second-layer solutions, such as the Lightning Network, where near-instant transactions are possible without relying on unconfirmed on-chain payments.

Over the years, miners generally leaned toward policies that maximize fees and network efficiency, though some were initially hesitant to adopt Full-RBF if it threatened to fracture the network into competing mempool policies. Merchants, payment processors, and Bitcoin ATM operators that favored zero-confirmation transactions resisted Full-RBF for obvious reasons: it undermined the trustworthiness of unconfirmed payments. Yet the momentum toward broader adoption of RBF never ceased, supported by the argument that it reflects the economic reality of how miners and users interact with the fee market.

Now, with Bitcoin Core v29, the final step has been taken: Full-RBF is the standard behavior, with no option to disable it. That shift closes a decade-plus chapter of argument and technical back-and-forth, one that Peter Todd alludes to when he says it goes back “even longer if you count it from when Satoshi first mentioned RBF in Dec 2010.”

At press time, BTC traded at $84,024.