Bitcoin P2P Network Message Reference: The Complete Wire Vocabulary
Every Bitcoin node — from a Raspberry Pi in a closet to a mining pool’s infrastructure — speaks the same small wire vocabulary. This reference lists every P2P network message currently defined in Bitcoin Core, grouped by where it sits in the protocol flow: the version/verack handshake and its modern feature negotiations, address gossip, inv-based transaction relay, header-first and compact-block relay, both filter families, and connection control. It completes our node-operator set alongside the RPC reference and the bitcoin.conf reference: what your node says to you (RPC), how you configure it (bitcoin.conf), and what it says to the network (this page).
Quick answer
Bitcoin speaks a peer-to-peer protocol of just 36 message types — that's the whole wire vocabulary. Every connection starts with the same handshake (version → optional negotiations like wtxidrelay and sendaddrv2 → verack), and everything after that is relay: peer addresses, transaction announcements via inv/getdata/tx, and blocks via headers or BIP152 compact blocks. This reference lists every message currently defined in Bitcoin Core (src/protocol.h, verified 1:1 against ALL_NET_MESSAGE_TYPES), what it does, the BIP that introduced it where the source states one, and where it sits in the protocol flow. The long-removed alert and reject messages are deliberately excluded.
The direction and group columns are D-Central editorial classifications — the source defines neither. The "feature" message (BIP434) is brand new in 2026: Core defines the message but no feature IDs are assigned yet. Free CSV/JSON under CC BY 4.0; as-of 2026-07-26, Core master commit cf0f2ae.
Download CSV Download JSON REST API →
Handshake & feature negotiation 6
| Message | Purpose | BIP | Direction |
|---|---|---|---|
version | Provides information about the transmitting node to the receiving node at the beginning of a connection. Each peer sends one as the first message. | — | both |
verack | Acknowledges a previously-received version message, informing the connecting node that it can begin to send other messages. | — | response |
wtxidrelay | Indicates that a node prefers to relay transactions via wtxid rather than txid. Sent during the handshake, before verack (protocol version 70016+). | BIP339 | announcement |
sendaddrv2 | Signals support for receiving addrv2 messages; also implies the sender can encode addrv2 and will send it instead of addr to peers that signaled the same. Sent before verack. | BIP155 | announcement |
sendtxrcncl | Contains a 4-byte version number and an 8-byte salt used to compute short txids for efficient transaction reconciliation (Erlay). Negotiated during the handshake. | BIP330 | announcement |
feature | Generic peer feature negotiation message: announces and negotiates support of new P2P features without bumping the protocol version. New in 2026; Core defines the message but no feature IDs are assigned yet. | BIP434 | announcement |
Address relay 3
| Message | Purpose | BIP | Direction |
|---|---|---|---|
addr | Relays connection information (IP addresses) for peers on the network. | — | announcement |
addrv2 | Relays peer connection information like addr, but extended to allow gossiping of longer node addresses (e.g. Tor v3, I2P). | BIP155 | announcement |
getaddr | Requests an addr message from the receiving node, preferably one with many IP addresses of other receiving nodes. | — | request |
Transaction relay 5
| Message | Purpose | BIP | Direction |
|---|---|---|---|
inv | Transmits one or more inventories (tx/block object identifiers) known to the transmitting peer. Used to announce both transactions and blocks. | — | announcement |
getdata | Requests one or more data objects (transactions, blocks, merkle blocks, compact blocks) from another node, typically after an inv. | — | request |
tx | Transmits a single transaction, typically in reply to a getdata request for an announced transaction. | — | response |
mempool | Requests the TXIDs of transactions the receiving node has verified as valid but which have not yet appeared in a block. Only available with service bit NODE_BLOOM (BIP111). | BIP35 | request |
feefilter | Tells the receiving peer not to inv any transactions that do not meet the specified minimum fee rate. | BIP133 | announcement |
Block relay 9
| Message | Purpose | BIP | Direction |
|---|---|---|---|
getblocks | Requests an inv message providing block header hashes starting from a particular point in the block chain (legacy block-first sync). | — | request |
getheaders | Requests a headers message providing block headers starting from a particular point in the block chain (protocol version 31800+). | — | request |
headers | Sends one or more block headers, either in reply to getheaders or as an unsolicited new-block announcement when the peer sent sendheaders. | — | both |
block | Transmits a single serialized block, typically in reply to a getdata request. | — | response |
sendheaders | Indicates the node prefers to receive new block announcements via a headers message rather than an inv. | BIP130 | announcement |
sendcmpct | Contains a 1-byte bool and 8-byte LE version number; indicates willingness to provide blocks via cmpctblock messages, and may indicate a preference to receive new block announcements as cmpctblock rather than inv. | BIP152 | announcement |
cmpctblock | Contains a CBlockHeaderAndShortTxIDs object providing a block header plus a list of short txids — sent as a high-bandwidth block announcement or in reply to a getdata compact-block request. | BIP152 | both |
getblocktxn | Contains a BlockTransactionsRequest asking for the transactions of a compact block that the receiver could not reconstruct from its mempool; peer should respond with blocktxn. | BIP152 | request |
blocktxn | Contains a BlockTransactions object with the requested transactions, sent in response to a getblocktxn message. | BIP152 | response |
Bloom filters (BIP37, legacy) 4
| Message | Purpose | BIP | Direction |
|---|---|---|---|
filterload | Tells the receiving peer to filter all relayed transactions and requested merkle blocks through the provided bloom filter. Only available with service bit NODE_BLOOM (BIP111). | BIP37 | request |
filteradd | Tells the receiving peer to add a single element (such as a new public key) to a previously-set bloom filter. Only available with service bit NODE_BLOOM (BIP111). | BIP37 | request |
filterclear | Tells the receiving peer to remove a previously-set bloom filter. Only available with service bit NODE_BLOOM (BIP111). | BIP37 | request |
merkleblock | Reply to a getdata message that requested a block using the inventory type MSG_MERKLEBLOCK — a filtered block with a partial merkle tree. | BIP37 | response |
Compact block filters (BIP157/158) 6
| Message | Purpose | BIP | Direction |
|---|---|---|---|
getcfilters | Requests compact block filters for a range of blocks. Only available with service bit NODE_COMPACT_FILTERS. | BIP157 / BIP158 | request |
cfilter | Response to a getcfilters request containing a single compact filter. | BIP157 / BIP158 | response |
getcfheaders | Requests a compact filter header and the filter hashes for a range of blocks, which can then be used to reconstruct the filter headers for those blocks. Only available with service bit NODE_COMPACT_FILTERS. | BIP157 / BIP158 | request |
cfheaders | Response to a getcfheaders request containing a filter header and a vector of filter hashes for each subsequent block in the requested range. | BIP157 / BIP158 | response |
getcfcheckpt | Requests evenly spaced compact filter headers, enabling parallelized download and validation of the headers between them. Only available with service bit NODE_COMPACT_FILTERS. | BIP157 / BIP158 | request |
cfcheckpt | Response to a getcfcheckpt request containing a vector of evenly spaced filter headers for blocks on the requested chain. | BIP157 / BIP158 | response |
Connection control 3
| Message | Purpose | BIP | Direction |
|---|---|---|---|
ping | Sent periodically to help confirm that the receiving peer is still connected. | — | request |
pong | Replies to a ping message, proving to the pinging node that the ponging node is still alive (protocol version 60001+, BIP31). | BIP31 | response |
notfound | Reply to a getdata message that requested an object the receiving node does not have available for relay (protocol version 70001+). | — | response |
Source: Bitcoin Core src/protocol.h (NetMsgType namespace, verified 1:1 against ALL_NET_MESSAGE_TYPES, commit cf0f2ae, 2026-07-21) + the BIP-0434 text. Completes the Bitcoin Core RPC reference and the bitcoin.conf reference — the full sovereign node-operator stack.
Related products, repair, and setup paths
- how D-Central diagnoses ASIC repairs
- ASIC troubleshooting library
- ASIC manuals and repair guides
- replacement hashboards
- ASIC control boards
- ASIC power supplies
- S19 family replacement hashboard
- C52 replacement control board
- APW12 S19 power supply
- immersion cooling hub
- home immersion cooling guide
- ASIC miners for immersion planning
- ASIC cooling parts
- airflow shroud before immersion
- compare miner specs in the database
- ASIC repair support
Last reviewed July 26, 2026.