There are two primary proposals on the table for increasing the transaction capacity on the Bitcoin blockchain.  I’m in favor of both of them.  Although nearly everyone agrees we want more capacity, it has been hard to decide the best path forward.  Regardless of where you stand, one interesting consideration is who gets to vote for the two proposals.

Segregated Witness

Segregated Witness, or “SegWit” for short, is a fantastic feature which has a number of positive impacts for Bitcoin.  It can be implemented with a “soft-fork” upgrade, and I have yet to hear anyone disagreeing that SegWit is a good idea.  The only delays would be implementation and testing, but those are progressing well.  Bitcoin Core developers have committed to a solid roadmap.

In terms of increasing the block capacity, SegWit should yield a 1.6x increase in transactions within a block, once fully implemented.  But implementation is not just within the core software, it also must be implemented in every wallet in that creates transactions.  In order to get full capacity gains, all transactions need to be created using wallets that have implemented SegWit.

So who votes for SegWit?  Since there is no contention that its a good feature, the voters end up being wallet implementations like BitGo, Blockchain.info, and Coinbase.   And, if you know the stats, you know that Blockchain.info is currently responsible for 40+% of blockchain transactions (that chart does not include BCI’s API based transactions).  

For the record, BitGo plans to implement SegWit early.  We feel it is a good improvement for our customers and will reduce their fees substantially.  It is a significant engineering effort, but we are committed.

2MB Blocksize

This approach is much simpler in concept – it’s a direct increase in the size of a block from 1MB to 2MB, thus allowing twice as many transactions.  There are some corollary impacts to consider with other limits to avoid scalability issues with massive transactions and such, but for the most part the implementation portion is understood.  The primary debate with the increase is that it requires a hard fork, and some are worried that we could end up creating two different versions of Bitcoin.

Everyone seems to have an opinion about the hard fork.  We’ve seen BitcoinXT, we’ve seen Bitcoin Classic, and we’ve seen Mike Hearn quit the Bitcoin world altogether.  Gavin Andreesen, long time lead engineer for Bitcoin is strongly in favor of the hard fork.  Brian Armstrong, CEO of Coinbase has been adamant about the hard fork.

But not everyone agrees. Some Bitcoin Core developers (Andresen and Garzik) are in favor of the 2MB increase, but most core developers are not, and they’ve been reluctant to add a blocksize increase to the roadmap.  I think everyone prefers the Bitcoin Core developers to agree with a direction, so the disagreement is troubling.

Regardless, none of these people get to vote on the hard fork – not even the Core developers. Only the Bitcoin miners really get to vote, as they’re the ones that create the larger blocks.  Everyone else is just an opinion.

Conclusions

Unfortunately, it doesn’t look like we’ll see a block size increase any time soon.  But SegWit is very likely.

The voters for SegWit are the wallets, and Blockchain.info is the lion’s share of transactions.  If you’re truly interested in Bitcoin capacity increases in 2016, it’s time to go pay Blockchain.info a boatload of money, because without them on board, the increases are less than 30% this year, even if every other wallet implements SegWit.