Skip to content

LibraryConsensus2015Design paperCorpus record

Secure High-Rate Transaction Processing in Bitcoin

GHOST. Yonatan Sompolinsky and Aviv Zohar.

At high block rates the longest chain throws away too much honest work. GHOST follows the heaviest subtree, so blocks off the main tip still count for the fork choice.

GHOST picks the heaviest subtree rather than the longest chain, so honest blocks that lost a race still count as work for the fork they support.
Evidence
Primary paper
Re-measured
No
Assumptions
4
Records linked
6

Code

Source, repository, and what is actually hosted

  • ePrint 2013/881https://eprint.iacr.org/2013/881
  • The source URL is not a GitHub repository. No code remote is invented.
  • Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
  • Add to a reading list

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

  1. Claim 01 · Paper model

    Fast blocks collide

    If the interval is short, two honest miners often find a block before either has seen the other. Longest-chain throws one away. The attacker, publishing in private, collides less and keeps more of their work.

  2. Claim 02 · Paper model

    Count the subtree

    At a fork, follow the child whose descendant tree contains the most work. An uncle that lost the tip still adds weight on the side that mined it.

  3. Claim 03 · Paper model

    The attacker must beat the forest

    Overtaking means outpacing the honest subtree, not a single path that got lucky with orphans.

  4. Claim 04 · Paper model

    Ethereum's uncles are not this protocol

    Paying uncles and mentioning them is related. GHOST is a fork-choice rule. A chain can pay uncles and still follow the longest chain.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

  1. 01 Fast blocks collide

    Observation

    What the study says

    If the interval is short, two honest miners often find a block before either has seen the other. Longest-chain throws one away. The attacker, publishing in private, collides less and keeps more of their work.

    Model

    What has to hold

    Work in the subtree is visible. A block that never propagates adds nothing.

    Falsifier

    What would retire it

    What block interval is assumed, and what is the measured orphan rate?

  2. 02 Count the subtree

    Observation

    What the study says

    At a fork, follow the child whose descendant tree contains the most work. An uncle that lost the tip still adds weight on the side that mined it.

    Model

    What has to hold

    Work in the subtree is visible. A block that never propagates adds nothing.

    Falsifier

    What would retire it

    Does the fork choice compare subtree weight or chain length?

  3. 03 The attacker must beat the forest

    Observation

    What the study says

    Overtaking means outpacing the honest subtree, not a single path that got lucky with orphans.

    Model

    What has to hold

    Work in the subtree is visible. A block that never propagates adds nothing.

    Falsifier

    What would retire it

    Does the fork choice compare subtree weight or chain length?

  4. 04 Ethereum's uncles are not this protocol

    Observation

    What the study says

    Paying uncles and mentioning them is related. GHOST is a fork-choice rule. A chain can pay uncles and still follow the longest chain.

    Model

    What has to hold

    Confirmation depth is still chosen by the user. The fork choice does not pick it.

    Falsifier

    What would retire it

    Does the fork choice compare subtree weight or chain length?

03 Sequence

One action, as an operating tape

  1. 01Miners publish blocks that may arrive to different nodes in different orders.
  2. 02A node builds the tree of all blocks it has seen.
  3. 03Starting at the genesis child, it chooses the branch with the heaviest subtree.
  4. 04That path is the chain it mines on and the chain it uses for confirmation counts.
  5. 05A block off that path can still add weight. It is not deleted from the security argument.

04 Load-bearing

The argument, and where a pitch drops it

  1. Orphans were a security hole, not just wasted fees

    The cut

    The paper's claim is that at high rates the longest chain quietly changes the honesty assumption. GHOST is a repair of the fork choice, not a throughput feature you can advertise on its own.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    The paper is not PHANTOM and not SPECTRE. Those are blockDAG protocols with different ordering rules.

  2. Weight is not finality

    The cut

    A heavier subtree is still a probabilistic claim. It does not give the accountable checkpoint Casper later asked for.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    Heavier subtrees do not by themselves give fast finality.

05 Register

What has to be true

  • Model · Not re-measured

    Work in the subtree is visible. A block that never propagates adds nothing.

  • Model · Not re-measured

    Miners build on the heaviest subtree they know. Strategic withholding is outside the basic claim.

  • Network · Not re-measured

    The network delay is what creates collisions. The paper does not remove delay. It changes how collisions score.

  • Model · Not re-measured

    Confirmation depth is still chosen by the user. The fork choice does not pick it.

06 Divergence

What happened after the paper

Ethereum cited GHOST in its early research and then implemented a simpler uncle-aware chain. PHANTOM and SPECTRE move from a tree to a DAG. If a team says GHOST, make them show the subtree comparison. A list of uncles is not enough.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

  1. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

The problem it names

If blocks are fast, two honest miners often publish at once. Bitcoin's longest-chain rule orphans one of them. An attacker who does not suffer the same collisions gains an edge. The paper is about that edge.

What the design proposes

  • Choose the chain by the weight of the subtree, not by the number of blocks in a single path.
  • Honest blocks that lost the race still contribute weight.
  • The security claim is about the fraction of hash power, at rates where orphans are common.

How the mechanism is specified

  • From the genesis, at each fork pick the child whose subtree contains the most work.
  • An attacker must outpace that subtree, not a thin path of lucky blocks.
  • Ethereum's later uncle rewards are a cousin of this idea. They are not an implementation of this fork choice.

What this page does not treat as proven

  • Heavier subtrees do not by themselves give fast finality.
  • The paper is not PHANTOM and not SPECTRE. Those are blockDAG protocols with different ordering rules.
  • A high rate still raises validation and propagation costs. The fork choice does not pay them.

Why the desk still reads it

When a design shortens the block time and still cites 'the Bitcoin rule', ask what happens to honest blocks that arrive second. GHOST is one answer. It is not the only one.

09 Lexicon

Terms, opened into the record

Subtree weight
The total work in a block and everything that builds on it, including branches.
Orphan
A valid block that lost the race to be on the canonical path.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.