jimmysong
March 23, 2026
The Case for a Conservative Bitcoin Client
ProductionReady was announced today, and I wanted to jot down some thoughts, and perhaps answer some questions that people might have about who we are and what we do.
The question about who we are is pretty simple. We're a 501(c)3, or in more plain language, a non-profit. We exist for the purpose of both educating new developers and funding another implementation. And we want that implementation to be conservative.
What We Mean by Conservative
Conservative is one of those words that means different things to different people, so let me be specific. When we say conservative Bitcoin client, we mean conserving, as in, preserving Bitcoin's monetary properties: fixed supply, censorship resistance, permissionless access, credible neutrality. These are the things that make Bitcoin worth anything at all, and every protocol change should be weighed against whether it strengthens or weakens them.
This isn't about never changing anything. Bitcoin has changed many times and will change again. But there's a difference between changes that make the money better and changes that serve some other agenda. When you're securing trillions of dollars for millions of people, the burden of proof should be on the change, not on the people who don't want it. The default answer should be no and only in the case of overwhelming support should it be yes.
Bitcoin got this far by being hard to change. As we say in software, that's not a bug, but a feature.
Why We're Building on Core
So why not start from scratch, or adopt an existing alternative like libbitcoin or btcd?
The answer is pretty straightforward given our goals. Bitcoin Core is the most battle-tested codebase in open-source history. Sixteen years of adversarial conditions, nation-state level incentives to break it, and it has never been successfully compromised. You don't just throw that away.
Our client will be built on Core because that's the conservative choice. We're not re-architecting the software. We're differentiating on development process, policy defaults, and priorities. What gets merged, how fast things move, and who has a seat at the table when decisions are made. The underlying consensus code stays compatible, which means node operators can switch with much less risk.
We're giving node operators another option that starts from the same proven foundation but makes different choices about how development proceeds.
Why a Third Implementation
Bitcoin Core and Bitcoin Knots have both done important work. But the long-term health of the network requires more than two options that have more than 5% of network adoption.
A single dominant implementation means a single set of maintainers making decisions for the entire network. That's a centralization risk that we talk about constantly when it comes to mining but somehow tolerate when it comes to software. The community isn't comfortable with one mining pool having a large majority of hashrate, and increasingly, I don't think it should be comfortable with one implementation having a large majority of nodes.
We saw this play out in real time. When Core v30 removed the OP_RETURN data limit, many node operators switched to Knots. The share of Knots nodes went from 2% to over 15% in a matter of weeks. The demand for choice isn't theoretical. It was demonstrated by people actually running different software on their own machines.
A third implementation expands those options. More implementations with real adoption means no single development team can unilaterally set the direction of Bitcoin. That's decentralization working the way it's supposed to: at every layer, including the code.
Building for the Long Term
Bitcoin's endgame is ossification, or the point where the protocol becomes effectively unchangeable. That's not a popular opinion in some developer circles, but it's the logical conclusion of what makes Bitcoin valuable. The less it can be changed, the more people can trust it and plan with it.
A conservative implementation accelerates that path by demonstrating that stability is viable and desirable. We want to prove that you can run a well-maintained, actively developed client that simply has a higher bar for what constitutes a necessary change.
This is generational work. We're building something that has to outlast every one of us. ProductionReady exists to make sure that work gets funded independently, transparently, with no strings attached.
We're optimizing for Bitcoin as sound money. Everything else is noise.