Bring Out Your Dead

The Story So Far

Bitcoin is proclaimed dead, by Mike Hearn, now the technical team lead of R3CEV, the bank consortium company to bring blockchains to the banks (whatever that means.) The reason for this rage quitting is the inept attempt to change the bitcoin protocol to directly allow more transactions. By not doing so, according to former developer Mike Hearn, bitcoin will degenerate into a meaningless protocol with no value.

But he's wrong. On multiple levels. So let me explain.

The current debate has split the developers into two camps. One camp is saying that we need a hard fork immediately so that the number of transactions are allowed to grow without hitting the hard limit. The other camp insists that we should retain backward compatibility. Currently, the maximum block size is 1 MB and it was put in place as a spam protection mechanism. It's very important to understand that both camps want bitcoin to scale, but they want to do it in different ways. For standard end users it won't matter. They'll just upgrade to the latest software and can send and receive value just as before.

The two proposals to extend the bitcoin protocol go under the name "hard fork" vs "soft fork."

What are Hard Forks?

The bitcoin protocol is an interesting beast. How does the client software know that it is connected to the real bitcoin network? It does so by the following two rules:

  1. The chain must start with the genesis block (hard coded into the client software.)
  2. The longest chain of valid blocks with most proof-of-work behind it.

It's important to notice the word "valid" here, because it's not an objective statement. Validity is determined by which software you're running. In the figure below I've shown three different softwares A, B and C. Software A has a maximum block size of 1 MB, B a maximum block size of 2 MB and finally C a maximum block size of 4 MB.

Depending on whether you run software A, B or C you'll see different block chains. In the figure above the blockchain as seen by software B is circled.

If miners are using Software A, then they won't be able to sell their newly minted coins on exchanges running Software B, and users running Software C won't be able to use their bitcoins bought from the exchanges running Software B. Thus, it is important that all players run the same software in order to be compatible with everybody else.

Nevertheless, if there's a hard fork and we have software A, B and C available, it's likely that the economic majority will define what "bitcoin" is and the other two become so called alt-coins. I find it unlikely that any fork that is not supported by the economic majority will survive long-term.

What are Soft Forks?

A soft fork is a way of retaining backward compatibility. Instead of forcing what is the right chain/fork we create a parallel chain to the existing one. The idea is that if something bad happens, then the parallel chain will die, but the original one will continue. Users then choose whether they want to perform transactions on the parallel chain or on the original one (basically by choosing which software to use.) The important aspect is that every node/miner is free to choose whether to they want to support the original chain only, or both chains. All software versions will be compatible with the main chain.

In some regard it seems obvious that the soft fork is always a safer/better option. Why would you risk a default on the entire main chain if something goes wrong? Isn't it always better to do a soft fork?

It is here that bitcoin developers are split into two camps. Some are extremely nervous to changes that break backward compatibility; it's always too risky and should be avoided.

However, the soft fork approach has its problems too, namely that in order to use the extensions the client software becomes way more complicated. All bitcoin providers out there running their own version of the bitcoin software has to modify / upgrade. This can be complicated especially if they're not even using bitcoin core, but written the entire software from scratch. Changing a small parameter from 1 MB to 2 MB is a simple change for all participants, but trying to cope with extension blocks and parallel chains require a lot more work.

The Economic Majority

What upgrades should bitcoin core provide? Should the bitcoin core developers themselves decide? Should bitcoin industry have a word? What about users and miners?

In recent weeks a new organization called bitcoinclassic popped up. It's an attempt to let the bitcoin community vote on issues, and then let the development team work in the direction of the voting process. It's important to understand that it's not a simple majority vote, but you need majority for each group in the bitcoin community. The groups consist of users, developers, merchants, exchanges and miners.

I think it's unwise for bitcoin core developers to alienate against the "economic majority," because if you do, then ultimately dissatisfaction will result in a hard fork both in terms of the client software as well as the development team.

It remains to be seen whether the bitcoinclassic attempt will be successful, but I'm sure that if current bitcoin core development team doesn't listen to what "everybody else wants," then sooner or later a successful break with bitcoin core will happen. The RBF (replace-by-fee) is such a controversy. It's clear that a very small number of people is actually happy with the RBF feature.

Dissecting the Argument "Hard forks open the door..."

Some say that hard forks are dangerous for political reasons; it shows that bitcoin protocol can be changed and it's then just a question of time when KYC/AML and/or the 21M cap on coins will be raised. That's just garbage talk. There's no way that no hard forking now will mean that hard forking will never happen. Nothing stops you from doing a hard fork. It's designed in the bitcoin protocol. If there's economic majority among the players, i.e. bitcoin exchanges, merchants, users and miners, then a hard fork will happen whether you like it or not. It's also important to know that you need substantial support in each group for a hard fork to be successful. That's precisely the intent with bitcoinclassic, to track that majority for each group before providing the opportunity to fork.

A raise of the 21M cap will never happen, because it's bad for all participants in the bitcoin community. Imagine we'd raise the limit to 42M by doubling the current rewards. Instantly, the fiat price of bitcoin would drop to half its price if not more. This would mean that all current bitcoin savers would take a loss which presumably include miners. Furthermore, miners won't get any net gains for newly minted coins, because the purchasing power is exactly the same or most likely worse (because loss of confidence.) So you see, don't worry about that 21M cap. It will always be there forever because the economic majority wants it.


I understand both camps.

In the soft fork approach, you would view main chain as "layer gold" and then the parallel chain as "layer silver." If silver defaults, then gold is still here. That's very reasonable.

In the hard fork approach, we'll avoid hitting the limit which will happen pretty soon. Changing the limit to 2 MB now is also reasonable to keep the network from not choking.

More importantly I view the bitcoinclassic concept with the voting process as a more important feature. Bitcoin core should not alienate themselves with the bitcoin community. If not, then bitcoin core will be ignored by the rest of community.

No camp wants to deliberate make the bitcoin network default. We've a conflict among developers which happens in most companies. Either a compromise will happen, or the economic majority will decide. Don't get me wrong. I support both camps. It doesn't matter whether the soft fork or the hard fork camp wins. Bitcoin will end up pretty good either way.

This is not the Apollo 11 moment landing on moon ( There'll always be one chain with most power (economic and proof-of-work) behind it. That chain will be called bitcoin. And bitcoin will never die.



More technical details: Yes, I'm aware of the mega transaction:

and the problems it brings. The validation process of this transaction takes a long time because the way the transaction is organized and how the bitcoin core client is implemented. In bitcoinclassic I'd suggest that the hard fork to 2 MB should also include a limit on the number of inputs and outputs a transaction can have (so it cannot exceed what's happening for 1 MB.) Then we should optimize the code. More information here: