Decentralizing the Block Size Limit

Bitcoin’s full node network itself, with special software, will find the most optimal block size limit via emergent consensus.

The most vexing problem in the history of Bitcoin — the block size limit — is finally being solved, invisibly, as these words are being written, as they are being published, and as they are first being read. Not by developers, but by individual full node owners. Really? Yes!

Bitcoin full nodes are being regularly started up which now include BUIP001 — special software which enables full node owners to set the maximum sizes for blocks that they will make and accept, also the delay for acceptance of oversized blocks. This capability for delayed acceptance effectively makes nodes become fork tolerant where forks exist due to block size limit disagreement. Because of this the forks will always be transient.

Bitcoin full nodes interact during block propagation. The differences in BUIP001 settings have a holistic effect on participating nodes and once critical mass occurs then emergence results effecting a varying block size limit on the entire network by top-down feedback.

How does this work? First a detour into history, we rewind six long years…

Centrally Planned Block Size Limits

Originally there was no block size limit for Bitcoin, except that implied by the 32MB message size limit. In mid-2010 Satoshi Nakamoto put in a smaller limit of 1MB. FPGA mining was first mentioned on bitcointalk, the forum he founded. Perhaps he was worried about a rogue miner making many large blocks while all Bitcoin users still needed a full node. BTC were being traded for nearly a dollar each and people were taking this new form of money seriously. Satoshi subsequently made it crystal clear that his new 1MB block limit would not remain to throttle Bitcoin’s growth, and wrote on October 4th, 2010:

It can be phased in, like:

if (blocknumber > 115000)

maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.

It is likely that Satoshi assumed largerlimit would be another constant. Then he vanished two months later. Afterwards, the debate about his block limit would rumble on month after month, year after year.

Like Ponce de Leon mythically searching in vain for the Fountain of Youth in the swamps of Florida, all subsequent searches for the optimum block size limit were fruitless. This was because of the a-priori assumption that it had to be a universal value at the protocol-level, known and observed by all Bitcoin miners and full nodes. i.e. agreed to by all nodes who wanted to make, send and receive blocks. Proposals for new constants morphed into new algorithms, BIPs, flex-cap proposals, until finally the towel was thrown in. It was impossible to come up with a centrally planned block size limit which satisfied all Bitcoiners. Perhaps at a communal level it was known that no centrally planned limit would ever be truly optimal for the network. Fees would be too high or too low and decentralization would be at risk from under-capacity or over-capacity.

Sadly, and consequently, the worst case scenario has come about since mid-2016 where the growth of Bitcoin’s network effect is arrested by centrally planned under-capacity.

What is far better than central planning is a market-driven solution. The algorithm closest to a market solution is BIP100 which relies upon miner voting, although it is handicapped by an inbuilt 21% miner veto on any block limit increases. This solution briefly found support by 70% of the hashing-power (who flagged its desirability on mined blocks). The Bitcoin Core developers rejected BIP100 because there was no feedback mechanism from the non-mining majority of full nodes. So it has languished since. Was hope lost? No! There still exists the cleanest form of market-driven solution: emergent consensus, and this is what is being rolled out right now in the Bitcoin Unlimited full node implementation.

Emergence — How it Works

Emergence is everywhere in nature. From crystals and snowflakes, to the spiralling shape of galaxies, macroscopic properties of liquids to weather patterns, ant-hills and living organisms.

Fig 1. Patterns in flocks of birds are emergent from individuals following a few simple rules

John Holland writes extensively about emergence in nature and describes emergent phenomena as typically persistent patterns with changing components, being quite paradoxical to categorize: changeless and changing, constant and fluctuating, persistent and shifting, inevitable and unpredictable. An emergent property is simultaneously part of a system and also external to it. Emergence depends upon a system to become manifest but also transcends it at the same time.

Fig 2. Interaction at peer-to-peer level produces emergent phenomena with top-down feedback

