Attacks on P2P and Blockchain Networks

Decentralized networks with no administrator face attacks different from those against centralized systems. Let us examine how the major attacks work, the design measures that defend against them, and how real Bitcoin and Ethereum implementations have responded.

Sybil attack

A Sybil attack is one in which a single attacker creates many fake identities (fake nodes) to pose as a majority and illegitimately seize influence within the network. The name comes from the novel “Sybil,” about multiple personalities. If one real machine can claim to be thousands of nodes, the basic premises of P2P (majority votes, picking a random peer) collapse.

This is where PoW/PoS from Distributed Consensus come in. PoW requires real compute to cast one vote; PoS requires locking assets, making it economically impossible to spin up unlimited identities. That is the essence of Sybil resistance: by measuring voice not by count of identities but by an unforgeable scarce resource (compute or stake), the attack is neutralized.

By contrast, a DHT without clear Sybil resistance (such as Kademlia) can be attacked by placing many nodes in a specific ID region to hijack lookups for that key range or hide data. Plain Kademlia lets a node self-declare its ID, so an attacker can freely mint IDs close to a targeted key.

This gap is what S/Kademlia (a secure Kademlia extension) addresses. Its core ideas are requiring a crypto puzzle to mint a node ID (deriving it one-way from a public key or IP address to make bulk generation costly) and running lookups over multiple disjoint paths in parallel so an attack on one path shows up as a mismatch against the others. Capping how many node IDs are accepted from a single IP subnet is another common mitigation.

Eclipse attack

An Eclipse attack fills a target node's connections entirely with attacker-controlled nodes, isolating it ("eclipsing" it) from the honest network. The target believes it is communicating normally, but everything it sees is a fabrication supplied by the attacker.

Where a Sybil attack targets the majority of the whole network, an Eclipse attack controls only a specific node's field of view (often built atop the swarm of fake nodes from a Sybil attack). Since the isolated node receives only transactions and blocks the attacker chooses, the following abuses become possible:

