Bitcoin Roundtable Consensus
Bitcoin Roundtable
3669

The Bitcoin Roundtable Consensus Proposal — Too Little, Too Late

First let me say that that I think the core devs and Samson Mow (who organized the event) are talented people with bitcoin’s best interests at heart. It is not easy to try and get so many people to agree on anything (which is part of the reason protocol development has struggled a bit lately).

I wasn’t at the event, but having read the plan, I unfortunately feel that it misses the mark.

Here’s why.

1. Prioritizing SegWit before a block size increase would be a mistake

SegWit contains several good features, but it is not a good solution to help bitcoin scale, which is the most urgent problem we need to solve.

My understanding is that Core believes SegWit contains features which are necessary to add before a hard fork can safely occur (to prevent certain attack vectors). However, I believe Classic already contains code that prevents these attack vectors (here and here). Gavin described them toward the end of this post about the upgrade to 2MB blocks.

2. July 2017 is too far away to raise the block size

If the plan is followed as written, SegWit would provide a slightly less than doubling of capacity by April 2016 (while adding some, I believe, unnecessary complexity). Then we would go another fifteen months (until July 2017) without any additional capacity increase. If bitcoin transactions per day continue to more then double annually, as they have been for the past few years, we will be in a worse position than we are today in the first half of 2017. This feels like a major oversight of the proposal.

3. We have a better option that is already available

There is a big difference between words and action. The consensus proposal is a series of words and it’s still unclear if those will be upheld. Meanwhile, another team, BitcoinClassic, has already taken action and shipped a working solution in code that we can use today.

That solution was written and reviewed by two former core devs (including the former lead of the project) so I believe it is a high quality option.

In the future, if Core ships a great improvement to the protocol (and I believe they will), I will have no problem running that software. But if they haven’t shipped that software yet, and someone else has, there is no reason to wait.

4. It perpetuates a centralized, single party system, in bitcoin

The final reason I feel this plan should be rejected is that it reinforces the idea that bitcoin protocol development should be done by a single group, regardless of how well they do the job. Bitcoin would be better off with a multi-party system, where several teams compete to add features to the protocol. Then the industry can vote on which to adopt (by encoding votes in the blockchain, seeing which node they want to run, etc). Yes, consensus rules still work in this model, which I’ve explained elsewhere.

Conclusion

The roundtable’s consensus proposal falls short in several areas, and only offers words (not working code). Luckily, we already have a working solution to solve bitcoin’s scaling challenge today: BitcoinClassic’s 2MB hard fork.

I think bitcoin will be best served by continuing on the following path:

  1. Over the next few weeks the industry should continue upgrading to BitcoinClassic. This will provide some immediate relief to bitcoin’s scaling problem and help restore confidence in the system. Once 75% of recent blocks mined contain a vote for Classic, there will be a 30 day waiting period during which the remaining 25% (and other actors) can upgrade. After the waiting period, the network will upgrade to 2MB blocks with 99% of the network or more (I believe) on a single chain.
  2. The bitcoin price will go up and confidence will be restored as we’ve bought ourselves some time on the scaling issue.
  3. After this, bitcoin will be in an era of multiple competing teams and nodes, which will accelerate bitcoin’s protocol development. Core, Classic, or any other team can propose upgrades to the protocol that everyone in the industry can vote on. Future protocol upgrades will be decided by consensus using the blockchain (longest valid chain wins), instead of consensus using industry meetings and letters.

If we follow this model, we can have bitcoin’s protocol upgraded to 2MB by April 2016, and keep right on moving to additional upgrades (such as Core’s excellent SegWit work).

If you are a bitcoin miner or business owner, please join the existing companies who have upgraded to BitcoinClassic to help bitcoin scale, and don’t delay based on a promise of what may come in the future. Thank you.