Original Source Medium (publicado por peerchemist) 

Hard forks are a hot topic in the cryptocurrency space since mid 2017 and the Bitcoin: Bitcoin-Cash split. The Bitcoin-Cash fork may be the most memorable fork in recent times, but forking is in fact commonplace among blockchains. Multiple renowned cryptocurrencies like Monero and Peercoin have hard-forked many times in order to upgrade and evolve the network protocol.

Photo by John Lockwood on Unsplash

A hard fork does not mean that there is a new coin being created. A hard fork means that the network is changing the set of agreed-upon consensus rules in a way that is no longer compatible with the old set of rules.

Nodes running the old software will be left behind and continue producing blocks using the old set of rules, which are now obsolete. These blocks (and transactions) will be understood as wrong by the nodes that have upgraded, so they will be dismissed. This dismissing is what forks the chain into two.

Forks are usually done to introduce new features into a blockchain.

Forks can also be unintended, as a result of a software bug for example. One such example is the unintended hard-fork of Bitcoin in March 2013, when migration from BerkeleyDB to LevelDB caused a chain split. [1]

Bound by history

There is only one blockchain, the one we all agree on.

In this case, “blockchain” refers to the accumulated history of transactions in the ledger. When you hard-fork the chain, you are forking the history as well. Up to the point of the hard-fork, both chains share exactly the same history. Post-fork, they diverge and create a new and different transaction history. If the hard-fork is done in order to upgrade the protocol, anyone running a node should upgrade as well in order to continue sharing the history with the rest of the network — unless you and your peers share a deep disagreement with the consensus update and decide to continue on your own path.

Nothing stops block producers from going their own way. It’s their money and their time. Public blockchains are usually very decentralized and if there is no startup leading the chain, they can be very democratic as well. If there is a group of users of some blockchain that do not like the way the project is heading, they are always free to break away and agree on their own set of rules. The question is: will the market accept “lesser” branches? There is more to cryptocurrency than software and nodes, there are miners, investors, service providers, exchanges, and traders to consider as well. Without support from all the involved parties, the “lesser” fork will inevitably fall behind on development and adoption.

Bitcoin: Bitcoin-Cash: Bitcoin-SV fork Olympics are a good example of how democratic the forking process is. First, Bitcoin-Cash split off from Bitcoin because they could not accept the SegWit protocol extension (which was deployed as a soft-fork) and because the majority of the Bitcoin block producers (miners) did not want to accept a block size increase to over 1Mb. On the Bitcoin-Cash blockchain, SegWit was never activated. However, it is a part of the history of the present Bitcoin (core) blockchain. Further down the road, Bitcoin-SV split off from Bitcoin-Cash for “reasons”. There were also many less known forks that did not do much more than ride the hype wave of forking in order to get paid.

Another famous chain split is Ethereum: Ethereum-Classic, where part of the community did not accept the decision to roll back the chain (undo history) in order to mitigate the infamous “DAO hack” [2]. On the present “Ethereum” chain, that hack has never happened, while it is part of the history of the “Ethereum-Classic” chain. Technically, “Ethereum” is a fork of “Ethereum-Classic”.

Clearly, history is whatever we all agree on.

Fork me softly

Blockchains are usually forked in order to introduce new features and a new set of rules to a shared consensus. There are two ways to update a blockchain. First is the hard-fork, where all previous versions of the reference software are proclaimed obsolete and can no longer participate in consensus and second which is “softer”: a soft fork.

Soft forks add features without breaking existing consensus rules.

In a soft-fork, nodes that do not update can still process blocks and share history with the rest of the network, but will not be able to use newly added features.

Bitcoin (core) has been updating through soft-forks since its genesis block. Even the famous “Segregated Witness” (SegWit) update was deployed as a soft-fork. This strategy is good for backward compatibility and it’s easier on the users, however, it hampers innovation as all updates must be executed in a way that is backward compatible. Hard-forking allows for much deeper changes in the protocol as it does not care about maintaining compatibility with old clients.

One could argue that the size of a blockchain network is a limiting factor when it comes to software updates, the logic being that a smaller network can hard-fork more easily than a large and established blockchain network which runs on tens of thousands of nodes.

Hard choices

From a developer perspective, hard forks are always difficult. This is true for any software. Whenever developers deploy breaking changes they always expect user woes and deployment problems. This is especially true in a decentralized system like a public blockchain. In order to execute a hard-fork, the entire community has to agree on the new set of rules before they are even implemented. Agreement on the changes is usually done by an inner circle of developers in a meritocratic process. Bitcoin uses Bitcoin Improvement Proposals (BIPs) to go through this process, Ethereum uses EIPs and Peercoin uses RFCs.

Photo by Ivan Aleksic on Unsplash

Upon discussion of each protocol adjustment and improvement, developers implement the changes in code and deploy it for testing on the test net. Once the testing period is over and developers believe that the new code is stable enough to be put in production, the process of deployment to the main net starts.

The hard part is convincing the entire community that this fork is worth their time and effort. The development team has to have a healthy amount of political capital and enjoy the trust of the wider community in order to push for the update. The more decentralized the blockchain is, the more this statement holds as true. For example, with the SegWit soft-fork, the Bitcoin-core development team did not have enough political capital and trust to convince the entire community to accept the SegWit protocol update, so a portion of the community has decided to split off.

A blockchain network can be forked in two ways, by setting a predefined date for the fork, or by waiting for a majority, or super-majority, of block producers to signal that they have updated their nodes.

Waiting for a supermajority of block producers to update is longer, but is generally a safer process while settling for a pre-defined date (timestamp) for the fork generally always leads to some problems as some subjects simply can’t be bothered to update on time.

Common questions

Let’s wrap this up with the most popular questions when hard forks are mentioned outside of developer chats.

Does a hard-fork update create a new coin?

Yes, but actually no.

If a block producer node does not update for the hard-fork, it will continue to produce blocks on the obsolete fork, which does not share history with the current state of the network. So technically they have created a new coin. Depending on circumstances and community support, such a blockchain can be sustained and get traction on the market, but usually, that is not the case.

Will I lose my coins if I don’t update before the hard-fork?

No.

Even if your node ends up on the wrong fork, it is easy to get back. The simplest procedure is to resync (re-synchronize) the blockchain after updating the node. However, no transactions executed after the fork have ever happened on the main blockchain — so they will be “forgotten”.

How do I claim my coins on a second chain, in case the community decides to uphold both? How can I protect my coins against replay attacks?

Just create a new set of UTXOs on both chains as soon as possible

… and continue using both chains with their respective clients. Mind that you do not try to send coins from one chain to another, because blockchains are not magic and this will not work.