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.
The five-minute read
The defect
A node that thinks it hears the network may be hearing only the attacker.
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.
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.
Where the claim stops
The paper studies Bitcoin's 2015 peer manager, not every later client.
One action, walked through
- 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.
- How many outgoing peers does the node insist on choosing itself?
The argument, unpacked
Why it is still on the desk
A payment that treats one node's view as the network has not read this paper.
After the text
Clients added more outgoing connections, feeler connections and address-manager changes. The lesson stands: peer selection is part of consensus security.
What has to be true
- 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.
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.
What to check before you use the idea
- How many outgoing peers does the node insist on choosing itself?
- Can one IP range fill the address table?
- What does the node do if every peer serves the same unusual tip?
Terms
- Eclipse
- A view of the network supplied entirely by the attacker.
- Address table
- The store of peers a node will try later.
The problem the paper 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 a venture studio still reads it
A payment that treats one node's view as the network has not read this paper.
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.