Référence des messages réseau P2P de Bitcoin : le vocabulaire complet du protocole

Chaque nœud Bitcoin — du Raspberry Pi dans un placard à l’infrastructure d’une pool de minage — parle le même petit vocabulaire réseau. Cette référence liste chaque message P2P actuellement défini dans Bitcoin Core, groupé selon sa place dans le flux du protocole : la poignée de main version/verack et ses négociations modernes, la diffusion d’adresses, le relais de transactions par inv, le relais de blocs par en-têtes et blocs compacts, les deux familles de filtres, et le contrôle de connexion. Elle complète notre trio de l’opérateur de nœud, avec la référence RPC et la référence bitcoin.conf : ce que votre nœud vous dit (RPC), comment vous le configurez (bitcoin.conf), et ce qu’il dit au réseau (cette page). Les descriptions par message sont conservées en anglais.

Réponse rapide

Bitcoin parle un protocole pair-à-pair de 36 types de messages — c'est tout. Chaque connexion commence par la même poignée de main (version → négociations optionnelles comme wtxidrelay et sendaddrv2 → verack), puis tout le reste est du relais : adresses de pairs, annonces de transactions par inv/getdata/tx, et blocs par en-têtes ou blocs compacts BIP152. Cette référence liste chaque message actuellement défini dans Bitcoin Core (src/protocol.h, vérifié contre ALL_NET_MESSAGE_TYPES), son rôle, le BIP qui l'a introduit quand la source le précise, et son groupe dans le flux du protocole. Les anciens messages alert et reject, retirés de Core, sont volontairement exclus. Les descriptions par message sont conservées en anglais (paraphrases fidèles des commentaires du code source).

Les colonnes direction et groupe sont des classifications éditoriales de D-Central — le code source ne les définit pas. Le message « feature » (BIP434) est tout neuf (2026) : Core définit le message mais aucun identifiant de fonctionnalité n'est encore assigné. CSV/JSON gratuits sous CC BY 4.0.

Télécharger le CSV Télécharger le JSON API REST →

Poignée de main et négociation de fonctionnalités 6

Message	Rôle	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

Relais d'adresses 3

Message	Rôle	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

Relais de transactions 5

Message	Rôle	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

Relais de blocs 9

Message	Rôle	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

Filtres de Bloom (BIP37, hérité) 4

Message	Rôle	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

Filtres de blocs compacts (BIP157/158) 6

Message	Rôle	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

Contrôle de connexion 3

Message	Rôle	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 (espace de noms NetMsgType, vérifié 1:1 contre ALL_NET_MESSAGE_TYPES, commit cf0f2ae du 2026-07-21) + le texte de BIP-0434. Complète la référence RPC de Bitcoin Core et la référence bitcoin.conf — la pile complète de l'opérateur de nœud souverain.

Produits, réparations et guides connexes

Dernière révision: 26 juillet 2026.