Bitcoin Peer-to-Peer Protocol

Bitcoin's peer-to-peer network is a dissemination system, not a source of truth. Peers exchange addresses, transactions, headers, and blocks; each node decides locally what to request, relay, store, and accept. An authenticated-looking connection cannot make an invalid transaction valid, and receiving the same claim from many peers is not a substitute for consensus validation.

Four layers that should not be conflated #

The layers interact but have different security properties. BIP324 can protect a connection's byte stream from passive observation and cheap manipulation; it does not identify the peer as honest. A validly framed block message can still contain an invalid block. A consensus-valid transaction can still fail one node's local relay policy.

Discovery and connection establishment #

A new node needs initial addresses before gossip can help. DNS seeds provide samples of reachable nodes; software may also ship fallback seed data. After connecting, peers exchange address records and the node maintains a tried/new address manager rather than choosing uniformly from whatever an untrusted peer advertises. BIP155's addrv2 format extends address gossip beyond fixed IPv4/IPv6 forms and can represent networks such as Tor v3 and I2P without pretending they are IP addresses.

The legacy application handshake begins with both peers exchanging version, then verack. The version message advertises protocol version, services, time, network address information, a nonce, user agent, starting height, and relay preferences. Optional feature negotiation messages may occur at the defined point around this handshake; for example, BIP339 negotiates witness-transaction relay before verack.

v1 and v2 transport #

Legacy v1 runs over TCP with a recognizable message envelope: network magic, a 12-byte command, payload length, checksum, then payload. It is plaintext and does not authenticate either endpoint. Public transaction and block data is visible by design, but plaintext also exposes timing metadata, makes traffic easy to fingerprint, and lets an on-path attacker alter or censor packets cheaply.

BIP324's deployed version-2 transport performs an ephemeral ElligatorSwift Diffie–Hellman exchange, derives directional keys, and carries application messages in authenticated-encryption packets whose byte stream is pseudorandom to a passive observer. It is opportunistic and unauthenticated: the AEAD detects modification by parties without the session key, but the handshake does not prove a real-world peer identity. An active attacker can still man-in-the-middle or force downgrade unless the operator separately authenticates a session or detects the interference.

sequenceDiagram
  participant A as Node A
  participant B as Node B
  Note over A,B: v2 transport when both sides use BIP324
  A->>B: ephemeral key material + decoy bytes
  B->>A: ephemeral key material + decoy bytes
  Note over A,B: derive directional AEAD keys
  A->>B: encrypted version
  B->>A: encrypted version
  A->>B: encrypted feature negotiation / verack
  B->>A: encrypted feature negotiation / verack

Encryption raises the cost of surveillance, fingerprinting, and tampering; it does not make public blockchain data secret or eliminate traffic analysis from packet sizes and timing.

Inventory relay is announce, request, transfer #

Peers generally avoid pushing every full object immediately. The basic pattern is:

sequenceDiagram
  participant P as Peer with object
  participant N as Receiving node
  P->>N: inv(object identifier)
  N->>N: check known/rejected/in-flight state
  N->>P: getdata(identifier)
  P->>N: tx or block payload
  N->>N: validate locally
  N-->>P: relay announcement only if local rules permit

For witness transactions, BIP339 lets peers negotiate announcements keyed by wtxid, so the identifier commits to the exact witness-bearing serialization. This prevents an invalid or altered witness with the same txid from poisoning the receiver's decision about whether to fetch the valid form.

Block relay has several paths. Nodes can announce headers, letting the receiver verify proof of work and continuity before requesting block data. BIP152 compact blocks send the header, short transaction identifiers, and a small set of prefilled transactions; the receiver reconstructs the block from transactions already in its mempool and requests only the missing ones. The bandwidth win comes from not resending transactions that already propagated.

Receiving is not accepting #

An inbound transaction travels through distinct gates:

1. Parse canonical message and transaction encodings; reject malformed or oversized input early.
2. Check transaction consensus conditions available at the current chain tip: referenced UTXOs, values, locks, scripts, and absence of conflicts.
3. Apply local mempool and relay policy: standardness, fee rate, resource limits, package relationships, and replacement behavior.
4. If accepted, store it in the mempool and announce it selectively to peers under privacy, bandwidth, and anti-DoS rules.

Bitcoin Core defines relay policy as rules in addition to consensus for unconfirmed transactions. Policy is local and configurable, and it is not applied to transactions inside blocks. This is why “my peer accepted it” proves neither eventual network propagation nor mineability, and why “ordinary nodes would not relay it” does not necessarily imply consensus invalidity.

For a block, the node checks header proof of work, linkage, all transactions and scripts, Merkle commitments, coinbase/reward rules, witness commitments, and every other active consensus rule. Only valid candidates participate in most-chainwork selection. Peer reputation may change download scheduling, but cannot override those checks.

Network threats and their boundaries #

Eclipse attacks surround a victim with attacker-controlled peers, distorting its view of transactions and chain tips. Defenses therefore depend on diversified outbound selection, address-manager bucketing, feeler connections, discouraging misbehavior, and avoiding trust in one advertised address source. Transport encryption alone cannot stop eclipse: an attacker that is itself the endpoint can encrypt perfectly.

Transaction-origin inference correlates the first observations of a transaction with network topology. Randomized relay timing and connection choices make inference harder but do not create anonymity. Broadcasting directly from a wallet to many public peers can leak more than broadcasting through a privacy-aware intermediary or network path.

Resource-exhaustion attacks exploit parsing, validation, memory, or bandwidth asymmetry. Nodes bound message sizes, track in-flight requests, apply orphan/package/mempool limits, and disconnect or discourage peers for protocol violations. These are operational defenses around consensus, not changes to which blocks are valid.

Partitions and delay create competing valid tips. P2P propagation reduces how long peers disagree; Nakamoto consensus decides how nodes converge after learning both branches. Networking does not provide an instant finality certificate.

How to experiment without confusing the layers #

Use regtest when the goal is transaction serialization, Script execution, rejection reasons, or controlled block production. Use a public test network only when real peer discovery and heterogeneous relay behavior matter. A useful trace records, for every step:

• transport version and negotiated features;
• application command and exact object identifier (txid versus wtxid);
• whether the node parsed, requested, accepted to mempool, relayed, mined, and confirmed the object;
• the exact consensus or policy rejection reason;
• the chain tip and active rules at the time.

Do not treat silence as a protocol verdict. A peer may already know the object, decline it by policy, delay relay for privacy, rate-limit the connection, or disconnect without explaining which byte was wrong.

Source claims audit #

The 2014 Shirriff experiment directly sends a legacy transaction over the then-current plaintext protocol and observes it in Wireshark. Its enduring lesson is the separation between constructing bytes, sending them, seeing relay, and later seeing block inclusion. Its concrete network recipe is historical.