You can listen to or watch this video here:
It has been pointed out before that because Bitcoin (BTC) and Ethereum Classic (ETC) have had coordinated emergency responses to bugs and attacks in the past, that this proves that they are centralized systems.
These arguments are not true.
In this post we will explain what is a unified emergency response, we will list some occasions in which there have been unified emergency responses both in BTC and ETC, which may be wrongly interpreted as centralization, and we will explain how these systems work at scale.
If people are using their cell phones and it is discovered that there is a general bug in the system, all users will soon receive a notification to upgrade their devices. As everyone goes accepting the terms and conditions and initiating the upgrades, it will take a few minutes in each phone until the download of the software patch is completed. Then, all phones will ask users to restart them and everything will be fixed in a matter of a few hours.
The above is a typical emergency response for fixing bugs in software systems. They are so easy and smooth because those systems are centralized, therefore very few people direct the whole upgrade process, and our devices and operating systems have channels and backdoors through which the providers can communicate instructions to users or sometimes even manage the systems remotely.
This kind of unilateral response is impossible in decentralized blockchains such as Bitcoin and Ethereum Classic.
With so many independent nodes in the networks located in different continents, regions, countries, and cultures, to achieve this level of centralized coordination is practically impossible. This is why these systems are secure.
However, Bitcoin and ETC have repeatedly been upgraded very quickly after catastrophic bugs or attacks.
How does an emergency response look like in a decentralized blockchain?
If anywhere in the world any user detects a failure in Bitcoin or ETC, they will immediately report the problem on social media and/or in the GitHub repository of the respective blockchain node software.
When the above happens, very quickly all economic nodes, meaning node operators with businesses dependent on running these nodes, will immediately raise the alert in their organizations, which may include exchanges, mining pools, mining companies, dapps, blockchain explorers, node services, etc.
As the core developers of these systems are alerted by all the noise in the ecosystem, they will immediately try to identify and create an emergency patch to correct the failure.
When the patch is announced by core developers, then the whole ecosystem of these blockchains will download and activate the new software, thus resolving the problem.
The Overflow Bug of 2010: On August 15 2010, on block 74,638, Bitcoin issued 184 billion BTC. This was a bug in the software client that a hacker discovered and started to exploit. Core developers identified the failure within 90 minutes. Within a few hours the patch was released and the network went back to normal.
The 2013 Involuntary Fork: In March 11 of 2013 some nodes in the Bitcoin network started to work on a different blockchain than the rest of the nodes, this is what is called a network split. The Bitcoin node software had been upgraded from version 0.7 to 0.8 but not all operators had done the upgrade. Because of a glitch in the 0.8 version, all the nodes and miners with that version split from the mainnet. After several alerts and alarms on social media, core developers started to work on a fix, and persuaded all network users to downgrade their nodes to the 0.7 version, fixing the failure.
The Gas Reprice of 2016: In October of 2016 a series of attacks on Ethereum Classic started to happen due to an inadequately low cost of certain operation codes in the virtual machine. After 10 to 14 days of development and ecosystem coordination, the fix to rebalance the gas costs were introduced by core developers by way of a hard fork on block 2,500,000.
The 51% Attacks of 2020: In August of 2020 there were a series of 51% attacks on ETC that involved the loss of several million dollars to the victims. The fix to solve this problem was not a change in the rules of the protocol but the addition of a feature called “Modified Exponential Subjective Scoring (MESS)” to the software clients of ETC that would reject alternative attacking blockchains. This feature was released in mid October of 2020 and the majority of node operators have used it.
As seen in the previous examples, both Bitcoin and ETC are supposed to be decentralized, but each time there has been a failure, emergency responses have been coordinated swiftly similar to centralized systems.
Does this mean that BTC and ETC are really centralized?
The answer is no. Whoever makes the analogy of centralized operating systems with decentralized blockchains is failing to distinguish the differences because they are making a very simplistic comparison of unified behavior and response times, and are not identifying the causes for such behavior.
When a blockchain is operating normally, there is no coordination whatsoever between the globally diverse sets of node operators, miners, and users in systems as Bitcoin and ETC. To convince all these participants of changes that are not desired, are controversial, or even lack interest, is practically impossible!
However, when there are failures in the systems, then these same participants, not only react quickly and positively to changes, but they may be on alert 24 hours a day to anxiously implement them swiftly.
The reason for this highly coordinated emergency response behavior in decentralized systems is that the incentives for resolving failures are the same as the incentives for the systems to be live and running in a totally decentralized way.
Liveness and decentralization are valuable because they guarantee the correct operation, censorship resistance, permissionlessness, and immutability of the ledger with accounts, balances, sound money, and unstoppable applications.
The minute that these attributes are threatened by software bugs or attacks, all ecosystem operators and users of the blockchain will naturally want to fix the system as soon as possible.
There is no mystery, conspiracy, or centralization, it is just the incentives of the ecosystem that drive it to act in a unified and coordinated fashion.
Proof of the above argument is that each time Bitcoin or ETC have been fixed after failures, they have both returned to full operation very quickly in a totally decentralized manner.
And, when any new controversial changes have been proposed, the typical debates and kantankerous attitudes between the same participants has regained the floor.
In social groups, if decentralization is achievable without degenerating the systems, then participants will choose decentralization.
Centralization is not a desired state of affairs. “Voting”, “Democracy”, and “Republic” are not ideal systems, they are just the least worse we can do.
But in proof of work systems there cannot be tyrants, kings, constitutions, presidents, or congresses. It is not possible because participants will never choose that, because they are not necessary, and they will always prefer to split.
As a final note, it is important to highlight that when these systems are small or their ecosystems are developing, they may seem centralized because few players control significant shares of the resources.
This is yet another fallacy in which detractors may fall. Blockchains such a Bitcoin and Ethereum Classic are even more decentralized at scale. It is just a matter of growth.
As these networks grow, there will be more node operators in more regions spread around the world. There will also be more miners seeking cheap sources of electricity which are naturally distributed around the globe. And, there will be more users, investors, and dapp developers everywhere who will permissionlessly access the system.
The increase in all these participants, and the fact that BTC and ETC use proof of work, makes them more decentralized and immutable.
Thank you for reading this article!
To learn more about ETC please go to: https://ethereumclassic.org