Bitcoin VerityOpen comparator ↗

Bonus · Financial history and Bitcoin curiosities

When Bitcoin split into two histories in 2013

How versions 0.7 and 0.8 produced two branches, and why technical consensus still needs human coordination.

Article
B09
Reading time
10 minutes
Reviewed
26 September 2026

In a nutshell

On 11 March 2013 Bitcoin 0.8 accepted a large block that many 0.7 nodes rejected because of a database-lock limit. Two chains emerged. Miners temporarily returned to the older version to reunify the network. A seemingly minor implementation detail had become a consensus issue.

A child-friendly recap

In very simple terms

On 11 March 2013 Bitcoin 0.8 accepted a large block that many 0.7 nodes rejected because of a database-lock limit. Two chains emerged. Miners temporarily returned to the older version to reunify the network. A seemingly minor implementation detail had become a consensus issue.

01

The block that divided software versions

Bitcoin 0.8 used a different database from 0.7 and could process a block with an unusually large number of transaction inputs. Many older nodes hit a database-lock limit and rejected it, although developers had not intended a protocol change.

Some miners extended the 0.8 branch while others followed 0.7. Until one branch prevailed, the same coins could have different recent histories and payments faced higher reorganisation risk.

02

Why the older branch won

Developers, mining-pool operators and services coordinated publicly. Major pools temporarily moved back to version 0.7, adding hash rate to the branch accepted by more existing nodes. It accumulated more work and the 0.8 branch was abandoned.

The choice preserved compatibility; it did not mean old software was generally better. Later releases prevented the accidental mismatch from recurring.

03

Consensus is code plus operation

Consensus rules are executed by real code with databases and resource limits. If implementations disagree about one block, the network no longer has one result.

Human coordination helped restore a common history, but conversation alone did not alter blocks. Miners redirected work and nodes executed rules. The event demonstrates both a social layer and independent technical enforcement.

Bonus · Financial history and Bitcoin curiosities

Terms to know

Chain split
A state in which groups of nodes continue on different block histories.
Database lock
A mechanism controlling concurrent data access whose limits can affect block processing.
Backward compatibility
The ability of a newer system to remain acceptable to older versions.

Common misconception

Bitcoin always has one unambiguous history without human coordination.

A more accurate explanation

Nodes can temporarily follow different branches, and bugs can prolong the split. Rules and proof of work guide convergence, while operators still choose their software.

A more accurate explanation

Did the pools' intervention prove central control?

It showed their substantial practical influence in a crisis. Their decision still had to remain acceptable to nodes, services and users; broad refusal could have left two networks.

B09

Key takeaways

  1. 01The 2013 split came from different behaviour in versions 0.7 and 0.8.
  2. 02Even a database limit can become a consensus problem.
  3. 03Miners temporarily supported the older branch to preserve compatibility.
  4. 04Bitcoin joins software verification with decisions by the people operating it.

Reviewed: 26 September 2026

Sources and further reading

Sources support particular facts and definitions; listing one does not mean the editors endorse every view of its author.

01
BIP 50: chain-fork post-mortemBitcoin Improvement Proposals
bips.dev ↗
02
Bitcoin.org alert of 11 March 2013Bitcoin.org
bitcoin.org ↗
03
Princeton analysis of the fork responsePrinceton Center for Information Technology Policy
blog.citp.princeton.edu ↗

Educational material, not an investment recommendation.