Bitcoin Network Protocol: Messages, Connection, and Data Relaying

Bitcoin operates on a decentralized peer-to-peer (P2P) network using TCP/IP communications. By default, it uses port 8333, but this can be customized via the -port parameter. The network supports IPv6 (since Bitcoind/Bitcoin-Qt v0.7) and is compatible with Tor for enhanced privacy.

Core Network Messages

Bitcoin nodes communicate through structured messages. Below are the key message types:

Message Type	Purpose
`version`	Exchanges program version and block count during initial connection.
`verack`	Acknowledges acceptance of a connection after receiving `version`.
`addr`	Lists IP addresses and ports of active peers.
`inv`	Announces new blocks/transactions without sending full data.
`getdata`	Requests specific blocks or transactions by hash.
`getblocks`	Requests an inventory of blocks within a specified range.
`tx`	Sends a transaction (only in response to `getdata`).
`block`	Sends a block (only in response to `getdata`).
`alert`	Broadcasts critical network alerts (e.g., security warnings).

👉 Explore Bitcoin’s technical architecture for deeper insights into these protocols.

Peer Connection Process

Handshake:
- A node sends a version message with its details (version number, block count, timestamp).
- The peer replies with verack and its own version if compatible.
- Both nodes calculate the median network time from peer timestamps for synchronization.
Address Exchange:
- Nodes share known peers via addr messages (containing 1–1,000 IPs).
- getaddr requests are used to bootstrap connections with active peers.

Transaction and Block Relaying

New Transactions:
- A node broadcasts an inv message to peers, who request the full transaction via getdata.
- Valid transactions are relayed further, avoiding duplicates.
Block Propagation:
- Miners announce new blocks via inv. Peers fetch the block with getdata and validate it.
- Blocks are rebroadcast until the network reaches consensus.

Initial Block Download (IBD)

New nodes sync the blockchain by:

Sending getblocks with the latest known block hash.
Receiving an inv listing up to 500 newer blocks.
Fetching blocks sequentially via getdata until fully synchronized.

Thin SPV Clients (BIP 0037)

Simple Payment Verification (SPV) clients (e.g., MultiBit, Bitcoin Wallet):

Download only block headers (not full blocks).
Use bloom filters to request relevant transactions from full nodes.
Trade some privacy for lighter resource usage.

Bootstrapping Methods

Bitcoin nodes discover peers through:

Addr Messages:
- Nodes relay addr messages with active IPs every 24 hours.
- Seed nodes (hardcoded addresses) help new nodes join the network.
DNS Seeding:
- Default in v0.6+; resolves IPs from predefined hostnames.
IRC (Deprecated):
- Pre-v0.8.2 clients used IRC channels (#bitcoin00–99) to encode peer IPs in nicknames.

👉 Learn about Bitcoin’s evolving node discovery and its impact on decentralization.

Network Health Monitoring

Heartbeat: Nodes send periodic messages to maintain connections (30-minute inactivity triggers a ping).
Timeout: Peers are disconnected after 90 minutes of inactivity.

FAQ

Q: Can Bitcoin run on non-standard ports?
A: Yes, use the -port parameter to specify custom ports.

Q: How do SPV clients verify transactions without full blocks?
A: They rely on Merkle proofs in block headers and bloom filters.

Q: Is IPv6 supported?
A: Yes, since Bitcoin-Qt v0.7.

Q: Why was IRC bootstrapping removed?
A: Due to reliability issues and the shift to DNS seeding.

For further reading: