Bitcoin Soft Fork History: Every Consensus Change Explained

Complete Bitcoin Soft Fork Timeline

Bitcoin has undergone seven major soft fork upgrades since 2012. Each one tightened the consensus rules in a backward-compatible way: upgraded nodes enforce new rules while non-upgraded nodes continue to accept the blocks as valid (though they cannot fully validate the new features). This reference covers every consensus soft fork, the BIPs that defined them, and the activation methods used to deploy them.

For a broader look at how these BIPs fit into the full standards process, see the Bitcoin BIP reference guide.

BIP16: Pay-to-Script-Hash (P2SH)

The first Bitcoin soft fork activated on April 1, 2012 at block 173,805. P2SH allowed coins to be sent to a hash of a script rather than directly to a public key hash. The spender reveals the full redeem script only at spend time, enabling multisig addresses and more complex Bitcoin Script constructions without burdening senders with long output scripts.

BIP16 was activated via a flag day with advisory miner polling. This process was contentious: the original proposal (BIP12, OP_EVAL) was abandoned after a security vulnerability was discovered. Gavin Andresen then proposed BIP16, but Luke Dashjr objected and offered a competing BIP17 (OP_CHECKHASHVERIFY). The first planned activation on March 1, 2012 failed because fewer than 50% of the last 1,000 blocks signaled readiness. A second poll succeeded, pushing activation to April 1. This episode is sometimes called the "first Bitcoin developer war."

BIP34, BIP66, BIP65: The IsSuperMajority Era

Three soft forks used the IsSuperMajority (ISM) activation mechanism, which checked whether a sufficient percentage of the last 1,000 blocks used an incremented version number.

BIP34: Height in Coinbase (2013)

BIP34 required version 2 blocks to include the block height as the first item in the coinbase transaction's scriptSig. This prevented duplicate transaction IDs: without it, coinbase transactions at different heights could be identical, creating ambiguity in the UTXO set. ISM enforced a two-stage process: at 75% (block 224,413), version 2 blocks had to follow the new rule; at 95% (block 227,931), version 1 blocks were rejected entirely.

BIP66: Strict DER Signatures (2015)

BIP66 mandated strict DER encoding for all ECDSA signatures. Before this change, Bitcoin depended on OpenSSL's signature parsing, which behaved inconsistently across versions and platforms. This was a consensus risk: two nodes running different OpenSSL versions could disagree on whether a transaction was valid. Removing the OpenSSL dependency was essential for deterministic validation.

The activation itself triggered a notable incident. On July 4, 2015, shortly after the 95% threshold was reached, a non-upgraded miner produced an invalid block. Roughly half the network hashrate was performing SPV mining (building on block headers without full validation), which propagated the invalid chain to six blocks deep. The incident cost miners over $50,000 and led to recommendations that SPV wallet users wait for 30 confirmations until all major pools switched to full validation.

BIP65: OP_CHECKLOCKTIMEVERIFY (2015)

BIP65 added the OP_CHECKLOCKTIMEVERIFY (CLTV) opcode, enabling absolute timelocks at the script level. A transaction output can be made unspendable until a specific block height or Unix timestamp. This enabled payment channels, escrow, and time-locked savings directly in Bitcoin Script. BIP65 was the last soft fork to use ISM. For more on how timelocks work in practice, see our research on Bitcoin timelocks: CLTV and CSV.

ISM had structural problems that motivated its replacement: the rolling 1,000-block window was imprecise, there was no timeout (a failed deployment would never expire), and it consumed the entire block version number rather than individual bits.

BIP68/112/113: Relative Timelocks and the First BIP9 Deployment

The CSV soft fork, activated on July 4, 2016 at block 419,328, was the first to use the BIP9 versionbits mechanism. It bundled three BIPs together:

• BIP68 repurposed the nSequence field to enforce relative lock-times, preventing a transaction input from being mined until a specified number of blocks or elapsed time after the output it spends was confirmed
• BIP112 added OP_CHECKSEQUENCEVERIFY (CSV), enabling script-level relative timelock verification, which was critical for bidirectional payment channels and the Lightning Network
• BIP113 changed nLockTime and CLTV to use the median of the last 11 block timestamps (Median Time Past) instead of the raw block timestamp, preventing miners from manipulating timelock enforcement

