Benefits of Bitcoin Cash's 6-monthly hard forks

Since Bitcoin Cash was created, there has been a lot of discussion around the policy of having a 6-monthly hard fork to upgrade the system. Such upgrade hard forks have been taking place on the 15th of May and 15th of November every year, following the creation of Bitcoin Cash on 1 August 2017.

Background: a "hard fork" in this article refers to a mandatory software upgrade for those running fully validating nodes. A hard fork does not imply that the currency persistently splits into two - it only does so if miners keep extending both the old (non-upgraded) and the new (upgraded) chain. In rare cases, there might be sufficient contention that some miners favor extending each of the chains. This has only happened once out of the five past upgrades, when BSV split off because they disagreed about the strategy followed by the majority of the Bitcoin Cash community.

In this post I want to briefly highlight the benefits of having a regular upgrade every 6 months. This isn't to say that I don't see potential drawbacks to it, or that I think it will forever be the optimal schedule, or that I don't want to give the downsides some airtime. Others have already done so in other fora, but I might do so in a separate post or add to this one.
The reason I'll focus first on the the benefits is that I believe they are often given little attention and consequently are not well known to many people.

Benefit #1: the "reminder effect"

What I call a "reminder effect" has several aspects to it.

1. To remind people that there is a voluntary aspect to choosing which rules to follow in Bitcoin. This freedom of choice is best expressed by hard forks rather than soft forks, since following the chain with the new rules requires opt-in, whereas following the current rules requires no action. In a soft fork, following the new rules requires no action, but staying with the old rules requires active opt-out and effectively, creating your own hard fork.
   A hard fork is less coercive, since you have at least the two choices without creating new software: (a) follow the new rules (b) stick with the old rules.
   This makes it harder to propagate consensus rule changes against the will of the majority of users.

2. To create a predictable schedule for system improvements. Now, "improvements" is always subjective, but so far Bitcoin Cash developers have a good track record of moving the protocol forward in terms of both scale and features. A widely agreed system upgrade schedule makes it easier for businesses to plan their own related IT adaptations. It is very easy to remember that at one or two recurring times a year, the protocol software needs to be upgraded. This keeps businesses on the lookout and on their toes a little, practicing and refining the internal procedures associated with upgrades of their Bitcoin Cash infrastructure. As they participate, companies not only gain experience with upgrading - which is a necessary thing if we want Bitcoin Cash to move from being the (currently) smaller relative of the BTC network to being the main infrastructure for the world's financial system. There will be lots more upgrades necessary to reach all of the roadmap's current goals.
   To summarize this point, it is keeping a lifecycle of upgrades which is really "alive" for all participants, giving ample opportunity to build, practise and retain the necessary skills in evolving the system.

Benefit #2: Reducing the complexity of the upgrades

This has a number of benefits of its own, the first of which I already touched on above.

1. It makes the changes easier to survey and follow along, both for businesses and interested individuals. Discussions between the community and developers become more productive as it's harder to miscommunicate if you're discussing a handful of changes rather than a huge set. It is also easier for companies to test integration of a smaller set of changes ahead of the upgrade day.

2. Users become more invested in the changes taking place if is easier for them to track what's happening. This leads to more participation and feedback rather than less, and hopefully in the long term less people "dropping out" because they find the changes too hard to understand and follow along.

3. Issuing fewer protocol changes at once makes it easier for various development teams to coordinate the development and verification. This improves quality and safety, which can suffer when too many things in an already complex system are changed at once.

4. It helps communicating the changes to the wider public (i.e. marketing). The public can't absorb too much at once. Step by step, and make sure the marketers can also have a clear view of where Bitcoin Cash is and where it's going with its next step forward.

Benefit #3: Demonstrate that BCH can upgrade smoothly

Bitcoin Cash has already demonstrated several extremely smooth system upgrades in this way.

There have been some with hiccups, but those two occasions so far have been unavoidable - in both cases attacks on the network:

1. a "hashwar" by a declared adversary that wanted to establish majority control of the protocol evolution by hashpower (threatening deep re-orgs, mining of empty blocks etc). This attack failed and resulted in the splitting off of BSV.

2. a black hat hacker exploiting a flaw without responsible disclosure (handled within the space of a few blocks with only delayed confirmation of a few blocks until nodes were patched)

As the Bitcoin Cash community and hashrate grows, we can expect hashpower-based attacks to subside as they become more difficult and costly. They have already been effectively mitigated for the time being.
Having transactions delayed in the mempool for a few blocks during an upgrade is regrettable, but compares extremely favorable to outages observed routinely on legacy financial systems. Ultimately, increased adoption leading to increased value will contribute here as well , as larger bounties can be offered for responsible disclosure and the pool of developers increases, making more talent available for "firefighting" and also increasing robustness of the system against exploit of node implementations.

Conclusion

The regular hard-fork upgrade schedule helps to prevent lock-in of the protocol such as we've encountered in the "soft-forks only" approach on BTC, where a single implementation (Bitcoin Core) comprises > 96% of all nodes. (Source: https://coin.dance/nodes)

The philosophy of Bitcoin Cash has been from the beginning that having node diversity helps with robustness of the network, and this has been practically demonstrated on at least two occasions. Having more frequent smaller upgrades helps with alignment and decreases the risk of dropout.

Experience of past upgrades on the BCH network demonstrates that some of the tenets propagated by the BTC thought leadership were in fact empirically false. For example, it is not necessary that 100% consensus exists on a set of changes. As long as no dedicated wish exists somewhere to split the chain and create a new currency, a hard fork upgrade will not split the coin persistently. Economics keeps the community on the same chain.

The hard fork upgrades also show that the idea that "controversial hard forks cannot happen" is wrong. Bitcoin Cash's very creation demonstrated that, and the controversial fork of BSV demonstrated it again.
There is nothing inherently wrong with controversy, and hard forks as upgrade path acknowledge that if someone wants to split away, whether by new rules of their own or retaining the old rules, they are free to do so.

Thus Bitcoin Cash demonstrates the permissionless nature of open source cryptocurrency to the world at regular intervals.

I hope you enjoyed this exposition - if you can think of further benefits of the semi-annual hard fork upgrades of Bitcoin Cash that I forgot, please leave a note in the comments!

Keep calm and upgrade regularly :)

Additional recommended reading links:

(will be adding a few more here in time)

• "On consensus and forks", Mike Hearn - https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7

• "The resolution of the Bitcoin experiment", Mike Hearn - https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7

• "Hard Forks, Soft Forks, Defaults and Coercion", Vitalik Buterin - https://hackernoon.com/hard-forks-soft-forks-defaults-and-coercion-ko9zn3pef