The 2017 Bitcoin Cash split required engineered incompatibility

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

One history, then two rule sets

On 1 August 2017, a new set of consensus rules activated that rejected any block smaller than one megabyte, splitting a chain that shared identical transaction history up to that point into two separately validated networks. The technical specification for this hard fork sets the activation trigger as a median-time-past of 1,501,590,000, which is 1 August 2017, 12:20 UTC, and states plainly: 'This enforces the hard fork from the original 1MB chain and prevents a re-organization of the forked chain to the original chain.' Anyone holding bitcoin before that timestamp held a claim recorded identically on both resulting ledgers, because both chains inherited the same transaction history up to the split; what diverged afterwards were the validation rules each side would accept going forward.

Why replay protection was a named requirement

A coin recorded on both chains creates an immediate hazard: a transaction valid under one rule set could also be valid under the other, so broadcasting a payment on one network could unintentionally spend the same coins on the second. The specification's own replay-protection requirements point to a companion document, the replay-protected sighash specification, which defines a new signature flag, SIGHASH_FORKID, embedding a chain-specific identifier into what gets signed. A transaction signed with this flag produces a different, incompatible result on a chain that does not recognise the flag, so a payment intended for one network is rejected outright by the other rather than silently succeeding on both. This is a deliberate cryptographic incompatibility, engineered specifically because the two chains would otherwise be too similar to tell apart.

The boundary: same history, different assets, different security

What a holder of pre-fork coins possessed after 1 August 2017 was not one asset that later diverged in price, but two separately validated assets that briefly shared a ledger and then did not. The original paper's description of a chain as the record accepted by the longest accumulated proof of work applies independently to each resulting network from the split forward; each has since accumulated its own separate proof of work and depends on its own validating nodes and miners for security. Neither the technical specification nor the replay document says anything about which resulting network any market would value more highly, and this record should not be read to imply either. It documents a mechanism, not an outcome.

Questions to carry forward

• For a coin split like this one, does 'holders retained value' describe an accounting fact about the ledger, or a claim about subsequent market price?
• What later technical changes, if any, caused the two networks' transaction formats to diverge further from the shared starting point this fork created?
• Would a wallet that implements replay protection incorrectly still expose a user to the double-spend risk this specification was written to prevent?

The activation timestamp and the replay-protection design are the two facts this record supports without qualification: a rule change split one shared history into two independently enforced networks, and the split's engineers treated the resulting collision risk as serious enough to require a dedicated cryptographic fix.