# CHIP-blockGrowth: Ensuring safe permissionless block growth

    Title: Block Growth
    Type: Process
    Layer: Coordination
    Maintainer: Tom Zander
    Status: Activated
    Initial Publication Date: 2023-01-04
    Latest Revision Date: 2024-05-15
    Version: 0.2

<details>

<summary><strong>Table of Contents</strong></summary>

- [Summary](#summary)
- [Deployment](#deployment)
- [Motivation](#motivation)
- [Benefits](#benefits)
- [Feedback & Reviews](#feedback--reviews)
- [Changelog](#changelog)
- [Copyright](#copyright)

</details>

## 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**.

<img src="network-state.png" width="455" height="200" />

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](#what-are-the-issues) 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](https://flowee.org/docs/spec/forks/bip-0034/)) 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](https://github.com/bitjson/chip-bcmr).

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 hits it doesn't move the outer limit just because it has a much improved blocksize-accept-limit. This is 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 realize it is not just about a full node product, there are a dozen products that are relevant for the capabilities of a stakeholder. This 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. Some companies may not replace software for years.

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.

This purpose of this proposal is to give the miners enough information to avoid building a block bigger than is accepted. If all miners follow this proposal, no splits or size-based orphans will happen.  
The traditional way of lowering risk in the mining community has been to make sure they all run the same software with the same settings. This has always been the practice, there is little reason to think this will change. The result of this behavior is that all miners will upgrade to a new release of their full node software shortly after it comes out, and thus largely synchronize their *blocksize-accept-limits*.

The deployment of a new *blocksize-accept-limit* throughout the rest of the ecosystem is typically going to take much longer and informing the miners about this state is in practice going to be the main focus of our proposal.

### Out of scope: actual coordination

Several ideas were given on how signaling can happen in this *process* proposal. We also have some actual products already available in open source form. The [BMP](https://bitcoincashresearch.org/t/746) project requires special mention here.

Coordination and communication are best to be decided by actual people doing it and creating the tools they deem worth while. To the author it does not make sense to try to solve this in a 'design-by-committee' manner. As such this kind of efforts are out of scope for this CHIP.

It is instead my hope that the general idea and concepts become shared and from this common idea we can work towards actually implementing this practice.

### Special mention on issue 3

What has not really gotten addressed is [issue](#what-are-the-issues) 3. "**Big Block mining attack**".

This is a bit of a special case because of the situation that Bitcoin Cash is in at the beginning of 2023. It is a minority chain and in many respects the ecosystem is small and fragile.
Should the BTC network tomorrow have a 100MB block limit, the chance of that network being attacked with multiple 100MB blocks is hardly imaginable. The cost to attack this way is simply too great. The main reason for Bitcoin Cash being different is because the cost to mine a single block is much lower.

If all this CHIP is going to be useful, we'll see natural growth towards 32MB and larger blocks on Bitcoin Cash. And it is fully expected that this will see a natural rise in price of the coin as well. We know that hashpower follows price and that means with higher price the cost to mine a single block goes up significantly as well.

It is thus fully expected that in due time a big block mining attack is simply no longer an issue. Basic network effect will have made it too expensive to execute.

## Activation of coordination algorithm

A specific coordination for the outer-limits has been added in the 2024-05-15 upgrade of Bitcoin Cash. Based on miners specified max blocksize, expressed as mined blocks, an algorithm was crafted to set the outer-limits.

This is a non-consensus change, as blocksizes have not been part of the consensus since August 2017. As such should the algorithm become a problem (too low growth) to stop using this is likewise not a consensus rule-change. It is, however, a coordination event for ecosystem participants running a full node.

## Changelog
## Copyright

Copyright (C) 2022-2024 Tom Zander

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.