....
The sacrifice for supporting back to 0.8 vs merely (say) supporting a year or two ago is insignificant-- mostly automated tests take a little longer to run and keeping around a bit of older redundant code to support the communication requirements of older nodes.
If there were a big cost difference between three years back and six years back, then perhaps newer versions would only still talk three years back.
That isn't the case because almost all of the compatibility costs are created by having any compatibility at all. One it exists, keeping it around isn't usually a large cost.
If you're running a relatively centralized system and can just demand everyone upgrade all at once to new behaviour you've specified then some things can be implemented somewhat easier. Though interestingly, it turns out-- most things are about the same either way. Changes to commitment structures (what data gets hashed) are hard to do in compatible ways, almost everything else is easy. But assuming everyone can upgrade at once is an extraordinarily centralizing assumption.
Supporting back a couple years means that users are free to run niche or custom software. They can keep on using Bitcoin XT or "Bitcoin Classic" or their own customized versions of them if those things have features they're dependent on.
They don't have to stop what they're doing and rebuild and retest their infrastructure on someone else's schedule. They don't have to take a risk that the new code introduces some backdoor or bad interaction with their other software. They can wait until they're doing other upgrades to change to new stuff.
Old versions can be insecure in various ways but you can keep your existing stuff running with a separate newer node as a firewall to protect it.
Even if you assume that everyone will eventually upgrade to new software-- and I generally do-- users being able to do it on their own timeframe can extraordinarily reduce their costs and risks. There are very few visible nodes in the Bitcoin network <0.13.1 (less than 5%), though we can't tell what people are running privately behind firewall nodes.
There are also other alternative implementations that are limping along. They add new features but because they're much smaller than the biggest public development effort, it sometimes takes them months or a year to catch up. Fortunately, compatibility means they're not killed dead if they can't always keep up with the fastest developed implementation.
None of that works in BCH land. If you really loved Bitcoin XT, Bitcoin Classic, or some other niche version ... or just had your own patches on an older version of ABC... well you're just SOL: you can't just keep running them. Your only option is to take on an incredible amount of development work either updating the code to the new consensus rules or recreating the features you need on the new software and testing that these changes don't break anything you care about. BCH's frequent hardfork practices have demonstratively killed many (most?) of the "many implementations" that were being so heavily promoted here a couple years ago.
I think there is a lot of juicy irony that many people around here were hollering about zomg dev control but then switch to BCH and an hardfork process that crams controversial (e.g. CTOR) changes down people's throat, actively kills competing implementation, and materially reduces user's freedom to choose to not follow around some client authors latest brainfart.
Post by @nullc on reddit .
https://www.reddit.com/user/nullc/Not even mentioning BSV which is a fork of a fork of a fork.....
