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.
|