Peer-to-peer gossip

Wonder

1. How does a new node on an empty network find its first peer?
2. How does a new block reach thousands of nodes within seconds without anyone coordinating it?
3. What prevents an attacker from isolating a node from the rest of the network?

Explore

1. Bitcoin operates as a decentralized peer-to-peer network where each full node maintains independent state. To join, a new node must establish TCP connections to existing peers. Mainnet uses port 8333 for these connections. Initial discovery relies on DNS seeds, run by long-standing community members and listed in the software, plus hard-coded fallback addresses. Once connected, a node can ask for addresses with ‘getaddr’ and receives them in ‘addr’ messages, allowing it to learn about other active participants and expand their peer set dynamically.
2. Bitcoin Core manages a specific topology: 8 outbound full-relay connections for transaction and block propagation, plus 2 block-relay-only connections to reduce bandwidth usage. It allows up to 125 connections in total, inbound and outbound. This structure ensures redundancy; if one peer disconnects or becomes unresponsive, the node maintains connectivity through others. Block-relay-only connections carry no transactions or addresses, which makes it harder for an observer to map the network’s topology.
3. Data propagation follows an announcement mechanism. When a node receives a new transaction, it announces it with an ‘inv’ (inventory) message containing the hash but not the data; new blocks are now usually announced by sending the header or a compact block directly. Peers receiving this announcement recognize they lack the object and send a ‘getdata’ request. The original holder then transmits the full payload. This two-step process prevents flooding the network with redundant large payloads before peers confirm their interest, ensuring efficient bandwidth usage across the distributed system.
4. Compact blocks (BIP152), introduced in 2016, optimize this further. Since most transactions in a block are already known to peers via mempool propagation, sending the full block is wasteful. Instead, a node sends the block header plus short identifiers (6 bytes each) for its transactions, along with the coinbase; the receiver rebuilds the block from its own mempool and requests only the few transactions it lacks. This significantly reduces latency in block propagation, allowing the network to reach consensus faster even with high transaction volumes.
5. Eclipse attacks demonstrate the fragility of peer diversity. Heilman et al. (2015) showed that an attacker who takes over all of a node’s connections can isolate it from the honest network, feeding it a false view of the chain. Bitcoin Core adopted their countermeasures from version 0.10.1, including feeler connections and more careful address-table eviction, and later added anchor connections that persist across restarts. Running only over Tor can make a node easier, not harder, to eclipse.
6. Verify your node’s connectivity by running ‘bitcoin-cli getpeerinfo’ in a terminal connected to a local Bitcoin Core instance. The output lists each peer’s address, its ‘connection_type’ (for example outbound-full-relay or block-relay-only), its software version and how far it has synced (‘synced_headers’, ‘synced_blocks’). A healthy node shows about ten outbound connections: eight full-relay and two block-relay-only.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Bitcoin Developer Guide, 'P2P Network' section
• Heilman et al., 'Eclipse Attacks on Bitcoin's Peer-to-Peer Network' (USENIX Security 2015)
• BIP152: Compact Block Relay