Why a “Conservative” Bitcoin Client Could Be Key to True Decentralization
Imagine a global, digital fortress. Its strength doesn’t come from a single, towering gatekeeper, but from thousands of independent sentries—each verifying the same rules. This is the vision for Bitcoin’s node network, and according to Jimmy Song, co-founder of the non-profit ProductionReady, preserving that vision requires a fundamentally conservative approach to the software that runs those nodes.
ProductionReady funds open-source development and education for Bitcoin node software. Song tells Cointelegraph the organization operates with a clear bias: resist significant code changes unless there is “overwhelming” community consensus. The guiding philosophy is simple but profound: “If you’re not sure a change makes the money better, don’t make it.” This stance is a direct response to growing concerns about node operational costs and network centralization.
“The more self-sovereign Bitcoin users are, the more decentralized and resilient the network becomes,” Song explains. For him, self-sovereignty means an ordinary person should be able to run a full node—the software that fully validates Bitcoin transactions and blocks—without prohibitive expense. “That means keeping the cost of running a node low enough for ordinary people to do it. When storage and bandwidth requirements grow, fewer people verify for themselves, and the network centralizes by default. A conservative client takes that tradeoff seriously.”
His concern centers on a specific piece of transaction data: the OP_Return field. Historically, Bitcoin Core limited arbitrary data stored here to 83 bytes—a tiny digital notepad. Song argues this limit is crucial for keeping node storage manageable. ProductionReady aims to restore this limit, viewing unrestricted data as a form of “on-chain spam” that inflates the blockchain’s size, making node operation more burdensome and expensive over time.
The Node Landscape: A Tale of Two Implementations
Today, the Bitcoin node landscape is overwhelmingly dominated by one implementation: Bitcoin Core. As data from Coin Dance shows, approximately 77.8% of reachable nodes run some version of Core. Its closest alternative, Bitcoin Knots, accounts for about 21.8%. This Core dominance makes its development decisions particularly consequential for the entire network’s architecture.
Source: Coin Dance
Bitcoin Core 30 and the OP_Return Firestorm
The debate over data limits ignited in October 2025 with the release of Bitcoin Core version 30. In a move that sparked immediate and significant backlash, Core developers removed the 83-byte cap on OP_Return data, increasing it to 100,000 bytes—a more than 1,000-fold expansion.
The community reaction was starkly negative. On the official GitHub pull request proposing the change, the proposal received approximately four times as many downvotes as upvotes, according to the public repository. Critics argued the change, implemented without broad consensus, prioritized certain use cases (like ordinal inscriptions or data storage) at the potential long-term expense of node decentralization.
The aftermath was a historic shift. Following Core 30’s activation, the number of nodes running the alternative Bitcoin Knots client surged to record highs. From a baseline of roughly 1% of the network in 2024, Knots nodes grew to represent over 21.7% of all reachable Bitcoin nodes by late 2025, with Coin Dance tallying 4,746 such nodes.
Source: Coin Dance
This migration underscored a critical fault line: a segment of the Bitcoin community is willing to switch software implementations to preserve what they see as the network’s core monetary and decentralization principles. For Song and ProductionReady, the path forward is clear. A “conservative” client, one that resists feature creep and prioritizes minimal resource requirements, is not just an alternative—it’s a necessary check on the system’s evolution. The ultimate security of Bitcoin, they argue, may depend on ensuring the guard post remains accessible to the many, not just the few.