The graphic here by the anthropologist Richard Seel is an abstraction of emergence in human cultures. All aspects of culture: language, standards, markets, cities, politics etcetera are emergent from the interaction of individuals or collectives of individuals.

In the graphic emergence begins at (A) with discrete entities such as molecules, insects, or humans. At (B) there is interaction. A construct emerges in (C) transcending the entities. It could be a vortex, beehive, or a market price. Finally in (D) there is top-down causation shaping the behavioural characteristics of individual entities. Causation takes varied forms like natural selection or adaptive information control. Emergence drives self-organization, and it can be hierarchical with many layers such as in multicellular biology. Reductionism fails at first base because not even all the layers are known.

An Emergent Block Size Limit for Bitcoin

Using the four-part graphic above we can consider (A) to be the population of Bitcoin full nodes. Peer-to-peer messaging interaction is described by (B). Flexibility over the handling of the block sizes, created by BUIP001 (or similar software), gives rise to an emergent construct (C), a block size limit. Finally the top-down feedback in (D) is a single block size limit becoming simultaneously effective across all participating nodes in the network.

BUIP001 has user-defined settings.

If the node is non-mining or a hasher then only the Excessive Block Size (EB) and Acceptance Depth (AD) values are important to set. EB is the largest block size the node owner is comfortable about handling. AD is the depth necessary for an excessive block to be buried before it is accepted by the node. Being dogmatic is unnecessary as AD reflects a point in a range of the flexibility of a user’s opinion. Existing Bitcoin Core behavior can be replicated by EB=1, AD=999999.

If the node is solo-mining or a pool operator then the Maximum Generate Size (MG) is also used to limit the size of blocks which will be created. In a healthy bitcoin network, where most miners and nodes are participating in emergent consensus, then miners will set their MG value to be less than their EB value.

Example: Node X is one of many Bitcoin nodes observing these rules:

Fig 3. A Bitcoin full node with rules for the block size limit receives an excessive block

The owner of node X has set their EB=4 and AD=3.

Block 1 is the current chain-tip with most proof-of-work. Block 2 is mined with the size of 6MB so this block is put “on probation” by node X. It is validated, but not propagated, and won’t be until there are 3 blocks built on top of it, reaching the acceptance depth. In the example, a further block is mined but this also has delayed acceptance. Node X is temporarily not participating in the network for block handling.

Fig 4. Alternate paths to resolving the case of an excessive block

The excessive block situation can play out in two ways, it gets accepted or rejected (orphaned) by the network.

At left, more blocks are added after the excessive block until the AD threshold for node X is reached . When block 5 arrives node X propagates blocks 2 through 5 normally. In this scenario the majority of the network has EB>=6 and node X is being too conservative. This user needs to consider upgrading hardware and updating the settings if their node falls behind too often.

At right, the excessive block is clearly too large for most of the network who, in this example, must have their EB<6 in aggregate. In a healthy network with emergent consensus this scenario is likely only when record-sized blocks are seen, larger than any block mined so far into the Bitcoin blockchain.

A decentralized block size limit is information which transcends the Bitcoin peer-to-peer messaging layer. Using it is future-proofing this important aspect of Bitcoin. An emergent limit is forward-looking, like a market price, as it includes each node owner’s future expectation of their node’s capacity. It will be exciting to see critical mass achieved and Bitcoin’s growth resuming once again at fast pace. It will have fair transaction fees appropriate to a functional block space market, where the block space available is appropriate to the capacity of the full node network.

All other full node implementations are encouraged to incorporate this feature and help to advance Bitcoin further.

General Observations and Questions

User configurable settings for emergent consensus on the block size limit are visible on the sub-version of the client name for non-miners and in the coin-base input script-sig for miners. These formats are detailed in BUIP005.

Growing the block limit slowly and safely

Miners will only incrementally increase the maximum size of mined blocks in accordance with peaks in real-world transaction demand which require it. Two new settings allow miners to co-ordinate block size limit increases: Future Generate Size (FG) and proposed Activation Block Height (ABH) which is published as (ABH - current blockchain height) / 12000 rounded up. Example: /MG2.0/EB3.5/AD4/FG2.5@3/

How will the 1MB be overcome?

The current block limit is universally observed, so it is a one-off problem requiring widespread co-operation. The best approach is for miners to use MG=1, EB=1 and AD=6 for a temporary period. This period ends when the number of blocks mined with these settings reaches a level which the miners feel comfortable with e.g. the 75% set by the Bitcoin Classic developers which is recommended by Haipo Yang of ViaBTC. Miners will also wait to see a majority of the non-mining ecosystem nodes advertising EB values, of which the default setting is EB=16. Once these background requirements are met, the miners can make use of the FG and ABH to create a window for the first block >1MB and a hard-fork will become effective. Obviously the whole Bitcoin community will be observing this and Bitcoin businesses of all types are strongly encouraged to upgrade their nodes in advance.

What is the story with BIP109?

The Bitcoin Classic developers implemented BIP109 which has a 2MB fixed limit, which Bitcoin Unlimited also supported for the purpose of overcoming the inertia to change present in the 1MB. However, BIP109 also introduces further universal limits. These are on SIGOPS and SIGHASH due to a potential attack threat of quadratic overhead in block validation. Yet, these new limits are themselves problematic for long-term on-chain scaling. Instead, parallel block validation* is a far more elegant solution which makes Bitcoin nodes immune from hard-to-validate block attacks, and this is currently being tested by Bitcoin Unlimited, in the meantime the existing Bitcoin Core SIGOPS limits are being observed.

* To be detailed in an upcoming article

How are Sybil nodes handled?

Sybil nodes are run by an attacker attempting to skew the behavior of a population of honest or “real” nodes. Normally they are low-cost and have minimal participation in the network, only interacting to cause overhead and nuisance. In the case of emergent consensus sybil nodes fail to have an impact because the attacker cannot magnify his or her economic footprint in the global Bitcoin ecosystem. No one cares if sybil nodes pretend to handle very large blocks as each real node has its own limit for block acceptance. If sybil nodes send large blocks to real nodes then those blocks will likely wait pending propagation until they have met acceptance depth. That won’t happen unless miners are building on the large blocks, which they won’t do because they have an increased orphaning risk building on a block which is likely to be over the EB size of most other real nodes.

How do non-miners affect the emergent block size limit?

Non-miners reflect a cross-section of the whole Bitcoin ecosystem and represent the economic majority. They create a ceiling for the emergent i.e. decentralized block limit. Where miner MG levels are below the majority non-mining EB levels then block sizes reflect just the supply/demand fee-market equation for block space. It is quite possible that demand will climb such that MG levels impinge on the non-miner EB levels. In this situation miners will receive push-back on block sizes as the non-mining nodes will be actively selecting for smaller blocks. The emergent block limit will then be profoundly influenced by the capacity of the non-mining nodes. If 51% of the miners persist on building on larger and larger blocks then this is simply another manifestation of the age-old 51% attack which Nakamoto consensus never pretends to solve. In practice a sustained sequence of larger blocks than the ecosystem wants will negatively affect the BTC market price, and miner profitability. Eight years of experience has shown that miner and non-miner financial interests are tightly bound and will remain so for as long as bitcoin currency units have value.

Why are most non-miner settings currently left at the defaults?

Critical mass is not yet present for a decentralized block size limit to become emergent. So, it is to be expected that users will not yet fine-tune their settings to suit their personal circumstances. In the future, for users who are unsure what settings are best, there will likely to be websites providing advice based upon hardware specifications supplied.

Further reading:

Emergence Nova ScienceNOW

http://www.pbs.org/wgbh/nova/nature/emergence.html

Types and Forms of Emergence by Jochen Fromm

https://arxiv.org/pdf/nlin/0506028.pdf