Skip to content
DonateБГ

Blockchain

Soft fork

A bitcoin soft fork tightens the rules, so nodes that did not upgrade still accept new blocks. Learn how activation works, with BIP 9 and BIP 8.

By Dimitar Zurnov · Updated 4 Nov 2026
Adapted from Learn Me a Bitcoin by Greg Walker.

A soft fork is an upgrade that makes the rules stricter. Blocks made under the new rules are still valid under the old ones, so nodes that did not upgrade keep following the chain. Every major bitcoin upgrade so far has been a soft fork.

How is a soft fork different from a hard fork?

A soft fork restricts what counts as a valid block or transaction. A hard fork expands the rules, or changes them in a way that old nodes reject. That difference decides what happens to nodes that do not upgrade.

A soft fork shrinks the set of valid blocks. Every block valid under the new rules is also valid under the old ones. Valid before the upgrade Valid after no longer valid
A new rule might ban a kind of transaction that the old rules allowed.

With a soft fork, an old node still accepts every block that upgraded miners make. It does not need to know the new rule, because the new blocks already pass the old checks too. Old nodes keep up with the chain without upgrading.

How does a soft fork take effect?

Before a rule switches on, miners have to agree to enforce it. They show that agreement in the block header. The version field is four bytes, and under BIP 9 its top three bits must be 001. Each of the remaining bits, numbered 0 to 28, can carry one soft fork. A miner who sets a bit says the miner will enforce that rule.

Under BIP 9, a soft fork moves through a few states. Most of the changes are checked once per 2,016-block period:

  • Defined: the rule is proposed, and the start time has not come yet.
  • Started: from the start time, miners signal in each period. Blocks that set the bit are counted.
  • Locked in: if at least the threshold of blocks in one period signal, the rule is locked in for one more period. The usual threshold is 95%, or 1,916 of 2,016 blocks.
  • Active: the rule is enforced from the activation height onward.
  • Failed: if the timeout passes before lock-in, the attempt ends for good.
A soft fork moves through four states: defined, started, locked in, then active. A timeout before lock-in sends it to failed. Defined waiting for the start time Started miners signal in each 2,016-block period Locked in enough signals seen, one more period to wait Active new rules are enforced from this height Failed the timeout came first, and it stays failed
Under BIP 9, the start and timeout are times. The lock-in and activation are counted in blocks.

The start and timeout are set as times, measured by median time past rather than by a single block's timestamp. A BIP 9 timeout is usually a year after the start.

What are Speedy Trial and BIP 8?

These are two ways to set those parameters, and they are often confused.

Speedy Trial is the short version of BIP 9. Taproot used it. Its signalling window ran from 24 April 2021 to 11 August 2021, about three and a half months. The threshold was lowered to 90%, or 1,815 of 2,016 blocks. Taproot also had a minimum activation height of 709,632. The rule locked in during the window and became active at that height in November 2021. A short window is quick, but if too few miners signal in time, the attempt fails and has to be tried again.

BIP 8 replaces the time-based timeout with a height-based one, and it adds a safety switch called lockinontimeout. With that switch on, the last period before the timeout is a must-signal period. Miners must set the bit, and a block that does not signal can be rejected once so many blocks have failed to signal that the threshold is out of reach. That guarantees lock-in by the timeout height. The trade-off is that nodes that enforce it may briefly follow a different chain from nodes that do not. BIP 8 recommends a 90% threshold. In 2021 some developers argued for BIP 8 with this switch on, but Taproot activated with the shorter BIP 9 window.

What happens if miners do not agree?

The main risk is a split. If too few miners enforce the new rule, the upgraded nodes see a chain split. Their chain follows the new rules, while the other side carries on with the old ones. Blocks from the old side can still form the longest chain, and the upgraded nodes reject them, so the two sides separate.

Unlike a hard fork, the split can heal. If the upgraded side gains enough hash power, its chain wins, and the old nodes reorganize onto it. Enough miners upgrading is what keeps everyone on one chain.

Which soft forks has bitcoin had?

The list below gives each soft fork by the first block where its rule applied. The date is when that block was mined, in UTC.

Seven soft forks in order, from P2SH in 2012 to Taproot in 2021, each with the first block where its rule applied. Pay to script hash (BIP 16) block 173,805, mined 1 April 2012 Block height in the coinbase (BIP 34) block 227,931, mined 25 March 2013 Strict DER signatures (BIP 66) block 363,725, mined 4 July 2015 CHECKLOCKTIMEVERIFY (BIP 65) block 388,381, mined 14 December 2015 Relative locktimes (BIP 68, 112, 113) block 419,328, mined 4 July 2016 Segregated Witness (BIP 141) block 481,824, mined 24 August 2017 Taproot (BIP 341) block 709,632, mined 14 November 2021
Each height is the first block under the rule, checked against Bitcoin Core's chain parameters.
  • P2SH (BIP 16): a script hash output gets extra checks. This one switched on by time, not height. The rule applied to blocks with timestamps from 1 April 2012, and the first such block is block 173,805.
  • BIP 34: from block 227,931, every coinbase transaction must include the block height. BIP 30, from 2012, banned a duplicate transaction ID only while the earlier transaction still had unspent outputs, so duplicate coinbases could still appear later. The height makes every coinbase unique.
  • BIP 66: signatures must follow one strict encoding, so implementations do not have to copy the looser parsing of OpenSSL. This activated at block 363,725.
  • BIP 65: the OP_NOP2 opcode became OP_CHECKLOCKTIMEVERIFY, which locks an output until a set height or time. This activated at block 388,381.
  • BIP 68, 112 and 113: relative locktimes and the OP_CHECKSEQUENCEVERIFY opcode. These activated at block 419,328.
  • SegWit (BIP 141): signatures move into a separate witness section, which is not part of the transaction ID. This activated at block 481,824.
  • Taproot (BIP 341): a new output type that can be spent with one key or a chosen script, so only the path used is revealed. This activated at block 709,632.

Why are most upgrades soft forks?

A soft fork lets everyone keep running the software they have while the network moves on. A hard fork forces every node to upgrade or fall behind. The cost of a soft fork is complexity. The new rules must fit inside the old ones, and that can make the code harder to read. SegWit is the usual example. Old nodes treat its new outputs as spendable by anyone, so they accept the blocks without checking the witness.

Summary

Soft forks are upgrades that old software can live with, because they only tighten the rules. Miners signal, and the rule locks in once enough of them agree. BIP 9 sets the process, Speedy Trial is its short form, and BIP 8 adds a height-based deadline. Bitcoin has used soft forks for every major upgrade, from P2SH in 2012 to Taproot in 2021.

In this section: Blockchain

All of Bitcoin from zero

Something look wrong? Tell us