Crypto Gloss

Eclipse Attack

An eclipse attack is a peer-to-peer network attack in which an attacker controls all, or enough, of a target node’s connections to keep it from receiving information from honest peers. The attacker can then filter or delay what that one node sees. An eclipse does not give the attacker control of the whole blockchain, and a fully validating node still rejects blocks that violate its consensus rules; the danger is that the node may act on an incomplete or distorted view of the network. The term is most often discussed in the Bitcoin peer-to-peer (P2P) network.

How an eclipse attack works

A node learns about blocks and transactions through connections to other nodes. If an attacker can monopolize those connections, the victim can be isolated while still appearing to be online. The attacker may withhold new blocks, delay the victim’s transactions, or show the victim a valid but outdated or attacker-favored chain view. Address poisoning can help an attacker influence future peer choices, especially around a restart, but simply advertising many IP addresses is not enough by itself: the attacker also needs reachable, controlled peers and a way to occupy the victim’s connections.

The 2015 Bitcoin study tested an older client and described a restart-based attack. Its resource estimates belong to that historical software version and should not be used as a current estimate for today’s nodes. Peer selection, network conditions, client version, and the attacker’s access to the victim’s network all affect feasibility.

What an attacker may gain

An eclipse is usually a way to manipulate one victim’s information, or to prepare another attack, rather than a direct way to take coins from a wallet.

  • Payment deception: a merchant, wallet, or service that trusts an isolated node’s view may be misled about whether a payment has propagated or received confirmations. This can support a double spend in some scenarios.
  • Transaction censorship or delay: the attacker can prevent a victim’s transactions from reaching honest peers promptly, which may matter for time-sensitive actions.
  • Mining or protocol manipulation: the original research describes ways isolation could assist selfish mining or adversarial chain views. The impact depends on the victim’s role and the surrounding network; it is not automatic.

Eclipse, Sybil, and 51% attacks

These terms describe related but different things. A Sybil attack uses many identities or peers to gain influence. An eclipse attack is the result of isolating a particular victim; Sybil resources may be one way to do it, but many fake identities do not guarantee that the victim is eclipsed. A 51% attack concerns control of a majority of a proof-of-work network’s hash rate and the resulting ability to reorganize blocks. An eclipse focuses on what one target can hear, so it does not by itself establish majority control or a global consensus takeover.

Limits and defenses

Eclipse attacks do not make a correctly implemented full node accept an invalid block or forge a user’s signature. They exploit isolation: if a node cannot hear honest peers, it cannot compare the chain it sees with the wider network’s best-work chain. When honest connections return, a node can update to the best valid chain it learns about, but a user or service may already have acted on the earlier information.

Defenses aim to make it harder for one party to dominate a node’s peer set. They include diversified peer selection, connections across distinct networks, and reducing dependence on a single peer-discovery path. These measures raise the cost of an attack but do not prove that every client or configuration is immune. For example, Bitcoin Core’s 31.0 release notes say embedded AS-map data can support peer grouping by autonomous-system number, but the option remains off by default and must be enabled explicitly.

History

  • 2015: Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg presented a detailed Bitcoin P2P eclipse-attack analysis at USENIX Security. Its experiments and resource estimates applied to the client and conditions studied at that time.
  • 2020: Bitcoin Core 0.20.0 documented an experimental -asmap option for limiting connections by autonomous-system number as one peer-diversity measure.
  • 2026: Bitcoin Core 31.0 release notes describe embedded AS-map data while retaining the setting as opt-in, illustrating that peer diversity is an ongoing configuration and engineering concern.

Common misconceptions

“An eclipse attack is the same as a 51% attack.”
No. It targets one node’s network connections; it does not necessarily give an attacker majority hash power or control of the network’s global consensus.

“A flood of fake addresses proves that nodes have been eclipsed.”
No. Address flooding can be a peer-discovery concern, but an observed increase in advertised addresses is not proof that an attacker has captured any particular node’s connections. Reachable attacker-controlled peers and successful isolation are also needed.

“An eclipsed full node will accept invalid blocks.”
A full node continues to enforce its consensus rules on the blocks it receives. The attacker tries to hide honest information or present an incomplete competing view, not bypass signature checks or make an invalid block valid.

Social Media Sentiment

  • Reddit (r/Bitcoin): In a May 2026 discussion about a reported increase in advertised Bitcoin peer addresses, some commenters worried it could be reconnaissance for a Sybil or eclipse attack. Others stressed that unreachable fake addresses alone do not isolate a node and that the report did not prove a successful attack. This is one thread’s reaction to a reported network anomaly, not a finding that Bitcoin nodes were eclipsed. Read the r/Bitcoin discussion.

Last updated: 2026-10

Related Terms

See Also

Sources