Bitcoin: All the Hard Forks and Soft Forks

This article describes every consensus upgrade Bitcoin has ever switched on without splitting its ledger. It is also the opening piece from the upcoming ”BTCTKVR: Forks!” magazine, which will get launched in October 2026 at Tabconf 8 in Atlanta, Georgia.

While most of the forks featured in this magazine were born the moment a group of people decided they could no longer share a blockchain with everyone else, this particular article is about the opposite behavior. It’s about the times Bitcoin changed the rules and everybody stayed. Eight times since 2012, the network has tightened what counts as a valid block. Eight times the chain, the coins, and the history carried on as one. Here is a comprehensive list that describes how each change was switched on, and the handful of cases where the story is messier than the block height suggests.

If you enjoy reading this piece, make sure you also check out the articles about Bitcoin Cash and Bitcoin SV!

Soft forks tighten the rules, hard forks change them

What’s in scope for this particular article is soft forks and genuine, general will hard forks that changed the consensus rules of Bitcoin mainnet while keeping one continuous chain and one continuous set of unspent coins.

For now, we won’t cover the coins that split off with their own copy of the ledger (Bitcoin Cash, Bitcoin SV, Paul’s eCash BIP300 fork and friends). We will also not take into account peer-to-peer changes that never touched block validity (BIP37 bloom filters, for example), address formats that only encode rules already in force, and relay policy that a node applies to its own mempool but not to blocks.

For the sake of correctness, it’s worth noting that research stopped on September 17th 2026. Heights follow the mainnet parameters shipped in Bitcoin Core’s src/kernel/chainparams.cpp, or the BIP text where Core still runs the deployment through version bits (Taproot). Activation times are the header time field of the activating block, read from mempool.space and shown in UTC, unless a BIP fixed a flag-day timestamp instead.

Two caveats worth knowing: a block’s header time is set by the miner and can drift a couple of hours from wall-clock time, and Core has quietly rewritten several old activations into simpler height checks (BIP90). So the code you read today is not always the code that ran at the time. Maybe there’s a reason why Satoshi decided to not name it the “timechain” (as the pre-release version of Bitcoin called it in November 2008) and opted for blockchain instead. Probably the best reason would be that Bitcoin is bad at telling the time, even if some people use block height for time stamping events.

Has Bitcoin ever hard forked?

No intended hard-fork upgrade has ever activated on the Bitcoin chain. The project’s tradition is to tighten rules rather than loosen them, so that a node running old software still follows the majority chain even if it cannot fully validate the new features. The one serious attempt at a coordinated hard fork of the main chain, the SegWit2x block size increase proposed in the 2017 New York Agreement, was called off before its planned block 494,784 activation. BIP101, 102, 103, and every other proposal to increase the block size has only been debated, without benefiting from a clear activation path.

But the honest answer is that Bitcoin’s chain has split by accident twice in its existence, and one of the incidents is arguably a hard fork.

First there’s the 2010 value overflow. On August 15th 2010, at block height 74,638, a transaction created roughly 184 billion bitcoin through an integer overflow. Satoshi Nakamoto quickly patched the software to launch version 0.3.10. The new client added the missing range check, miners reorganized the chain about 53 blocks later, and the bad block vanished from history. The inflation bug fix was a tightening, so it counts as a soft fork with an unusually violent activation.

Then there’s the March 2013 database split. Bitcoin 0.8 replaced Berkeley DB with LevelDB and, without anyone realizing, removed an implicit limit of about 10,000 database locks that older versions hit when processing large blocks. On March 11th 2013, block 225,430 triggered a split of at least 24 blocks. To end this accidental fork, the pools downgraded their software to version 0.7. During the confusion that ensued, one experimental double spend succeeded. Version 0.8.1 shipped a temporary rule (no more than 4,500 transaction IDs referenced by inputs in a block) that expired on May 15th 2013.

On August 16th 2013, block 252,451 finally exceeded the old limit and forked unpatched nodes off for good. BIP50, the post-mortem, later removed the words “hard fork” because the limit was never a written rule and varied from node to node. BitMEX Research and Jameson Lopp both argue that, on balance, it was one anyway. To please every side of the debate, let’s say that this was the closest Bitcoin has come to hard forking.

A third, quieter case was CVE-2018-17144. Disclosed in September 2018 by a Bitcoin Cash developer, this bug would have let a miner spend the same input twice within a block. Core versions 0.14.0 to 0.16.2 carried it. No block ever exploited it, so no split occurred… but strictly speaking, those versions had loosened a rule without anyone noticing and the patch tightened it back.

If the entire network updates to the latest version of the client in order to make a change, is that not a hard fork? Well, you could argue that the older broken version is still in consensus and therefore anyone can run it. But in practice, it’s unsafe to do so and every network participant chooses to make the switch.

How a soft fork gets switched on