• Enabling double-spends: trick the target (say, a merchant's node) into believing a payment is final, receive the goods, then invalidate the transaction on the real network.
• Stealing mining power: waste an isolated miner's compute, or make it mine a chain favorable to the attacker.
• Blocking and tampering with information: prevent the target from learning the real chain's state.
• Censorship: hide transactions from specific addresses from the target's view, making a payment look as if it never arrived.

Defense comes down to increasing connection diversity: securing a number of outbound connections, choosing peer IPs from a wide address range, and keeping known trusted nodes on hand; these are measures actually adopted in real Bitcoin and Ethereum implementations.

Countermeasures in Bitcoin

Bitcoin's P2P network overhauled its peer-address manager (addrman) after a 2015 paper by Heilman et al., “Eclipse Attacks on Bitcoin's Peer-to-Peer Network.” The main defenses:

• Securing outbound connections: maintain a fixed number of connections the node initiates itself, rather than relying solely on inbound connections it does not control.
• Feeler connections: brief, background test connections to unverified addresses; only ones confirmed alive get promoted to the higher-trust “tried” table. Flooding a node with fake addresses does not help an attacker unless those addresses survive a liveness check.
• Diversified address buckets: candidate peer addresses are spread across buckets keyed by source IP or network group (e.g. /16), so a single attacker with a small IP range cannot dominate any one bucket.
• Known seed nodes: using trusted DNS seeds and hardcoded seed nodes shortens the vulnerable window right after startup, when the routing table is still empty.

Countermeasures in Ethereum

Ethereum's discovery protocols (discv4/discv5) are also built on a Kademlia-style DHT, so Eclipse resistance is the same kind of design problem. Measures include capping how many peers are accepted from a single /24 subnet to prevent connection concentration, using --bootnodes or a static node list to reliably reach trusted nodes at startup, and requiring signature verification on node identity records (ENRs) to raise the cost of impersonation.

Routing-table poisoning and attacks on the DHT

One variant of the Eclipse attack targets a DHT's routing table directly. The attacker feeds a victim node's k-buckets or finger table with fake node entries under its control, pushing out legitimate ones. Once the table is poisoned, the node's lookups keep following attacker-supplied paths, which can block reachability into a key range or return forged responses.

• Replace only after a liveness check: many Kademlia implementations ping an existing bucket entry before evicting it for a new candidate, keeping the older node as long as it answers. This “least-recently-seen” policy blunts a burst of fake nodes sent in a short window.
• Lookups over multiple paths: as with S/Kademlia above, cross-check results from several independent paths instead of trusting a single one.
• Costly ID generation: as with S/Kademlia above, derive node IDs one-way from a public key or IP address so an attacker cannot freely pick arbitrary IDs.

The economics of the 51% attack

A 51% attack seizes a majority of hash power (PoW) or stake (PoS) to reverse transactions or censor them. See the PoW section of Distributed Consensus for the mechanics; here we look at the economics of why it is hard to pull off on most chains.

Getting a majority of hash power means either building and operating hardware yourself (a large upfront cost) or renting it from a hash-power marketplace (rentable capacity is limited). The larger a chain's total hash power or staked value, the higher the cost of attacking it. That is why smaller chains, where the rental market alone can approach a majority, are relatively more exposed.

Many PoS designs also apply slashing, confiscating the collateral of a validator caught misbehaving, so an attacker's own stake is damaged by the attack itself. And if an attack succeeds and is discovered, the chain's credibility, and its token price, tends to fall, hurting the attacker most if they hold a large position: a kind of built-in self-deterrence. On the exchange side, the common response is to raise the number of confirmations required before crediting a deposit, scaled to the coin's risk.

DDoS and amplification attacks

Where an Eclipse attack manipulates what the target sees, a DDoS (Distributed Denial of Service) attack simply floods a node with traffic or connection requests until its bandwidth, CPU, or memory is exhausted, taking away its availability outright. Broadcasting large volumes of invalid transactions or messages to exhaust a mempool or bandwidth (spam transactions) falls into the same category.

One thing to watch for is the amplification attack. Connectionless protocols like UDP let an attacker spoof the source IP on a request. Sending requests with a victim's IP spoofed as the source to many nodes causes every response to land on the victim instead. The larger the response is relative to the request (the higher the amplification factor), the more damage a small amount of attack traffic can do. UDP-based discovery protocols therefore need a handshake that verifies the requester's legitimacy, and should avoid sending large responses before that verification.

• Rate limits and connection caps: bound the message volume and connection count accepted from a single peer.
• Misbehavior scoring: add a penalty (a “ban score”) for protocol violations or excessive requests, and disconnect or block a peer once it crosses a threshold.
• Anti-spoofing handshakes: require a round trip (challenge-response) that verifies the source IP before sending a large response to a spoofed request.
• Cost per message: require a fee or minimal PoW for transaction relay so the network cannot be loaded for free.

Lessons from real cases, and common misconceptions

Bitcoin's Eclipse-attack defenses described above (the addrman overhaul and feeler connections) are a textbook case of an implementation improving in response to published research. Ethereum Classic, a PoW chain with relatively low hash power, has suffered multiple 51% attacks; major exchanges responded by raising the confirmation count required for deposits of that coin. Both are examples of defenses and operational practices being updated on the assumption that an attack can happen.

• Misconception: more nodes means more security. If the cost of creating each identity is close to zero, a larger node count buys no Sybil resistance. What matters is not the count but its tie to an unforgeable scarce resource.
• Misconception: PoW is absolutely safe from a 51% attack. Hash power can be rented on the open market, and the smaller a chain's total hash power, the lower the relative cost of attacking it.
• Misconception: encrypted traffic prevents an Eclipse attack. Encryption protects content confidentiality and tamper-detection, but it does not stop an attacker from controlling who you connect to. The defense lies in connection diversity itself.
• Practical note: light clients and mobile wallets keep far fewer peer connections than a full node, making them more exposed to Eclipse attacks. Connecting directly to trusted nodes and checking balances or deposits against multiple sources is a practical mitigation.

This body of attack research is a concrete embodiment of the Byzantine-fault-tolerance mindset: design on the assumption that the system must not break even with malicious participants present.