Module bitcoin_netmsg::NetMsgType
source · Expand description
| Bitcoin protocol message types. When | adding new message types, don’t forget | to update allNetMessageTypes in protocol.cpp. |
Constants
- | 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. @since protocol version 70014 | as described by BIP 152 |
- | 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”. @since protocol version | 70014 as described by BIP 152 |
- | The feefilter message tells the receiving | peer not to inv us any txs which do not | meet the specified min fee rate. @since | protocol version 70013 as described | by BIP133 |
- | The filteradd message tells the receiving | peer to add a single element to a previously-set | bloom filter, such as a new public key. | @since protocol version 70001 as described | by BIP37. | | Only available with service bit NODE_BLOOM | since protocol version 70011 as described | by BIP111. |
- | The filterclear message tells the receiving | peer to remove a previously-set bloom | filter. @since protocol version 70001 | as described by BIP37. | | Only available with service bit NODE_BLOOM | since protocol version 70011 as described | by BIP111. |
- | The filterload message tells the receiving | peer to filter all relayed transactions | and requested merkle blocks through | the provided filter. @since protocol | version 70001 as described by BIP37. | | Only available with service bit NODE_BLOOM | since protocol version 70011 as described | by BIP111. |
- | 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. @since protocol version 70014 | as described by BIP 152 |
- | 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. @since protocol version | 31800. |
- | The headers message sends one or more | block headers to a node which previously | requested certain headers with a getheaders | message. @since protocol version 31800. |
- | 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. @since | protocol version 60002. |
- | The merkleblock message is a reply to | a getdata message which requested a | block using the inventory type MSG_MERKLEBLOCK. | @since protocol version 70001 as described | by BIP37. |
- | The notfound message is a reply to a getdata | message which requested an object the | receiving node does not have available | for relay. @since protocol version | 70001. |
- | 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. @since | protocol version 60001 as described | by BIP31. |
- | 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. @since protocol | version 70014 as described by BIP 152 |
- | Indicates that a node prefers to receive | new block announcements via a “headers” | message rather than an “inv”. @since | protocol version 70012 as described | by BIP130. |
- | 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. @since protocol version 70016 | as described by BIP 339. |