Bitcoin has never had one fixed procedure for soft fork activation. Each generation of developers attempted to fix the failures of the previous one. As you can see in the table below, there are seven different ways… and every time a new proposal emerges (such as BIP300, CTV, or OP_CAT), the community must figure out how to reach the fabled consensus.

MECHANISM	DEFINED IN	HOW IT WORKS	WHERE IT WAS USED, AND WHAT WENT WRONG
Flag day after a miner poll	BIP16 pattern	Miners put a marker (`/P2SH/`) in coinbase text; if support looked sufficient, enforcement began at a fixed timestamp	P2SH, 2012. Fragile: the date slipped twice (1 Feb, 1 Mar, then 1 Apr) and an early enforcement bug produced the block 170060 exception
IsSuperMajority (ISM)	BIP34 pattern	Nodes count block `nVersion` over the last 1,000 blocks: at 750 the new rule is enforced on new-version blocks, at 950 old-version blocks are rejected	BIP34, BIP66, BIP65. No timeout, and only one upgrade could run at a time
Version bits	BIP9	Each proposal gets its own bit in `nVersion`, a start time and a timeout (both median-time-past); 1,916 of 2,016 blocks (95%) in one retarget period locks it in, and it activates one period later	CSV suite (bit 0), SegWit (bit 1). Gave miners an effective veto, which the SegWit fight exposed
Version bits with forced lock-in	BIP8	BIP9 measured in heights instead of time, with an optional `lockinontimeout` that makes signaling mandatory in the final period	Debated at length for Taproot; never used for a mainnet activation. BIP343 was a parallel BIP8 (LOT=true) client that stayed compatible with Speedy Trial
Speedy Trial	BIP9 variant, described in BIP341	Short signaling window (about three months), 1,815 of 2,016 blocks (90%), plus a `min_activation_height` that delays enforcement	Taproot, 2021. Locked in within seven weeks
Miner-enforced bridge	BIP91	Miners reject blocks that do not signal an existing BIP9 bit, with an 80% threshold over 336 blocks, so the original deployment can reach 95%	SegWit, July 2017
User-activated soft fork (UASF)	BIP148	Nodes reject any block that does not signal SegWit from 1 August 2017	Pressure tactic rather than a feature; see Deferred below

Before there were BIPs

The list below starts in 2012 because that is when Bitcoin began announcing rule changes in advance. Satoshi tightened the rules several times in 2010 with nothing more than a software release, so these have version numbers rather than clean activation heights. BitMEX’s fork history warns that no precise date can be given where the change went through without a split.

July to August 2010 (0.3.5 to 0.3.8): a batch of script opcodes was disabled outright, among them OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT and OP_RSHIFT, after a bug let anyone spend any output. OP_VER, OP_VERIF and OP_VERNOTIF were made invalid at the same time, along with a 10,000-byte script size cap and a 201-opcode limit.
August 2010 (0.3.10): output value range checks, the response to the overflow described above.
September 2010 (0.3.12): the 1,000,000-byte block size limit and the 20,000 signature-operations limit, written into the code so that enforcement began at block 79,400.

None of these was announced as a fork. All of them still bind every block mined today.

The eight activated soft forks

These Bitcoin upgrades are ordered by the block height at which they were activated. “Core” is the first release that shipped the rule.

#	UPGRADE	BIPS	HEIGHT	ACTIVATION (UTC)	METHOD	CORE
1	Pay to Script Hash (P2SH)	BIP16	173,805 (first block after the flag day)	Flag day 2012-04-01 00:00; block 173,805 mined around 00:43	Flag day after `/P2SH/` poll	0.6.0
2	No duplicate transaction IDs	BIP30	Timestamp rule at first, later applied to every block except 91,842 and 91,880	2012-03-15 00:00 (blocks with header time above 1331769600)	Flag day, later extended	0.6.0 era
3	Block height in coinbase	BIP34	227,931	2013-03-25 07:30:09	ISM on version 2	0.7.0
4	Strict DER signatures	BIP66	363,725	2015-07-04 01:54:32	ISM on version 3	0.10.0
5	CHECKLOCKTIMEVERIFY (CLTV)	BIP65	388,381	2015-12-14 17:24:44	ISM on version 4	0.11.2
6	CSV suite (relative locktime)	BIP68, BIP112, BIP113	419,328 (locked in from 417,312)	2016-07-04 23:16:01	BIP9 bit 0, “csv”	0.12.1
7	Segregated Witness (with NULLDUMMY)	BIP141, BIP143, BIP147 (BIP144 for P2P)	481,824 (locked in from 479,808)	Lock-in 2017-08-09; active 2017-08-24 01:57:37	BIP9 bit 1, pushed over the line by BIP91 and BIP148	0.13.1
8	Taproot	BIP340, BIP341, BIP342	709,632 (locked in at block 687,285 on 2021-06-12)	2021-11-14 05:15:27	Speedy Trial, bit 2, 90%, minimum activation height	0.21.1

