On Bitcoin chain reconvergence

In his recent article titled "What are the Key Properties of Bitcoin?" on nakamoto.com, Jameson Lopp brought the following argument about convergence of Bitcoin clients, taking a swipe at Bitcoin ABC for their recent (Nov 2018) implementation of rolling checkpoints:

While there are several other things I can and would like to critique about his article, in this post I'll focus on this swipe at ABC which I find to be misleading by way of omission of certain facts.

Bear in mind here that Bitcoin ABC is a client for Bitcoin Cash - and that Lopp is using this opportunity to insinuate that Bitcoin Cash is somehow not Bitcoin because of this change.

Salient facts

1. There is no formal consensus for a "10 block maximum chain reorganization rule" in Bitcoin Cash.

2. The feature Lopp is talking about is an OPTIONAL feature with a CONFIGURABLE parameter setting that controls the depth at which a block is considered finalized.

3. OPTIONAL means not all users of the ABC software necessarily have this feature enabled at all - for any depth.

4. CONFIGURABLE means not all users of the ABC software necessarily have this feature configured to the same value.

5. Users of the ABC software can reconfigure this feature, disabling it if desired (requires a restart of the software).

6. Whether or not the majority of economic nodes running Bitcoin ABC actually use this feature is undetermined (no data).

So what we have here is a feature, implemented only in 1 of the Bitcoin Cash clients, that is potentially consensus relevant, but is discretionary and adjustable, with no firm indication (*) that it is actually in use on the network after the "hashwar" of 2018.

A national split means big problems regardless

In the case of a persistent split of the Internet, e.g. splitting off China, the two chains would diverge even in the case of BTC i.e. without this feature.

Lopp seems to think that automatic convergence of Bitcoin after such a split can be taken for granted simply because it's technically possible.

I would strongly disagree.

A large re-organization after an extended time period would pose a huge problem for the BTC network (or the BCH network if nobody was using the mentioned ABC feature) because a big chunk of economic activity could go unrewarded for the "losing side" that loses their blockchain history since the split.

Miners of the losing side would lose all the coinbases produced on the lesser-worked fork chain. All transactions building upon inputs from those coins would also be invalidated. These transactions would effectively be erased from history in the reconverged blockchain. Depending on how long the outage lasted and what steps were taken to limit the loss, this may represent a huge political problem that has no simple technical resolution.

This situation represents a general challenge for the concept of Bitcoin's "immutability", which would be severely put to the test by such an event.

If the outage is days or weeks, how to move on?

Which side gets to win - do we decide by least work lost, and what if it is close?

I think it is an open question, especially since during such an event, the length of the disruption and the resolution would not be clear in advance. Look at how long Kashmir has been purposely cut off from the Internet by the Indian authorities. This shows that such acts of disruption could last months if not more. In another example, Russia has recently conducted a test where they severed themselves from the Internet.

The 10-block default finalization in ABC would not play a huge role in determining any outcome under such circumstances.

When such a break of the Internet is detected, it might be expected - not guaranteed though, but I'll come to why it doesn't matter much - that miners would disable any additional finalization to make future chain convergence smoother.

However, not disabling it during the crisis would not stand technically in the way of reconvergence. Unless it was a short-lived outage (hours not days), the dispute over which side should sacrifice the record of its elapsed economic activity would likely dominate all.

We need to know that reconvergence is technically still a quick and easy process of disabling such a finalization criterion - easy because of Fact (3) above. ABC users could prepare for smoother reconvergence by disabling the feature while the network split event is happening. Even if they only notice the need after the disruption event, they can still disable and force their software to re-evaluate the chains, which only adds a little bit of time and additional work.
Miners (actually: pools) and big businesses using Bitcoin (Cash) in operation are quite familiar with the relevant processes.

Thus, the effort and time spent on technically assuring reconvergence would likely quickly be dwarfed by the economic losses to the side that will lose their coinbases and other transactions building upon them. Remember, in a Bitcoinized world, those are possibly the transactions of an entire economy, not just those of the block producers and a few exchanges and payment processors.

Ultimately, any lengthy persistent chain split on Bitcoin is difficult to sort out

That difficulty is not at all decreased by the absence of a 10-block finalization threshold.

There is NO agreed on protocol for amicably resolving such outages should they occur for a prolonged time.

It is quite likely that on both sides of such a disruptive split, users will take immediate steps to reduce their network usage to a minimum pending a resolution.

Despite the likelihood of such sensible measures being undertaken at first call, it is still possible a long incident duration means that Bitcoin splits into two chains which are not reconciled because either side refuses to take the economic hit.

I view it as much more likely that if Bitcoin is considered important enough, that in the case of such a split efforts would be intensified to reconnect as soon as possible to reduce the economic damage and make an amiable merge an urgent possibility.

Virtually the only case where this would not happen, I think, is in the case of war (†).

In that case I would expect that the warring factions disagree on the state of the ledger and would not easily be persuaded otherwise even if both sides managed to reconnect via the Internet, so it may result in the creation of a national cryptocurrency split off from Bitcoin.

Conclusion

While I think there are valid criticisms of the 10-block automatic finalization feature that Bitcoin ABC included in their software, I think the scenario of a nation splitting off from the Internet is one which is far too complex to safely use as a basis for BTC's supposed superiority in this aspect.

Both BTC and BCH networks would have problems under such circumstance which would likely require extensive human coordination to resolve. The possibility of long-lasting splits, for reasons of both economic interests and unresolved technical obstacles in fairly merging such diverged blockchains, should not be dismissed on such grounds but taken rather more seriously. (‡)

Footnotes

(*) A firm indication would be someone actually running into a limit imposed by the feature while trying to reorganize the network to a certain level. This has not happened to my knowledge.

(†) I'm at a loss to come up with some natural disaster scenario where Internet connectivity to the outside world could not be restored fairly quickly.

(‡) It is my hope that in future articles on nakamoto.com, I would not encounter such partisan arguments against Bitcoin Cash projects unless they were served with much stronger foundations than the instance in the cited article. Call this an appeal for better review ;-)