A soft fork is a backward-compatible update to the previous version of the software that introduces a change leading to a tightening of the protocol rules.
TL;DR: A soft fork is a backward-compatible upgrade to Bitcoin’s consensus rules: it tightens the rules, so blocks and transactions created under the new rules remain valid for nodes running older software. Unlike a hard fork, a soft fork does not split the chain. The main consensus soft forks in Bitcoin’s history range from P2SH in April 2012 to Taproot, which activated on 14 November 2021 at block 709,632 after signaling by more than 90% of miners. Activation can be driven by miners (MASF), by users running nodes (UASF, as with BIP148 in 2017), or by hybrid mechanisms like the Speedy Trial used for Taproot.
What is a soft fork?
A soft fork is a backward-compatible change to a blockchain’s consensus rules. In Bitcoin, it works by tightening the rules: things that were valid before become invalid, while everything created under the new rules remains valid for nodes that have not upgraded. Old nodes keep accepting the blocks produced by upgraded miners, unaware that those blocks follow stricter criteria. This is why a soft fork, unlike a hard fork, does not force every participant to upgrade and does not split the network into two chains.
To understand how this is possible, it is first necessary to clarify what is meant by a fork.
What is a fork in Bitcoin?
The Bitcoin blockchain is, among other things, a distributed database across thousands of computers called nodes. Each node verifies and stores all blockchain information in its storage space. Information between nodes is disseminated through the gossip protocol and does not reach the entire network simultaneously. Each peer receives the data, verifies it, and forwards it to neighboring peers, resulting in a temporal latency in information reception among all nodes, dictated by the physical limits of the Internet.
Let’s imagine we are at block number 3, as shown in the image. When a miner finds a solution to the Proof-of-Work and sends the next block to neighboring peers, they receive it before other nodes. Now, imagine that simultaneously with the first miner, another miner finds a valid solution and transmits their block to nearby nodes. In such an event, two distinct blocks spread across the network, both potentially valid. Nodes closest to the first miner’s node receive block 4a first, while those closest to the second miner’s node receive block 4b first.
After a short time, nodes close to the first miner also receive block 4b, while nodes close to the second miner receive block 4a. Thus, all network peers find themselves with two potentially valid versions of block 4. The first ones consider block 4a valid for the moment but do not discard block 4b; they keep it linked to block 3 in a blockchain that appears forked. This creates what is defined as a fork. Nodes that received block 4b first behave similarly, considering it valid and keeping block 4a in a forked chain.
At this point, miners who deem block 4a valid start searching for the Proof-of-Work solution for the next block, block 5a. Other miners try to find block 5b.
Let’s assume a miner who had considered block 4b valid finds a solution. The node spreads its candidate block 5b to the rest of the network: all nodes that had considered block 4b valid see that the next block is compatible with the chain and simply add it to their main blockchain. Nodes that had considered block 4a valid note that 5b is not compatible with the main chain but with block 4b they had kept in a forked chain. They face two chains, one with an additional block than the other.
Which chain is considered valid? As stated in the Bitcoin White Paper, “Nodes always consider the longest chain as correct and will continue to work to extend it.” In this case, the valid chain is the one that reaches block 5b, as it is the one with more accumulated computational work. Nodes that had considered block 4a valid discard it, consider the correct chain the one containing blocks 4b and 5b, and start searching for a Proof-of-Work solution for block 6b.
How does a soft fork work?
The operation just described often occurs in the Bitcoin network: it is a technical fork that, in the majority of cases, is resolved within one block. What happens when one wants to modify a consensus rule of the protocol?
When rules are tightened, meaning previously considered valid elements are subsequently considered invalid, the changes are compatible with versions of the old software. This happens because non-upgraded nodes continue to approve what they approved before, unaware that upgraded nodes are forwarding blocks with stricter parameters than theirs.
In essence, to be compatible with the future, transactions and blocks created with the new rules must also be valid according to the old rules, but not the other way around, as the past history is already established.
It’s important to note that a soft fork is not a fork in the traditional sense; there is no chain separation in a soft fork. However, implementing a soft fork is a delicate operation: since it introduces additional consensus constraints by tightening the rules, a soft fork is in practice an irreversible change once the network has adopted it.
How is a soft fork activated?
Changing Bitcoin’s consensus rules requires coordination among miners, node operators, developers and users. Over the years, the network has used several activation mechanisms, each trying to balance safety (avoiding chain splits) with progress.
Flag day and supermajority signaling
The first soft fork, P2SH (BIP16), activated in April 2012 on a flag day: a predetermined date at which the new rules came into force, with miner signaling used only as an advisory poll. Later upgrades (BIP34, BIP66, BIP65) used the mechanism known as “IsSuperMajority”: the new rules activated once 95% of the last 1,000 blocks signaled support by incrementing the block version number. The approach had structural flaws: it had no timeout and consumed the entire version field, so only one upgrade could be deployed at a time.
BIP9 version bits
BIP9 fixed those flaws by turning the version field into a bitfield: each proposed upgrade gets its own bit, multiple deployments can run in parallel, and each has a defined timeout. Activation requires 95% of blocks signaling within a 2,016-block retargeting period. CSV (BIP68, BIP112, BIP113) activated this way in July 2016 without controversy. SegWit, deployed with the same mechanism, did not: miner signaling stalled for months at around 30-44%.
MASF and UASF
These dynamics define the two broad categories of soft fork activation:
- Miner Activated Soft Fork (MASF): the majority of miners signal readiness and enforce the new rules;
- User Activated Soft Fork (UASF): node operators commit to enforcing the new rules at a given time regardless of miner signaling, putting the economic pressure on miners to follow.
The most famous UASF is BIP148, which in 2017 committed nodes to rejecting blocks that did not signal SegWit starting 1 August 2017. Faced with that deadline, miners coordinated through BIP91, a bridge mechanism with an 80% threshold that forced SegWit signaling. SegWit locked in on 9 August 2017 at block 479,808 and activated on 24 August 2017 at block 481,824.
Speedy Trial
For Taproot, the community had near-universal consensus on the upgrade itself; the debate was about how to activate it. The chosen mechanism, Speedy Trial, lowered the threshold to 90% of blocks within a difficulty period and compressed the signaling window to about three months: a quick test of miner support, with the option to try other paths if signaling failed. Miners locked Taproot in by June 2021, and the rules took effect on 14 November 2021 at block 709,632.
Which soft forks have happened in Bitcoin’s history?
The table below lists the main consensus soft forks activated in Bitcoin’s history.
| Soft fork | BIPs | Activation | Block height | Mechanism |
|---|---|---|---|---|
| P2SH | BIP16 | 1 April 2012 | 173,805 | Flag day |
| Height in coinbase | BIP34 | 25 March 2013 | 227,931 | Supermajority (95%) |
| Strict DER signatures | BIP66 | 4 July 2015 | 363,725 | Supermajority (95%) |
| CheckLockTimeVerify | BIP65 | 14 December 2015 | 388,381 | Supermajority (95%) |
| CSV, relative timelocks | BIP68, BIP112, BIP113 | 4 July 2016 | 419,328 | BIP9 version bits |
| SegWit | BIP141, BIP143, BIP147 | 24 August 2017 | 481,824 | BIP9 + BIP91/BIP148 |
| Taproot | BIP340, BIP341, BIP342 | 14 November 2021 | 709,632 | Speedy Trial |
SegWit (2017): a contentious activation
Segregated Witness moved signature data (“witness” data) outside the part of the transaction used to compute the transaction ID. This fixed transaction malleability and increased block capacity through the block weight system, all within soft fork rules: for old nodes, SegWit transactions look like valid anyone-can-spend outputs. Its activation became the focal point of the scaling debate, was resolved through the combined pressure of BIP148 (UASF) and BIP91, and demonstrated in practice that economic nodes, not only miners, decide Bitcoin’s rules.
Taproot (2021): the Speedy Trial
Taproot introduced Schnorr signatures (BIP340), Taproot outputs (BIP341) and Tapscript (BIP342). It improves privacy and efficiency by making complex spending conditions look like simple single-signature payments when spent cooperatively. It activated smoothly via Speedy Trial, with over 90% of hashrate signaling support.
What is the difference between a soft fork and a hard fork?
A hard fork is a loosening or incompatible change of the consensus rules: blocks valid under the new rules are rejected by old nodes. If part of the network keeps running the old software, the chain splits permanently into two networks with a shared history, as happened with Bitcoin Cash on 1 August 2017.
Key differences:
- Compatibility: a soft fork is backward compatible; a hard fork is not.
- Chain split: a soft fork does not create a new chain; a hard fork can create two permanent chains.
- Upgrade requirement: in a soft fork, non-upgraded nodes keep following the network; in a hard fork, every node must upgrade to stay on the new chain.
- Direction of change: a soft fork restricts what is valid; a hard fork expands or changes it.
A soft fork remains a delicate operation: since it adds consensus constraints, it is in practice irreversible once the network has adopted it.
Frequently asked questions
What is a soft fork in simple terms?
It is a software upgrade that tightens a blockchain’s rules in a backward-compatible way. Nodes that do not upgrade keep working and accept the new blocks, so the network does not split.
Is a soft fork the same as a hard fork?
No. A soft fork restricts the consensus rules and old nodes remain compatible. A hard fork relaxes or changes them in a way old nodes reject, which can split the chain into two networks, as with Bitcoin Cash in 2017.
How many soft forks has Bitcoin had?
The count depends on the criteria used, but the main consensus soft forks activated are P2SH (2012), BIP34 (2013), BIP66 (2015), CLTV (2015), CSV (2016), SegWit (2017) and Taproot (2021).
Was SegWit a soft fork or a hard fork?
A soft fork. SegWit transactions are valid under the old rules too, which is what allowed it to activate without splitting the chain. It activated on 24 August 2017 at block 481,824.
What is a UASF?
A User Activated Soft Fork: node operators enforce the new rules from a set date regardless of miner support. BIP148, which pushed SegWit activation in 2017, is the best-known example.
Can a soft fork be reversed?
In practice, no. Removing a restriction introduced by a soft fork would itself be a hard fork, because blocks valid under the loosened rules would be rejected by nodes still enforcing the restriction.
