Bitcoin 2.0 — Part 1 — Fork
In this weekly series, I’m going to explain the technical concepts of Bitcoin to give you a grasp on what has been made to guarantee the future of the network.
To begin with, nothing better than explaining what a Fork is, what causes it and its consequences in case consensus aren’t reached by its participants.
* para ler este artigo em português visite: https://www.criptomoedasfacil.com/bitcoin-2-0-parte-1-as-divisoes-e-atualizacoes-da-rede-do-bitcoin/*
What is a Fork?
As the name states, a Fork is a point where something, especially a road or river, divides into two parts (Y).
In Bitcoin, a Fork happens for a few reasons and in these cases the nodes should choose which path to follow, providing its processor power to the new chain.
Why do Forks exist?
In a straightforward explanation, because of the distributed and decentralized nature of Bitcoin, a consensus is needed to perform a modification or update in the network.
This means that for any and every change in the Bitcoin network, be it at the protocol, the consensus rules or the data format level, there will be a Fork.
There are 3 types of Forks. One of them happens with a certain frequency in the network and the other two happens only in upgrades.
The most common one happens when two miners publish their block at the same time, this breaks the chain in 2 simultaneous workloads, each of them with a certain processor power being applied to it.
The upgrade Forks are:
- Soft-Fork: happens when the upgrade is fully backward compatible with the previous client versions. The previous clients will continue to work even though their code is not the same as the new one;
- Hard-Fork: as opposed to the last one, this one happens when the upgrade breaks the previous clients, rendering them not working (or only working if there’s a message containing the previous rules).
At some point, while a Fork is in progress, one of the chains has more processing power than the other, which makes its blocks process faster and consequently makes that its blocks to be received by more nodes. This allows one of the chains to have 6 more accepted blocks than the other. What happens then is that the smaller chain is usually abandoned by all the participating nodes, that changes its processing power to the longest chain.
The most (in)famous Bitcoin Fork
The most famous Fork in the network happened in August 2017, when it went through, to this day, its greater ordeal.
After 3 years of development of a new client version by Bitcoin Core development team, countless meetings with developers, and a few meetings behind closed doors with a few companies, the FUD took over investors and believers because, at the time, few knew what a Hard-Fork was.
Besides the upgrade proposed by Bitcoin Core, there was also a proposal created by big market players, known as the New York Agreement or NYA, in which Bitcoin Core developers were not invited. In this meeting they have decided that there would be 2 upgrades: first the activation of the SegWit protocol and 90 days after, the rise of the block size to 2MB, the famous SegWit2X.
As soon as they learned that SegWit2X was being used to do a UASF (User Activated Soft Fork) that would only be active to activate SegWit, they have created a new team known as BitcoinABC, that was made possible with investments from Jihan Wu (Bitmain’s founder) and Roger Ver. This team developed a new client, that produced 8MB blocks, in a record time. Because of the sped up development, a bug was found by a Bitcoin Core developer and corrected almost at the launch time.
In the end, we had 3 simultaneous upgrade attempts:
- Bitcoin Core: bet that the best solution to end transaction malleability and at the same time raise the network capacity would be the activation of the SegWit protocol. This protocol changed the way the blocks look to the new client version, keeping them unchanged to the non-upgraded clients. This Soft-Fork required a bit in the block header from the new clients to know that 95% of the network was ready for activation.
- NYA: they defended SegWit2X, that not only the SegWit protocol would be activated, ending the transaction malleability, but also a rise in the block size to improve the network capacity.
- BitcoinABC: didn’t want SegWit activation, but a rise in block size (in MB), which would cause a Hard-Fork since one of the network consensus rules is that the blocks could not be bigger than 1MB, this would make the official Bitcoin Core client to invalidate the blocks generated by it.
In resume, we didn’t reach consensus between the participating nodes, this created a Hard-Fork and the network was separated in two by BitcoinABC’s software, resulting in the creation of a new coin, BCash.
- Bcash: A group of nodes, which used BitcoinABC’s client, started to validate only the bigger blocks, that had 8MB and suffered from transaction malleability;
- BTC: The other group, which continued to use not only the new Bitcoin Core but also its older versions, was validating the new blocks with the SegWit format that not only corrected the transaction malleability but also had a bigger transaction capacity, helping the network’s transaction flux.
Despite the fear this word brought us in the past we can conclude that Forks are natural in decentralized/distributed systems thanks to network latency and consensus difficulty.
Also, Soft-Forks and Hard-Forks are needed to upgrade the network e are, almost always, not harmful to the ecosystem.
In the next article, I’ll explain exactly how SegWit works and how it has allowed us to add new functionalities to the network without needing a Fork using Side Chains.