An overview of Bitcoin Cash consensus upgrade schedule possibilities, and a recommendation

Current Situation

Since November 2017, Bitcoin Cash has persisted on a schedule where consensus rules are changed every six months, once in May and once in November every year. This schedule was enforced by a mechanism called "Automatic Replay Protection" (ARP) a.k.a. "the poison pill" in the formerly popular full node client, Bitcoin ABC. At the upgrade date, any node that has not been upgraded and has the poison pill code will silently split to a new chain through a mechanism called forkID. Self-poisoned mining nodes would silently stop mining on BCH and start mining a new chain that no one has any intention of using. Non-mining nodes would similarly start silently accepting transactions incompatible with the BCH chain. Expiration is postponed every six months, by pushing the date forward in a new major release. As a consequence, every six months users face a choice: Upgrade to the new version and adopt new consensus rules; do nothing and automatically follow a chain, if mined, that is incompatible with the entire ecosystem; or edit the code and recompile, in order to persist on current consensus rules.

Bitcoin Cash Node (BCHN) inherited the higher level idea of this mechanism, but changed it to a user-configurable simple warning and shutdown to prevent accidental loss to mining pools and exchanges. On May 15th 2021, we will once again have a mandatory scheduled upgrade at least for the BCHN client, and we have a choice to make: Where do we take it from here?

Problem Statement

The periodic expiration mechanism, whether implemented punitively as seen in Bitcoin ABC or in a more straightforward fashion as seen in BCHN, has so far succeeded in its low-level intended effect. Every six months, almost all actively used nodes have changed their consensus rules, be it following the majority or splitting off with separate consensus rules. Almost no economic activity has followed the "old" consensus through any of the upgrades.

The higher level impact on the ecosystem, though, has been a mixed bag.

On a practical level, having to adapt to changing clients and consensus rules every six months have been a significant burden for services and merchants looking to adopt BCH as a usable medium of exchange. Exchanges such as Coinbase, service integrators such as Bitcoin.com as well as software developers have voiced concerns that a six month schedule imposed a high cost of operations.

More importantly, every upgrade introduces a focal point of vulnerability, where it is possible for differing opinions to become wedge issues that result in irreconcilable splits , greatly lowering network effect at worst, stalling progress and lowering reputation of BCH at best. In theory, longer periods of research, analysis and presentation beyond the six-month cycle should have been able to converge stakeholders towards one set of consensus upgrades. However, in practice, the community only pays attention to the next set of changes after doing the work from last one, and not nearly enough time has been spent on consensus building. This presented opportunities for influential figures to attempt ramming through their favorite changes without considering costs, both economic and social, to the wider ecosystem. As the community moved from one crisis to the next punctuated at six month intervals, even the more baseline testing and analysis were not performed adequately, not to mention consensus-building efforts that are essential to having a majority in a decentralized network agree or reject changes in an informed way.

The results can be seen through the most prominent splits over the past three years, the BSV fork siphoning significant value from the chain, while the ABC fork stalled adoption and damaged the chain's reputation. Even for upgrades without a significant split, major bugs have been introduced through ill-tested changes, resulting in loss of function that is unacceptable for a major cryptocurrency.

While it may be convenient to blame specific groups of actors for these woes, there is much room for improvement in the schedule and process themselves, so that they are less vulnerable and more confidence-inspiring in the future. A better schedule that allows for more research and consensus building ensures that even in the worst case, the community and chain can steer away from the chaotic scrambles we have seen in the past.

Considerations

While the downsides of scheduled upgrades seem quite apparent, we must not ignore its benefits. To achieve its goal as peer-to-peer electronic cash for the world, Bitcoin Cash still has at least a few functional and scalability changes ahead of it that require significant development work. Without scheduled upgrades and corresponding expiration as enforcement, even uncontroversial upgrades can face significant hurdles to adoption, especially among exchanges who are apathetic about Bitcoin Cash. While protocol ossification can be a good thing for stability at high adoption, without a sensible path to useful upgrades, usecases that are necessary for adoption may be bottlenecked on the way. Even if no consensus changes are adopted during any given period, the path to upgrades must be left open by process and precedents.

