Timechain Wiki

The peer-to-peer network

10 min read

Bitcoin runs as an unstructured peer-to-peer overlay network — no central server, no directory, no hierarchy. Each node connects to a handful of others (typically 8-10 outbound, up to ~125 inbound) and relays blocks and transactions via gossip; new nodes bootstrap through DNS seeds and hardcoded fallback IPs, then learn additional peers via ongoing addr-message gossip. In 2026 the network has roughly 15,000-20,000 reachable full nodes globally, with many more behind NAT. Block propagation uses compact-block-relay (BIP-152) — header plus short transaction identifiers rather than full transactions — sharply reducing bandwidth and latency; transactions propagate via inventory announcements that peers can request on demand. Specialized block-relay networks (FIBRE, Falcon, BlockSpace) operate alongside the public p2p layer for sub-second propagation between major miners. The design is partition-resistant: short partitions resolve naturally on reconnect, while long ones would produce reorganizations.

Why this note matters

The peer-to-peer network is the physical substrate Bitcoin runs on. Everything else — block production, transaction propagation, node validation — happens through it. The structural choices (unstructured topology, gossip-based propagation, decentralized peer discovery) are what make Bitcoin censorship-resistant at the network layer; centralized alternatives would have a single point of failure.

The network is also where eclipse attacks happen — where an attacker controls a victim’s view of the network by surrounding them with malicious peers. Self-custody operational practice around running nodes (see Practical self-custody and sovereignty) is partly motivated by the security improvements from connecting to your own node rather than trusting a third-party SPV server. The structural network layer is what makes both the threat and the mitigation possible.

Architecture

Bitcoin’s p2p network is an unstructured overlay:

  • No central directory. No node has a global view of all other nodes.
  • No hierarchy. All full nodes are peers in the protocol sense; there are no “super-nodes” or routing nodes (though specialized infrastructure like FIBRE exists for performance).
  • No persistent identity. Nodes are identified by IP:port (or onion address for Tor); there’s no protocol-level identity beyond this.

Each node maintains a list of known peers and selects a subset to connect to:

  • Outbound connections (typically 8): initiated by the node; peers chosen from its known-peer list, biased toward unique network groups (different /16 IPv4 ranges or /32 IPv6 ranges) to maximize topological diversity.
  • Inbound connections (up to ~125): accepted from other nodes that initiate. Limited but not strictly capped.
  • Block-relay-only connections (post-BIP-155, “addrv2”): additional outbound connections used solely for receiving blocks, not for transaction relay. Reduces eclipse-attack surface.

The result is each node has ~8-10 outbound peers + however many inbound connect. The total set of “edges” in the global network graph is roughly 200,000-300,000 connections, distributed across the ~15,000-20,000 reachable nodes.

Peer discovery

A fresh node has no peers initially. The discovery sequence:

  1. DNS seeds. A small set of hardcoded domain names (currently 8-10 in Bitcoin Core) resolve to IP addresses of well-known nodes. Operated by community-trusted parties (Pieter Wuille, Luke Dashjr, Sjörs Provoost, etc.). The fresh node queries these to obtain initial peer candidates.
  2. Hardcoded fallback IPs. If DNS seeds fail (network filtering, DNS poisoning), Bitcoin Core embeds a small static list of IPs as a last-resort fallback. Sufficient to bootstrap into the network.
  3. Saved peers. A node that has previously been running stores its known-peer set on disk; on restart, it reconnects from that store.
  4. Addr-message gossip. Once connected to any peer, the node learns about additional peers via addr messages — small announcements of “here’s a peer I know about.” Modern nodes gossip ~1000 peers via this mechanism over time.

The DNS-seed bootstrap is the most centralized part of the network. A coordinated attack on all DNS seeds could prevent new nodes from connecting (existing nodes would be unaffected). The hardcoded fallback IPs are the secondary defense. For long-term resilience, manual peer configuration remains an option.

Tor and onion peers. Modern Bitcoin Core supports Tor connections; nodes can run as onion services (.onion addresses) and accept inbound Tor connections. This provides network-level privacy for node operators who don’t want their IP addresses associated with their Bitcoin activity. The BIP-155 addrv2 message format supports onion addresses natively.

Block propagation

When a miner finds a new block, propagation through the network proceeds:

Legacy propagation (pre-BIP-152, mostly historical):

  1. Miner sends inv message (“I have block X”) to all peers
  2. Peers respond with getdata if they don’t have X
  3. Miner sends the full block via block message
  4. Each peer validates, accepts, and re-announces via inv to its peers

The latency was substantial — at multi-megabyte block sizes, the full-block transfer is slow over consumer internet. Propagation across the global network took 10+ seconds, which contributed to orphan-block rates and reorg frequency.

Compact block relay (BIP-152, the modern default):

  1. Miner sends compact-block message — block header plus 6-byte truncated transaction IDs of all included transactions
  2. Recipient checks its mempool for the listed transactions
  3. For any missing transactions, recipient requests them specifically via blocktxn
  4. Recipient reconstructs the full block from its mempool plus the requested missing transactions

Compact block relay dramatically reduces bandwidth (a 1 MB block becomes a ~25 KB announcement plus per-missing-transaction round-trips) and latency (typical block propagates in under 1 second to most peers).

Block-relay-only specialized networks. FIBRE (Fast Internet Bitcoin Relay Engine), Falcon, BlockSpace, and similar operate as low-latency relay networks alongside the public p2p network. Major mining operations and large nodes connect to these to receive blocks faster than the gossip layer alone provides. The infrastructure is operated by mining-adjacent organizations; the public p2p network remains the substrate for everyone else.

Transaction propagation

