On the emerging consensus regarding Bitcoin’s block size limit: insights from my visit with Coinbase and Bitpay

“The upgrade to larger blocks must be decisive and absolute.”

After visiting with Coinbase on 16 March 2017 and with Bitpay on 20 March 2017, this is the message that resonates inside me: “the upgrade to larger blocks must be decisive and absolute.” The community does not want the blockchain to split. A split would threaten Bitcoin’s network effect, cause confusion in the media, and create unnecessary work for many Bitcoin businesses. This article presents my perspective on what is happening in Bitcoin and how I suspect the upgrade to larger blocks will unfold (hint: it will be anticlimactic). It is adapted from the presentations I gave at Coinbase and Bitpay (in both cases, I presented to the entire company, with people from remote offices watching online), and augmented with the information I’ve learned since then. The images are screenshots of my slides.

Part 1: Where we are now

Growth has hit a wall — The chart above illustrates how the size of blocks have grown since the genesis block was mined on 3 January 2009. Each block is represented by a tiny dot and the coordinates of that dot indicate the time the block was mined and the block’s size. Bright regions indicate that a lot of blocks of a particular size were mined at that particular time while dark regions indicate that very few blocks of a particular size were mined at that particular time.

We see that Bitcoin went through a dormant period for the first year, before exploding exponentially. Two important observations to make are:

1. At nearly all points in Bitcoin’s history, there was a broad distribution of block sizes. The explanation is that sometimes a block is found within a few seconds of the previous block and so very few transactions are waiting to be cleared, while other times the next block may not be found for over an hour and so many transactions are waiting to be cleared. The distribution of block sizes is a result of miners dynamically adjusting the amount of block space they produce to meet the real-time demand from Bitcoin users.
2. There are several bright white horizontal lines on the chart that correspond to historical (soft) limits imposed on the size of blocks by miners. In every case, once demand rose sufficiently, the line gave way to a new line at a larger block size. The Bitcoin network began to hit the uppermost line in 2015 and — as can be seen by dimming the exposure in the image above—no line has become this bright before breaking. This is the invisible wall at 1 MB.

The invisible wall at 1 MB has changed the behavior of Bitcoin — Because miners can no longer dynamically adjust the size of the blocks they produce to meet the real-time demand for block space (e.g., nearly all blocks are now 1 MB in size), transactions cannot be cleared in a timely manner. For example, one year ago the average confirmation time was 18 minutes; now it is 1 hour and 46 minutes. Fees have increased too, jumping from $0.09 one year ago to $0.83 today (28-day trailing averages).

As a result of these changes, Bitcoin has become less usable and thus (all else held constant) will be used less, giving opportunities to similar systems (alt-coins) without these internally-imposed constraints to out-compete Bitcoin.

The wall is internal, not external — Normally when a complex system in nature stops growing, it is the result of something in the external environment: less available energy or a physical blockage, for example. In the case of the Bitcoin network, the wall is internal. Inspecting the “genetic code” of a typical network node reveals a gene instructing the node to reject blocks that are over 1,000,000 bytes in size.

Node operators are modifying their nodes to accept larger blocks — Remember that there are human operators behind the nodes that make up the Bitcoin network, and these human operators want Bitcoin to thrive. Nodes operators are modifying their nodes to accept larger blocks today and signalling this fact to the network. Last year, 1.2% of visible nodes expressed a new “permissive gene,” by November 6.7% did, and today 12% do.

Miners are modifying their nodes to begin producing larger blocks — Like node operators, miners are also expressing their preference for larger blocks. Miners do this by leaving a signal in the blocks they mine. Last year, 0.5% of the network hash power produced this signal, by November 12% did, and today approximately 40% of the network hash power is signalling that they wish to begin producing larger blocks.

Part 2: How I suspect the upgrade to larger blocks will unfold

In point form:

1. The number of node operators and miners signalling for larger blocks will continue to increase.
2. Once a certain hash power threshold is met (perhaps 2/3rds or 3/4ths), miners will begin orphaning blocks from non-upgraded miners (e.g., refer to this piece from ViaBTC). This will serve as an expensive-to-ignore reminder to non-compliant miners to get ready for the upgrade.
3. Miners will agree on a new block size limit that is equal to or less than what they believe the majority of the network is willing to accept (which appears to suggest a new block size limit less than or equal to 16 MB [some suggestions are 2 MB and 8 MB]).
4. Several weeks of notice will be given before miners will begin to accept larger blocks, to allow node operators running non-upgraded software sufficient time to upgrade.
5. Several weeks later, miners will begin producing larger blocks.
6. The client implementation known as Bitcoin Core will split internally, as one faction modifies the software it maintains in order to permit its users to track the emerging consensus.
7. The future will look similar to the past. Looking back, the bright line at 1 MB will not look that much different than the bright lines that came before it nor the bright lines that will come after it.

Part 3: Minimizing the risk of a blockchain split

The following section is descriptive rather than normative. I describe the mechanism that exists and that I believe will be used to deter a split (rather than the mechanism I believe ought to be used), taking into account our discussions at BU with miners, businesses, and the incentive structures underlying bitcoin.

[Level 1] Anti-split protection — The first level of anti-split protection comes from the power of Bitcoin’s network effect. If we imagine a blockchain split where 20% of the hash power splits off to maintain a “small-block” branch, then blocks on that branch will initially be found 4x as slowly as blocks on the “large block” branch. If we further imagine that the large-block branch permits (for example) up to 8 MB blocks, then the capacity of the small-block branch (ignoring Level 3 protection described below) would be only 1/32nd that of the large-block branch. On the large-block branch transactions would confirm quickly and fees would be small, whereas on the small block branch, wait times and fees would explode beyond the already-high levels we experience today.

Initially it would cost miners the same amount to mine a block on either the small-block or large-block chain. For example, if the cost to mine a block prior to a blockchain split was $10,000 USD, then the cost to mine a block immediately after the split would also be $10,000 USD regardless of which branch the miner chooses to mine on. What makes things interesting, is that a miner would not be able to sell his coins until 100 new blocks are built on top of the block he mined, and so his decision for which chain to mine must reflect the probability that the branch he selects would survive long enough for these mined coins to be sold.

Which chain is more likely to exist 100 blocks in the future? The secure chain with 80% of the hash power and 32X the capacity, or the insecure chain with only 20% of the hash power, high fees and long wait time? As more miners defect from the small block chain, the probability of that chain making it to 100 blocks is further reduced, encouraging even more miners to defect. Eventually the prospects for the minority chain become so poor that it is completely abandoned. No small-block miner would receive any revenue from the blocks he mined.

Of course, since miners know this ahead of time, it is unlikely that any will bother to mine on the minority chain in the first place (and thus no split would occur).

[Level 2] Anti-split protection — Miners will orphan the blocks of non-compliant miners prior to the first larger block to serve as a reminder to upgrade. Simply due to the possibility of having blocks orphaned, all miners would be motivated to begin signalling for larger blocks once support definitively passes 51%. If some miners hold out (e.g., they may not be paying attention regarding the upgrade), then they will begin to pay attention after losing approximately $15,000 of revenue due to an orphaned block.

[Level 3] Anti-split protection — In the scenario where Levels 1 and 2 protection fails to entice all non-compliant miners to upgrade, a small-block minority chain may emerge. To address the risk of coins being spent on this chain (replay risk), majority miners will deploy hash power as needed to ensure the minority chain includes only empty blocks after the forking point. This can easily be accomplished if the majority miners maintain a secret chain of empty blocks — built off their last empty block — publishing only as much of this chain as necessary to orphan any non-empty blocks produced on the minority chain.

Risks — In order to be certain that the blockchain does not split, miners need to be confident that a sufficient fraction of the network hash power has upgraded, so that Level 3 anti-split protection will be effective if necessary. The biggest risk associated with the coming upgrade is that miners attempt to upgrade too early and without sufficient support. Exchanges, wallets, and other similar businesses have a fiduciary duty to preserve their customers’ assets and so all will honor bitcoins on the majority chain.

Part 4: What you can do

In my meetings with BitPay and Coinbase, the second-most common theme (second to the theme that there should be no split) is that we need more genetic diversity in nodes that are ready and willing to accept larger blocks. Presently, most of the upgraded nodes run Bitcoin Unlimited. To reduce the chances that a bug takes out several nodes of “one species,” we want to see more nodes running alternative implementations such as:

1. Bitcoin Classic (or XT if upgraded to accept larger blocks)
2. Btcd (upgraded to accept larger blocks)
3. Bcoin (upgraded to accept larger blocks)
4. Bitcoin Core 0.14 (upgraded to accept larger blocks)

Anyone can help by running such a node, either at home or in the cloud. The members of Bitcoin Unlimited are happy to provide assistance to qualified developers who wish to upgrade and maintain alternative implementations to prepare for larger blocks. Feel free to contact Bitcoin Unlimited at info@bitcoinunlimited.info.

Acknowledgment

The author acknowledges Andrew Clifford, John Swingle, Zanglebert Bingledack, Jerry Chan and Norway for their comments and suggestions. Special thanks to Jake Smith for presenting with me at Coinbase and BitPay.