BIP9 versionbits represented a major improvement over ISM. Instead of incrementing the block version number, it used individual bits in the version field as a bitfield. This allowed multiple soft forks to be signaled in parallel. BIP9 measured signaling over 2,016-block retarget periods (approximately two weeks), required a 95% threshold (1,916 of 2,016 blocks), and included a defined timeout so failed deployments would expire cleanly. CSV signaling reached threshold quickly, locking in at block 417,312 with 96.53% support.

BIP141/143/147: Segregated Witness

SegWit activated on August 24, 2017 at block 481,824. It was the most significant protocol upgrade in Bitcoin's history at that point and the most contentious to deploy.

BIP141 restructured the transaction format to move signature ( witness) data outside the transaction ID calculation. It replaced the 1 MB block size limit with a 4 million weight unit block weight limit, effectively increasing capacity to roughly 2 to 2.3 MB per block. By fixing transaction malleability, SegWit made second-layer protocols like Lightning viable. BIP143 introduced a new signature hashing algorithm that solved quadratic hashing and enabled safer hardware wallet signing. BIP147 required the dummy stack element in OP_CHECKMULTISIG to be exactly OP_0, eliminating a minor malleability vector.

The SegWit Activation Crisis

BIP9 signaling for SegWit began on November 15, 2016. Miner signaling stalled around 30 to 44%, far below the 95% threshold. Several large mining pools, particularly those aligned with Bitmain, refused to signal in favor of a block size increase via hard fork.

In March 2017, Shaolin Fry authored BIP148 (User Activated Soft Fork), proposing that nodes reject any block not signaling for SegWit after August 1, 2017. This created direct economic pressure on miners. In May 2017, 58 companies signed the New York Agreement (NYA), a compromise to activate SegWit first and then hard fork to 2 MB blocks within 90 days (SegWit2x). Bitcoin Core developers were excluded from and opposed the agreement.

James Hilliard's BIP91 acted as a compatibility bridge: it required only 80% signaling over 336-block periods and, once activated, forced SegWit signaling. BIP91 locked in on July 21, 2017 at block 477,120, defusing the BIP148 deadline. SegWit locked in on August 9 at block 479,808 and activated on August 24 at block 481,824. The SegWit2x hard fork was cancelled on November 8, 2017 due to lack of community consensus. Bitcoin Cash had already forked away on August 1. For a deeper look at SegWit's technical impact, see SegWit adoption tracker.

BIP340/341/342: Taproot and Schnorr Signatures

Taproot activated on November 14, 2021 at block 709,632. Unlike SegWit, the upgrade itself had near-universal community support. The debate centered entirely on how to activate it.

BIP340 introduced Schnorr signatures as an alternative to ECDSA. Schnorr signatures are more efficient, enable native key aggregation (MuSig2), and allow batch validation for faster block verification. BIP341 introduced Taproot outputs (P2TR), a new SegWit v1 output type that combines a public key path with an optional Merkle tree of scripts. Simple spends appear identical to single-signature transactions regardless of underlying complexity, improving privacy. BIP342 (Tapscript) updated Bitcoin Script for Taproot script-path spends, replacing OP_CHECKMULTISIG with OP_CHECKSIGADD and introducing OP_SUCCESS opcodes for easier future upgrades. For a full technical breakdown, see Taproot and Schnorr signatures explained.

The LOT Debate and Speedy Trial

BIP8 was proposed as an improved activation mechanism with a key parameter: lockinontimeout (LOT). With LOT=true, nodes would require signaling in the final period if threshold was not met, effectively forcing activation. With LOT=false, an unsuccessful deployment would simply expire. LOT=true advocates argued that universally supported upgrades should not be blockable by miners. LOT=false advocates warned that forced activation was dangerous precedent.

The compromise was Speedy Trial: a short three-month signaling window with a lowered 90% threshold (1,815 of 2,016 blocks). If miners did not signal, the deployment would expire harmlessly and the community could reassess. If they did, a long delay before activation (roughly five months) gave everyone time to upgrade. The 90% threshold was met in the second signaling period at block 687,284 on June 12, 2021. Taproot activated at block 709,632 on November 14.

Activation Methods Compared

Bitcoin has used four distinct activation mechanisms across its soft fork history, each designed to address shortcomings in its predecessor.

The evolution from flag days to Speedy Trial reflects a recurring tension in Bitcoin governance: how to coordinate upgrades across a decentralized network where miners, node operators, developers, and users may have competing interests. Each mechanism attempts to balance safety (avoiding chain splits) with progress (deploying improvements that have broad support). For more on how consensus rules are enforced, see the consensus rules reference.