Transactions propagate similarly but with simpler mechanics:

  1. Wallet broadcasts a transaction to a node it’s connected to
  2. Node validates the transaction; if valid, adds to mempool
  3. Node sends inv to peers announcing “I have transaction TX”
  4. Peers fetch and validate; cycle continues

Erlay (BIP-330). A proposed extension that uses set-reconciliation rather than full inventory announcements. Reduces bandwidth substantially for high-mempool-throughput nodes by only sending the set-difference between two peers’ mempools. Designed by Pieter Wuille and Gregory Maxwell among others; not yet deployed as of 2026 but expected in coming releases.

Mempool variance across nodes. Each node’s mempool is its own; nodes do not agree on a global mempool. Differences arise from connection-time gaps, mempool-eviction policies, fee thresholds, transaction-replacement decisions, etc. This is intentional — there is no canonical pre-confirmation transaction set; only confirmed blocks have consensus.

Eclipse attacks and partition resistance

An eclipse attack is when an attacker controls all of a victim’s network connections, replacing them with malicious nodes. The victim sees only what the attacker shows them — potentially a fake chain, double-spent transactions, or no transactions at all.

The attack requires:

  • Controlling all of the victim’s outbound peer slots (~8 outbound)
  • And preventing legitimate inbound peers from connecting

Effective execution requires either:

  • Network-level control — being able to filter the victim’s traffic (e.g., an ISP-level adversary, or a hostile WiFi network)
  • Sybil attacks on peer discovery — flooding DNS seeds and addr-message gossip with attacker-controlled IPs

The 2015 Heilman et al. paper Eclipse Attacks on Bitcoin’s Peer-to-Peer Network demonstrated feasibility against the then-current Bitcoin Core; subsequent mitigations have made the attack substantially harder:

  • Diversified outbound connections by network group
  • Block-relay-only connections to additional peers (more redundancy)
  • Anchor connections — preserving some peer relationships across restarts
  • Tor and onion services — making victim peering less observable

In 2026, eclipse attacks are operationally difficult but not impossible. Self-custody operational practice recommends running your own full node and verifying chain state independently.

Partition resistance. If the global network partitions (e.g., the trans-Pacific cable is cut), each partition continues operating; blocks are produced on each side. When reconnection happens, the longer-cumulative-work chain wins and the other partition’s blocks reorganize out (see Chain reorganizations). The protocol handles arbitrary partition durations gracefully — though long partitions produce large reorgs when reconnected, which is operationally disruptive.

Tradeoffs and design choices

Unstructured topology. Structured overlays (Kademlia DHT, Chord, etc.) provide better routing efficiency but require global state synchronization. Bitcoin’s unstructured choice prioritizes simplicity and partition resistance over routing efficiency. The cost is some redundant gossip; the benefit is no central state.

Why DNS seeds remain in the bootstrap path. Hardcoded IP lists go stale; pure peer-discovery-from-running-nodes is unavailable when bootstrapping; DNS provides a maintainable, semi-centralized solution. The community-operated seed model has held up since 2009. Pure decentralization (e.g., bootstrapping via blockchain-stored peer lists) has been proposed but not deployed; the marginal benefit doesn’t justify the engineering investment.

Compact-block-relay tradeoff. Compact blocks save bandwidth at the cost of additional round-trips for missing transactions. For typical blocks with mostly-mempool-matched transactions, this is a clear win; for blocks with many unseen transactions, the round-trips add latency. The tradeoff has been empirically validated as net-positive.

The bandwidth tax on full-node operators. Operating a relaying full node uses substantial bandwidth — historically 50-200 GB/month, more recently higher with Ordinals-driven transaction volume. This is a friction point that can deter casual node operation. The block-relay-only connection type helps: nodes that don’t want to relay transactions can still validate blocks at reduced bandwidth.

Eclipse attack remains a structural concern. While substantially mitigated, eclipse attacks are not impossible. The right operational practice (running multiple nodes, using anchor connections, validating chain state on multiple devices) remains relevant for high-value-target node operators.

For substantive engagement with network-layer attacks beyond eclipse (e.g., BGP-hijacking, sustained Sybil attacks), see Consensus-layer attack theories (Criticisms section).

Open questions for further development

  • Will the move toward block-relay-only connections eventually fragment the public p2p network into a “block tier” and “transaction tier”? Some argue this is already happening informally.
  • How will Erlay deployment shift the bandwidth dynamics of running a node? Could lower the operational friction for casual node operators substantially.
  • What’s the right level of DNS-seed centralization? Adding more seeds increases robustness but also expands the trust surface.
  • How do quantum-resistant signature schemes (when adopted) interact with the network layer? Larger signatures may stress propagation more than current ECDSA/Schnorr signatures.

Canonical sources for this note

Bitcoin Improvement Proposals

  • BIP-152 — Compact block relay.
  • BIP-155 — addrv2 message format (supports Tor v3, I2P, etc.).
  • BIP-330 — Erlay (proposed; not yet activated).

Bitcoin engineering references

  • Mastering Bitcoin, Andreas Antonopoulos (chapter 8: “The Bitcoin Network”) — canonical engineering treatment. See Mastering Bitcoin - Andreas Antonopoulos.
  • Programming Bitcoin, Jimmy Song (chapter 10: “Networking”) — working-programmer treatment.

Network-layer security research

  • Eclipse Attacks on Bitcoin’s Peer-to-Peer Network (Heilman et al., 2015) — the foundational paper on the eclipse attack.
  • Various more recent research on BGP-hijacking and routing-layer attacks on Bitcoin.

Bitcoin Core implementation

  • net.cpp, net_processing.cpp in Bitcoin Core source — canonical implementation.

Graph View

Backlinks