What each one actually did, in a sentence: P2SH let a sender pay to the hash of a script so the recipient carries the complexity (the origin of addresses starting with 3). BIP30 closed a loophole in which two transactions could share an ID. BIP34 forced miners to write the block height into the coinbase, which made BIP30’s problem impossible in practice. BIP66 stopped relying on OpenSSL’s forgiving signature parser, after it turned out that different parsers could disagree on validity. CLTV gave Bitcoin its first absolute timelock opcode.

The CSV suite added relative timelocks (BIP68 in the sequence field, BIP112 as an opcode) and made a block’s locktime comparisons use median-time-past (BIP113), the plumbing that Lightning channels depend on. SegWit moved signatures out of the transaction ID, fixing third-party malleability and raising capacity through the weight limit, while NULLDUMMY removed a small malleability vector in multisig. Taproot introduced Schnorr signatures, a new output type where a single key and a tree of scripts look identical on chain, and a cleaner script version for the future.

Where the block heights are contested

P2SH: date or height? BIP16 says the rule applies to blocks with a header timestamp of 1333238400 (April 1st 2012, 00:00 UTC) or later. Bitcoin Core 0.16.0 briefly expressed this as BIP16Height = 173805. Since 0.17.0 Core takes a different approach: it applies P2SH and witness rules to every block back to genesis, with one exception… block 170,060 (hash beginning 00000000000002dc…), which spent a P2SH-looking output under the old rules a few weeks before the flag day. That list of exceptions later grew to include one block from 2021 that would fail Taproot rules if judged retroactively. For historic purposes, quote the flag day; for what Core enforces today, use the exception list.
BIP34: 227,835 or 227,931? The BIP’s results section records the last version-1 block as 227,835. Core’s BIP34Height is 227,931 (hash ending 0808b8), the point at which its simplified BIP90 check begins. Use 227,931 as the enforced activation height and cite the BIP text for the last-v1 story.
SegWit: lock-in versus activation. The BIP9 state machine reached LOCKED_IN at height 479,808 (August 9th 2017) and ACTIVE one retarget period later at 481,824 (August 24th 2017). Both dates circulate as “the SegWit date”; only the second is when the rules took effect.
BIP30’s two exceptions. Blocks 91,842 and 91,880 contain coinbase transactions that duplicate those of blocks 91,812 and 91,722 respectively. They are grandfathered forever. Core also stops checking BIP30 once BIP34 is active, except that it must resume at height 1,983,702, where a version-1 block’s coinbase could in principle collide with a BIP34-style serialized height.

BIP91: a mechanism, not a feature

BIP91 (“Reduced threshold Segwit MASF”) added no script rule of its own. From late July 2017 miners running it rejected blocks that did not signal SegWit’s bit 1, which pushed the original BIP9 deployment past 95% and averted the 1 August UASF deadline. It belongs in the SegWit factsheet under activation politics; a standalone sheet is optional.

Deferred: proposals that shaped the story without becoming rules

These are tagged “deferred, scope expansion” and must not be counted as activated upgrades.

ITEM	WHAT IT WAS	WHY IT SITS HERE
BIP148 UASF	Nodes reject non-signaling blocks from August 1st 2017	An activation tactic and a coordination story, not a new script feature
SegWit2x (NYA, btc1 client)	A 2 MB base block hard fork planned for block 494,784, roughly three months after SegWit	Suspended on November 8th 2017; would have hard forked BTC; the politics fed the Bitcoin Cash split at block 478,559 on August 1st 2017
BIP149	A second SegWit deployment using BIP8 with a 2018 forced timeout	Made unnecessary once BIP91 and BIP148 forced the issue
BIP62	Cer A catalogue of malleability fixes	Withdrawn as written; its parts resurfaced as BIP66, NULLDUMMY and SegWit
OP_EVAL (BIP12)	Gavin Andresen’s first attempt at pay-to-script	Rejected for allowing unbounded recursion; replaced by BIP16 (and BIP17, another alternative, also lost)
Covenant and other future proposals	OP_CTV (BIP119), OP_CAT revival (BIP347), LNHANCE and others	Not activated as of the research date; out of scope until one is

Explicitly out of scope

BIP37 bloom filters: a peer-to-peer privacy and denial-of-service topic, not consensus.
BIP70 payment protocol: application layer.
Address encodings BIP13, BIP173 (bech32) and BIP350 (bech32m): they describe how to write down outputs whose rules P2SH, SegWit and Taproot already define.
Relay and standardness policy changes that never applied to block validity.

This essay is part of BTCTKVR: Forks!, my free 2026 magazine about Bitcoin forks. Start with What the Fork?! for the overview, or hear the guests argue it in their own words in Bitcoin Forks, Described by Dorks.