Network Attacks: Eclipse, Sybil & Partitioning

Proof of work makes it ruinously expensive to rewrite the ledger. But before an attacker tries to out-mine the world, there’s a cheaper target: the wires between nodes. If you can’t beat the honest chain, maybe you can stop a victim from hearing about it. This page covers the three classic attacks on Bitcoin’s network layer — eclipse, Sybil, and partitioning — and why the same proof-of-work insight that secures consensus does not automatically secure connectivity.

The setup: a node’s narrow window

Recall from the P2P protocol that a node maintains only a modest number of connections — a few it dials outbound plus some inbound ones. That small neighbor set is the node’s entire view of the world. It learns about new blocks and transactions only through those peers. Control all of them, and you control the node’s reality. That’s the vulnerability every attack here exploits.

Eclipse attack — owning a victim’s peers

In an eclipse attack, the attacker arranges for every one of a victim node’s connections to be attacker-controlled. The victim isn’t disconnected — it thinks it’s healthy — but every block, transaction, and peer-address it receives is filtered through the attacker.

            (the honest network)
                 ╲  ╱  ╲  ╱
   ┌───────────────────────────────┐
   │   A   A   A   A   A   A   A    │   every peer slot = Attacker
   │    ╲  │  ╱  ╲  │  ╱  ╲  │      │
   │         VICTIM NODE            │   victim sees only what A allows
   └───────────────────────────────┘
        honest blocks never reach it

How an attacker gets there: by flooding the victim’s address tables with attacker IPs (so that when the victim picks new outbound peers, it picks attackers) and by occupying its inbound slots — often combined with forcing a restart so the victim re-selects peers from the poisoned tables.

Once eclipsed, the attacker can:

• Feed a false chain. Show the victim a stale or fabricated low-work chain and hide the real tip — the victim may accept payments that the honest network considers invalid or already spent.
• Enable double-spends against the victim. A merchant who only sees the attacker’s view can be shown a confirmation that the rest of the world never recognizes.
• Waste the victim’s hash power (if it’s a miner) by pointing it at a dead-end chain.

Eclipse weaponizes “trust no one” against itself

A full node’s strength is that it verifies everything it sees. Eclipse attacks don’t break that — they control what it sees. Validation can’t save you if you’re only shown a valid-but-stale chain and never offered the real one. Connectivity is a security assumption, not a given.

Sybil at the network layer vs PoW Sybil resistance

This is the distinction the whole book has been building toward, so make it sharp. Recall from Byzantine & Sybil that a Sybil attack is spawning many fake identities to gain disproportionate influence.

• Consensus is Sybil-resistant. Voting on the chain is weighted by proof of work, not by identity count. Spinning up a million fake nodes buys zero extra say over which chain is valid — you’d need a million CPUs’ worth of energy, not a million IPs. This is Nakamoto’s core trick.
• The network layer is not inherently Sybil-resistant. IP addresses and node identities are cheap. An attacker can cheaply run thousands of fake peers, stuff victims’ address tables, and occupy connection slots. Proof of work secures which chain is true — it does nothing to secure which peers you happen to connect to.

   PoW Sybil resistance  →  protects: "which chain is the valid ledger?"
                            (fake nodes get no vote — work is what counts)

   Network-layer Sybil   →  attacks:  "which peers does this node talk to?"
                            (fake IPs are cheap — eclipse becomes feasible)

That gap — strong consensus-layer Sybil resistance, weak network-layer Sybil resistance — is exactly the seam an eclipse attack works through.

Partitioning and BGP hijacks

A partition attack splits the network into pieces that can’t talk to each other, so each side builds its own chain in ignorance of the other. When the partition heals, one side’s work is discarded in a reorg — and any payments confirmed on the losing side are reversed.

Because Bitcoin traffic rides the public internet, a powerful adversary can attempt this at the routing layer via a BGP hijack — falsely announcing routes to capture or black-hole the IP ranges of many nodes, splitting the network geographically. This is an infrastructure-level attack, not a Bitcoin-protocol flaw, but it has been demonstrated to be feasible against unprotected traffic.

Defenses

No single trick makes a node bulletproof; defense is layered, and most of it is about diversifying and protecting your connections so an attacker can’t own all of them cheaply.

• Many, diverse outbound connections. The more independent peers a node chooses (rather than accepts inbound), the more attacker IPs it takes to surround it. Bucketing peers by network group (different /16 IP ranges, different autonomous systems) stops one network operator from supplying all your peers. (Efficiencies like Erlay, from propagation, make affording more peers cheaper.)
• Anchor connections. A node remembers a few good, long-lived outbound peers and reconnects to them after a restart, so a forced reboot can’t make it re-pick an all-attacker set from poisoned tables.
• Hardened address management. Limiting how fast the address tables can be filled by any one source blunts table-flooding.
• Reach across network types. Adding peers over Tor, I2P, or even satellite/radio broadcast diversifies the paths into a node, so a BGP hijack or local ISP can’t intercept all of them — and block-relay-only (“blocks-only”) connections add cheap, hard-to-poison links that still deliver the real tip.
• Distrust a single source of truth. Cross-checking the chain tip’s height/work against several independent peers makes a stale-chain feed easier to spot.

The cheapest defense: run your own node, well-connected

An eclipsed user who relies on someone else’s node has no recourse. A user running their own full node with diverse, anchored connections is far harder to deceive — and can sanity-check what they’re told. See running a node.

The thread

How does this help untrusting strangers agree on one ledger? These attacks reveal the boundary of proof of work. PoW guarantees that, among chains a node can see, it will pick the truly heaviest one — so the remaining job is making sure honest nodes can always see the real chain. Network defenses exist to preserve that visibility: keep enough diverse, independent links open that no cheap army of fake peers can wall you off from the honest majority’s work. Consensus answers “which chain is true”; the network layer’s fight is to make sure that answer can actually reach you.

Check your understanding

1. In an eclipse attack, the victim’s node is still fully validating. Why doesn’t that protect it, and what can the attacker then accomplish?
2. Explain precisely why Bitcoin’s consensus is Sybil-resistant while its network layer is not. Which resource is scarce in each case?
3. How does an attacker typically maneuver into eclipsing a node (think address tables and connection slots)?
4. What is a partition attack, and how could a BGP hijack cause one even though Bitcoin’s protocol isn’t broken?
5. Why do diverse outbound peers and anchor connections specifically defeat the mechanics of an eclipse attempt?