To balance between the needs for stability and beneficial upgrades, it seems wise to at least relax the existing six month schedule, so there is more time for research, consensus-building, and testing.

Possible Alternatives to the 6-month upgrade cycle

One-year cycle

Description: Existing expiration mechanism is kept as-is, but the cycle is extended to 1-year after May. Upgrade dates are May 2021, May 2022, May 2023 and so on.

Benefits:

1. Most conservative extension possible, easy to understand and converge on.

2. Expiration mechanism will still ensure inertia isn't a major factor when upgrade date comes.

3. One year should allow for significantly more time to debate, research and build consensus than six months. Note that hard forks intervals are on average longer than one year even on Ethereum, a chain much more experiment-friendly and has more resources than BCH.

Costs:

1. One year is a long time in crypto, there may be parties with specific needs who would like their features in sooner.

2. While a one year cycle should allow significantly more time for research and consensus building, controversies can still arise. It must be noted that having a schedule does not equal having proper decisionmaking processes, which is a separate pressing issue not explored in this writeup. At the very least, proposals for an upgrade should publicly make it to various milestones along the cycle, with expectation that it can be rejected by the community at any point.

Various longer cycles (18 months, 2 years, 4 years...)

Description: Same as the above, but extend the cycles even longer. Some very long cycles seek to mimic political cycles in modern democracies.

Benefits:

1. Longer cycles allow even more time for research and consensus-building to play out.

2. Long cycles can minimize time spent in periods of uncertainty, inspiring confidence for businesses and investors who seek stable foundations for their enterprise.

Costs:

1. Technology in cryptocurrency moves rather quickly. While its larger sibling BTC can spend multiple years debating even less consequential upgrades like Taproot, BCH does not have the luxury of expecting existing network effect to carry it through very long periods of time. If necessary usecase and scability improvements are delayed for too long, the chain can lose its competitive advantages and become irrelevant.

2. Over a longer time, the infrastructure, processes and social will necessary to even evaluate new proposals will likely deteriorate.

3. If even uncontroversial upgrades are subjected to a multiyear wait before activation, the long schedule may paradoxically cause damaging community and network splits.

No schedule

Description: Remove the expiration mechanism altogether from all clients, and substitute with a yet-undefined process of consensus building that culminates in an upgrade date "when it's ready".

Benefits:

1. Given a sufficiently convincing process, may be the best way forward. Proposals would not be subject to undue "make it or wait another year" deadlines, and can proceed at an optimal pace in research, implementation and consensus-building.

2. Default mode of operation for some of the biggest coins like BTC and ETH.

Costs:

1. We do not have a fully convincing process to decide when to "seal the deal" on any upgrade yet. While many parties in BCH including BCHN are committed to developing a long-term solution to decisionmaking, no mature and robust process exists right now. Proposals of miner voting, stakevoting and other decisionmaking schemes of various sophistication abound, each with glaring pitfalls and tradeoffs that need time to be worked out. None are likely to be available in a sufficiently convincing manner for May 2021, before which a decision will need to be made.

2. Without a robust process, going no-schedule in a decentralized landscape can easily stall uncontroversial and beneficial upgrades indefinitely, resulting in similar or worse woes as a long cycle. It will also be impossible to set expectations on progress for any given proposal, making conflict over how "ready" a proposal is more controversial. Having a defined schedule to evaluate proposals makes worst-case long-term stagnation less likely while better processes are being researched and refined.

Recommendation: One year cycle

While each of the above has its benefits and costs, I recommend going with the simple one-year cycle.

Going no-schedule may be an appealing idea to many, and it will likely become quite attractive to me as well once we have a robust decisionmaking process in place. For now, however, the twin risks of stagnation and controversy are simply too great for a network looking to regain its standing.

Between one year and much longer cycles, the benefit of a minimal one-year change can be seen as a matter of balancing. While the drawbacks of a short six month cycle is apparent by now, we should not ignore that it did also bring us some beneficial upgrade items in time, such as Checkdatasig and ASERT DAA. Extended to a year, the schedule should allow reasonably ample time to research, implement and build consensus for each upgrade, while investors and developers can still look forward to a close horizon for new features and scaling improvements.

