P2P network messages

How nodes find each other and gossip blocks and transactions.

Bitcoin has no central server. Nodes talk directly to each other over a simple peer-to-peer protocol, by default on TCP port 8333.

The message frame

In the original (v1) protocol, every message starts with a header: 4 "magic" bytes identifying the network (F9 BE B4 D9 on mainnet), a 12-byte command name, a payload length and a 4-byte checksum. The traffic is unencrypted.

v2: encrypted transport

BIP324 adds an encrypted transport. Bitcoin Core supports it and has turned it on by default since version 27.0. It does not authenticate peers, but it makes passive spying and tampering much harder.

The handshake

Two nodes exchange version messages (software version, services offered, best height) and confirm with verack. Feature messages such as sendheaders, sendcmpct, wtxidrelay and sendaddrv2 are sent around the handshake.

Gossiping data

  • inv announces "I have this transaction or block".
  • getdata asks for it, and tx or block delivers it.
  • headers and getheaders exchange block headers, up to 2,000 at a time.
  • cmpctblock, getblocktxn and blocktxn carry compact blocks (BIP152).
  • feefilter tells a peer not to send transactions below a feerate.
  • ping/pong check that the connection is alive.

Finding peers

A new node first asks DNS seeds, run by known community members, for addresses. After that it learns more through addr and addrv2 messages. BIP155's addrv2 can carry Tor v3, I2P and CJDNS addresses.

Resisting attacks

Bitcoin Core makes 8 full-relay outbound connections and 2 block-relay-only connections by default. It picks addresses from different network groups so that one attacker cannot easily surround a node (an "eclipse attack"). Peers that send invalid data are disconnected.

Takeaway

The P2P layer only moves data. Every node still checks every block and transaction against the consensus rules itself.