A Closer Look at Bitcoin Unlimited’s Configurable Block Size …

Bitcoin Unlimited, one of the Bitcoin Core software forks introduced in late 2015, garnered much attention in recent months. The project gained hash power support from several new Bitcoin mining pools, including ViaBTC, GBMiners and BTC.TOP, while node adoption appears to be on the rise as well.

The central idea behind Bitcoin Unlimited — specified in “Bitcoin Unlimited Improvement Proposal 001” (BUIP001) — is to hand control of Bitcoin’s block size limit to users and miners. Or perhaps more accurately: to make this control more explicit and easier to handle.

Here’s how.

The Proposal

The Bitcoin protocol, as enforced by economically relevant nodes, currently includes a one-megabyte block size limit. If a miner were to create a block larger than one megabyte, that block would be considered invalid. It would not become part of Bitcoin’s blockchain, and the miner that mined it would have wasted its resources producing it.

BUIP001 — drafted by Bitcoin Unlimited lead developer Andrew Stone — disposes of the one-megabyte block size limit protocol rule entirely, and replaces it with three configurable options. Two of these are configurable by all node operators, which include regular users as well as miners. And a third option is only for miners.

These configurations are signaled to the Bitcoin network. Regular users broadcast their preferences to other nodes, and miners embed their preferences in the blocks they mine.

Option 1: Maximum Generation Size, or “MG”

First, there is the Maximum Generation Size, also referred to as “MG.” This option is for miners only and is fairly straightforward: it lets miners set the size of blocks they produce. The default setting is one megabyte: It doesn’t automatically diverge from the current Bitcoin protocol. But if a miner wants to create a two-megabyte block, it’s as simple as “flipping a switch” in Bitcoin Unlimited’s user interface. If a miner wants to produce an eight-megabyte block, it’s the same switch.

(The only limits left are limits on message length, which Bitcoin Unlimited set at 160 megabytes. And eventually data type limits or machine resource limits.)

MG gives miners full control over the size of blocks they produce. But of course, as explained above, a two-megabyte block would be rejected by the network right now.

That’s where the second configurable option comes in.

Option 2: Excessive Block Size, or “EB”

The Excessive Block Size, typically referred to as “EB,” determines the size of blocks that nodes and miners accept. If a miner produces a two-megabyte block, that block will be accepted by all nodes and miners that set EB to at least two megabytes.

EB is set at sixteen megabytes by default and is configurable by both normal users and miners. But it is an especially important configuration for miners: miners only mine on top of blocks they accept. A miner that maintains Bitcoin’s current one-megabyte block size limit will reject a two-megabyte block, to instead keep mining on the last one-megabyte block. A miner that sets EB to two megabytes, however, will immediately mine on top of that same two-megabyte block, regardless of what the rest of the network does.

Of course, this also presents a problem.

If a minority of miners sets EB to one megabyte, and a majority of miners sets EB to, say, two megabytes, the network could split in two. As soon as anyone mines a two-megabyte block, a minority of miners will ignore it, and instead continue to extend the one-megabyte chain. The majority of miners, however, will accept the chain with the two-megabyte block, and extend that chain.

Different groups of miners would consider different chains valid, and mine on top of their “own” chain while ignoring the other chain. This split could technically last forever without the two chains ever converging, in effect splitting Bitcoin into two different networks and currencies.

In an attempt to resolve this, Bitcoin Unlimited introduces the third configurable option.

Option 3: Excessive Acceptance Depth, or “AD”

Excessive Acceptance Depth, or “AD,” essentially overrules EB. More specifically, AD determines the number of added confirmations a block requires, before nodes and miners accept it regardless of that block’s size. The default is four.

So, let’s say a node sets EB to two megabytes, and AD to four added confirmations. If that node receives a three-megabyte block, it will initially ignore that block since it exceeds its two-megabyte EB. But if a majority of miners does not ignore that block, and mines four new blocks on top of it, the node’s two-megabyte EB is overruled by its four AD confirmations. The three-megabyte block is retroactively accepted as valid.

As such, different miners (and nodes) should — eventually — converge on a single valid chain, even if they have different MG and EB settings.

Last, it’s worth briefly mentioning the “sticky gate.” If a node’s AD is hit, that node will accept subsequent blocks of any size for about 24 hours (144 blocks). This sticky gate ensures that miners immediately build on the chain with the newly accepted bigger blocks, and not continuously lag behind on the rest of the network, while waiting for each block to reach sufficient AD.

The next article will take a closer look at some of the weaknesses of BUIP001.

“Jonny1000” contributed to this article.