Secure High-Rate Transaction Processing in Bitcoin

The five-minute read

One action, walked through

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

The argument, unpacked

What has to be true

• Work in the subtree is visible. A block that never propagates adds nothing.
• Miners build on the heaviest subtree they know. Strategic withholding is outside the basic claim.
• The network delay is what creates collisions. The paper does not remove delay. It changes how collisions score.
• Confirmation depth is still chosen by the user. The fork choice does not pick it.

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.

What to check before you use the idea

• Does the fork choice compare subtree weight or chain length?
• Do off-path blocks add weight?
• What block interval is assumed, and what is the measured orphan rate?
• Is confirmation still probabilistic?

Terms

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.

The problem the paper 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 a venture studio 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.