What Soft Forks Enable Today

The cumulative effect of these soft forks defines modern Bitcoin functionality. P2SH made multisig practical and enabled HD wallet standards. CLTV and CSV provided the timelock primitives that Lightning payment channels depend on. SegWit fixed transaction malleability, increased block capacity, and introduced the witness discount that makes Lightning economically viable. Taproot brought Schnorr signatures, key aggregation, and Tapscript, laying the groundwork for more advanced constructions like FROST threshold signatures and potential future covenants.

Layer 2 protocols like Lightning and Spark build directly on these consensus changes. Spark leverages Taproot and Schnorr-based key aggregation for its off-chain Bitcoin and stablecoin transfers. Understanding the soft fork history is essential for understanding what is and is not possible at the protocol layer today.

Frequently Asked Questions

What is the difference between a soft fork and a hard fork?

A soft fork tightens consensus rules: blocks valid under the new rules are also valid under the old rules, so non-upgraded nodes still accept the chain. A hard fork loosens or changes rules in a way that non-upgraded nodes reject, causing a permanent chain split unless all nodes upgrade. Every Bitcoin consensus change since 2012 has been a soft fork. Hard forks have produced separate chains like Bitcoin Cash (August 1, 2017) and Bitcoin SV (November 15, 2018).

How many soft forks has Bitcoin had?

Bitcoin has had seven major soft forks: BIP16 (P2SH, 2012), BIP34 (height in coinbase, 2013), BIP66 (strict DER, 2015), BIP65 (CLTV, 2015), BIP68/112/113 (CSV and relative timelocks, 2016), BIP141/143/147 (SegWit, 2017), and BIP340/341/342 (Taproot, 2021). Some earlier changes were also soft forks (such as the introduction of OP_NOP and the 1 MB block size limit), but these predate formal BIP-based activation processes.

Why did SegWit take so long to activate?

SegWit's activation was delayed by a political conflict between those who wanted to increase block capacity via a hard fork and those who preferred SegWit's soft fork approach. Several large mining pools withheld signaling to pressure for a block size hard fork. BIP9 signaling stalled at 30 to 44% for months. Resolution came through a combination of BIP148 (a user-activated soft fork threat), the New York Agreement compromise, and BIP91 (a lower-threshold bridge that forced SegWit signaling). The entire process took about nine months from signaling start to activation.

What is Speedy Trial and how does it differ from BIP9?

Speedy Trial, used for Taproot activation, is a modified version of BIP9 with two key changes: a lower threshold (90% instead of 95%) and a shorter signaling window (approximately three months instead of a year or more). If miners signal support within the window, activation happens after a long delay. If they do not, the deployment expires without consequence. This design prevents the extended stalling that plagued SegWit while giving the community a clear fallback path if signaling fails.

What was the LOT=true vs LOT=false debate?

LOT stands for lockinontimeout, a parameter in BIP8. LOT=true means that if the signaling threshold is not met by the timeout, nodes would force activation by requiring signaling in the final period. LOT=false means the deployment simply expires. The debate was about whether miners should have veto power over upgrades that the broader community supports. Speedy Trial sidestepped the issue by using a short window where the LOT question became less relevant.

Could a soft fork accidentally cause a chain split?

Yes, temporarily. The BIP66 activation on July 4, 2015 produced an invalid chain fork six blocks deep because miners were performing SPV mining (building on headers without full validation). A non-upgraded miner produced a block that violated the new strict DER rule, and SPV miners extended it. The chain reorganized once fully validating miners caught up, but lightweight wallet users were briefly at risk. This incident demonstrated why running a full node matters during soft fork activations.

Is there a soft fork planned after Taproot?

As of mid-2026, no soft fork has reached the deployment stage after Taproot. Several proposals are under active discussion, including OP_CAT (BIP347), OP_VAULT, and various covenant designs. These would enable new capabilities like vaults, more expressive smart contracts, and improved Layer 2 constructions. However, none has achieved the broad consensus needed to begin an activation attempt. The activation method for the next soft fork also remains an open question.

This reference is for informational purposes only and does not constitute financial or technical advice. Dates, block heights, and activation details are based on publicly available protocol documentation and blockchain records. Always consult the original BIP specifications and Bitcoin Core release notes for authoritative details.