In order to make any kind of modification to Bitcoin, there are BIPs and forks.
When talking about Bitcoin some of the most frequently asked questions are:
- Who manages Bitcoin?
- Who is in charge of updating it and correcting any flaws considering that it is a distributed system?
When developing software, it’s unlikely to be perfect the first time.
The “first time right” only works in film shootings, or almost.
Programmers know that code can often involve bugs or problems and their job is to put the code back in place to fix any errors, and not only that.
This makes us understand that the problems in the IT world exist, can become evident over time and often depend on external factors that are difficult to predict.
In private software, any errors are corrected by the programmers who developed it or by others in charge of maintenance.
The same doesn’t apply to open source software, i.e. those programs that are open to everyone in a transparent way, where anyone is able to apply an improvement or correction.
Since Bitcoin is a distributed system, it is obviously open-source software.
Whoever wants can contribute towards improving the system, obviously reaching the consensus of most of the network.
Therefore, in order to make any kind of modification to Bitcoin, there is a standard called BIP.
What are BIPs
The Bitcoin community is very large. How to explain the features of a modification to everyone in an effective way?
This brings us to BIPs (Bitcoin Improvement Proposals), a document that defines the reasons and methods for making a change and the consequences it will have on the system.
In essence, a BIP represents a meeting point thanks to which the Bitcoin community is able to make a decision for a possible update.
However, this way of communicating has several implications.
First, a factor to take into account is the level of consensus, i.e. the change must be accepted by almost the entire network.
If this is split in half, with two different and opposing thoughts and ideas, there could be a division of the Blockchain, by means of a fork.
And the timing?
The timing of the whole process, even for a simple modification, could be very slow and could go on for years.
Just consider that if in a centralized application the modification is done by the programmer, in a distributed blockchain like that of bitcoin, all the nodes scattered around the world must discuss it, evaluate the real advantages and changes and only after decide whether to proceed with the modification.
What are forks?
A change to the previous code, it is called Fork.
Here is an image that helps us to better understand what happens to the Blockchain when a Fork occurs.
Forks are divided into hard forks and soft forks.
The main difference is that a soft fork is a retro-compatible change, which means that the updates must be made in such a way that they do not conflict with the rules already established previously.
So even nodes that have not implemented the update, must be able to continue to make transactions and add new blocks to the Blockchain, obviously without violating the new rules that the change involves.
Whereas a hard fork is the opposite, i.e., all previous nodes that have not updated the protocol are no longer able to create new blocks because the rules that follow are in contrast with the new changes.
This phenomenon has sometimes also led to the birth of new coins.
For example, the Bitcoin Cash altcoin was born from a Bitcoin hard fork in 2017.
The main topic of contention was the block size.
The network found itself divided into two parts:
- one wanted to keep the current size of the block, because by increasing it, the total size of the Blockchain also increased a lot, a factor to avoid if one wants to ensure greater decentralization because, having a lower overall size, it’s easier for everyone to download it.
- the other party, on the other hand, wanted to increase the capacity of each block to 1 GB, so as to improve scalability and ensure a greater number of transactions per second.
The result? Hard fork and a division of the blockchain.
Luca La Marca