Bitcoin protocol message types. When adding new message types, don't forget to update ALL_NET_MESSAGE_TYPES below.
Variables
Name |
Description |
The addr (IP address) message relays connection information for peers on the network. |
|
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). |
|
The block message transmits a single serialized block. |
|
Contains a BlockTransactions. Sent in response to a "getblocktxn" message. |
|
cfcheckpt is a response to a getcfcheckpt request containing a vector of evenly spaced filter headers for blocks on the requested chain. |
|
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 is a response to a getcfilters request containing a single compact filter. |
|
Contains a CBlockHeaderAndShortTxIDs object ‐ providing a header and list of "short txids". |
|
BIP 434 Peer feature negotiation |
|
The feefilter message tells the receiving peer not to inv us any txs which do not meet the specified min fee rate. |
|
The filteradd message tells the receiving peer to add a single element to a previously‐set bloom filter, such as a new public key. |
|
The filterclear message tells the receiving peer to remove a previously‐set bloom filter. |
|
The filterload message tells the receiving peer to filter all relayed transactions and requested merkle blocks through the provided filter. |
|
The getaddr message requests an addr message from the receiving node, preferably one with lots of IP addresses of other receiving nodes. |
|
The getblocks message requests an inv message that provides block header hashes starting from a particular point in the block chain. |
|
Contains a BlockTransactionsRequest Peer should respond with "blocktxn" message. |
|
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 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 requests compact filters for a range of blocks. Only available with service bit NODE_COMPACT_FILTERS as described by BIP 157 & 158. |
|
The getdata message requests one or more data objects from another node. |
|
The getheaders message requests a headers message that provides block headers starting from a particular point in the block chain. |
|
The headers message sends one or more block headers to a node which previously requested certain headers with a getheaders message. |
|
The inv message (inventory message) transmits one or more inventories of objects known to the transmitting peer. |
|
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. |
|
The merkleblock message is a reply to a getdata message which requested a block using the inventory type MSG_MERKLEBLOCK. |
|
The notfound message is a reply to a getdata message which requested an object the receiving node does not have available for relay. |
|
The ping message is sent periodically to help confirm that the receiving peer is still connected. |
|
The pong message replies to a ping message, proving to the pinging node that the ponging node is still alive. |
|
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. |
|
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. |
|
Indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv". |
|
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. |
|
The tx message transmits a single transaction. |
|
The verack message acknowledges a previously‐received version message, informing the connecting node that it can begin to send other messages. |
|
The version message provides information about the transmitting node to the receiving node at the beginning of a connection. |
|
Indicates that a node prefers to relay transactions via wtxid, rather than txid. |
Created with MrDocs