P2P Network Protocol

Bitcoin uses a peer-to-peer (P2P) network protocol for nodes to communicate, share blocks, and propagate transactions. Understanding the P2P protocol is essential for running nodes and understanding network behavior.

Bitcoin's P2P design was inspired by the same P2P ideas and era (early 2000s), including BitTorrent's success; decentralization, no single point of failure, and censorship resistance. Bitcoin does not use BitTorrent's protocol; it has its own messages and peer discovery.

Satoshi wrote that governments are good at cutting off centrally controlled networks like Napster, but that "pure P2P networks like Gnutella and Tor" hold their own; so the design philosophy aligns with that lineage.

Node Types

Full Nodes:
- Download and validate entire blockchain
- Relay blocks and transactions
- Maintain network consensus

Light Nodes (SPV):
- Download block headers only
- Request specific transactions
- Rely on full nodes for data

Connection Model

Typical Node:
├── 8-10 outbound connections (you connect to others)
├── Up to 125 inbound connections (others connect to you)
└── Block-relay-only connections (privacy)

Handshake

Nodes establish connections through a handshake:

1. Version Message: Announce capabilities
2. Verack Message: Acknowledge version
3. Connection established

Core Messages

Magic Bytes

Each P2P message on the wire starts with magic bytes, a fixed 4-byte value that identifies the network (mainnet, testnet, signet, regtest). They help nodes detect message boundaries and reject messages intended for other networks. Mainnet magic is 0xF9BEB4D9 (little-endian). The message format is: magic (4 bytes) + command string (12 bytes) + payload length (4 bytes) + checksum (4 bytes) + payload. See the Bitcoin P2P protocol for the full wire format.

Establishing Connection

Sending Inventory

Block Propagation

1. Miner finds block
2. Sends 'inv' message to peers
3. Peers request block with 'getdata'
4. Miner sends 'block' message
5. Peers validate and forward

Transaction Propagation

1. User creates transaction
2. Sends 'inv' or 'tx' to peers
3. Peers validate transaction
4. Peers forward to their peers
5. Transaction spreads across network

Methods

1. DNS Seeds: Hardcoded DNS servers
2. Hardcoded Seeds: Bootstrap IP addresses
3. Peer Exchange: Peers share addresses
4. Manual Connection: User-specified peers

Address Management

Known Addresses:
├── Tried addresses (recently connected)
├── New addresses (not yet tried)
└── Banned addresses (avoid)

Eclipse Attacks

Prevented by:

• Connecting to diverse IP ranges
• Using multiple outbound connections
• Verifying block data independently

Sybil Attacks

Mitigated by:

• Requiring proof-of-work for blocks
• Independent validation by all nodes
• No trust in individual peers

Tor is an anonymity network that routes traffic through volunteer relays so that observers cannot see who is talking to whom. Satoshi cited Tor (with Gnutella) as an example of a resilient pure P2P network.

Running a Bitcoin node or wallet over Tor hides a user's IP from peers and mitigates some network-level surveillance and eclipse risks. Many nodes support Tor (e.g. via .onion addresses). Lightning's onion routing is inspired by Tor's design.

Running Bitcoin Core over Tor

Bitcoin Core can route P2P traffic through Tor. Install and run Tor (e.g. the Tor service or Tor Browser), then use the proxy option so that outbound connections go through Tor:

# Tor typically listens on 9050 (service) or 9150 (Tor Browser)
bitcoind -proxy=127.0.0.1:9050

In bitcoin.conf:

proxy=127.0.0.1:9050

To also advertise an onion address and accept incoming connections over Tor, set listenonion=1 (Bitcoin Core will create a hidden service if Tor is configured with ControlPort and cookie authentication). Use onlynet=onion if you want the node to connect only to .onion peers (Tor-only mode).

Trade-offs

• Benefits: IP hidden from peers and passive observers; reduces eclipse and network-level surveillance.
• Costs: Higher latency and often slower initial block sync; Tor relay capacity can be a bottleneck.

See Bitcoin Core Tor documentation and the Tor Project for setup details.

Optimization for faster block propagation:

Standard Block:
- Full block: ~1-2 MB
- Slow propagation

Compact Block:
- Header + short IDs: ~20 KB
- Receiver reconstructs from mempool
- Much faster

BIP 324 defines a v2 P2P transport that encrypts and authenticated the peer-to-peer link. Protocol messages (e.g., version, verack, inv, block, tx) are encrypted so that a passive on-path observer cannot read or tamper with them. This improves privacy (e.g., hiding which blocks or transactions are requested) and helps prevent some eclipse-style and downgrade attacks.

• Handshake: v2 uses an ECDH-based key agreement; once the shared secret is established, the rest of the session is ChaCha20-Poly1305 encrypted.
• Rollout: Bitcoin Core and other nodes can support both the legacy (unencrypted) and v2 transports; v2 is used when both peers support it. Adoption is increasing; see Bitcoin Core and BIP 324 for the latest status.

• Block Propagation - How blocks spread
• Mempool - Transaction pool
• Node Types - Different node configurations

• Bitcoin Protocol Documentation
• BIP 152: Compact Block Relay
• BIP 324: Version 2 P2P Encrypted Transport