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

11 761
Avatar for im_uname
2 years ago

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


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.


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.


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.


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.


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".


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.


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:

Edit: Typos and formatting oddities

$ 18.07
$ 5.23 from @TheRandomRewarder
$ 2.49 from @BitcoinBCH
$ 2.00 from @btcfork
+ 16
Avatar for im_uname
2 years ago


One year might be better but let’s be sure to pack twice as much work into that as the last thing we need is to fall behind. Technology matters and more than ever we need to create contrast vis a vis LTC with our improving tech.

Longer cycles are unthinkable.

$ 0.00
2 years ago

Great article and very thoughtful effort. I totally agree there is a serious need for a decision-making process. I am not sure a good one is possible on a sufficiently-decentralized project that has fake community members pretending their concerns are genuinely based on a desire to support the dream of BCH (Bitcoin). That's another topic at this point.

As I believe the anti-BCH forces push for delays like this (a 1.5 year beginning wait followed by 1 year waits) I am not excited about the over-all effect. I think there is an underlying assumption built into this article that shorter time-spans are the reason for failures to do proper code-related work and community consensus building before implementing code in an upgrade. I would say it may have influenced those issues, but was not the real reason. You don't need a 1 year or longer upgrade schedule to make each change spend that much time getting properly processed if you think they need that much time. What I am saying is you could keep the 6 month upgrade option available, but not use it unless a new change is ready. I would argue some changes would not need the full timeline you suggest anyway, but that is another thing to discuss by others who know better than me. As a compromise idea maybe the poison-pill could be switched to yearly, but the option of 6 month upgrades in between kept on the table in case a great idea is very ready.

I have a feeling the real reason for failures to do proper code-related work before upgrades has been due to a combination of a perceived need for speed and a lack of developer resources dedicated to doing the proper work in a timely fashion. Because I believe the need for speed is real as pointed out in this article, I am concerned this proposal suggests we plan on continuing to do the development work slowly and just take longer to get important work done. This does not allow for the possibility of well-funded development projects getting done properly and quickly (which I believe we need). I hope we do not plan guaranteed delays into our upgrade schedule in case they are not needed to get the same results this article hopes for more quickly.

$ 0.00
2 years ago

my own 'crazy' suggestion...

Utilise scarcity: Informally agree to only 8 [or other arbitrary number] more hard forks ever. Leave open when or what they specifically are. Each one that is used makes the remaining ones more valuable, hence hard forks will happen decreasingly often and require increasingly stringent justification and consensus.

$ 0.00
2 years ago

Must of the people who write about BCH are the more paid people I don't really know about BCH that well but I have learned a lot from this article of your

$ 0.00
2 years ago

BCH lost some high-end merchants I deal with because the fork train-wrecked their systems.
Perhaps part of that were local issues/prejudices but such should not be often refuelled.

  • We need a solution that never inflicts more than one hard-fork a year unless absolutely urgent.

$ 0.00
2 years ago

This proposal will go through the process too, right

$ 0.00
2 years ago

Unfortunately, you might notice there is a hard cutoff date for some process to be in place after May 2021, else we'll descend into either balkanized chaos or centralized dictatorship, neither of which are very desirable. So no, this (or any modified version of it) will have to be expedited and cannot go through a yearlong research/testing/consensus-building/long-preparation process.

$ 0.00
2 years ago

I agree with this logic, but I think there will also be future issues with similar necessity for bypassing an intentionally slow process. I do not disagree some changes should take the full time you are suggesting.

$ 0.00
2 years ago

else we'll descend into either balkanized chaos or centralized dictatorship

I would not jump to such drastic conclusions :) Or, simply: making dramatic statements requires you to prove them.

You didn't respond to the invitations to participate in the network discussions which were set up months ago to address exactly the problems your blog talks about. We've had a couple dozen people participate in them so far, including some exchange and even other business stakeholders.

It probably is useful to join the conversation, its open (although I doubt much will happen between now and new years), and you are welcome.

$ 0.00
2 years ago

Is it public?

$ 0.00
2 years ago

Absolutely, easiest to start is here:

$ 0.00
2 years ago

Expedited still seems good enough IMO

$ 0.00
2 years ago

thanks im_u Ye as a business the current schedule was too much to update 6 months, the year sounds good, and should be enough time to debate and reconcile. The default mode would be ideal as business/exchange/user/miner, can just run the standard edition which is set in stone perhaps this is too centralized for BCH as the many node teams may have difference of opinions. The longer the better, as upgrading is just a hassle. 1 year should be next november or something or may 2022 this gives lots of time to sort any issue,

great read sir hope all is well! and i am glad BCHN are in charge and will make BCH cash for the world, although many nations will choose not to see these as actual means of exchange, we must reach such countries national financial sectors to show how effective BCH can be such as USA, Russia, China, and so on.

$ 0.00
2 years ago