There is an important incident in Bitcoin history that happened in March 2013. I thought it would be relevant to the current event happening in Bitcoin Cash network.
On March 11th 2013 some miner & exchange noticed strange behaviors in the Bitcoin client & network. It was quickly perceived that there has been a fork due to an inconsistency between the two versions of bitcoin software 0.7v & 0.8v. I'm not sure what the bug was but it seems like the block size limit had been raised in 0.8v so as a result some miners were able to mine bigger blocks.
That's how the event unfolds, but I want you to especially pay attention to the bold ones:
23:06 Luke Dashjr so??? yay accidental hardfork? :x 23:06 Jouke Hofman Holy crap
23:11 Mark Karpeles I've disabled the import of bitcoin blocks for now until this is sorted out 23:13 Luke Dashjr I'm trying to contact poolops [mining pool operators]
23:21 Luke Dashjr at least 38% [of hashpower] is on 0.8 right now otoh, that 38% is actively reachable
23:22 Gavin Andresen the 0.8 fork is longer, yes? So majority hashpower is 0.8.... 23:22 Luke Dashjr Gavin Andresen: but 0.8 fork is not compatible earlier will be accepted by all versions
23:23 Gavin Andresen first rule of bitcoin: majority hashpower wins 23:23 Luke Dashjr if we go with 0.8, we are hardforking 23:23 Pieter Wuille the forking action is a too large block if we ask miners to switch temporarily to smaller blocks again, we should get to a single chain soon with a majority of miners on small blocks, there is no risk 23:24 Luke Dashjr so it's either 1) lose 6 blocks, or 2) hardfork for no benefit 23:25 BTC Guild We'll lose more than 6
The problem with people who think like Luke or Pieter is that they look at earlier version as the majority consensus (or better version) rather than looking at majority (of hashpower) as majority. He's basically saying to roll back to 0.7v because 0.8v is not compatible. This is utterly absurd because you can also argue that we should roll back to 0.8v because 0.7v are not compatible.
What they fail to understand (intentionally?) is that majority of hashpower (i.e. people with skin in the game & vested interests) are behind 0.8v, as Gavin Andresen had mentioned "majority of hashpower wins".
What I mean by vested interest here is that miners who receive their prize after finding a block will not be able to redeem their bitcoins until 100 blocks later. By forcing the majority of miners to downgrade to 0.7v, Luke & et. al made majority of miners to lose more bitcoins at the expense of minorities.
At the end, it came down to Luke picking up the phone & calling BTC Guild (one of the largest mining pool at that time) to downgrade to the older version.
Even though the incident is an unintended (or innocuous) fork because of two incompatible software (earlier & upgrade versions) this can also be applied to two different software implementations (i.e. ABC vs. SV) that will deliberately be used by two groups of miners.
Whether a fork happens due to block propagation in the Bitcoin network which gets resolved by following Nakamato consensus, I believe we should also HONOR this SIMPLE consensus on the Nakamato consensus in cases a fork occurs because of unintended or intended reasons. It's still Bitcoin, and in Bitcoin the longest chain is what most people agree on.
So let's honer this & have consensus on consensus!



1 of 1 reviewers say it's worth paying for

0 of 1 reviewers say it's not worth paying for