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.
Network Architecture
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)
Protocol Messages
Handshake
Nodes establish connections through a handshake:
1. Version Message: Announce capabilities
2. Verack Message: Acknowledge version
3. Connection established
Core Messages
| Message | Purpose |
|---|---|
version | Initial handshake, announce capabilities |
verack | Acknowledge version message |
addr | Share peer addresses |
inv | Inventory announcement (blocks/tx) |
getdata | Request specific data |
block | Send block data |
tx | Send transaction data |
headers | Send block headers |
getheaders | Request block headers |
ping / pong | Keep connection alive |
Code Examples
Establishing Connection
Sending Inventory
Message Flow
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
Peer Discovery
Methods
- DNS Seeds: Hardcoded DNS servers
- Hardcoded Seeds: Bootstrap IP addresses
- Peer Exchange: Peers share addresses
- Manual Connection: User-specified peers
Address Management
Known Addresses:
├── Tried addresses (recently connected)
├── New addresses (not yet tried)
└── Banned addresses (avoid)
Network Security
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
Compact Blocks (BIP 152)
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
P2P v2 / Encrypted Transport (BIP 324)
BIP 324 defines a v2 P2P transport that encrypts and authenticated the peer-to-peer link. 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.
Related Topics
- Block Propagation - How blocks spread
- Mempool - Transaction pool
- Node Types - Different node configurations