Does XT make Mike and Gavin dictators?

Some people are portraying XT vs Core as “Dictatorship vs Meritocratic Consensus”. This isn’t right.

Gavin and I can’t be ‘dictators’ because all we do is write software: if we go crazy, or do other things you disagree with, XT can be forked in exactly the same way as we did.

But that’s not the real reason that statement is wrong. Many don’t seem to realise this, but Bitcoin Core uses exactly the same leadership model as XT for everything except the block size debate. Virtually all code changes in Core are not made by consensus, but rather, by Wladimir van der Laan (the maintainer) making a decision by himself.

We can see this easily in a disagreement that flared up on Monday about whether support for serving lightweight/P2P smartphone wallets should be made optional:

But no, this won’t convince me that this change is not “needed” ….. Full community consensus is important for changes to the consensus code, certainly for hard forks. Not for an optional behavior change in the P2P network code.

— laanwj

Oh look, Wladimir ignoring lack of consensus and being a dictator! Except …. no. He’s just being an ordinary maintainer, and doing what maintainers are meant to do: make decisions. Which is fine, and as it should be. Several developers including me and Gavin happen to disagree with his decision, and we’ll get to that later, but disagreements within a group of people is nothing special.

The details of that particular dispute are obscure and not that interesting; my goal here is to talk about decision making.

The differences between Bitcoin XT and Bitcoin Core’s decision making process are actually very small, and boil down to this:

Do maintainers make decisions for all code changes submitted, or all of them except those related to a specific type of protocol change?

It’s worth remembering that for most of Bitcoin Core’s history the answer was the first: the maintainer made decisions for all code changes. This continued up until Gavin stepped back to focus on research, which wasn’t as long ago as it feels: it was in April 2014. The idea that unanimity is required for rule changes to get into Core is actually very new.

An example from a few years ago will make this clearer.

The story of P2SH

In 2012 the Bitcoin community realised that it needed to make support for multi-signature wallets easier to use. Satoshi had put support for multi-sig in the protocol right from day one, but the problem was it was awkward to use because it didn’t work with Bitcoin addresses, and addresses were (and still are) a really popular way to ask for payments.

After some debate, the community decided to create a new kind of Bitcoin address that would fix this. To do it would require some new features in the Bitcoin protocol and block chain. It would require …. changing the rules.

You can guess what happened next.

Yup, there was a massive drama and a disagreement that was put to a miner vote. One proposal was called P2SH and it’s what we use today. The other was called OP_EVAL.

This post by edmundedgar on reddit gives a good summary:

The P2SH rollout was a huge, slow-moving psycho-drama with people putting NoP2SH in their blocks. If we’d had to wait for a full developer consensus (not to mention the kind of world+dog wider-world consensus some of the core devs are saying is needed here) we’d probably still be waiting for it to get done.

The details of that dispute were so arcane that I actually can’t remember what they were. The proposal that won is described in BIP 16. I guess it seemed like a big deal at the time.

The P2SH soap opera had all the same features the block size has:

Miners voting for what they wanted by putting markers into their blocks

A mini-fork of Bitcoin. It didn’t have a logo, it was just called the OP_EVAL patches and you had to compile it yourself, but it was there.

A voting threshold of 55% (much lower than the 75% that BIP 101 uses!)

Giant and seemingly never-ending debates splatted all over reddit, bitcointalk etc. Developers got testy with each other.

Here are some things it didn’t have:

Rampant censorship in the community forums

Accusations of destroying Bitcoin, etc

Companies signing letters to indicate their support

Media stories about a Bitcoin civil war

You may wonder why the P2SH rollout was so much less traumatic.

If you ask your local Bitcoin Core developer, they might mumble something about soft vs hard forks, but that’s a distraction: the differences between the two types are tiny and cease to matter entirely once the rollout is over and everyone has upgraded.

The real reason for the difference is that back then Gavin was the maintainer of Bitcoin Core and he wasn’t afraid to pick something and require a simple majority to activate it, whereas now Wladimir is the maintainer and he requires unanimity. It seems literally every last person in the Bitcoin universe must agree or else a change cannot happen. We think, based on experience, that this can’t ever work.

So in the end, this is all XT is doing leadership wise: going back to the exact same model of decision making we used up until April 2014.

(as an aside, I was one of the people who disagreed with Gavin about P2SH. I favoured a different, more ambitious approach. But Gavin thought the community wasn’t ready for it; hindsight proved him right and me wrong)