Much about the current Bitcoin splitting debate has revolved around the notion of a hard fork splitting of the network being dangerous. So dangerous, in fact, that core developers have constantly stuck to the argument that the community should trust in their (exclusive) council in order to ensure that we don’t engage in anything that may be unsafe for ourselves. Trust them, they know what is good for us. When libertarians and skeptics around the world hear that they are immediately put on alert.
Most recently an exchange between ex-Bitcoin lead maintainer Gavin Andresen with Core contributor Matt Corallo was especially interesting. Besides the run-of-the-mill talking past each other where Matt seems to ignore points that Gavin clearly addressed (regarding n**2 sighash issues, solved by capping txn sizes to 1mb) the core theme (pun intended) repeated again by Matt was that Hard Forks have no community support (by his own judgement) which is clearly shown by the fact that nobody seems to be giving much attention to the HF proposals in his (exclusive core dev curated) proposal list. Not much surprise here, the standard echo-chamber reality distortion field stuff. What was interesting, was that he once again mentioned the need, nay, the necessity of ‘replay protection’ in ANY hard fork proposal. This is very important point in the core dev platform, as it serves a dual purpose. One which on the surface is ostensibly for the public good, the other may be much more shadowy. Let’s examine what replay protection is, and why we really don’t need it.
Ethereum made crypto-history this week by being the first PoW blockchain to execute a hard fork. They claimed it was done after getting unanimous consensus from the community through stake voting which many have criticised as being nothing more than a farce, as less that a total of 13% of the coin population bothered to turn up to vote, and some sources say it was even possibly less than 2%. Nevertheless, the hard fork was devised and coded, hastily tested, and released, and when the fateful day arrived when it was pre-programmed to activate, July 21st 2016, the network indeed split into two. Quietly, smoothly, without much fanfare.
A week before a group of developers and supporters who opposed the hard fork on ethical principles formed a movement called Ethereum Classic, and pledged to reject the new fork which would see the seizure and confiscation of the ETH that the DAO attacker had acquired during his raid. This movement also saw the defection of about 5% of the mining power in the ethereum network.
What happened after the fork block made history. Contrary to what the ETH developers said, the fork did not remerge and the minority chain persisted. At first the block rate was a fraction of the majority chain. But now after 2 days the block rate has stabilized and the minor chain is mining blocks at about the same rate as before the fork. In addition, the difficulty of the mining is only 1% of the majority chain, which adds an economic incentive for miners to mine on the minor chain in order to make more rewards. This second chain represents the split-fork scenario that many Bitcoin core devs have been warning the community that would cause chaos and destroy both systems. Only, it didn’t. At least not yet.