Inside Bitcoin
Opening the selected file…
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1// Copyright (c) 2009-2010 Satoshi Nakamoto2// Copyright (c) 2009-present The Bitcoin Core developers3// Distributed under the MIT software license, see the accompanying4// file COPYING or http://www.opensource.org/licenses/mit-license.php.6#ifndef BITCOIN_PROTOCOL_H7#define BITCOIN_PROTOCOL_H9#include <kernel/messagestartchars.h> // IWYU pragma: export10#include <netaddress.h>11#include <primitives/transaction.h>12#include <serialize.h>13#include <streams.h>14#include <uint256.h>15#include <util/time.h>17#include <array>18#include <cstdint>19#include <limits>20#include <string>22/** Message header.23* (4) message start.24* (12) message type.25* (4) size.26* (4) checksum.27*/28class CMessageHeader29{30public:31static constexpr size_t MESSAGE_TYPE_SIZE = 12;32static constexpr size_t MESSAGE_SIZE_SIZE = 4;33static constexpr size_t CHECKSUM_SIZE = 4;34static constexpr size_t MESSAGE_SIZE_OFFSET = std::tuple_size_v<MessageStartChars> + MESSAGE_TYPE_SIZE;35static constexpr size_t CHECKSUM_OFFSET = MESSAGE_SIZE_OFFSET + MESSAGE_SIZE_SIZE;36static constexpr size_t HEADER_SIZE = std::tuple_size_v<MessageStartChars> + MESSAGE_TYPE_SIZE + MESSAGE_SIZE_SIZE + CHECKSUM_SIZE;38explicit CMessageHeader() = default;40/** Construct a P2P message header from message-start characters, a message type and the size of the message.41* @note Passing in a `msg_type` longer than MESSAGE_TYPE_SIZE will result in a run-time assertion error.42*/43CMessageHeader(const MessageStartChars& pchMessageStartIn, const char* msg_type, unsigned int nMessageSizeIn);45std::string GetMessageType() const;46bool IsMessageTypeValid() const;48SERIALIZE_METHODS(CMessageHeader, obj) { READWRITE(obj.pchMessageStart, obj.m_msg_type, obj.nMessageSize, obj.pchChecksum); }50MessageStartChars pchMessageStart{};51char m_msg_type[MESSAGE_TYPE_SIZE]{};52uint32_t nMessageSize{std::numeric_limits<uint32_t>::max()};53uint8_t pchChecksum[CHECKSUM_SIZE]{};54};56/**57* Bitcoin protocol message types. When adding new message types, don't forget58* to update ALL_NET_MESSAGE_TYPES below.59*/60namespace NetMsgType {61/**62* The version message provides information about the transmitting node to the63* receiving node at the beginning of a connection.64*/65inline constexpr const char* VERSION{"version"};66/**67* The verack message acknowledges a previously-received version message,68* informing the connecting node that it can begin to send other messages.69*/70inline constexpr const char* VERACK{"verack"};71/**72* The addr (IP address) message relays connection information for peers on the73* network.74*/75inline constexpr const char* ADDR{"addr"};76/**77* The addrv2 message relays connection information for peers on the network just78* like the addr message, but is extended to allow gossiping of longer node79* addresses (see BIP155).80*/81inline constexpr const char* ADDRV2{"addrv2"};82/**83* The sendaddrv2 message signals support for receiving ADDRV2 messages (BIP155).84* It also implies that its sender can encode as ADDRV2 and would send ADDRV285* instead of ADDR to a peer that has signaled ADDRV2 support by sending SENDADDRV2.86*/87inline constexpr const char* SENDADDRV2{"sendaddrv2"};88/**89* The inv message (inventory message) transmits one or more inventories of90* objects known to the transmitting peer.91*/92inline constexpr const char* INV{"inv"};93/**94* The getdata message requests one or more data objects from another node.95*/96inline constexpr const char* GETDATA{"getdata"};97/**98* The merkleblock message is a reply to a getdata message which requested a99* block using the inventory type MSG_MERKLEBLOCK.100* @since protocol version 70001 as described by BIP37.101*/102inline constexpr const char* MERKLEBLOCK{"merkleblock"};103/**104* The getblocks message requests an inv message that provides block header105* hashes starting from a particular point in the block chain.106*/107inline constexpr const char* GETBLOCKS{"getblocks"};108/**109* The getheaders message requests a headers message that provides block110* headers starting from a particular point in the block chain.111* @since protocol version 31800.112*/113inline constexpr const char* GETHEADERS{"getheaders"};114/**115* The tx message transmits a single transaction.116*/117inline constexpr const char* TX{"tx"};118/**119* The headers message sends one or more block headers to a node which120* previously requested certain headers with a getheaders message.121* @since protocol version 31800.122*/123inline constexpr const char* HEADERS{"headers"};124/**125* The block message transmits a single serialized block.126*/127inline constexpr const char* BLOCK{"block"};128/**129* The getaddr message requests an addr message from the receiving node,130* preferably one with lots of IP addresses of other receiving nodes.131*/132inline constexpr const char* GETADDR{"getaddr"};133/**134* The mempool message requests the TXIDs of transactions that the receiving135* node has verified as valid but which have not yet appeared in a block.136* @since protocol version 60002 as described by BIP35.137* Only available with service bit NODE_BLOOM, see also BIP111.138*/139inline constexpr const char* MEMPOOL{"mempool"};140/**141* The ping message is sent periodically to help confirm that the receiving142* peer is still connected.143*/144inline constexpr const char* PING{"ping"};145/**146* The pong message replies to a ping message, proving to the pinging node that147* the ponging node is still alive.148* @since protocol version 60001 as described by BIP31.149*/150inline constexpr const char* PONG{"pong"};151/**152* The notfound message is a reply to a getdata message which requested an153* object the receiving node does not have available for relay.154* @since protocol version 70001.155*/156inline constexpr const char* NOTFOUND{"notfound"};157/**158* The filterload message tells the receiving peer to filter all relayed159* transactions and requested merkle blocks through the provided filter.160* @since protocol version 70001 as described by BIP37.161* Only available with service bit NODE_BLOOM since protocol version162* 70011 as described by BIP111.163*/164inline constexpr const char* FILTERLOAD{"filterload"};165/**166* The filteradd message tells the receiving peer to add a single element to a167* previously-set bloom filter, such as a new public key.168* @since protocol version 70001 as described by BIP37.169* Only available with service bit NODE_BLOOM since protocol version170* 70011 as described by BIP111.171*/172inline constexpr const char* FILTERADD{"filteradd"};173/**174* The filterclear message tells the receiving peer to remove a previously-set175* bloom filter.176* @since protocol version 70001 as described by BIP37.177* Only available with service bit NODE_BLOOM since protocol version178* 70011 as described by BIP111.179*/180inline constexpr const char* FILTERCLEAR{"filterclear"};181/**182* Indicates that a node prefers to receive new block announcements via a183* "headers" message rather than an "inv".184* @since protocol version 70012 as described by BIP130.185*/186inline constexpr const char* SENDHEADERS{"sendheaders"};187/**188* The feefilter message tells the receiving peer not to inv us any txs189* which do not meet the specified min fee rate.190* @since protocol version 70013 as described by BIP133191*/192inline constexpr const char* FEEFILTER{"feefilter"};193/**194* Contains a 1-byte bool and 8-byte LE version number.195* Indicates that a node is willing to provide blocks via "cmpctblock" messages.196* May indicate that a node prefers to receive new block announcements via a197* "cmpctblock" message rather than an "inv", depending on message contents.198* @since protocol version 70014 as described by BIP 152199*/200inline constexpr const char* SENDCMPCT{"sendcmpct"};201/**202* Contains a CBlockHeaderAndShortTxIDs object - providing a header and203* list of "short txids".204* @since protocol version 70014 as described by BIP 152205*/206inline constexpr const char* CMPCTBLOCK{"cmpctblock"};207/**208* Contains a BlockTransactionsRequest209* Peer should respond with "blocktxn" message.210* @since protocol version 70014 as described by BIP 152211*/212inline constexpr const char* GETBLOCKTXN{"getblocktxn"};213/**214* Contains a BlockTransactions.215* Sent in response to a "getblocktxn" message.216* @since protocol version 70014 as described by BIP 152217*/218inline constexpr const char* BLOCKTXN{"blocktxn"};219/**220* getcfilters requests compact filters for a range of blocks.221* Only available with service bit NODE_COMPACT_FILTERS as described by222* BIP 157 & 158.223*/224inline constexpr const char* GETCFILTERS{"getcfilters"};225/**226* cfilter is a response to a getcfilters request containing a single compact227* filter.228*/229inline constexpr const char* CFILTER{"cfilter"};230/**231* getcfheaders requests a compact filter header and the filter hashes for a232* range of blocks, which can then be used to reconstruct the filter headers233* for those blocks.234* Only available with service bit NODE_COMPACT_FILTERS as described by235* BIP 157 & 158.236*/237inline constexpr const char* GETCFHEADERS{"getcfheaders"};238/**239* cfheaders is a response to a getcfheaders request containing a filter header240* and a vector of filter hashes for each subsequent block in the requested range.241*/242inline constexpr const char* CFHEADERS{"cfheaders"};243/**244* getcfcheckpt requests evenly spaced compact filter headers, enabling245* parallelized download and validation of the headers between them.246* Only available with service bit NODE_COMPACT_FILTERS as described by247* BIP 157 & 158.248*/249inline constexpr const char* GETCFCHECKPT{"getcfcheckpt"};250/**