Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Peer-to-Peer Network Protocol

The P2P protocol transports blocks, transactions, headers, addresses, filters, and relay-control messages between nodes. This section specifies interoperable wire behavior.

Message envelope

Legacy unencrypted Bitcoin P2P messages use a 24-byte header followed by a payload:

FieldTypeMeaning
startbyte[4]Network magic identifying mainnet, testnet, signet, or regtest.
commandbyte[12]ASCII command name padded with zero bytes.
payloadSizeuint32Number of payload bytes.
checksumbyte[4]First four bytes of $H(payload)$.
payloadbyte[]Command-specific serialized payload of length payloadSize.

BIP324 defines an encrypted v2 transport that changes transport framing after negotiation, but command payload semantics remain command-specific (sources: bip-0324,bitcoin-core-v31).

Handshake

A connection becomes usable after version negotiation:

  1. each side sends version;

  2. each side validates network, protocol version, services, timestamp, nonce, and user-agent limits;

  3. each side sends verack; and

  4. optional relay, compact-block, address-relay, filter, and transport features are negotiated by later messages.

version fieldTypeMeaning
versionint32Protocol version offered by the sender.
servicesuint64Service bits offered by the sender.
timestampint64Sender Unix time in seconds.
addrRecvnetwork addressAddress of the receiving peer as understood by the sender.
addrFromnetwork addressAddress of the sender.
nonceuint64Random connection nonce used to detect self-connections.
userAgentstringBIP14 user-agent string.
startHeightint32Sender’s current best height estimate.
relaybool, optionalBIP37 transaction-inventory relay preference when present.

Control and negotiation payloads

MessagePayloadMeaning
verackemptyCompletes version negotiation.
sendheadersemptyRequests direct headers announcements instead of block inventory announcements.
wtxidrelayemptyNegotiates transaction relay by witness transaction identifier.
sendaddrv2emptyNegotiates BIP155 address relay.
pinguint64 nonceLiveness probe.
ponguint64 nonceResponse echoing the received ping nonce.
feefilteruint64 feerateAsks the peer not to announce transactions below the feerate in satoshis per 1000 virtual bytes.

Service flags

FlagBitMeaning
NODE_NETWORK0Peer can serve the full block chain.
NODE_BLOOM2Peer supports BIP37 bloom-filter service.
NODE_WITNESS3Peer supports witness transaction and block relay.
NODE_COMPACT_FILTERS6Peer supports BIP157 compact block filter service.
NODE_NETWORK_LIMITED10Peer can serve at least a limited recent block window.

Service flags advertise capability. A node must still validate responses and apply local resource limits.

Inventory and object retrieval

Inventory relay announces objects by type and hash. A peer requests announced objects with getdata; the responder sends the corresponding object or a notfound response when unavailable.

RecordFieldsMeaning
InventoryVectortype:uint32, hash:uint256Identifies a transaction, block, filtered block, compact block, witness transaction, or witness block.
invvector< InventoryVector>Announces available objects.
getdatavector< InventoryVector>Requests announced objects.
notfoundvector< InventoryVector>Reports requested objects not available from the responder.

Witness inventory types request serialization that includes witness data. A peer that has not negotiated witness support must not rely on receiving witness objects from that connection (sources: bip-0144).

Inventory typeValueObject requested or announced
MSG_TX1Transaction by txid.
MSG_BLOCK2Block without requiring witness serialization.
MSG_FILTERED_BLOCK3BIP37 filtered block.
MSG_CMPCT_BLOCK4BIP152 compact block.
MSG_WITNESS_TX$2^30 + 1$Transaction including witness data, identified by txid request type with witness flag.
MSG_WITNESS_BLOCK$2^30 + 2$Block including witness data.
MSG_FILTERED _WITNESS_BLOCK$2^30 + 3$Filtered block including witness data.

Header and block synchronization

Headers synchronize chain work before full block data. A locator is a sequence of block hashes, newest first, stepping back from a known tip toward genesis.

Messages getheaders and getblocks carry a locator and stop hash. Message headers returns block headers in forward order, each followed by CompactSize zero. Message block carries serialized full block data. A node must validate proof of work, linkage, target, timestamp, and deployment context for received headers before using them for chain selection.

RecordFieldsEncoding rule
BlockLocatorversion, hashesint32 version followed by vector<uint256> locator hashes.
getheaders/ getblocksversion, locator, stopHashint32, locator vector, then uint256 stop hash.
headers itemheader, txCount80-byte block header followed by CompactSize zero. A nonzero count is invalid for headers.

Compact block relay

BIP152 compact blocks reduce block-relay bandwidth by sending a header, short transaction identifiers, selected prefilled transactions, and requesting any missing transactions (sources: bip-0152).

Message sendcmpct negotiates compact-block mode and announcement preference. Messages cmpctblock, getblocktxn, and blocktxn carry the compact block and missing-transaction exchange. Compact reconstruction is an optimization only. The reconstructed full block must pass the same block validation rules as any received block message.

RecordFieldsEncoding rule
Compact Blockheader, nonce, shortIds, prefilledTxHeader, uint64 nonce, CompactSize count plus 6-byte short ids, then vector<PrefilledTx>.
PrefilledTxindexDelta, txCompactSize differential index from the previous prefilled transaction, then full transaction.
getblocktxnblockHash, indexesBlock hash followed by CompactSize differential transaction indexes.
blocktxnblockHash, transactionsBlock hash followed by transaction vector.

Address relay

Legacy address records and BIP155 address records use different encodings:

RecordFieldsEncoding rule
NetAddress NoTimeservices, address, portuint64 services, 16 address bytes, then uint16 port in big-endian network byte order. Used inside version.
NetAddress Legacytime, services, address, portuint32 time plus NetAddressNoTime. Used by addr.
AddrV2time, services, networkId, address, portuint32 time, CompactSize services, uint8 network id, CompactSize address length, address bytes, then big-endian port.

Messages addr and addrv2 relay legacy and BIP155 address records. Message sendaddrv2 announces BIP155 address-relay support, and getaddr requests known peer addresses subject to local rate limits. Address relay is unauthenticated gossip. Received addresses are hints, not validated reachability claims (sources: bip-0155).

Light-client services

Bitcoin P2P includes two optional light-client service families:

ServiceMessagesStatus
BIP37 bloom filtersfilterload, filteradd, filterclear, merkleblockOptional peer service; disabled unless a node chooses to provide bloom-filter support.
BIP157/158 compact filtersgetcfilters, cfilter, getcfheaders, cfheaders, getcfcheckpt, cfcheckptOptional compact-filter service for clients that verify filters against block-filter headers.

These services do not change block or transaction validity (sources: bip-0037,bip-0157,bip-0158).

MessagePayload fieldsEncoding rule
filterloadfilter, hashFuncs, tweak, flagsvarbytes, uint32, uint32, uint8.
filteradddatavarbytes.
filterclearemptyClears the peer’s BIP37 filter state.
merkleblockheader, total, hashes, flagsBlock header, uint32 total transactions, vector<uint256> hashes, and flag bytes.
getcfilterstype, startHeight, stopHashuint8, uint32, uint256.
cfiltertype, blockHash, filteruint8, uint256, varbytes.
getcfheaderstype, startHeight, stopHashuint8, uint32, uint256.
cfheaderstype, stopHash, prevHeader, filterHashesuint8, two uint256 values, then vector<uint256>.
getcfcheckpttype, stopHashuint8, uint256.
cfcheckpttype, stopHash, headersuint8, uint256, vector<uint256>.