Bitcoin Cash: why Bitcoin split on 1 August 2017, and what happened to both sides after

Two answers to one question: how should Bitcoin carry more payments?

By 2017 Bitcoin’s blocks were often full. A block could hold about 1 MB of transactions, and when demand exceeded that, people paid more to get in and waited longer if they did not. Nobody disputed the problem. The dispute was about the fix, and it ran for years before it came to a head. Our block size war dossier reconstructs that history from the proposals, software releases and block records; this article is about the split it produced.

One camp wanted to keep the base layer small enough that ordinary people could run a node, and to grow capacity with SegWit, a soft fork that discounts signature data and fixes an old bug, plus payment systems built on top. The other camp wanted to raise the block size limit directly, which requires a hard fork: a rule change that older software rejects, so everyone must upgrade or split. Bitcoin Cash’s own website describes the divide the same way: “One side favored keeping blocks small and positioning Bitcoin as a settlement layer. The other believed in scaling on-chain to preserve its utility as everyday electronic cash.”

Both positions were held sincerely by people who had been in Bitcoin for years. If you are new to the vocabulary, our article on soft forks and hard forks explains why one kind of change can be rolled out gradually and the other cannot.

It started as a contingency plan

The immediate trigger was a deadline. A proposal called BIP148 would have had nodes reject any block that did not signal for SegWit from 1 August 2017, a tactic known as a user-activated soft fork. On 14 June 2017, Bitcoin Magazine reported, the mining hardware company Bitmain published a plan for a user-activated hard fork, or UAHF, with blocks of up to 8 MB. Bitmain framed it as insurance rather than a project: the UAHF “will only be launched in response to a successful BIP148 UASF.”

It became a project anyway. A software implementation called Bitcoin ABC adopted the UAHF rules, and in late July the mining pool ViaBTC said it would list the resulting coin under the name Bitcoin Cash. CoinDesk’s report from 26 July 2017 described the plan as two main changes, an 8 MB block size and the removal of SegWit, and set the time: 1 August at 12:20 UTC. One developer quoted in that report, Calin Culianu, tied it to the separate SegWit2x compromise, predicting that if that agreement’s promised block size increase failed to materialize, “many miners will likely defect to Bitcoin Cash.”

What changed in the code

The technical specification published by the Bitcoin Cash project is short and specific. The fork was time-based: it triggered when the median timestamp of the last eleven blocks passed 1501590000, which the document translates as 1 August 2017 at 12:20 UTC. Blocks up to 1,000,000 bytes stayed under the old rules. Above that, the software required the operator to allow at least 8,000,000 bytes, with the rationale that “8MB is chosen as a minimum since miners have indicated in the past that they would be willing to support such a size.”

Two details made the split clean. First, the specification required the very first post-fork block to be larger than 1 MB, so that Bitcoin nodes would reject it and the two chains could not accidentally rejoin. Second, it changed how transactions are signed, adding a flag called SIGHASH_FORKID, so a transaction valid on one chain would be invalid on the other. Without that replay protection, a payment on one chain could be copied onto the other by anyone who saw it.

SegWit was simply absent. The signing changes are described as an adaptation for a “non-Segwit deployment,” and none of the SegWit rules were carried over. That absence is what made Bitcoin Cash a different network rather than a variant: Bitcoin went on to activate SegWit later that month, and from then on the two chains accepted different transactions and different blocks.

1 August 2017: the ledger splits at block 478,558

The split has an unusually official description. In a memorandum on how to tax forked coins, the IRS Office of Chief Counsel wrote: “On August 1, 2017, at block height 478,558, the bitcoin ledger split into two separate ledgers. Bitcoin Cash became available and tradeable on cryptocurrency exchanges shortly after the fork occurred.” Every coin that existed at that height existed on both chains, so anyone holding bitcoin then also held the same amount of Bitcoin Cash, whether or not their wallet or exchange let them reach it.

Then, for several hours, nothing. The fork time passed at 12:20 UTC, but a chain needs a block, and mining one at Bitcoin’s difficulty with a small share of the hash power takes time. CoinDesk reported that ViaBTC mined the first Bitcoin Cash block at about 6:14 p.m. UTC, nearly six hours later. It was 1.915 MB and held 6,985 transactions, which made the point: it was a block Bitcoin’s rules would never have accepted.

From that block on there were two networks, two coins and two communities, each convinced the other had left. Bitcoin kept its name and ticker; Bitcoin Cash kept the shared history up to the split and set its own rules from there.

Bitcoin Cash splits again: Bitcoin SV, November 2018

Bitcoin Cash scheduled regular upgrades, and the one due on 15 November 2018 broke its community in two. The Bitcoin ABC side’s specification for that date added a new opcode, OP_CHECKDATASIG, required transactions within a block to be sorted in numerical order, and set a minimum transaction size of 100 bytes. It said nothing about the block size, which by then stood at 32 MB.

A rival implementation, Bitcoin SV, short for Satoshi’s Vision, rejected those changes. CoinDesk reported that it aimed instead to “restore retired code from the original bitcoin protocol” and to raise the block size “from 32 MB to 128 MB.” Its most prominent public supporter, CoinDesk reported, was Craig Wright, the subject of our article on the COPA ruling. In the days before the fork, mining pools supporting Bitcoin SV held a majority of Bitcoin Cash’s hash power, and there was open talk of a “hash war” in which each side would try to out-mine or disrupt the other.

The chain split on 15 November 2018 after block 556,766, the last block the two sides shared. Neither side eliminated the other. Bitcoin Cash continued under the ABC rules and Bitcoin SV continued as its own network. That is the recurring lesson of 2017 and 2018: when people who disagree about the rules cannot persuade each other, the system lets them separate rather than forcing one answer on everyone.

What the fork settled, and what it did not

The split answered one question for good: a hard fork with replay protection can create a working second chain without breaking the first. Holders ended up with coins on both. Exchanges, wallets and tax authorities had to decide how to treat the new asset, and the IRS memorandum quoted above is one result of that.

It did not settle the argument. Each community believes it kept the real Bitcoin, and no technical fact can adjudicate that; it is a question of which rules people choose to run and which coin they choose to value. What the record shows is narrower and more useful. Bitcoin’s rules were not changed by the fork. Bitcoin Cash’s rules did change, first to 8 MB blocks and then further, and its own disagreements produced a second split a little over fifteen months later. Both outcomes came from the same mechanism, people running the software they preferred, which is the part of the story that our block size war dossier is really about.

Separate the 2017 fork rules from present-day product claims

A historical fork specification answers which rules separated the networks at that point. It should not be used as a current specification for either network after later upgrades. Read the date and activation conditions before repeating a block-size or signing rule.

Replay protection addresses a narrower issue than wallet access: whether a signature intended for one branch can be reused as a valid spend on the other. It does not by itself establish that a custodian credited a customer, that a wallet supports both branches, or that a person can spend an output without satisfying its locking conditions.