What is a soft fork? What is a hard fork? What are their differences?

Question

When people talk about possible changes to how Bitcoin works they sometimes say a particular change can be implemented as a soft fork. What does that mean? How does this compare to a hard fork?

Answer 1

What is a Project Fork?

A fork in software development refers to the event of an independent project spinning off from a software project. Such forks sometimes occur in the opensource sphere, when there are irreconcilable plans/goals within a project's community, then often leading to a split in the community and two distinct projects thereafter. In practice this takes form in the sourcecode being copied and henceforth being developed in a different direction independently by the forkers. For example in this conventional sense of fork, Litecoin is a fork of Bitcoin: Litecoin started as a copy of Bitcoin's code-base, but developed into an independent project (although still closely related).

Softfork and Hardfork in Bitcoin terminology

The terms softfork and hardfork in Bitcoin describe compatibility breaking changes in the Bitcoin protocol: Should the community be irreconcilably divided about such an issue, the old version and the new version of Bitcoin could emerge as distinct projects thereafter. While both versions of the Bitcoin protocol are in use, the differences in acceptance may cause a lasting blockchain-fork, i.e. two distinct longest chains which are both considered valid by part of the network.

Softforks are forward compatible

Softforks restrict block acceptance rules in comparison to earlier versions.

The new rules allow a subset of the previous valid blocks, therefore all blocks considered valid by the newer version are also valid in the old version. If at least 51% of the mining power shifts to the new version, the system self-corrects:
Blocks created by old versions of Bitcoin Core that are invalid under the new paradigm might commence a short-term "old-only blockchain-fork", but eventually, they would be overtaken by the chain fork created under the new paradigm, as the hashing power working on the old paradigm would be smaller ("only old versions") than on the new paradigm ("accepted by all versions").

However, if less than 51% of the hashing power switches to the new version, the blockchain-fork will not mend automatically as the chain created under the old rules has more hashing power and is incompatible to the new rules. This can either be remedied by the adopters of the softfork giving up their chain, or more hashing power switching to the softfork chain. The latter would cause the softfork chain to eventually overtake and reorganize the other chaintip.

Hardforks are not forward compatible

Hardforks ease block acceptance rules making previously invalid blocks valid in the new version. Obviously, this is not forward compatible as older versions will not accept the new blocks, causing the users of the old paradigm to remain on their own blockchain-fork indefinitely. To implement a hardfork, without a blockchain-fork, all users must switch to the new protocol consensually.

HF != blockchain-forks

Lately, I've seen "hardfork" being used interchangeably with "chain split". They refer to different things. A chain split is the state of the network when mining is based on more than one chaintip at the same time. This can happen for various reasons, including hardforks, softforks, buggy node software, and simply two miners discovering a block at the same height.

Answer 2

Softforks are forwards-compatible

Old nodes will accept blocks created by new nodes.

With a softfork, only miners will have to upgrade, or else they will end up on the losing fork. Users and merchants can keep running older nodes, which will accept the newer blocks.

Hardforks are not forwards-compatible

Old nodes may not accept blocks created by new nodes.

With a hardfork, everyone (miners, users, and merchants) will need to upgrade to the new code.

Answer 3

I found the best exact definition in the First three paragraphs here: gavinandresen / BitcoinVersioning

We recently rolled out two changes to the Bitcoin block acceptance rules (BIP16 and BIP30); this document records the lessons learned and makes recommendations for handling future blockchain rule changes.

Note: there are "soft" rule changes and "hard" rule changes. "Soft" changes tighten up the rules-- old software will accept all the blocks and transactions created by new software, but the opposite may not be true. "Soft" changes do not require the entire network of miners and merchants and users to upgrade or be left behind.

"Hard" changes modify the rules in a way that old, un-upgraded software consider illegal. At this point it is much, much more difficult (some might say impossible) to roll out "hard" changes, because they require every miner and merchant and user to upgrade.

Answer 4

To quote Andreas Antonopulous:

you run a vegetarian only restaurant and if you change it to be an only-vegan restaurant then you are soft forking it, if you change it to include meat you are hard forking it

https://www.youtube.com/watch?v=rpeceXY1QBM

Answer 5

On a fork new nodes are introduced into the network, creating a 'dirty' network. I like to imagine green(old) and red(new) nodes maintaining a single blockchain at the launch time.

In a soft fork:

• If a new red block is mined it is accepted by all nodes, the network bchain grows normally.
• If an old green block is mined it is rejected by the new nodes, creating a do-or-die chain split. Unlike a normal chain split the new nodes will never accept the version with the old block.

As with each chain split the miners decide where they put their hashes. Since the hash difficulty doesn't change immediately the chain backed with most hashpower will grow the fastest. If the 'redblock' chain has enough mining support they win the race and old nodes adopt their chain, and the process repeats every time an old block gets mined.

Eventually one of the following happens:

• green blocks are no longer mined and the chain continues red. The fork was a successful upgrade.
• two different chains stabilize, the green-red chain has become too long to be rejected by a longer all-red one.

In the case of the latter, brand confusion may ensue, two chains means one is an altcoin. When this happens good quality wallet software should be able to make transactions on one particular chain. Each user, exchange and wallet maker will decide on which chain gets the original brand name (if any), typically this is related to philosophical or political choices. E.g. the chain with the most nodes and users vs. the chain with the most hashpower.

If the original brand is agreed (~consensus) to be the red chain it is expected much of the hold-out hashpower will migrate to that chain, as the market value is strongly correlated to the name and not the underlying technology. The altcoin technology would have to be significantly better to avoid this brand-drain. When a fork does not include replay protection it promotes confusion and prevents separating transactions; this is seen as a hostile brand-takeover attempt.

The backwards-compatible nature of soft forks means they can succeed on hashpower alone. A single node producing enough blocks (51%) can dominate an older network. To avoid hash-domination the older network must separate. This can be done by introducing an unpatchable incompatibility (i.e. a new software version) turning the SF into a hardfork. Note that the opposite does not follow: just because a SF with enough hashpower is guaranteed success, it doesn't mean a SF with little hashpower is doomed to fail. This is the theory behind the user activated soft fork (UASF) concept. The success of the UASF theory merely depends on:

1. a minimum threshold of miners to keep the transactions reasonably usable until the difficulty adjusts.
2. the original brand being transferred based on the (perceived) 'user support'.