Hard fork vs soft fork

The most interesting thing going on in the Bitcoin world this week hasn’t been the alleged unmasking of Satoshi Nakamoto (and I stress “alleged” because, no, I don’t think so). It’s the gathering of the Bitcoin influencers at the Scaling Bitcoin conference in Hong Kong. As the second part to the Scaling Bitcoin conference in Montreal earlier this year, the objective was to get miners and developers together to discuss a possible solution to the block size debate.

image via Coindesk
image via Coindesk

Up until now, everyone has been assuming that the choice is between leave things as they are, or launch a hard fork that will increase the block size and give Bitcoin more scalability. There are pros and cons for each version, and firm, uncompromising beliefs on both sides. Yet some interesting ideas have emerged.

To appreciate what’s at stake here, it is important to understand what a “hard fork” is. A hard fork is a change to the current Bitcoin Core protocol that renders older versions invalid. The Bitcoin Core protocol defines how Bitcoin works. It is the core program that nodes use to validate blocks, and dictates such parameters as the block size, the difficulty of the cryptographic puzzle that needs to be solved, limits to additional information that can be added, etc. A change to any of these rules that would cause blocks to be accepted by the new protocol but rejected by older versions, would lead to serious problems on the blockchain.

Let’s say that the protocol is changed in a relatively fundamental way that relaxes the rules or broadens the code’s scope. If this happens, mining nodes running new versions would produce validated blocks that will not be accepted by nodes running an older version. For instance, if the block size limit is increased from 1MB to 4MB, a 2MB block will be accepted by nodes running the new version, but rejected by nodes running the older version. Let’s say that this 2MB block is validated by an updated node, and added on to the blockchain. But what if the next block is validated by a node running an older version of the protocol? It will try to add its block to the blockchain, but it will detect that the latest block is not valid. So, it will ignore that block and attach its new validation to the previous one. Suddenly you have two blockchains, one with both older and newer version blocks, and another with only older version blocks. Which chain grows faster will depend on which nodes get the next blocks validated, and there could end up being additional splits. It is feasible that the two (or more) chains could grow in parallel indefinitely.


This is a hard fork, and it’s messy. It’s also risky, as it’s possible that bitcoins spent in a new block could then be spent again on an old block (since merchants, wallets and users running the previous code would not detect the spending on the new code, which they deem invalid). The only solution is for one branch to be abandoned in favour of the other, which involves some miners losing out (the transactions themselves would not be lost, they’d just be re-allocated). Or, all nodes switch to the newer version at the same time, which unfortunately is almost impossible to achieve in a decentralized, widely spread system. Or, Bitcoin splits, which would damage its usefulness and scalability. With a hard fork, since new version blocks are only accepted by upgraded nodes, it is essential that all nodes upgrade as soon as possible. This is very hard to achieve.

In March 2013, an accidental hard fork – brought on by an update which led to a database glitch – split the blockchain. The chain mined by updated nodes was longer than the chain containing only older nodes, so it would have been more efficient for the shorter chain transactions to pass to the longer chain. But that would have required a massive forced upgrade, which would have been logistically complicated, so the community decided to abandon the update and go back to the previous version.

For examples of changes that would require a hard fork, see the “hardfork wishlist”.

If, however, the protocol is changed in a way that tightens the rules, that implements a cosmetic change or that adds a function that does not affect the structure in any way, then new version blocks will be accepted by old version nodes. Not the other way around, though: the newer, “tighter” version would reject old version blocks. Old-version miners would realize that their blocks were being pushed off (“orphaned”), and would upgrade. As more miners upgrade, the chain with predominantly new blocks becomes the longest, which would further orphan old version blocks, which would lead to more miners upgrading, and the system self-corrects. Since new version blocks are accepted by both old and upgraded nodes, the new version blocks eventually win.

For instance, say the community decided to reduce the block size to 0.5MB from the current limit of 1MB. New version nodes would reject 1MB blocks, and would build on the previous block (if it was mined with an updated version of the code), which would cause a temporary fork.

This is a soft fork, and it’s already happened several times. Initially, Bitcoin didn’t have a block size limit. Introducing the limit of 1MB was done through a soft fork, since the new rule was “stricter” than the old one. The pay-to-script-hash function, which enhances the code without changing the structure (more on this later), was successfully added through a soft fork. This type of amendment requires only the majority of miners to upgrade, which makes it more feasible and less disruptive.

Soft forks do not carry the double-spend risk that plagues hard forks, since merchants and users running old nodes will read both new and old version blocks.

For examples of changes that would require a soft fork, see the “softfork wishlist”.

One interesting development to come out of the Hong Kong talks is Pieter Wiulle’s “segregated witness” proposal, which would enable Bitcoin to increase the number of possible transactions in a block without a hard fork (more details later). This has the Bitcoin community quite excited, as it would enable a greater level of growth, while avoiding the risks and the controversy. The drama is far from over, though. And the next time you find yourself setting the dinner table, think about using spoons instead.




Leave a Reply

Your email address will not be published. Required fields are marked *