On 8 August 2026 at 19:35:55 UTC, the AntPool blockchain and earns a reward, which makes rewriting history very expensive.">mining smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool found Bitcoin block 961,632. The block’s version field left bit 4 unset. Most nodes ignored that detail: the block was valid and F2Pool built on it at 20:18:56 UTC. For a small group of nodes enforcing BIP-110, a temporary rule change meant to limit arbitrary data in Bitcoin transactions, the same block was invalid, and what followed is a live lesson in soft fork vs hard fork mechanics.
Those nodes refused it and waited. They accepted a rival block 961,632, mined by a group called Roughnecks through the Ocean pool, and found themselves on a chain of their own. The Block reported that evening that this minority chain had produced two blocks while the main chain had moved on to 961,640. It never really started again.
BIP-110 was a soft fork, the kind of upgrade that is supposed to be backward-compatible. It still split Bitcoin, if only for a day and only for the people who ran it. Why that can happen is the shortest way into the whole question of soft fork vs hard fork, because the answer depends less on the code than on who runs it and who mines with it.
The word “fork” covers three different events. The first is the everyday race in which two miners find a block at the same height and one of them loses within minutes. The second is a planned upgrade of the rules, either a soft fork or a hard fork. The third is a chain split, when part of the community keeps the old rules (or adopts different ones) and a second coin is born, as with Ethereum Classic in 2016 and Bitcoin Cash in 2017. This lesson takes them in that order, then turns to what a split means for the coins you hold and for your tax return.
It follows the previous lesson of this path, finality and chain reorganisations, which explains how deep a reorganisation can go and why a payment becomes harder to undo with every block. Here the focus moves from “which block wins” to “which rules win”.
Two blocks at the same height: stale blocks, not orphans
What happens when two miners win at once
A new block takes a few seconds to cross a network of thousands of nodes, as our lesson on peer-to-peer networks and block propagation shows. If two miners find a valid block at almost the same moment, some nodes see one first and some see the other. Each node keeps the first one it received and keeps the other in reserve. Nobody disagrees about the rules: both blocks are valid, they simply arrived in a different order.
The tie breaks when the next block appears. Miners who built on block A extend that branch, the nodes that were following block B switch over because A’s branch now carries more work, and block B is dropped. Its transactions go back to the mempool and are usually included again in one of the next blocks. This is a fork in the literal sense, two branches from the same parent, but it lasts minutes and changes nothing about the protocol.
Orphan or stale: why the words got mixed up
The block that loses is often called an “orphan block” in the press and even on some block explorers. The Bitcoin developer glossary uses a stricter vocabulary. A stale block is a block that was mined correctly but is not part of the current best chain. An orphan block is something else: a block whose parent the local node has not received yet, so it cannot be fully checked for the moment. The second case is a node-level bookkeeping problem that fixes itself when the parent arrives; the first is the losing side of a race.
So when a headline says a pool “had a block orphaned”, it means a stale block. Stale blocks are rare on Bitcoin today, rare enough that researchers keep a public list of the ones they spot: the bitcoin-data stale-blocks dataset on GitHub is free to download. No monitor sees every one, because a stale block that reached few nodes may never be recorded.
For a user the consequence is small but real. If your transaction sat in a block that went stale, its confirmation count drops back to zero until it is mined again. It is not lost and nobody stole it, but this is one of the reasons exchanges wait for several confirmations before crediting a deposit.
Soft fork vs hard fork: which nodes get left behind
A planned fork changes the rules that every full node checks. The difference between a soft fork and a hard fork lies in how the new rules relate to the old ones, and therefore in what happens to the nodes that do not upgrade.
A soft fork tightens the rules
A soft fork only forbids things that used to be allowed. The Bitcoin glossary describes it as a change in which only previously valid blocks or transactions become invalid. Every block made under the new rules is still valid under the old ones, so a node that never upgrades keeps accepting new blocks and stays on the same chain. It just stops checking everything: the new restrictions are enforced by the upgraded nodes and by the miners, not by the old software.
Bitcoin has used soft forks for its larger upgrades. Segregated Witness (SegWit) in 2017 moved signature data into a new structure that old nodes do not look at, and Taproot in 2021 added a new output type with new spending rules. In both cases a node running software from years earlier could keep following the chain without noticing much.
The catch is in the word “compatible”. A soft fork is backward-compatible only if the miners producing most of the blocks enforce the new rules. If they do, the chain that old nodes follow is also valid for upgraded nodes, and everyone stays together. If only a minority enforces the stricter rules, the upgraded nodes start rejecting blocks the majority keeps producing. They then sit on a slower chain of their own, which is exactly what happened to the BIP-110 nodes in August 2026. Soft forks are “soft” for the side that has the hash power.
A hard fork loosens or changes them
A hard fork does the opposite: it makes valid something that the old rules rejected, or changes a rule outright. The glossary calls the result a permanent divergence in the block chain, because nodes that have not upgraded see the first new-style block as invalid and refuse everything built on it. To stay on one chain, practically every node and every miner must upgrade before the switch.
Raising a block size limit is the classic example. A Bitcoin node of 2017 treated any block over its limit as invalid; Bitcoin Cash, which raised the limit, therefore had to be a hard fork. Ethereum works the other way round from Bitcoin: almost every Ethereum upgrade, from the DAO fork of 2016 to the Merge of 2022 and Fusaka in December 2025, has been a hard fork, coordinated by releasing new client software with a fixed activation block or epoch.
Not every hard fork creates a second coin. When everyone upgrades, the old chain simply stops: no one mines it and no one uses it. A second coin appears only when a group decides to keep the old rules alive.
| Soft fork | Hard fork | |
|---|---|---|
| Rule change | Tightens: some previously valid blocks or transactions become invalid | Loosens or changes: some previously invalid blocks become valid |
| Nodes that do not upgrade | Keep following the chain, without checking the new rules | Reject the new blocks and stay on the old chain |
| What keeps the chain together | Most of the hash power (Bitcoin) enforcing the new rules | Nearly every node and miner upgrading in time |
| Examples | SegWit (2017), Taproot (2021) on Bitcoin | Bitcoin Cash (2017); Ethereum upgrades such as London (2021), the Merge (2022), Pectra and Fusaka (2025) |
| When it splits the chain | When only a minority enforces it (BIP-110, August 2026) | When part of the community refuses it (Ethereum Classic, 2016) |
Accidental forks: when a bug writes the rules
Some forks are nobody’s plan. In August 2010 a value-overflow bug let one transaction create about 184 billion bitcoins. The fix was a patched client that rejected such outputs, in effect a soft fork, and the corrected chain overtook the bad one; the full story is in our guide to whether a blockchain can be hacked. In March 2013, a block that Bitcoin 0.8 accepted was rejected by older versions limited by their database settings, and the chain stayed split until two large pools went back to the old version. BIP 50 documents that accidental fork, and the previous lesson gives its depth.
Ethereum had its own on 11 November 2020. A consensus bug had been fixed quietly in a recent release of Geth, its most used client, and at block 11,234,873 nodes still running older versions followed a different chain from the upgraded ones. Blockchair developer Nikita Zhavoronkov, who called it an unannounced hard fork, counted about 30 blocks on the short branch, which lasted around two hours. Infura, the infrastructure provider behind many wallets, was on the wrong side, and some exchanges paused ether withdrawals while operators upgraded. Nobody had voted for that fork. Old software had simply been left running.
How an upgrade gets switched on
Bitcoin: miners signal, nodes enforce
Bitcoin has no release date that forces an upgrade. Its soft forks are usually switched on by a counting method described in BIP 9. Miners set a chosen bit in the version field of the blocks they produce to show they are ready. Every 2,016 blocks, the length of a difficulty period, nodes count the signals. If 1,916 of the 2,016 blocks (95 percent) carry the bit, the change is locked in, and it becomes active one period later. If the deadline passes first, the attempt fails. BIP 9 names the stages DEFINED, STARTED, LOCKED_IN, ACTIVE and FAILED.
Signalling is not voting in the political sense. It is a way for miners to say “we will enforce this”, so that a soft fork starts only when the hash power behind it is large enough to keep the chain together. The 2017 SegWit saga showed its limit: miner signalling stayed far below 95 percent for months, while a camp of large miners and companies pushed for bigger blocks instead.
Users answered with a user-activated soft fork, BIP 148: from 1 August 2017, nodes running it would reject any block that did not signal SegWit. Miners began signalling before that deadline, and SegWit became active at block 481,824 on 24 August 2017 at 01:57 UTC. The big-block camp took another road. Part of it launched Bitcoin Cash on 1 August, and the “SegWit2x” plan of the New York Agreement, a 2 MB hard fork planned for mid-November, was suspended on 8 November 2017 in an email from BitGo chief executive Mike Belshe, who cited a lack of consensus.
That fight led to new activation designs. BIP 8 adds an option to lock a change in automatically at the deadline whether or not miners signal, which split developers in early 2021 into “lock-in on timeout” true and false camps. Taproot used a compromise the community nicknamed Speedy Trial (the term is not in the BIP text): a short signalling window from 24 April to 11 August 2021, a lower threshold of 1,815 blocks out of 2,016 (90 percent) and a minimum activation height. According to BIP 341, the deployment activated at height 709,632, a block mined on 14 November 2021 at 05:15:27 UTC.
| Bitcoin soft fork | Method | Threshold | Outcome |
|---|---|---|---|
| SegWit (BIP 141) | BIP 9 version bit 1, pushed by the BIP 148 user-activated soft fork from 1 August 2017 | 95 percent (1,916 of 2,016 blocks) | Active at block 481,824, 24 Aug 2017, 01:57 UTC |
| Taproot (BIP 341) | BIP 9 variant (“Speedy Trial”), bit 2, window 24 Apr to 11 Aug 2021, minimum activation height | 90 percent (1,815 of 2,016) | Active at block 709,632, 14 Nov 2021, 05:15 UTC |
| BIP-110 (temporary data limits) | Modified BIP 9, bit 4, mandatory signalling from block 961,632 | 55 percent (1,109 of 2,016) | Never active on the main chain; minority chain stalled 8 Aug 2026; BIP marked Closed |
Sources: the BIP texts on GitHub and block times read on mempool.space, 7 November 2026.
Ethereum: a date on the calendar
Ethereum does not count miner or validator signals. Its core developers agree on a set of changes, client teams publish releases that switch them on at a fixed block or, since the Merge, at a fixed epoch, and every node operator has to install the new version before that moment. Because Ethereum has run two layers of software since 2022, operators must update both their execution client and their consensus client. A node that misses the deadline does not crash: it carries on along an abandoned chain that nobody else follows.
The list on ethereum.org shows how routine this has become. Several upgrades, such as Muir Glacier, Arrow Glacier and Gray Glacier, did nothing but push back the “difficulty bomb” that was meant to force the move away from mining. Others carried large changes: London introduced the base fee that is burned with every transaction, Paris was the Merge to proof of stake, Shapella opened staking withdrawals and Dencun added the cheaper “blob” space used by rollups.
Pectra went live on 7 May 2025 and brought, among others, EIP-7702, which lets ordinary accounts run code the way smart-contract wallets do, and EIP-7251, which raises the maximum effective balance of a single validator to 2,048 ETH. Fusaka followed on 3 December 2025 and is the latest upgrade live on mainnet as of 7 November 2026. The next one, Glamsterdam, with enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928), went live on the Sepolia test network on 6 October 2026, but its activation on the Hoodi test network was postponed in a note dated 22 October. In its announcement post, the Ethereum Foundation wrote: “The mainnet activation date has not yet been decided.”
| Date (UTC) | Ethereum upgrade | Block or epoch | Main change |
|---|---|---|---|
| 30 Jul 2015 | Frontier | Genesis | Launch of the network |
| 20 Jul 2016 | DAO fork | Block 1,920,000 | Returned the DAO’s funds; Ethereum Classic split off |
| 22 Nov 2016 | Spurious Dragon | Block 2,675,000 | Replay protection with chain IDs (EIP-155) |
| 5 Aug 2021 | London | Block 12,965,000 | Base fee burned with each transaction (EIP-1559) |
| 15 Sep 2022 | Paris (the Merge) | Block 15,537,394 | Switch from proof of work to proof of stake |
| 12 Apr 2023 | Shapella | Epoch 194,048 | Staking withdrawals |
| 13 Mar 2024 | Dencun | Epoch 269,568 | Blob space for rollups (EIP-4844) |
| 7 May 2025 | Pectra | Epoch 364,032 | EIP-7702 account code, 2,048 ETH maximum validator balance |
| 3 Dec 2025 | Fusaka | Epoch 411,392 | Latest live upgrade as of 7 Nov 2026 |
| Not set | Glamsterdam | Sepolia 6 Oct 2026; Hoodi postponed | Proposer-builder separation, block access lists |
Source: ethereum.org upgrade history and Ethereum Foundation blog, read 7 November 2026.
When a soft fork splits the chain: the BIP-110 episode
BIP-110, titled Reduced Data Temporary Softfork and written under the pseudonym Dathon Ohm, set out to limit at the consensus level the arbitrary data, such as inscriptions, that people store in Bitcoin transactions. Its rules would have made new output scripts over 34 bytes invalid (with an exception for OP_RETURN outputs up to 83 bytes), banned data pushes and witness items over 256 bytes, and outlawed several Taproot script features. They were meant to last 52,416 blocks, roughly a year, and to leave coins created before activation untouched.
The activation design is what made the split certain. Signalling used bit 4 with a threshold of only 55 percent, but from block 961,632 to block 963,647 signalling was mandatory: an enforcing node would reject every block that did not set the bit, whatever the count. In the last voluntary period, according to The Block, only 51 blocks out of 2,016, or 2.53 percent, had signalled. When the mandatory window opened on 8 August, the first block, AntPool’s, did not signal, and the minority went its own way.
The rival blocks were mined through Ocean, the pool whose chief technology officer at the time, according to The Block, was Luke Dashjr, maintainer of the Bitcoin Knots node software that enforced BIP-110. On 9 August 2026 the BIP text was updated with a one-line changelog entry: “Mark as Closed, following a chain split with stalled mining”. The main chain never reorganised. For an ordinary Bitcoin node, the two minority blocks were not even invalid: a soft fork block follows the old rules too, so they were simply stale blocks on a branch that lost the race.
Chain splits: Ethereum Classic, Bitcoin Cash and Bitcoin SV
A chain split is a hard fork, or occasionally a failed soft fork, in which both sides keep producing blocks. Each side has the full history up to the fork point, so every balance that existed at that height now exists twice. Whether the second chain becomes a coin people trade depends on miners, exchanges and users, not on the code alone.
Ethereum Classic, 2016: the fork part of the network refused
The story of The DAO, the investment contract drained in June 2016, and of the hard fork that moved its ether to a recovery contract is told in our lesson on immutability and social forks. In short: the fork activated at block 1,920,000 on 20 July 2016 at 13:20:40 UTC, and a minority of miners and users refused it on principle, keeping the original chain alive as Ethereum Classic (ETC). ethereum.org sums up their view: some miners refused because the DAO incident was not a defect in the protocol itself.
What matters here is the mechanics. Nobody had planned for the old chain to survive, so nothing told the two networks apart. A transaction signed on one chain was perfectly valid on the other. Someone who sent ether to an exchange could see an identical transfer of their ETC replayed by a third party on the Classic chain. This is called a replay attack, and it works especially well in the account model, where a transaction names a sender, a nonce and a recipient but nothing about which chain it belongs to (our lesson on the UTXO and account models explains nonces).
The fix came four months later. EIP-155, proposed by Vitalik Buterin and switched on with the Spurious Dragon upgrade at block 2,675,000 on 22 November 2016, lets a signature include a chain identifier, with chain ID 1 for Ethereum mainnet. A transaction signed this way for one chain ID is invalid on any other. The proposal explicitly encouraged Ethereum Classic to adopt the same scheme with a different identifier.
Markets moved faster than the developers. The Poloniex exchange opened ETC/BTC and ETC/ETH trading on 24 July 2016, as the Ethereum Classic blog noted that day, four days after the fork, and said users who held ether at the fork had a matching ETC balance. A coin no one had planned for had a price within a week. Ethereum Classic later suffered several 51 percent attacks, covered in our lesson on whether a blockchain can be hacked.
Bitcoin Cash, 2017: the block-size dispute ends in two coins
Bitcoin’s dispute was about capacity. One side wanted to raise the 1 MB block size limit with a hard fork; the other preferred SegWit, a soft fork, and second-layer payment systems. When SegWit looked set to win, a group of miners and companies launched Bitcoin Cash (BCH) through a planned hard fork known as UAHF, short for user-activated hard fork.
The UAHF technical specification is a short lesson in how to split a chain on purpose. The fork activated once the median time of recent blocks reached 12:20 UTC on 1 August 2017. The next block had to be larger than 1,000,000 bytes, so that it could never be valid on the original chain and the new chain could not be reorganised back onto it; nodes had to be configured to accept blocks of at least 8 MB. And every Bitcoin Cash transaction had to carry a new signature flag, SIGHASH_FORKID, so that it was invalid on Bitcoin: replay protection from the first day, the lesson of Ethereum Classic.
The last block both chains share is 478,558, mined at 13:16:14 UTC on 1 August 2017. On the Bitcoin chain, block 478,559 followed seven minutes later at 13:23:00 UTC, with 272,502 bytes of transactions. The first Bitcoin Cash block, also numbered 478,559, did not arrive until 18:12:41 UTC, almost five hours later: 1,915,175 bytes and 6,985 transactions. Two different blocks at the same height, each valid only under its own rules, is what a chain split looks like on an explorer.
Bitcoin SV, 2018, and the splits that followed
Bitcoin Cash split in turn on 15 November 2018, when the Bitcoin ABC and Bitcoin SV software camps disagreed on the next upgrade. Both camps pledged their hash power to defend their own chain, a short “hash war” followed, and major exchanges kept the BCH ticker for the ABC chain, while the other became Bitcoin SV (BSV). Another split came on 15 November 2020. Bitcoin ABC wanted miners to keep only 92 percent of each block reward and send 8 percent to a development fund, Decrypt reported ahead of the fork; the Bitcoin Cash Node software removed that rule, and the two camps went separate ways.
| Date | Split | Fork point | Cause | Replay protection |
|---|---|---|---|---|
| 20 Jul 2016 | Ethereum / Ethereum Classic | Block 1,920,000 | DAO fund recovery refused by part of the community | None at first; EIP-155 on Ethereum from 22 Nov 2016 |
| 1 Aug 2017 | Bitcoin / Bitcoin Cash | Last common block 478,558 | Block size limit raised to 8 MB instead of SegWit | Yes, SIGHASH_FORKID from the start |
| 15 Nov 2018 | Bitcoin Cash (ABC) / Bitcoin SV | Bitcoin Cash chain | Dispute over the protocol roadmap | Not covered here |
| 15 Nov 2020 | Bitcoin Cash Node / Bitcoin ABC | Bitcoin Cash chain | Plan to fund developers from the block reward | Not covered here |
| 8 Aug 2026 | Bitcoin / BIP-110 nodes | Block 961,632 | Data-limit soft fork enforced by a small minority | None; minority chain stalled after two blocks |
What happens to your coins when a chain splits
If you hold your own keys, the split happens to you whether you act or not. At the fork height your balance exists on both chains, controlled by the same private keys. You do not need to “claim” anything for the coins to exist. To spend the new ones you need a wallet that supports the new chain, and that is where most of the risk lies.
A few habits protect you. Wait until the new chain has replay protection, or until reputable wallets explain how they handle the split, before moving anything. A common practice is to first move the original coins to a fresh address on the original chain, with your usual wallet, and only then use the old keys on the new chain. Never type a recovery phrase into a “fork claim” website or app you found through an advert or a message: whoever sees that phrase controls every coin on every chain. Our guide to seed phrase security explains why no legitimate service needs it.
If your coins sit on an exchange, the exchange decides. It can credit the new coin, list it later, or ignore it. Coinbase’s Bitcoin Cash help page says customers were credited only for bitcoin held in their account at the fork, block 478,558 on 1 August 2017; bitcoin withdrawn before the fork or bought after it earned nothing. Coinbase added Bitcoin Cash as an asset its customers could buy, sell and send on 19 December 2017, more than four months later. Poloniex listed Ethereum Classic within four days. An exchange is under no obligation to support a minority fork, and many never do.
Nothing guarantees that a new coin is worth anything, or that it will still be traded in a year. A split is not a dividend and this lesson is not a recommendation to buy before one. For a planned upgrade where no split is expected, holders have nothing to do at all: no “migration”, no “token swap”, no new address. Messages that tell you to move your ether or your bitcoin “before the upgrade” are a well-known scam pattern.
Taxes on forked coins in the US and the UK
In the United States, the IRS set out its view in Revenue Ruling 2019-24. A hard fork alone creates no income if you receive no new coins. If new coins are recorded on the ledger after a hard fork and you are able to sell or transfer them, you have ordinary income equal to their fair market value at that moment, and that value becomes your cost basis. The ruling calls this receipt an airdrop following a hard fork. Coins you cannot reach, for example because your exchange does not support the new chain, are not yet income under this test. Our guide to crypto taxes in the United States covers how to report the income and later disposals.
British rules work through cost, not income. In HMRC’s Cryptoassets Manual, section CRYPTO22300, the new tokens go into a section 104 pool of their own, and part of the cost of the original tokens is moved to them: costs “must be split on a just and reasonable basis” under section 52(4) of the Taxation of Chargeable Gains Act 1992. The manual adds: “HMRC does not prescribe any particular apportionment method.” If your exchange does not recognise the new tokens, the manual allows putting all the cost on the original tokens, as long as that is just and reasonable, and mentions a negligible value claim as an alternative. See our guide to crypto taxes in the UK for the pooling rules.
For both countries the practical step is the same: record the date, the time and the dollar or pound value of what you received at the fork, and keep it with your other records. This is general information, not tax advice; a tax professional can apply it to your situation.
How to read fork news without getting fooled
Headlines use “fork” for everything from a two-minute stale block to a new coin. A few questions sort them out quickly. Is it an upgrade that everyone is expected to adopt, or a group leaving with its own rules? For a soft fork on Bitcoin, how many blocks are signalling, and is there a mandatory phase? For an Ethereum upgrade, have the client teams published releases with the activation epoch, and has the change already run on the test networks?
For a split, look at who is mining or validating the new chain, which exchanges have said in writing that they will support it, and whether transactions carry replay protection. Primary sources answer most of these questions: the BIP repository on GitHub, ethereum.org’s upgrade list, client release notes and the exchanges’ own help pages. A block explorer lets you check heights, block times and version bits yourself; reading one field by field is the subject of the next lesson of this path, on block explorers.
The next date to watch on this subject is Glamsterdam. As of 7 November 2026 it runs on Sepolia, its Hoodi activation has been postponed and no mainnet date is set. When one is announced, it will appear on ethereum.org and in the Ethereum Foundation’s blog, and every node operator will have until that epoch to upgrade.
