[DRAFT v.4] Executive Summary: Adaptive Block Size Limit Algorithm for Bitcoin Cash
Abstract: By employing an Adaptive Block Size Limit Algorithm, Bitcoin Cash will be able to reach its stated goal of becoming a global, peer-to-peer currency, with always-low fees and next-block transaction inclusion to the best degree possible, without requiring any further developer or user intervention to increase block size limits, and while protecting essential network decentralization and stability.
Background
Since the creation of Bitcoin, the block size limit has remained one of the most difficult and controversial unsolved problems. At least one Bitcoin version has demonstrated that some limit is necessary in order to prevent centralising flood attacks on the network; while other Bitcoin versions have demonstrated that the limit itself can become an attack vector if enough participants refuse to change it. Satoshi himself left very little information about the limit, stating only that he would increase it when necessary.
Since consensus rules govern and determine the expected long term behaviour of the system, we can say that consensus rules represent a kind of social contract between the developers and participants of the system. For example, the "21M coin limit" is social contract that effectively binds users together around a common agreement that the system will always maintain a specific inflation rate. It is therefore important that a coin's consensus rules reflect the intended long term goals of the project as closely as possible.
Bitcoin Cash seeks to carry on the original intent of the Bitcoin project of becoming peer-to-peer cash for the world, where any two participants can transact with no need of an intermediary (ie. onchain). Key to this goal is that BCH maintain always-low fees and next-block transaction inclusion insofar as possible. As such, it is clear that blocks must be allowed to become larger and larger over time, as more and more people use the system.
Problem
Unfortunately, BCH's current, static block size limit does not do a good job of reflecting its social contract, because a static limit implies that blocks will never be allowed to become larger than the limit. While Bitcoin Cash has performed a successful increase of the static block size limit, we have also learned that doing so requires a tremendous amount of coordination, and each time the limit is raised we incur the risk of a possible chain split. The amount of coordination, and the risks inherent in upgrading, will only become worse over time.
In order to align Bitcoin Cash's block size limit with the stated goals of the BCH project (and indeed the Bitcoin white paper) it is therefore necessary to move from a static limit to one that will automatically adjust upward over time. By deploying an automatically adjusting block size limit, Bitcoin Cash establishes a social contract among existing participants and new entrants to the system that guarantees, to the best degree possible, the block size limit will permit always low fees and next-block inclusion, while still providing the needed safeguards against denial-of-service and flood attacks.
Solution
Bitcoin Cash will institute a block size limit that will automatically adjust upward over time as demand warrants, with no intervention from users or developers. The block size limit will be calculated algorithmically based on actual usage. As usage increases, the algorithm will raise the block size limit accordingly. The rate of change will be damped by the algorithm to prevent large, unexpected, or discontinuous changes that could disrupt the network. By limiting the rate of change, the algorithm also guarantees that the increase in the block size limit can never exceed an absolute "worst case" maximum of 4X in the first year decreasing to 2X year-over-year, even under a sustained spam attack by 100% of network hashrate. Furthermore, the existing 32MB "standby capacity" will be set as the guaranteed minimum block size limit allowed by the algorithm.
Benefits
This design offers the following protections and benefits:
- It eliminates the "fork vector" caused by participants who refuse to upgrade when needed (as with a static limit). As there is no longer a need for the user to upgrade or change any software settings in order to accept larger blocks, their consent to the increase in the block size limit is implicit in the software.
- It ensures that the limit cannot be gamed excessively downward by participants who seek to artificially limit the network (via the 32MB "standby capacity" limit)
- It guarantees that the limit will not experience sudden, unpredictable jumps upward (or downward) which could come as a shock to existing participants
- It prevents the limit from being gamed upward by participants who seek to flood other peers off the network
Full specification: https://gitlab.com/0353F40E/ebaa/
