Du kannst diesen Artikel auch auf Deutsch lesen.
Puoi leggere questo articolo anche in italiano.
If you ever read or talked to someone about Bitcoin updates like Segwit and Taproot or even network forks such as Bitcoin Cash, you probably stumbled across the terms “hard fork” and “soft fork”. There are quite a lot of misunderstandings and confusion about terminology when it comes to changing Bitcoin’s consensus rules.
For example, despite its harsh sounding name, a “hard” fork is not necessarily something to be afraid of, while a soft fork does not always have to be as “soft” as it sounds. Let’s explore the exact difference between these two abstract concepts, and most importantly, when you should even apply them in the first place. This will help you understand the basic mechanisms behind upgrade proposals for the Bitcoin network more easily in the future.
Software forks
In very general terms, a fork of a software project is nothing extraordinary. Especially in the open source community, anyone can fork (clone or copy) an existing project’s source code, put a new name on it and start developing on their own – or even with a new team.
On the popular development platform GitHub, forking the official Bitcoin repository is just a matter of pressing a simple button:
Of course, nothing changes about the Bitcoin network if you fork the Bitcoin repository on GitHub, even though it could in theory – provided your fork is adopted by enough users. But that’s not what this article is about. Hard and soft forks are more about categorizing rule changes than actually forking or splitting things apart.
Consensus rules
The Bitcoin protocol, embedded into the reference implementation Bitcoin Core, consists of many different rules, policies and more. Some of those rules, arguably the most important ones, determine whether a block is valid. Therefore, these rules are essential for achieving consensus in the network, since participants have to agree on them in order to come to a consensus about which chain is the real “Bitcoin blockchain”.
Some of these consensus rules are quite obvious, and you might naturally come up with them when thinking about the validity of a Bitcoin block. For example, transactions cannot spend a previous output twice, miners cannot create more bitcoin in a new block than what is allowed in the current halving period and the block size cannot be larger than the set limit.
Note that not all rules that are talked about in Bitcoin are relevant for consensus. You might have noticed recent debates about removing Ordinals transactions from a node’s local mempool, for example. The rules that would limit a Bitcoin node to store and relay such transactions are usually referred to as policies instead of hard-baked rules, since blocks containing these transactions still remain valid – it’s just a matter of individual user preferences.
Like almost all rules, consensus rules can be changed too. However, this is where things get “soft” and “hard”. Rule changes can be categorized in two ways: Hard forks remove consensus rules, while soft forks add new ones. To phrase it more carefully, a hard fork increases the total theoretical set of valid blocks, making previously invalid ones valid, while a soft fork decreases the set of valid blocks, making what would previously be valid blocks invalid. Sounds confusing? Stick with us, as this will make more sense after a more practical, real-world analogy.
Forks in a restaurant
Imagine a vegetarian restaurant that exclusively serves dishes containing no meat or fish. You can think of these dishes like valid Bitcoin blocks. Many people can enjoy eating in a vegetarian restaurant without any conflicts, including omnivores (people that eat both plants and animals). If you decide to eat at this place, you agree to the restaurant’s consensus rules, which means that you will have some veggies with eggs, for example.
Vegan-only
One day, the owner decides to take things a step further, transforming their menu to strictly vegan options only. This is clearly a soft fork, because a new rule was added and the total amount of theoretical dishes you could choose has decreased. Some previous dishes are just not possible anymore. While making rules more strict sounds quite “hard” at first, the consequences this change has on the existing customers are actually quite “soft”.
Think of the people who could eat at the restaurant now, or in other words, the compatible Bitcoin versions: Personal preferences aside, everyone who previously ate at the vegetarian place can technically continue to eat a vegan meal without breaking their dietary rules. The change is therefore forward compatible, without introducing any conflicts, since nobody needs to find a new restaurant to eat at.
However, it’s possible a vegan person would have refused to eat what was previously served at the vegetarian restaurant, since those older consensus rules are not compatible with their current version. For this reason, soft forks are not compatible with older versions from this point of view.
Relaxing the rules
With a sudden change of mind, the owner now decides to relax the restrictions on their menu, even allowing meat to be served to the guests. Naturally, this causes conflicts with the vegetarians and vegans, as some or maybe even all menu options are out of the question now. This is a hard fork, with the previously added rule now removed and the amount of theoretical dishes increasing.
The key thing to understand in the Bitcoin context is how the previous guests need to either change their mind now or move on to a different restaurant. Because of this mechanism, hard forks are not forward compatible.
Again, however, the other way around it’s the opposite: Even if you like meat, you could have eaten at the old vegetarian version of the restaurant, since your consensus rules are less strict than the old ones anyway. This is why hard forks can be compatible with blocks created by older versions.
To summarize
- Hard forks remove consensus rules, making what would previously be invalid blocks valid, while usually breaking forward compatibility. Everyone should upgrade to the new version if they agree with the change and want to avoid conflicts.
- Soft forks add consensus rules, making previously valid blocks invalid, while usually maintaining forward compatibility. Not everyone has to use the new version, since blocks under the new rules will still be considered valid anyway, whether one agrees with the change or not.
Chain splits
Hard forks
Hard forks are very commonly confused with what we will refer to as chain splits: an actual fork on the Bitcoin blockchain, that may or may not result in an entirely new alternative network. Let’s take a brief look at why hard forks do not automatically cause chain splits, and why chain splits themselves are actually quite common in Bitcoin.
For hard forks, users on the new hard fork version can accept blocks from the old version, while still continuing to mine blocks under the new rules themselves. Users running the old version will refuse to accept these new blocks, even if they have the majority of hashrate.
If we take the example of a hard fork that increases the bitcoin block size, the new hard fork chain is able to accept smaller blocks that adhere to the former rules, but the old chain will refuse the bigger blocks. This makes a chain split (and therefore upgrade) more likely and easier for the new version to pull off, because it does not have to directly compete with the hashrate of the old chain.
Soft forks
For soft forks, users on the new version can refuse blocks from the old version. They can mine blocks under the new rules, but these can also be accepted by the old version.
If we use the example of a soft fork that reduces the blocksize, the new chain cannot accept blocks from the former chain rules, but the new chain will stay compatible with users running the old chain rules.
Successful soft fork upgrades are more difficult, requiring a majority of the hash power on the new version to “force” users of the old version to accept the new rules. This is because a bitcoin node will accept the blockchain with the most work put into it as the valid chain. Chain splits on soft forks are possible, contrary to popular belief that soft forks make arbitrary changes automatically safe.
In fact, any change could theoretically be designed as a soft fork, somewhat making the “black and white” categorization of the two terms a bit pointless. As an example, the Segwit update was cleverly designed to effectively increase the block size without increasing the block size limit itself, making it a soft fork.
Bitcoin forks
Chain splits occur naturally almost every few weeks, when two miners find competing blocks at the same height by accident (e.g. because of a timing coincidence). There is even a website to track these accidental chain splits. Sometimes, when there are large mining pools competing on the same height, they might double down on their “fork”, causing a two or even three-block reordering of blocks. Since there is no malicious intent behind it, this is totally fine and part of mining game theory (and partly the reason you should wait for 3-6 confirmations so you know your transaction is on the winning chain).
One of the most prominent chain splits was the attempted block size increase that resulted in the creation of Bitcoin Cash in 2017. As the rules of the new chain were incompatible with the existing rules of the Bitcoin blockchain, Bitcoin Cash’s hard fork forked off into another blockchain — creating a second network and with it a second coin, named “BCH”.
The last bitcoin soft fork was the Taproot activation in 2021, which was achieved by a majority of hashrate signalling they’re prepared for the new consensus rules and users updating their clients to the new version accordingly. No chain split occurred for this soft fork.
Conclusion
Hard forks don’t necessarily result in chain splits, and soft forks don’t necessarily come without them. Even though these words are often mistakenly used interchangeably, they mean different things. As this blog post explains, the definition of a soft fork is generally the tightening of existing rules, while hard forks remove existing rules. Soft forks are compatible with existing rules, while hard forks are not.
Another key takeaway is how soft forks are not automatically the safer option over hard forks and vice versa. One reason is the interesting fact that pretty much any change can be purposely designed as a soft fork, making it impossible to determine the nature of a change solely based on the “soft fork” label. In addition, some changes may even benefit from the lack of forward compatibility that comes with hard forks. In short, debates about future Bitcoin upgrades should first and foremost focus on the actual change, its implications and how it should be activated, rather than the technicalities behind the rule changes.
Don’t own a BitBox yet?
Keeping your crypto secure doesn't have to be hard. The BitBox02 hardware wallet stores the private keys for your cryptocurrencies offline. So you can manage your coins safely.
The BitBox02 also comes in a Bitcoin-only version, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing Bitcoin.
Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease - along with its software companion, the BitBoxApp.