The Third Way: The Case for a Third Implementation

Bitcoin development has gotten political. Over the past year, the accusations, name-calling and tribalism have gotten out of hand. People aren't debating technical merits. They've essentially been reduced to picking teams.

I don't think this is because Bitcoiners are bad people. I believe this is a structural problem. The way Bitcoin software development is organized creates bad incentives and bad dynamics. And in this post, I'm going to show you how a third implementation is the fix.

The Monopoly Problem

For most of Bitcoin's history, there has been one dominant implementation, which means power is concentrated in one place. One process for everything, one set of gatekeepers, one on-ramp for developers. One implementation is, by definition, a single point of failure.

The incentives under a monopoly are terrible. First, goals are unclear or non-existent. Having them is actually problematic as you get accusations of centralization and favoritism. But without explicit goals for the project, visibility becomes the goal. Developers get rewarded for shipping something big and attention-grabbing, not for doing the boring work of securing the network. They need to make their mark so they can attract grants and keep funding flowing. That may or may not have anything to do with what Bitcoin needs. I don't blame the developers for this because the structure made it inevitable.

The other problem with a monopoly is that it's one-size-fits-all. There are many different reasons to run a node and many different kinds of node operators. A miner has very different priorities from a merchant. An exchange cares about things a home node runner doesn't. A block explorer would love to have an address index, but Bitcoin Core doesn't have an address index and probably never will, because they don't want to be everything to everybody. But when you're the only implementation, that's exactly what you end up having to be, and you end up serving nobody particularly well.

Worst of all, users have almost no say under a monopoly. Their preferences have to filter through GitHub issues and development processes that most of them don't understand or participate in. And developers have very little incentive to listen. That’s not to say that they don’t, I’m sure many of them care about what users want. But the incentive to listen isn’t there because there's no real alternative. If you want to run Bitcoin, you run Core. The devs know that. They’re not incentivized to be attentive to user feedback because the users have nowhere else to go. In other words, there's no market pressure and no accountability loop. The developers are incentivized to answer to their grant funders and to each other, not to the people actually running the software.

Two Is Better, But Not By Much

We now have two main implementations, which is an improvement. But the power dynamic just shifts to a majority vs. minority situation. Goals get defined by opposition to the other side, not by what you're actually for. And you're still one step from being back to a monopoly.

The biggest problem with two is that user choice becomes binary. There is no room for moderates. You pick one extreme or the other. Each side defines itself by what's wrong with the other. "Those people are crazy." "Those people are woke." "Coretards." "Knotzis." It's easier to throw mud than to lay out your own vision. The conversation becomes tribal, not rational.

This is the weakness of any bipolar power dynamic. There's no room for anybody who wants to sit in the middle or has different priorities. You're either for one or the other, and the pressure to pick a side is enormous.

Why Three Changes the Game

Three or more implementations create entirely different social dynamics.

When nobody has a majority, you have to build coalitions. You can't just push things through because you control the repo. The process becomes market-based, with multiple approaches competing, and the one that works best wins. You can't define yourself by being against the other guy when there are several alternatives. You have to actually say what you're for. You have to set explicit goals, because "we're not them" isn't good enough when there are multiple "thems."

More implementations means more paths into Bitcoin development. Right now, Core developers are concentrated in London, New York and San Francisco which are some of the most expensive cities in the world. That's not representative of the Bitcoin community. The main on-ramp into Core development is the Chaincode Labs residency which is a great program, but it requires moving to New York for months, dropping everything else you might have going on in your life. How many people with families are doing that? You end up selecting for a very specific kind of person. Different implementations with different teams and different cultures open up the developer pipeline in ways a single repo never can.

Resilience gets better because the network can survive more than one failure. Think about what would happen if the Core maintainers were somehow captured or compromised. Right now there's sort of an alternative in Knots, but then you're back to a monopoly. Additional implementations give us protection against any single group being a point of failure.

Most importantly, users express what they want by choosing software. That's a market signal. It's way more rational than navigating GitHub processes or making a binary political choice. Each implementation has to compete for users by delivering on its stated goals, and users, businesses and miners express their preference with what they run. That's the accountability loop that doesn't exist under a monopoly.

The incentive shift matters more than anything else. With two implementations, each one defines itself by trashing the other. With three or more, that stops working. You have to articulate what you stand for and deliver on it. Users choose based on what you ship, not how much noise you make and that's a way more productive conversation for everyone.

Why Not Start from Scratch?

You might wonder why the multi-implementation dynamic doesn't work now. After all, there are lots of different Bitcoin node implementations, and several more on the way that all use a different programming language and/or different development teams. But looking at three alternative Bitcoin node implementations that have run for over a decade is instructive. btcd in Go, libbitcoin in C++, and bcoin in JavaScript have been around 10+ years, yet they have effectively zero adoption.

Why? The reason is hardening. Bitcoin is money. If your node has a vulnerability, people lose real money. Exchanges, miners, merchants and even some home users can't take that risk. They need battle-tested software with years of production use behind it.

This creates a chicken-and-egg problem. You won't get adoption unless the software is hardened, and the software won't get hardened unless it has adoption. Nobody has solved this. btcd didn't solve it. libbitcoin didn't solve it. bcoin didn't solve it. Each of them have existed for more than a decade and none of them have been able to bootstrap enough usage to get the hardening they need. And neither will any other from-scratch implementation. The gap is too wide. Core has a 16-year head start and the reality of hardening makes it nearly impossible to close that gap from zero.

The way out is to bootstrap from the Satoshi client. Use the code that's already battle-tested. Keep the hardening, but run it with a different team, different process, different goals. That's how you escape the chicken-and-egg problem without asking anyone to trust unproven software with their money.

Production Ready

We're starting a 501(c)(3) to fund this third implementation. Here's what we're building:

Conservative. We don't want to be on the bleeding edge. Not everyone buys a car in its first model year because there are always problems. Exchanges and economically significant operators think the same way about their node software. We'll go back a few versions and build for the people who need stability and security above all else.

No drama. We want to be the implementation that rejects 100KB OP_RETURNs and BIP110 which lack consensus. Both of those are filled with drama. We want none of that.

Sound money. That's the use case. We're not building for stablecoins, escrow, discrete log contracts or anything else. Bitcoin’s primary use is as sound money. Period. Everything else is noise.

Pleb-funded. The funding model for other implementations tends to be whale donors or companies looking for good press, and those donations come with strings. They want influence. We want Production Ready to be driven by its users. Your voice should be the loudest one, not some altcoin exchange trying to buy a better reputation.

We want good changes in our implementation to be portable to other implementations, too. This isn't about fracturing Bitcoin. A third implementation benefits everyone, including Core and Knots, through competition, accountability and shared improvements.

The Choice

If Bitcoin belongs to its users, they need a feedback mechanism that actually works.

With a monopoly, such mechanisms are noisy at best. Devs have little incentive to listen and users have nowhere else to go. With two implementations, the choice is binary and political. With three or more, users express their will by choosing software. That's a market and markets work.

Go to productionready.org if you want to support this or get involved. We're looking for donors and developers.

Based on my talk at BitBlockBoom 2026. Watch it here

.