Network Architecture
Bitcoin is a peer-to-peer network with no central server. Every node is equal; there's no hierarchy. The network's job is to propagate blocks and transactions to every node as quickly as possible.
net.cpp
Low-level connection management. TCP sockets, reading/writing bytes, managing the peer list.
net_processing.cpp
High-level message handling. Interprets protocol messages, coordinates block/tx relay.
AddrMan
Address manager. Stores known peer addresses, handles DNS seeding, peer discovery.
Connection Types
Bitcoin Core maintains different types of connections:
Peer Discovery & Connection
How does a Bitcoin node find other nodes?
- DNS Seeds: On first start, the node queries hardcoded DNS seeds (e.g.,
seed.bitcoin.sipa.be) to get a list of active nodes. - ADDR messages: Connected peers share addresses of other nodes they know about.
- Hardcoded seeds: As a final fallback, a list of IP addresses is compiled into the binary.
- Manual (-addnode): Users can specify peers directly.
The Version Handshake
Every new connection starts with a version handshake:
P2P Message Types
The Bitcoin P2P protocol uses ~25 message types. Here are the most important ones:
Block-Related
Transaction-Related
Network Management
Block Synchronization
When a node starts up (or falls behind), it needs to download and validate the entire blockchain. This uses headers-first synchronization:
Phase 1: Download Headers
- Send
GETHEADERSwith our best known block hash - Peer responds with up to 2,000 headers
- Validate each header's PoW and chain continuity
- Repeat until we reach the peer's tip
- This is fast, headers are only 80 bytes each
Phase 2: Download Blocks
- Now that we know the full header chain, request blocks in parallel from multiple peers
- Download blocks out of order for speed, but validate in order
- Use
GETDATAmessages to request specific blocks - Each block is validated and connected as it arrives (if in sequence)
During initial sync, Bitcoin Core skips script verification for blocks below the assumevalid hash (a recent block known to be valid). This dramatically speeds up IBD, UTXO updates are still performed, but expensive signature checks are skipped.
Compact Blocks (BIP 152)
Once synced, new blocks propagate using compact block relay:
- Sender transmits a
CMPCTBLOCK, block header + short 6-byte IDs for each transaction - Receiver reconstructs the block using transactions it already has in its mempool
- If any transactions are missing, request them with
GETBLOCKTXN - This typically avoids transmitting the full block entirely, since most transactions are already in the mempool
High-Bandwidth vs. Low-Bandwidth Mode
- High-bandwidth: send compact blocks immediately without waiting for an INV/GETDATA round trip. Used with 3 selected peers for fastest propagation.
- Low-bandwidth: announce blocks via INV first, send compact block only if requested. Used for the remaining peers to save bandwidth.
Transaction Relay
Transaction propagation is carefully designed for both speed and privacy:
Relay Process
- Node validates a new transaction (ATMP succeeds)
- Sends
INVmessages to all peers it wants to announce to - Interested peers respond with
GETDATA - Node sends the full
TXmessage
Privacy Protections
- Poisson-timed relay: INV messages are delayed by a random amount (average 2 seconds for outbound, 5 for inbound) to prevent timing analysis that could link transactions to IP addresses.
- WTXID relay (BIP 339): use witness txid instead of txid for relay, preventing witness-malleated duplicates.
- Transaction reconciliation (Erlay, BIP 330): instead of flooding INV messages to all peers, nodes can efficiently reconcile their mempools using set reconciliation. Saves ~40% bandwidth.
Address Manager (AddrMan)
AddrMan stores peer addresses using a bucketed structure designed to resist eclipse attacks:
- New table: 1,024 buckets for addresses we've heard about but haven't connected to
- Tried table: 256 buckets for addresses we've successfully connected to
- Bucket placement uses hashing of the address + source, making it hard for an attacker to fill specific buckets
- Addresses are evicted based on time-since-last-seen and connection failures
Encrypted P2P (BIP 324)
BIP 324 (v2 transport protocol) adds encryption to Bitcoin P2P connections:
- ECDH key exchange: peers perform an ephemeral key exchange using secp256k1
- ChaCha20-Poly1305: all subsequent messages are encrypted and authenticated
- Short message IDs: 1-byte or 13-byte message IDs replace ASCII command names (saves bandwidth)
- Garbage padding: connection establishment includes random garbage to prevent fingerprinting
Encryption doesn't provide authentication (you don't know who you're talking to), but it prevents passive eavesdroppers from seeing which transactions you relay - important for privacy.
DoS Protection
The P2P layer includes several mechanisms to protect against denial-of-service attacks:
- Misbehavior scoring: peers that send invalid data accumulate a score. At threshold (100), they're disconnected and banned.
- Headers sync state machine: protects against memory exhaustion from fraudulent headers chains.
- Orphan transaction limits: cap on stored orphan transactions (100 by default).
- Rate limiting: limits on address messages, compact block requests, etc.
- Stalling detection: peers that are too slow to serve blocks get disconnected.
- Outbound eviction protection: diverse peer selection (by network, latency, services) to resist eclipse attacks.