Title: Block Growth
Type: Process
Layer: Coordination
Maintainer: Tom Zander
Status: Draft
Initial Publication Date: 2023-01-04
Latest Revision Date: 2023-01-06
Version: 0.1

Latest CHIP version: https://codeberg.org/bitcoincash/CHIP-Block-Growth

Summary

We propose a process and coordination method that can be used to continue the growth of Bitcoin Cash in a decentralized and permissionless manner.

The growth of the blocksize can be an open market property with a small amount of coordination and communication. The goal is to avoid any central control or choke-points in Bitcoin Cash.

Deployment

This proposal does not require deployment.

Motivation

Probably the best feature of Bitcoin, as Satoshi saw it, is the elegant balance of power between the different groups. From software developers to holders to merchants and miners, each has its role to play and none is the boss over any other.

The Bitcoin Core (BTC) system has famously been captured with one specific property that had been moved from the bigger ecosystem to now be under the control of the software developers. The block size has been set to not be allowed to become larger without software developers permission. The entire system there has since become rather toxic and their failure is a really the core motivation for this CHIP. To avoid similar misalignment of priorities and subsequent capture on our chain.

The author of this CHIP means for this proposal to also show the world Bitcoin Cash already moved the blocksize limit out of control of the software developers. It makes sense to explain in practical terms how Bitcoin Cash can keep growing safely in a decentralized and permissionless way according to market needs based on market capacity.

Benefits

In our proposal there are two properties that we use to signal and coordinate. The proposal describes how different actors in our ecosystem can use those two properties to accomplish our goals, as described in the motivation section.

1. The blocksize-accept-limit.
   This is a technical property, meant to indicate the technical abilities of anyone parsing blocks in the Bitcoin Cash space. The property indicates the maximum blocksize this specific party, software or exchange is tested to parse and process without problems. It is known in full nodes as excessive-block (EB).

2. The max-blocksize.
   This property is only used by miners or mining pools. This property is set by them to indicate the maximum size of the blocks they will produce.
   The maximum size any individual miner or pool creates is directly linked to the capacity of the Bitcoin Cash chain and as such there is a distinct economical element to this property related to the supply of blockspace.

By contrast there is the 'effective blocksize'. Any individual block may be smaller than the max-blocksize of miners simply because at the time there were not enough transactions to put in it. After this clarification we won't mention the effective blocksize again.

Those two properties are both talking about a blocksize. Both in bytes. They appear very similar, but they are in fact used for very distinct and different ideas and purposes. The blocksize-accept-limit is distinctly more technical in nature because it indicates what any individual is capable and willing to accept from some miner on the network. As software and hardware gets more capable, this number will go up.

The blocksize-accept-limit is expected to be far ahead of the curve, which means that our systems have over-capacity. This is useful because it allows the miners to increase their max-blocksize when there is more demand for blockspace without fear. This proposal goes into details how we can accomplish that below.

What are the issues

To understand if a solution is a good one, we first need to understand the problem we are facing.

There are 3 scenarios that cause damage and should be avoided;

1. Orphans
   A miner that mines a valid block, except that it exceeds the blocksize-accept-limits of the network and they get their block orphaned.

2. Chain Split
   When there is enough hashpower that is confused we can see two factions appear. One that extends the chain on the bigger block, and one that rejected the bigger block and mines a different chain.

3. Big Block mining attack
   When blocks are being mined that are accepted by all miners, but are so large and full of generated transactions that it hurts the wider ecosystem.

In this proposal we will lay out the basic concept of the blocksize-accept-limit and the max blocksize properties and how they can be used to avoid all these scenarios.

Outer Limit

What is the networks technical support.

The outer limit of growth is set by the capabilities of all the the technical support systems there are. Open source products like full nodes have been tested and set a specific blocksize-accept-limit that the developers feel is safe and stable to grow to on their product, and their product alone.

The blocksize-accept-limit are chosen by developers for their product in test operations. The point is that the developers know their product on normal hardware can support that size in the various scenarios. The limits are what their specific software allows, with only their software as far as it can be tested stand-alone.

Different infrastructure teams will then reach different conclusions on what their specific blocksize-accept-limit is. This depends on which software they run, which hardware they have deployed and similar practical considerations.

The outer limit is thus a bitcoin-cash wide view of all the important players. From supporting software to exchanges and major payment processors.

The outer limits are shown in the above image as the outer semi-circle. It is not smooth because different players have different blocksize-accept-limits. If we take all the important players we can thus get the smallest limit and we can call that the "Network accept size". This indicates the maximum block size that the ecosystem at large comfortable accepting.

At the point it may be asked, how do we know if we incorporated all the different parties, exchanges and block explorers into this whole? Is it possible we end up over-estimating the Network accept size at some point? To answer that we need to understand this proposal is not a set of hard rules, there are no absolutely correct or wrong answers.
With that in mind, the real question we need to ask is when do we have a good enough overview of what is supported?

You can see the parallels with the CHIP process itself, we also don't get a perfect score on buy-in on protocol changes. Should someone fail to upgrade long enough and his full node rejects the chain, they can just upgrade after the fact with no negative consequences to anyone else.

Max blocksize

Individual miners set a max-blocksize on their mining setup. This is the biggest size block they are willing to create given the transactions available in the mempool.

Miners have the market incentive to find the ideal block size for their mining setup, it is the purpose of this proposal to give those miners the required information on what is a safe maximum blocksize. The safe maximum blocksize is to stay under the "Network accept size" (described in the previous section) because going over that size is going to trigger issue one or even two.

It is thus important for a miner to know the network accept size, and keep the max-blocksize below that limit.

Given that basic rule, to stay below the network accept size, miners are free to pick their max-blocksize based on what works for them. It is safe for one miner to mine 10MB blocks while another mines 20MB blocks. They will not orphan each other based on any limits set by the miners.

Communication of the blocksize-accept-limit

In early 2023 the Bitcoin Cash network is generally understood to have an outer-limit of 32MB. Not all implementations actually are capable of that, though. Some have significantly higher and others have lower blocksize-accept-limits.

In order to keep things decentralized and permissionless, we propose to make the individual limits public and the responsibility of the individual products and teams.

As a thought-experiment of why this is the best strategy, consider maybe one block-explorer that refuses to upgrade from a raspberry Pi and has a throughput problem and thus opens a ticket with the biggest implementation imploring them to not increase the outer limit.
If that full node implementation accepts the plea and keeps the limits low while its actual throughput is much higher, you have re-introduced a central point of control. Unless the market works around that central control, decision on limits are moved to individuals, capture commences and societies collapse.

Instead, making each individual implementation of critical software advertise its limits to the world at large allows the market to pick the ones that provide them the best value. And likely the singular block-explorer will be forced to get new hardware in order to not hold back the entire industry.

To make this strategy work, the industry needs to find a way to communicate the blocksize-accept-limits of all the important players. We already have the full nodes that are reachable from the Internet, they advertise their accept-limits in their connection string. "EB32" for instance.

Miners can include a statement in the coinbase. Add a var-int after the blockheight (bip34) with their blocksize-accept-limit, for instance.

Exchanges, merchants and block-explorers are very likely just going to be restrained by the full node software they use. But in general it may be useful for them to create a blocksize-accept-limit status commit on their AuthChain.

Rule of thumb here is that if miners have access to full nodes accepting bigger blocks, then so does the bigger ecosystem. It then becomes a question of gathering information for individual miners and decide what is best for them and Bitcoin Cash.

Products that support the network, like indexers and REST APIs would do well to be ahead of what full nodes can handle. Have bigger tested-to-work blocksize-accept-limits than common used full nodes. Yet, it is a very good idea for them to start advertising in their release notes or on their web presence what their actually tested value is. After all, if we have a growing industry then this value is likely going to become a selection criterea on what software people are willing to build their products on top of.

Understanding deployments

Our graph on the outer limits above was simplified for understanding. In real life we'll likely see multiple versions of the same software being deployed on the network. With possibly different blocksize-accept-limits.

What this means is that the month a product releases with a much improved blocksize-accept-limit, that doesn't move the outer limit. Because the outerlimit is set by what people are actually running on the network. Only when people deployed the improved software will that new blocksize-accept-limit actually become the new outer limit.

Now imagine it is not just about one full node product, there are a dozen products which makes considering the slowness of deployments relevant. We expect that the yearly mandatory upgrades will eventually slow down and that makes the deployment cycle slower too.

We also expect that even after the mandatory upgrades slow down, a couple of years later voluntary upgrades will likely speed up little again. Not because of more protocol updates, but because of performance and blocksize-accept improvements.

Taking these issues into account it is expected that between a software product release and the first possible miner going over its limit in a natural organic way, we will have a adjustment period of about 2 years. If the market becomes constrained (grows faster) then social channels and coordination can certainly speed up that cycle.

Conclusions

When miners, full nodes and other players are very far ahead of the curve, accepting much bigger blocks than are being produced, we can grow the block size without issues.

To keep this state and not get worried about unknowns, those miners and exchanges can make clear what size blocks they accept. So when some miners decide its time to increase the maximum blocksize, they can be certain the rest of the Bitcoin Cashers will accept it just fine.

The game of increasing the accept limit on full nodes and other software while miners increase the blocksize is going to be on-going. It will always keep on growing on both sides. As long as Bitcoin Cash remains growing and successful.
The expectation is that there will always be a very large gap between what software can handle and what miners want to produce. Overcapacity is key to a stable network.