Branch data Line data Source code
# 1 : : // Copyright (c) 2009-2010 Satoshi Nakamoto
# 2 : : // Copyright (c) 2009-2019 The Bitcoin Core developers
# 3 : : // Distributed under the MIT software license, see the accompanying
# 4 : : // file COPYING or http://www.opensource.org/licenses/mit-license.php.
# 5 : :
# 6 : : #ifndef __cplusplus
# 7 : : #error This header can only be compiled as C++.
# 8 : : #endif
# 9 : :
# 10 : : #ifndef BITCOIN_PROTOCOL_H
# 11 : : #define BITCOIN_PROTOCOL_H
# 12 : :
# 13 : : #include <netaddress.h>
# 14 : : #include <serialize.h>
# 15 : : #include <uint256.h>
# 16 : : #include <version.h>
# 17 : :
# 18 : : #include <stdint.h>
# 19 : : #include <string>
# 20 : :
# 21 : : /** Message header.
# 22 : : * (4) message start.
# 23 : : * (12) command.
# 24 : : * (4) size.
# 25 : : * (4) checksum.
# 26 : : */
# 27 : : class CMessageHeader
# 28 : : {
# 29 : : public:
# 30 : : static constexpr size_t MESSAGE_START_SIZE = 4;
# 31 : : static constexpr size_t COMMAND_SIZE = 12;
# 32 : : static constexpr size_t MESSAGE_SIZE_SIZE = 4;
# 33 : : static constexpr size_t CHECKSUM_SIZE = 4;
# 34 : : static constexpr size_t MESSAGE_SIZE_OFFSET = MESSAGE_START_SIZE + COMMAND_SIZE;
# 35 : : static constexpr size_t CHECKSUM_OFFSET = MESSAGE_SIZE_OFFSET + MESSAGE_SIZE_SIZE;
# 36 : : static constexpr size_t HEADER_SIZE = MESSAGE_START_SIZE + COMMAND_SIZE + MESSAGE_SIZE_SIZE + CHECKSUM_SIZE;
# 37 : : typedef unsigned char MessageStartChars[MESSAGE_START_SIZE];
# 38 : :
# 39 : : explicit CMessageHeader(const MessageStartChars& pchMessageStartIn);
# 40 : :
# 41 : : /** Construct a P2P message header from message-start characters, a command and the size of the message.
# 42 : : * @note Passing in a `pszCommand` longer than COMMAND_SIZE will result in a run-time assertion error.
# 43 : : */
# 44 : : CMessageHeader(const MessageStartChars& pchMessageStartIn, const char* pszCommand, unsigned int nMessageSizeIn);
# 45 : :
# 46 : : std::string GetCommand() const;
# 47 : : bool IsValid(const MessageStartChars& messageStart) const;
# 48 : :
# 49 : 154071 : SERIALIZE_METHODS(CMessageHeader, obj) { READWRITE(obj.pchMessageStart, obj.pchCommand, obj.nMessageSize, obj.pchChecksum); }
# 50 : :
# 51 : : char pchMessageStart[MESSAGE_START_SIZE];
# 52 : : char pchCommand[COMMAND_SIZE];
# 53 : : uint32_t nMessageSize;
# 54 : : uint8_t pchChecksum[CHECKSUM_SIZE];
# 55 : : };
# 56 : :
# 57 : : /**
# 58 : : * Bitcoin protocol message types. When adding new message types, don't forget
# 59 : : * to update allNetMessageTypes in protocol.cpp.
# 60 : : */
# 61 : : namespace NetMsgType {
# 62 : :
# 63 : : /**
# 64 : : * The version message provides information about the transmitting node to the
# 65 : : * receiving node at the beginning of a connection.
# 66 : : * @see https://bitcoin.org/en/developer-reference#version
# 67 : : */
# 68 : : extern const char* VERSION;
# 69 : : /**
# 70 : : * The verack message acknowledges a previously-received version message,
# 71 : : * informing the connecting node that it can begin to send other messages.
# 72 : : * @see https://bitcoin.org/en/developer-reference#verack
# 73 : : */
# 74 : : extern const char* VERACK;
# 75 : : /**
# 76 : : * The addr (IP address) message relays connection information for peers on the
# 77 : : * network.
# 78 : : * @see https://bitcoin.org/en/developer-reference#addr
# 79 : : */
# 80 : : extern const char* ADDR;
# 81 : : /**
# 82 : : * The inv message (inventory message) transmits one or more inventories of
# 83 : : * objects known to the transmitting peer.
# 84 : : * @see https://bitcoin.org/en/developer-reference#inv
# 85 : : */
# 86 : : extern const char* INV;
# 87 : : /**
# 88 : : * The getdata message requests one or more data objects from another node.
# 89 : : * @see https://bitcoin.org/en/developer-reference#getdata
# 90 : : */
# 91 : : extern const char* GETDATA;
# 92 : : /**
# 93 : : * The merkleblock message is a reply to a getdata message which requested a
# 94 : : * block using the inventory type MSG_MERKLEBLOCK.
# 95 : : * @since protocol version 70001 as described by BIP37.
# 96 : : * @see https://bitcoin.org/en/developer-reference#merkleblock
# 97 : : */
# 98 : : extern const char* MERKLEBLOCK;
# 99 : : /**
# 100 : : * The getblocks message requests an inv message that provides block header
# 101 : : * hashes starting from a particular point in the block chain.
# 102 : : * @see https://bitcoin.org/en/developer-reference#getblocks
# 103 : : */
# 104 : : extern const char* GETBLOCKS;
# 105 : : /**
# 106 : : * The getheaders message requests a headers message that provides block
# 107 : : * headers starting from a particular point in the block chain.
# 108 : : * @since protocol version 31800.
# 109 : : * @see https://bitcoin.org/en/developer-reference#getheaders
# 110 : : */
# 111 : : extern const char* GETHEADERS;
# 112 : : /**
# 113 : : * The tx message transmits a single transaction.
# 114 : : * @see https://bitcoin.org/en/developer-reference#tx
# 115 : : */
# 116 : : extern const char* TX;
# 117 : : /**
# 118 : : * The headers message sends one or more block headers to a node which
# 119 : : * previously requested certain headers with a getheaders message.
# 120 : : * @since protocol version 31800.
# 121 : : * @see https://bitcoin.org/en/developer-reference#headers
# 122 : : */
# 123 : : extern const char* HEADERS;
# 124 : : /**
# 125 : : * The block message transmits a single serialized block.
# 126 : : * @see https://bitcoin.org/en/developer-reference#block
# 127 : : */
# 128 : : extern const char* BLOCK;
# 129 : : /**
# 130 : : * The getaddr message requests an addr message from the receiving node,
# 131 : : * preferably one with lots of IP addresses of other receiving nodes.
# 132 : : * @see https://bitcoin.org/en/developer-reference#getaddr
# 133 : : */
# 134 : : extern const char* GETADDR;
# 135 : : /**
# 136 : : * The mempool message requests the TXIDs of transactions that the receiving
# 137 : : * node has verified as valid but which have not yet appeared in a block.
# 138 : : * @since protocol version 60002.
# 139 : : * @see https://bitcoin.org/en/developer-reference#mempool
# 140 : : */
# 141 : : extern const char* MEMPOOL;
# 142 : : /**
# 143 : : * The ping message is sent periodically to help confirm that the receiving
# 144 : : * peer is still connected.
# 145 : : * @see https://bitcoin.org/en/developer-reference#ping
# 146 : : */
# 147 : : extern const char* PING;
# 148 : : /**
# 149 : : * The pong message replies to a ping message, proving to the pinging node that
# 150 : : * the ponging node is still alive.
# 151 : : * @since protocol version 60001 as described by BIP31.
# 152 : : * @see https://bitcoin.org/en/developer-reference#pong
# 153 : : */
# 154 : : extern const char* PONG;
# 155 : : /**
# 156 : : * The notfound message is a reply to a getdata message which requested an
# 157 : : * object the receiving node does not have available for relay.
# 158 : : * @since protocol version 70001.
# 159 : : * @see https://bitcoin.org/en/developer-reference#notfound
# 160 : : */
# 161 : : extern const char* NOTFOUND;
# 162 : : /**
# 163 : : * The filterload message tells the receiving peer to filter all relayed
# 164 : : * transactions and requested merkle blocks through the provided filter.
# 165 : : * @since protocol version 70001 as described by BIP37.
# 166 : : * Only available with service bit NODE_BLOOM since protocol version
# 167 : : * 70011 as described by BIP111.
# 168 : : * @see https://bitcoin.org/en/developer-reference#filterload
# 169 : : */
# 170 : : extern const char* FILTERLOAD;
# 171 : : /**
# 172 : : * The filteradd message tells the receiving peer to add a single element to a
# 173 : : * previously-set bloom filter, such as a new public key.
# 174 : : * @since protocol version 70001 as described by BIP37.
# 175 : : * Only available with service bit NODE_BLOOM since protocol version
# 176 : : * 70011 as described by BIP111.
# 177 : : * @see https://bitcoin.org/en/developer-reference#filteradd
# 178 : : */
# 179 : : extern const char* FILTERADD;
# 180 : : /**
# 181 : : * The filterclear message tells the receiving peer to remove a previously-set
# 182 : : * bloom filter.
# 183 : : * @since protocol version 70001 as described by BIP37.
# 184 : : * Only available with service bit NODE_BLOOM since protocol version
# 185 : : * 70011 as described by BIP111.
# 186 : : * @see https://bitcoin.org/en/developer-reference#filterclear
# 187 : : */
# 188 : : extern const char* FILTERCLEAR;
# 189 : : /**
# 190 : : * Indicates that a node prefers to receive new block announcements via a
# 191 : : * "headers" message rather than an "inv".
# 192 : : * @since protocol version 70012 as described by BIP130.
# 193 : : * @see https://bitcoin.org/en/developer-reference#sendheaders
# 194 : : */
# 195 : : extern const char* SENDHEADERS;
# 196 : : /**
# 197 : : * The feefilter message tells the receiving peer not to inv us any txs
# 198 : : * which do not meet the specified min fee rate.
# 199 : : * @since protocol version 70013 as described by BIP133
# 200 : : */
# 201 : : extern const char* FEEFILTER;
# 202 : : /**
# 203 : : * Contains a 1-byte bool and 8-byte LE version number.
# 204 : : * Indicates that a node is willing to provide blocks via "cmpctblock" messages.
# 205 : : * May indicate that a node prefers to receive new block announcements via a
# 206 : : * "cmpctblock" message rather than an "inv", depending on message contents.
# 207 : : * @since protocol version 70014 as described by BIP 152
# 208 : : */
# 209 : : extern const char* SENDCMPCT;
# 210 : : /**
# 211 : : * Contains a CBlockHeaderAndShortTxIDs object - providing a header and
# 212 : : * list of "short txids".
# 213 : : * @since protocol version 70014 as described by BIP 152
# 214 : : */
# 215 : : extern const char* CMPCTBLOCK;
# 216 : : /**
# 217 : : * Contains a BlockTransactionsRequest
# 218 : : * Peer should respond with "blocktxn" message.
# 219 : : * @since protocol version 70014 as described by BIP 152
# 220 : : */
# 221 : : extern const char* GETBLOCKTXN;
# 222 : : /**
# 223 : : * Contains a BlockTransactions.
# 224 : : * Sent in response to a "getblocktxn" message.
# 225 : : * @since protocol version 70014 as described by BIP 152
# 226 : : */
# 227 : : extern const char* BLOCKTXN;
# 228 : : /**
# 229 : : * getcfilters requests compact filters for a range of blocks.
# 230 : : * Only available with service bit NODE_COMPACT_FILTERS as described by
# 231 : : * BIP 157 & 158.
# 232 : : */
# 233 : : extern const char* GETCFILTERS;
# 234 : : /**
# 235 : : * cfilter is a response to a getcfilters request containing a single compact
# 236 : : * filter.
# 237 : : */
# 238 : : extern const char* CFILTER;
# 239 : : /**
# 240 : : * getcfheaders requests a compact filter header and the filter hashes for a
# 241 : : * range of blocks, which can then be used to reconstruct the filter headers
# 242 : : * for those blocks.
# 243 : : * Only available with service bit NODE_COMPACT_FILTERS as described by
# 244 : : * BIP 157 & 158.
# 245 : : */
# 246 : : extern const char* GETCFHEADERS;
# 247 : : /**
# 248 : : * cfheaders is a response to a getcfheaders request containing a filter header
# 249 : : * and a vector of filter hashes for each subsequent block in the requested range.
# 250 : : */
# 251 : : extern const char* CFHEADERS;
# 252 : : /**
# 253 : : * getcfcheckpt requests evenly spaced compact filter headers, enabling
# 254 : : * parallelized download and validation of the headers between them.
# 255 : : * Only available with service bit NODE_COMPACT_FILTERS as described by
# 256 : : * BIP 157 & 158.
# 257 : : */
# 258 : : extern const char* GETCFCHECKPT;
# 259 : : /**
# 260 : : * cfcheckpt is a response to a getcfcheckpt request containing a vector of
# 261 : : * evenly spaced filter headers for blocks on the requested chain.
# 262 : : */
# 263 : : extern const char* CFCHECKPT;
# 264 : : }; // namespace NetMsgType
# 265 : :
# 266 : : /* Get a vector of all valid message types (see above) */
# 267 : : const std::vector<std::string>& getAllNetMessageTypes();
# 268 : :
# 269 : : /** nServices flags */
# 270 : : enum ServiceFlags : uint64_t {
# 271 : : // NOTE: When adding here, be sure to update serviceFlagToStr too
# 272 : : // Nothing
# 273 : : NODE_NONE = 0,
# 274 : : // NODE_NETWORK means that the node is capable of serving the complete block chain. It is currently
# 275 : : // set by all Bitcoin Core non pruned nodes, and is unset by SPV clients or other light clients.
# 276 : : NODE_NETWORK = (1 << 0),
# 277 : : // NODE_GETUTXO means the node is capable of responding to the getutxo protocol request.
# 278 : : // Bitcoin Core does not support this but a patch set called Bitcoin XT does.
# 279 : : // See BIP 64 for details on how this is implemented.
# 280 : : NODE_GETUTXO = (1 << 1),
# 281 : : // NODE_BLOOM means the node is capable and willing to handle bloom-filtered connections.
# 282 : : // Bitcoin Core nodes used to support this by default, without advertising this bit,
# 283 : : // but no longer do as of protocol version 70011 (= NO_BLOOM_VERSION)
# 284 : : NODE_BLOOM = (1 << 2),
# 285 : : // NODE_WITNESS indicates that a node can be asked for blocks and transactions including
# 286 : : // witness data.
# 287 : : NODE_WITNESS = (1 << 3),
# 288 : : // NODE_NETWORK_LIMITED means the same as NODE_NETWORK with the limitation of only
# 289 : : // serving the last 288 (2 day) blocks
# 290 : : // See BIP159 for details on how this is implemented.
# 291 : : NODE_NETWORK_LIMITED = (1 << 10),
# 292 : :
# 293 : : // Bits 24-31 are reserved for temporary experiments. Just pick a bit that
# 294 : : // isn't getting used, or one not being used much, and notify the
# 295 : : // bitcoin-development mailing list. Remember that service bits are just
# 296 : : // unauthenticated advertisements, so your code must be robust against
# 297 : : // collisions and other cases where nodes may be advertising a service they
# 298 : : // do not actually support. Other service bits should be allocated via the
# 299 : : // BIP process.
# 300 : : };
# 301 : :
# 302 : : /**
# 303 : : * Convert service flags (a bitmask of NODE_*) to human readable strings.
# 304 : : * It supports unknown service flags which will be returned as "UNKNOWN[...]".
# 305 : : * @param[in] flags multiple NODE_* bitwise-OR-ed together
# 306 : : */
# 307 : : std::vector<std::string> serviceFlagsToStr(uint64_t flags);
# 308 : :
# 309 : : /**
# 310 : : * Gets the set of service flags which are "desirable" for a given peer.
# 311 : : *
# 312 : : * These are the flags which are required for a peer to support for them
# 313 : : * to be "interesting" to us, ie for us to wish to use one of our few
# 314 : : * outbound connection slots for or for us to wish to prioritize keeping
# 315 : : * their connection around.
# 316 : : *
# 317 : : * Relevant service flags may be peer- and state-specific in that the
# 318 : : * version of the peer may determine which flags are required (eg in the
# 319 : : * case of NODE_NETWORK_LIMITED where we seek out NODE_NETWORK peers
# 320 : : * unless they set NODE_NETWORK_LIMITED and we are out of IBD, in which
# 321 : : * case NODE_NETWORK_LIMITED suffices).
# 322 : : *
# 323 : : * Thus, generally, avoid calling with peerServices == NODE_NONE, unless
# 324 : : * state-specific flags must absolutely be avoided. When called with
# 325 : : * peerServices == NODE_NONE, the returned desirable service flags are
# 326 : : * guaranteed to not change dependent on state - ie they are suitable for
# 327 : : * use when describing peers which we know to be desirable, but for which
# 328 : : * we do not have a confirmed set of service flags.
# 329 : : *
# 330 : : * If the NODE_NONE return value is changed, contrib/seeds/makeseeds.py
# 331 : : * should be updated appropriately to filter for the same nodes.
# 332 : : */
# 333 : : ServiceFlags GetDesirableServiceFlags(ServiceFlags services);
# 334 : :
# 335 : : /** Set the current IBD status in order to figure out the desirable service flags */
# 336 : : void SetServiceFlagsIBDCache(bool status);
# 337 : :
# 338 : : /**
# 339 : : * A shortcut for (services & GetDesirableServiceFlags(services))
# 340 : : * == GetDesirableServiceFlags(services), ie determines whether the given
# 341 : : * set of service flags are sufficient for a peer to be "relevant".
# 342 : : */
# 343 : : static inline bool HasAllDesirableServiceFlags(ServiceFlags services)
# 344 : 121 : {
# 345 : 121 : return !(GetDesirableServiceFlags(services) & (~services));
# 346 : 121 : }
# 347 : :
# 348 : : /**
# 349 : : * Checks if a peer with the given service flags may be capable of having a
# 350 : : * robust address-storage DB.
# 351 : : */
# 352 : : static inline bool MayHaveUsefulAddressDB(ServiceFlags services)
# 353 : 269 : {
# 354 : 269 : return (services & NODE_NETWORK) || (services & NODE_NETWORK_LIMITED);
# 355 : 269 : }
# 356 : :
# 357 : : enum class AddrSerialization {
# 358 : : DISK,
# 359 : : NETWORK_NOTIME,
# 360 : : NETWORK_WITHTIME,
# 361 : : };
# 362 : :
# 363 : : /** A CService with information about it as peer */
# 364 : : class CAddress : public CService
# 365 : : {
# 366 : : static constexpr uint32_t TIME_INIT{100000000};
# 367 : :
# 368 : : /** The disk serialization for CAddress includes a version number.
# 369 : : * Traditionally the number CLIENT_VERSION was used, but it has since
# 370 : : * been disentangled from it. */
# 371 : : static constexpr uint32_t DISK_VERSION{210000};
# 372 : :
# 373 : : public:
# 374 : 71386 : CAddress() : CService{} {};
# 375 : 15843 : explicit CAddress(CService ipIn, ServiceFlags nServicesIn) : CService{ipIn}, nServices{nServicesIn} {};
# 376 : :
# 377 : : SERIALIZE_METHODS_PARAMS(CAddress, obj, AddrSerialization, fmt)
# 378 : 4272 : {
# 379 : 4272 : SER_READ(obj, obj.nTime = TIME_INIT);
# 380 : 4272 : switch (fmt) {
# 381 : 202 : case AddrSerialization::DISK: {
# 382 : 202 : uint32_t disk_version = DISK_VERSION;
# 383 : 202 : READWRITE(disk_version);
# 384 : 202 : READWRITE(obj.nTime);
# 385 : 202 : break;
# 386 : 0 : }
# 387 : 1293 : case AddrSerialization::NETWORK_WITHTIME:
# 388 : 1293 : READWRITE(obj.nTime);
# 389 : 1293 : break;
# 390 : 2777 : case AddrSerialization::NETWORK_NOTIME:
# 391 : 2777 : // The only time we serialize a CAddress object without nTime is in
# 392 : 2777 : // the initial VERSION messages which contain two CAddress records.
# 393 : 2777 : break;
# 394 : 4268 : } // no default case, so the compiler can warn about missing cases
# 395 : 4268 : READWRITE(Using<CustomUintFormatter<8>>(obj.nServices), AsBase<CService>(obj));
# 396 : 4268 : }
# 397 : :
# 398 : : ServiceFlags nServices{NODE_NONE};
# 399 : : // disk and network only
# 400 : : uint32_t nTime{TIME_INIT};
# 401 : : };
# 402 : :
# 403 : : /** getdata message type flags */
# 404 : : const uint32_t MSG_WITNESS_FLAG = 1 << 30;
# 405 : : const uint32_t MSG_TYPE_MASK = 0xffffffff >> 2;
# 406 : :
# 407 : : /** getdata / inv message types.
# 408 : : * These numbers are defined by the protocol. When adding a new value, be sure
# 409 : : * to mention it in the respective BIP.
# 410 : : */
# 411 : : enum GetDataMsg {
# 412 : : UNDEFINED = 0,
# 413 : : MSG_TX = 1,
# 414 : : MSG_BLOCK = 2,
# 415 : : // The following can only occur in getdata. Invs always use TX or BLOCK.
# 416 : : MSG_FILTERED_BLOCK = 3, //!< Defined in BIP37
# 417 : : MSG_CMPCT_BLOCK = 4, //!< Defined in BIP152
# 418 : : MSG_WITNESS_BLOCK = MSG_BLOCK | MSG_WITNESS_FLAG, //!< Defined in BIP144
# 419 : : MSG_WITNESS_TX = MSG_TX | MSG_WITNESS_FLAG, //!< Defined in BIP144
# 420 : : MSG_FILTERED_WITNESS_BLOCK = MSG_FILTERED_BLOCK | MSG_WITNESS_FLAG,
# 421 : : };
# 422 : :
# 423 : : /** inv message data */
# 424 : : class CInv
# 425 : : {
# 426 : : public:
# 427 : : CInv();
# 428 : : CInv(int typeIn, const uint256& hashIn);
# 429 : :
# 430 : 175979 : SERIALIZE_METHODS(CInv, obj) { READWRITE(obj.type, obj.hash); }
# 431 : :
# 432 : : friend bool operator<(const CInv& a, const CInv& b);
# 433 : :
# 434 : : std::string GetCommand() const;
# 435 : : std::string ToString() const;
# 436 : :
# 437 : : int type;
# 438 : : uint256 hash;
# 439 : : };
# 440 : :
# 441 : : #endif // BITCOIN_PROTOCOL_H
|
