Classic? Unlimited? XT? Core?

Almost two years ago, when I stepped down as lead maintainer for Bitcoin Core, I wrote:

I’m pleased to be able to focus more on protocol-level, cross-implementation issues and less on issues specific to the Bitcoin Core software.

I’d still like to focus on protocol-level, cross-implementation issues but lately I’ve been distracted and have generated a lot of controversy (and hurt feelings) by helping out with some other implementations (first XT, lately Bitcoin Classic, maybe Bitcoin Unlimited soon.

Madness! Chaos! ANARCHY! … I hear some people say, but there is a method to my madness. When I was lead maintainer of Core I had the following top-three priorities:

1) Keep the system secure.
2) Keep the network reliably processing transactions.
3) Eliminate single points of failure.

Those are still my top priorities, but I try to take a higher-level view, looking at the entire Bitcoin ecosystem instead of just the Core software implementation. So if those are my top priorities, what should I be working on?

Bitcoin-the-protocol is doing really well security-wise; the responsibly-report-a-vulnerability-in-bitcoin mailing list has been quiet for many months. And seeing multi-signature “p2sh” adopted is very personally satisfying. I’m still active asking dumb questions to people smarter than me to try to avoid mistakes as the protocol evolves.

I’m still worried about reliability of the network in the short term, which is why I’ve been so vocal on the block size limit issue, and which is part of the reason I’m supporting alternatives to Bitcoin Core. In the long run I think everything will work out fine, no matter what happens with the block limit.

Clever engineers will find ways to work around around the limit, whether that is ‘extension blocks’ or the lightning network or a sidechain that everybody moves their coins to doesn’t really matter. I’d prefer a nice, simple, clean solution, but I’m old enough to know that most of the world’s great technologies are built on top of horrifying piles of legacy cruft, and they work just fine pretty much all of the time.

And Bitcoin will survive without a short-term solution, but adoption and growth might be set back a year or two.

What to do about the short-term scaling issues brings me to my third priority: eliminating single points of failure. Also known as “decentralize all the things”/“diversity is good”/“competition is good”.

Part of eliminating single points of failure is trying different solutions to a problem at the same time. Assuming you have the resources, that is a good strategy– you increase your chances of success, because you only fail to solve the problem if all of the solutions fail.

Apply that reasoning to development teams and, assuming you have the resources, it is better to have multiple teams because there will be less disruption if one of them fails.

Six years ago the Bitcoin ecosystem didn’t have the resources to support multiple development teams – it certainly does now.

Specialization is natural as technologies mature; Ford Motor Company used to have raw materials delivered to one end of its enormous factory and turn out finished cars at the other end. Today, Ford assemble parts made from thousands of suppliers, and try to make sure they have more than one supplier for everything to eliminate single points of failure.

I’m doing what I can to speed up this natural process for Bitcoin. I’ll be contributing my advice and experience (and code review and code) to Bitcoin Classic and Bitcoin Unlimited and Bitcoin Core and maybe other open source projects that come along. I hope that they are all successful, and figure out where in the Bitcoin ecosystem they should specialize– maybe Bitcoin Classic will be the preferred distribution for miners and Bitcoin Unlimited will focus on features for end-users. Maybe Bitcoin Core will decide to focus on longer-term improvements at the core protocol level.

Or perhaps they will specialize by having different development cultures or processes for making decisions. If that sounds crazy to you, I’d encourage you dig into how various Linux distributions differ in priorities, decision-making, culture, etc. Diversity is good.

But what if the various implementations can’t agree on something they all need to do the same way? Linux has Linus – who gets to make the final decision on what the Bitcoin consensus rules are?

Satoshi answered that question in the last sentences of his whitepaper:

Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

I plan on writing more about incentives and the process of coming to consensus in the near future.