Bitcoin protocol message types. When adding new message types, don't forget to update ALL_NET_MESSAGE_TYPES below.
| Name | Description |
|---|---|
ADDR | The addr (IP address) message relays connection information for peers on the network. |
ADDRV2 | The addrv2 message relays connection information for peers on the network just like the addr message, but is extended to allow gossiping of longer node addresses (see BIP155). |
BLOCK | The block message transmits a single serialized block. |
BLOCKTXN | Contains a BlockTransactions. Sent in response to a "getblocktxn" message. |
CFCHECKPT | cfcheckpt is a response to a getcfcheckpt request containing a vector of evenly spaced filter headers for blocks on the requested chain. |
CFHEADERS | cfheaders is a response to a getcfheaders request containing a filter header and a vector of filter hashes for each subsequent block in the requested range. |
CFILTER | cfilter is a response to a getcfilters request containing a single compact filter. |
CMPCTBLOCK | Contains a CBlockHeaderAndShortTxIDs object - providing a header and list of "short txids". |
FEATURE | BIP 434 Peer feature negotiation |
FEEFILTER | The feefilter message tells the receiving peer not to inv us any txs which do not meet the specified min fee rate. |
FILTERADD | The filteradd message tells the receiving peer to add a single element to a previously-set bloom filter, such as a new public key. |
FILTERCLEAR | The filterclear message tells the receiving peer to remove a previously-set bloom filter. |
FILTERLOAD | The filterload message tells the receiving peer to filter all relayed transactions and requested merkle blocks through the provided filter. |
GETADDR | The getaddr message requests an addr message from the receiving node, preferably one with lots of IP addresses of other receiving nodes. |
GETBLOCKS | The getblocks message requests an inv message that provides block header hashes starting from a particular point in the block chain. |
GETBLOCKTXN | Contains a BlockTransactionsRequest Peer should respond with "blocktxn" message. |
GETCFCHECKPT | 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 as described by BIP 157 & 158. |
GETCFHEADERS | 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 as described by BIP 157 & 158. |
GETCFILTERS | getcfilters requests compact filters for a range of blocks. Only available with service bit NODE_COMPACT_FILTERS as described by BIP 157 & 158. |
GETDATA | The getdata message requests one or more data objects from another node. |
GETHEADERS | The getheaders message requests a headers message that provides block headers starting from a particular point in the block chain. |
HEADERS | The headers message sends one or more block headers to a node which previously requested certain headers with a getheaders message. |
INV | The inv message (inventory message) transmits one or more inventories of objects known to the transmitting peer. |
MEMPOOL | The mempool message requests the TXIDs of transactions that the receiving node has verified as valid but which have not yet appeared in a block. |
MERKLEBLOCK | The merkleblock message is a reply to a getdata message which requested a block using the inventory type MSG_MERKLEBLOCK. |
NOTFOUND | The notfound message is a reply to a getdata message which requested an object the receiving node does not have available for relay. |
PING | The ping message is sent periodically to help confirm that the receiving peer is still connected. |
PONG | The pong message replies to a ping message, proving to the pinging node that the ponging node is still alive. |
SENDADDRV2 | The sendaddrv2 message signals support for receiving ADDRV2 messages (BIP155). It also implies that its sender can encode as ADDRV2 and would send ADDRV2 instead of ADDR to a peer that has signaled ADDRV2 support by sending SENDADDRV2. |
SENDCMPCT | Contains a 1-byte bool and 8-byte LE version number. Indicates that a node is willing to provide blocks via "cmpctblock" messages. May indicate that a node prefers to receive new block announcements via a "cmpctblock" message rather than an "inv", depending on message contents. |
SENDHEADERS | Indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv". |
SENDTXRCNCL | Contains a 4-byte version number and an 8-byte salt. The salt is used to compute short txids needed for efficient txreconciliation, as described by BIP 330. |
TX | The tx message transmits a single transaction. |
VERACK | The verack message acknowledges a previously-received version message, informing the connecting node that it can begin to send other messages. |
VERSION | The version message provides information about the transmitting node to the receiving node at the beginning of a connection. |
WTXIDRELAY | Indicates that a node prefers to relay transactions via wtxid, rather than txid. |