This is a semi-stable draft of a high-level summary regarding the proposed Adaptive Block Size Limit Algorithm. The latest version is maintained here and is still undergoing minor tweaks.

Bitcoin Cash is extremely fortunate to have /u/bitcoincashautist spearheading this effort.
/u/bitcoincashautist has tirelessly iterated design after design, patiently worked with stakeholders to solicit feedback, remained stoically calm in the face of sometimes-withering confrontation, and held true to the goal of resolving this much needed improvement.

This Executive Summary seeks to explain:

1. Why a limit is needed
2. Why a static limit is inconsistent with BCH's stated goals
3. The benefits and protections offered by the proposed algorithmic limiter

I would sincerely ask all proponents of Bitcoin: a Peer-to-Peer Electronic Cash System to study the proposal in full, giving special attention to the various simulations and security considerations. While it is impossible to design a perfect algorithm, it is hard to imagine an algorithmic solution to our common problem that has been more deeply steelmanned. I urge everyone to give their gratitude and support to /u/bitcoincashautist for the immense effort that has been put into this excellent proposal.

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 limited 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 block size limit can never exceed a "worst case" maximum, even under a sustained spam attack by a miner with access to 50% 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:

1. 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.
2. 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)
3. It guarantees that the limit will not experience sudden, unpredictable jumps upward (or downward) which could come as a shock to existing participants
4. It prevents the limit from being gamed upward by participants who seek to flood other peers off the network (since doing so would require many years of sustained full-capacity spam attack by a miner with near control of the network)

By employing an Adaptive Block Size Limit Algorithm, Bitcoin Cash will align its block size limit with its stated goals of always-low fees and next-block transaction inclusion to the best degree possible, while preserving network decentralization and stability.