Intra-cycle milestones

Between each upgrade, it is important for consensus change proposals to follow certain milestones to maximize chances for orderly inclusion or rejection.

Unless faced with extraordinary circumestances, missing them should result in the proposal being rejected for the next upgrade.

One possible setup is:

May 15th: Previous upgrade activation day. Proposals for next cycle should already be under work and/or circulated.

July 15th: Proposals for the next upgrade should be published by this date, complete with draft-BIP style technical description, economic cost/benefit analysis and preliminary surveys among prominent stakeholders in the ecosystem.

September 15th: For proposals that were published and did not result in major controversies, functional implementations from at least one full node client should be available by this date. After this date, the implementation should then be subject to testing on a separate testnet fork, evaluating impact on popular applications and services. Technical reports from tests should be published and circulated among major ecosystem actors for feedback during evaluation.

Proposals that face strong opposition from prominent businesses, stakeholders, miners or face significant, high-level technical difficulties should not be considered for November lock-in, but instead seek to alleviate concerns in time for the cycle after. Note that a given proposal MUST have spent reasonable effort in actively contacting major ecosystem actors when evaluating reception, instead of assuming consent from parties who did not respond to broadcast publications.

November 15th "tentative lock-in": If the one-client implementation of said change is sufficiently evaluated and still did not raise major controversies or inadequacies, by this date there should be more than one full node team that implements the change. Specification for the change should be finalized by this date as well. Node teams should begin to produce production-ready releases for their users to upgrade early. Wider testing commences, applications are encouraged to start developing for the new features on upgrade testnet.

Note that proposals who made it to November 15th should be considered tentatively locked in for implementation across the ecosystem.

February 15th "lock-in": If no major bugs or emergencies were found during wider testing, all full node implementations are expected to deliver a compatible production release by this date, or cease to be recommended for BCH. Stronger push for upgrade throughout the ecosystem.

May 15th: New upgrade activation date.

Expectations on no-op "upgrade days"

A regularly scheduled upgrade, and enforcing expiration mechanisms, are merely convenient Schelling points to have orderly consensus changes. They MUST NOT be seen as mandates for having at least some consensus changes, and indeed simple extensions of the expiration mechanism without consensus change, leaving upgrades to the next cycle, should be an acceptable outcome for any given cycle if no proposal can get wide agreement and robust testing by the aforementioned milestones.

Recommendation for May 2021

If a one-year cycle is adopted, May 2021 becomes a special case as it is a much shorter cycle than subsequent ones. While there are uncontroversial ideas such as longer integers, along with some more controversial plans, no proposal is even close to gaining sufficient rigor in specification, wide implementation, testing and consensus-building. It may be tempting to incorporate less controversial consensus changes for this cycle only, to get their benefits before a rigorous, longer upgrade cycle truly begins. I will strongly recommend against that act, though, as BCH desperately needs to regain a semblance of stability, and making exceptions out of a process before it begins does not inspire confidence. In contrast, establishing a no-op "upgrade cycle" reduces future pressure to rush unfinished proposals for the sake of having some change for an upgrade.

As such, I recommend that BCH do not implement any consensus changes for May 2021.

There are nonconsensus changes, such as longer unconfirmed mempool chains, that need coordination but may not require as stringent a process, as they cannot result in a chain split. This recommendation should not be seen as a discouragement towards implementing them this May.

Future changes

As mentioned, it is quite possible that we can eventually converge on a much more robust decisionmaking process than scheduled upgrades, and indeed some are being actively explored even now. When such a process emerges, it should be subject to the same schedule, milestones and rigor as other proposals, and upon activation the existing schedule is abolished in favor of the new process.

Thanks for reading! I also created a discussion thread here: https://bitcoincashresearch.org/t/an-overview-of-bitcoin-cash-consensus-upgrade-schedule-possibilities-and-a-recommendation/235

Edit: Typos and formatting oddities