Skip to content
Blockchain LabBlockchain LabTHE VENTURE STUDIO

LibraryConsensus2015Design paperCorpus record

Eclipse Attacks on Bitcoin's Peer-to-Peer Network

Eclipse Attacks. Ethan Heilman, Alison Kendler, Aviv Zohar and Sharon Goldberg.

Fill a node's peer table with attacker addresses so every connection the node opens lands on the attacker. The node can then be fed a private view of blocks and transactions.

A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.

A payment that treats one node's view as the network has not read this paper.
Evidence
Primary paper
Re-measured
No
Assumptions
3
Records linked
2

Code

Source, repository, and what is actually hosted

  • ePrint 2015/263https://eprint.iacr.org/2015/263
  • 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

    The defect

    A node that thinks it hears the network may be hearing only the attacker.

  2. Claim 02 · Paper model

    The rule

    Fill a node's peer table with attacker addresses so every connection the node opens lands on the attacker. The node can then be fed a private view of blocks and transactions.

  3. Claim 03 · Paper model

    How it is put together

    Bitcoin nodes, at the time of the paper, accepted incoming addresses and stored them. Restarting a node was a moment the table could be replaced. The victim does not need to be a majority. One merchant can be enough.

  4. Claim 04 · Paper model

    Where the claim stops

    The paper studies Bitcoin's 2015 peer manager, not every later client.

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 The defect

    Observation

    What the study says

    A node that thinks it hears the network may be hearing only the attacker.

    Model

    What has to hold

    The paper studies Bitcoin's 2015 peer manager, not every later client.

    Falsifier

    What would retire it

    How many outgoing peers does the node insist on choosing itself?

  2. 02 The rule

    Observation

    What the study says

    Fill a node's peer table with attacker addresses so every connection the node opens lands on the attacker. The node can then be fed a private view of blocks and transactions.

    Model

    What has to hold

    The paper studies Bitcoin's 2015 peer manager, not every later client.

    Falsifier

    What would retire it

    Can one IP range fill the address table?

  3. 03 How it is put together

    Observation

    What the study says

    Bitcoin nodes, at the time of the paper, accepted incoming addresses and stored them. Restarting a node was a moment the table could be replaced. The victim does not need to be a majority. One merchant can be enough.

    Model

    What has to hold

    The paper studies Bitcoin's 2015 peer manager, not every later client.

    Falsifier

    What would retire it

    Can one IP range fill the address table?

  4. 04 Where the claim stops

    Observation

    What the study says

    The paper studies Bitcoin's 2015 peer manager, not every later client.

    Model

    What has to hold

    The paper studies Bitcoin's 2015 peer manager, not every later client.

    Falsifier

    What would retire it

    What does the node do if every peer serves the same unusual tip?

03 Sequence

One action, as an operating tape

  1. 01Advertise many addresses the attacker controls.
  2. 02Wait until the victim evicts honest peers.
  3. 03Serve the victim a chain or a transaction set the rest of the network does not see.
  4. 04How many outgoing peers does the node insist on choosing itself?

04 Load-bearing

The argument, and where a pitch drops it

  1. Why it is still on the desk

    The cut

    A payment that treats one node's view as the network has not read this paper.

    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 studies Bitcoin's 2015 peer manager, not every later client.

  2. After the text

    The cut

    Clients added more outgoing connections, feeler connections and address-manager changes. The lesson stands: peer selection is part of consensus security.

    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 studies Bitcoin's 2015 peer manager, not every later client.

05 Register

What has to be true

  • Model · Not re-measured

    The paper studies Bitcoin's 2015 peer manager, not every later client.

  • Model · Not re-measured

    An eclipse is not a 51 percent attack.

  • Model · Not re-measured

    Fixes to address management change the attack. Cite the version.

06 Divergence

What happened after the paper

Clients added more outgoing connections, feeler connections and address-manager changes. The lesson stands: peer selection is part of consensus security.

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

  4. 0 of 3 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

A node that thinks it hears the network may be hearing only the attacker.

What the design proposes

  • Bitcoin nodes, at the time of the paper, accepted incoming addresses and stored them.
  • Restarting a node was a moment the table could be replaced.
  • The victim does not need to be a majority. One merchant can be enough.

How the mechanism is specified

  • Advertise many addresses the attacker controls.
  • Wait until the victim evicts honest peers.
  • Serve the victim a chain or a transaction set the rest of the network does not see.

What this page does not treat as proven

  • The paper studies Bitcoin's 2015 peer manager, not every later client.
  • An eclipse is not a 51 percent attack.
  • Fixes to address management change the attack. Cite the version.

Why the desk still reads it

A payment that treats one node's view as the network has not read this paper.

09 Lexicon

Terms, opened into the record

Eclipse
A view of the network supplied entirely by the attacker.
Address table
The store of peers a node will try later.

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.

Concepts

Protocols

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.