When it comes to new functions and updates for the Bitcoin network, we often talk about so-called soft or hard forks. In this article, we take a closer look at what these terms actually mean and where the specific differences lie. We also clear up common misunderstandings that often lead to the two terms being misunderstood.
In general, software projects, mainly in the area of open source development, are referred to as "forks" when they split in some way, for example because some of the developers have different ideas and visions for the future of a project. Especially in the case of ongoing discussions and differences of opinion, it is important to be able to go separate ways at any time instead of getting too bogged down in debates and arguments.
Unfortunately, the term "fork" is used several times in the Bitcoin context and it is often unclear what it actually means. We will also go into this in more detail in the course of this article. What is important for now, however, is that a fork, as in the previous section, is something special for Bitcoin.
Unlike a simple application, which can theoretically be forked with a click and adapted as desired, this is not so easy with Bitcoin, a large and decentralized network. This is because rule changes that affect the validity of Bitcoin blocks are relevant for the entire network and its users and can have far-reaching consequences.
The set of all rules currently found in the Bitcoin network specifies exactly which blocks are valid and which are not. All the so-called consensus rules, i.e. the rules that determine the validity of a block, are at the heart of Bitcoin and make the network what it is.
If you want to change these consensus rules, you can go in exactly two different directions: You can tighten the rules, or you can loosen them. And this is precisely where the distinction between a soft fork and a hard fork lies. The two terms merely describe the form of the rule change, nothing more and nothing less. Potential consequences for the network, which we will also discuss later, are not initially part of this distinction and should be considered completely separately.
To illustrate this, let's imagine a vegetarian restaurant.
The menu only includes dishes that do not contain meat and can be eaten by vegetarians. Changing the menu away from this characteristic can now potentially cause conflict with the current clientele - or not. This is where we will get to know the subtleties between soft and hard fork in a moment.
With a soft fork, we restrict the existing rules. In the case of our restaurant, we change the menu so that the dishes no longer contain any animal products and vegans can therefore also eat in the restaurant.
This is referred to as a soft rule change, as the existing customers, i.e. vegetarians, do not have to change their attitude in order to continue visiting the restaurant - after all, a vegetarian can eat a completely vegan diet without any problems.
In the Bitcoin context, a soft fork therefore does not force you to update to the new rules, as they are not in direct conflict with the previous rules.
Summarized in a few key points:
Let's go back to our now vegan restaurant and change the rules again: This time we are literally taking a tougher st ance and removing the restriction on vegan dishes completely. From now on, we will only serve meat dishes, but this leads to a tough conflict with our existing customers: Either they accept the new rules and eat the meat dishes, or they can no longer visit the restaurant in future.
Back in the Bitcoin context, the special thing about a hard fork is the need to accept the new, hard rule change, as it would contradict the old rules.
Summarized in a few key points:
We have not yet talked about a very special fork: A split of the blockchain itself, i.e. competing blocks that are no longer part of the same blockchain. In the following, we will refer to such a fork as a chain split in order to avoid confusion with the previous meaning of the term.
This is because chain splits are very often equated with forks, especially hard forks, and used synonymously. As is always the case with common misunderstandings, there is some truth behind this. Nevertheless, it is very important to understand the difference between a chain split and a soft or hard fork.
A chain split is a clearly defined state in the network, namely when several blocks are at the top ("chain tip") of the blockchain at the same time and compete with each other. In fact, such chain splits can occur randomly and therefore naturally, without any soft or hard fork, for example if two independent miners happen to find a new block at the same time.
Reading tip:Unusual Bitcoin blocks and where to find them
The terms soft and hard fork, on the other hand, are merely categorizations for the type or "direction" of a rule change. One can have something to do with the other - but it doesn't have to. Contrary to what is often assumed, a hard fork does not necessarily have to end in a chain split and, conversely, a soft fork can very well lead to such a split in the blockchain despite a "soft" rule change. Let's take a look at why this is the case using a popular example, namely the maximum block size.
In simplified terms, we can change the hard block size limit defined in the Bitcoin rules in exactly two directions: Increase or decrease.
We remember: A reduction in the maximum block size is arestrictionof an existing rule, and therefore asoft forkto be categorized as a soft fork. An increase, on the other hand, would be arelaxationof the rule and therefore ahard fork. So let's take a look at the respective scenarios when the two types of rule changes would lead to a chain split - and when they would not.
Due to the forward compatibility of a soft fork, the new blocks are still valid for old, non-updated versions. This means that not all participants in the Bitcoin network need to update to the new version in order to successfully activate the change.
Therefore, a carefully planned update will not result in a chain split. However, this is still possible, for example if many miners continue to work on the old version and produce blocks that are too large in this example.
As there is no forward compatibility with a hard fork, the new blocks are invalid for old versions. All participants in the Bitcoin network must therefore update to the new version together in order to prevent a chain split, i.e. a conflict directly on the blockchain.
However, this is not realistic, especially in the case of controversial decisions, which is why hard forks often end up in two different networks, such as the Bitcoin Cash fork in 2017.
Anyone familiar with the Segregated Witness (SegWit) update from 2017 will probably be wondering: How can it be that the maximum block size was increased back then, even though SegWit was clearly a soft fork?
The answer to this legitimate question is more or less quite simple: the actual block size limit was not changed at all, so it is still 1 MB, but only indirectly via an additional data attachment that is transferred separately from the actual block. From the perspective of an old version of Bitcoin, which does not want to know anything about SegWit, this attachment does not even exist and the additional data does not represent a conflict. The transactions in the blocks are constructed in such a way that they can be evaluated as valid even without the additional SegWit data.
We note: Even complex changes that at first glance require a hard fork can also be realized with a soft fork through elegant design decisions.
