> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/the-network/the-bitcoin-network/peer-to-peer-protocol.md). # Peer-To-Peer Protocol This page describes the Bitcoin Network Protocol used by nodes running SV Node to communicate transaction and block information on the BSV Blockchain network. This is a current standard means for nodes to communicate information about the ledger between each other including valid transactions, block discovery messages and more. For protocol used in mining, see Getminingcandidate. There have been a number of P2P protocol changes made since 2020. These changes are published on the [Bitcoin SV Node Github repository](https://github.com/bitcoin-sv-specs/protocol/tree/master/p2p) 1. Message structure | Field Size | Description | Data type | Comments | | ---------- | ----------- | --------- | ------------------------------------------------------------------------------------------------------------ | | 4 | magic | uint32\_t | Magic value indicating message origin network, and used to seek to next message when stream state is unknown | | 12 | command | char\[12] | ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected) | | 4 | length | uint32\_t | Length of payload in number of bytes | | 4 | checksum | uint32\_t | First 4 bytes of sha256(sha256(payload)) | | ? | payload | uchar\[] | The actual data | Known magic values: | Network | Magic value | Sent over wire as | | --------------- | ----------- | ----------------- | | mainnet | 0xE8F3E1E3 | E3 E1 F3 E8 | | testnet 3 | 0xF4F3E5F4 | F4 E5 F3 F4 | | scaling testnet | 0xF9C4CEFB | FB CE C4 F9 | | regtest | 0xFABFB5DA | DA B5 BF FA | 1. Variable length integer Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length. Longer numbers are encoded in little endian. | Value | Storage length | Format | |-------|----------------|--------| | = 31402). **Not present in version message.** | | | | 8 | services | uint64\_t | same service(s) listed in version | | 16 | IPv6/4 | char\[16] | IPv6 address. Network byte order. The original client only supported IPv4 and only read the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [IPv4-mapped IPv6 address](http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses) (12 bytes *00 00 00 00 00 00 00 00 00 00 FF FF*, followed by the 4 bytes of the IPv4 address). | | 2 | port | uint16\_t | port number, network byte order | Hexdump example of Network address structure 1. Inventory Vectors Inventory vectors are used for notifying other nodes about objects they have or data which is being requested. Inventory vectors consist of the following data format: | Field Size | Description | Data type | Comments | | ---------- | ----------- | --------- | --------------------------------------------------- | | 4 | type | uint32\_t | Identifies the object type linked to this inventory | | 32 | hash | char\[32] | Hash of the object | The object type is currently defined as one of the following possibilities: | Value | Name | Description | | ----- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | ERROR | Any data of with this number may be ignored | | 1 | MSG\_TX | Hash is related to a transaction | | 2 | MSG\_BLOCK | Hash is related to a data block | | 3 | MSG\_FILTERED\_BLOCK | Hash of a block header; identical to MSG\_BLOCK. Only to be used in getdata message. Indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set. | | 4 | MSG\_CMPCT\_BLOCK | Hash of a block header; identical to MSG\_BLOCK. Only to be used in getdata message. Indicates the reply should be a cmpctblock message. See BIP 152 for more info. | Other Data Type values are considered reserved for future implementations. 1. Block Headers Block headers are sent in a headers packet in response to a getheaders message. | Field Size | Description | Data type | Comments | | ---------- | ------------ | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 4 | version | int32\_t | Block version information (note, this is signed) | | 32 | prev\_block | char\[32] | The hash value of the previous block this particular block references | | 32 | merkle\_root | char\[32] | The reference to a Merkle tree collection which is a hash of all transactions related to this block | | 4 | timestamp | uint32\_t | A timestamp recording when this block was created (Will overflow in 2106) | | 4 | bits | uint32\_t | The calculated difficulty target being used for this block | | 4 | nonce | uint32\_t | The nonce used to generate this block… to allow variations of the header and compute different hashes | | 1+ | txn\_count | var\_int | Number of transaction entries, this value is always 0 | cf. Block hashing algorithm 1. Differential encoding Several uses of CompactSize below are "differentially encoded". For these, instead of using raw indexes, the number encoded is the difference between the current index and the previous index, minus one. For example, a first index of 0 implies a real index of 0, a second index of 0 thereafter refers to a real index of 1, etc. 2. PrefilledTransaction A PrefilledTransaction structure is used in HeaderAndShortIDs to provide a list of a few transactions explicitly. | Field Name | Type | Size | Encoding | Purpose | | ---------- | ----------- | ---------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------- | | index | CompactSize | 1, 3 bytes | Compact Size, differentially encoded since the last PrefilledTransaction in a list | The index into the block at which this transaction is | | tx | Transaction | variable | As encoded in tx messages | The transaction which is in the block at index index. | See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 1. HeaderAndShortIDs A HeaderAndShortIDs structure is used to relay a block header, the short transactions IDs used for matching already-available transactions, and a select few transactions which we expect a peer may be missing. | Field Name | Type | Size | Encoding | Purpose | | -------------------- | ----------------------------- | ----------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | header | Block header | 80 bytes | First 80 bytes of the block as defined by the encoding used by "block" messages | The header of the block being provided | | nonce | uint64\_t | 8 bytes | Little Endian | A nonce for use in short transaction ID calculations | | shortids\_length | CompactSize | 1 or 3 bytes | As used to encode array lengths elsewhere | The number of short transaction IDs in shortids (ie block tx count - prefilledtxn\_length) | | shortids | List of 6-byte integers | 6\*shortids\_length bytes | Little Endian | The short transaction IDs calculated from the transactions which were not provided explicitly in prefilledtxn | | prefilledtxn\_length | CompactSize | 1 or 3 bytes | As used to encode array lengths elsewhere | The number of prefilled transactions in prefilledtxn (ie block tx count - shortids\_length) | | prefilledtxn | List of PrefilledTransactions | variable size\*prefilledtxn\_length | As defined by PrefilledTransaction definition, above | Used to provide the coinbase transaction and a select few which we expect a peer may be missing | See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 1. BlockTransactionsRequest A BlockTransactionsRequest structure is used to list transaction indexes in a block being requested. | Field Name | Type | Size | Encoding | Purpose | | --------------- | -------------------- | ----------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------ | | blockhash | Binary blob | 32 bytes | The output from a double-SHA256 of the block header, as used elsewhere | The blockhash of the block which the transactions being requested are in | | indexes\_length | CompactSize | 1 or 3 bytes | As used to encode array lengths elsewhere | The number of transactions being requested | | indexes | List of CompactSizes | 1 or 3 bytes\*indexes\_length | Differentially encoded | The indexes of the transactions being requested in the block | See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 1. BlockTransactions A BlockTransactions structure is used to provide some of the transactions in a block, as requested. | Field Name | Type | Size | Encoding | Purpose | | -------------------- | -------------------- | ------------ | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- | | blockhash | Binary blob | 32 bytes | The output from a double-SHA256 of the block header, as used elsewhere | The blockhash of the block which the transactions being provided are in | | transactions\_length | CompactSize | 1 or 3 bytes | As used to encode array lengths elsewhere | The number of transactions provided | | transactions | List of Transactions | variable | As encoded in tx messages | The transactions provided | See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 1. Short transaction ID Short transaction IDs are used to represent a transaction without sending a full 256-bit hash. They are calculated by: 2. single-SHA256 hashing the block header with the nonce appended (in little-endian) 3. Running SipHash-2-4 with the input being the transaction ID and the keys (k0/k1) set to the first two little-endian 64-bit integers from the above hash, respectively. 4. Dropping the 2 most significant bytes from the SipHash output to make it 6 bytes. See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 5. Message types 6. version When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version. Payload: | Field Size | Description | Data type | Comments | | ---------- | ------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | 4 | version | int32\_t | Identifies protocol version being used by the node | | 8 | services | uint64\_t | bitfield of features to be enabled for this connection | | 8 | timestamp | int64\_t | standard UNIX timestamp in seconds | | 26 | addr\_recv | net\_addr | The network address of the node receiving this message | | | | | Fields below require version ≥ 106 | | 26 | addr\_from | net\_addr | The network address of the node emitting this message | | 8 | nonce | uint64\_t | Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self. | | ? | user\_agent | var\_str | [User Agent](https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki) (0x00 if string is 0 bytes long) | | 4 | start\_height | int32\_t | The last block received by the emitting node | | | | | Fields below require version ≥ 70001 | | 1 | relay | bool | Whether the remote peer should announce relayed transactions or not, see [BIP 0037](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) | A "verack" packet shall be sent if the version packet was accepted. The following services are currently assigned: | Value | Name | Description | | ----- | ---------------------- | ------------------------------------------------------------------------------ | | 1 | NODE\_NETWORK | This node can be asked for full blocks instead of just headers. | | 2 | NODE\_GETUTXO | See [BIP 0064](https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki) | | 4 | NODE\_BLOOM | See [BIP 0111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki) | | 1024 | NODE\_NETWORK\_LIMITED | See [BIP 0159](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki) | Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent): And here's a modern (60002) protocol version client advertising itself to a local peer... Newer protocol includes the checksum now, this is from a mainline (satoshi) client during an outgoing connection to another local client, notice that it does not fill out the address information at all when the source or destination is "unroutable". 1. verack The *verack* message is sent in reply to *version*. This message consists of only a message header with the command string "verack". Hexdump of the verack message: 2. addr Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours Payload: | Field Size | Description | Data type | Comments | | ---------- | ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 4 | version | int32\_t | Transaction data format version (note, this is signed) | | 1+ | tx\_in count | var\_int | Number of Transaction inputs (never zero) | | 41+ | tx\_in | tx\_in\[] | A list of 1 or more transaction inputs or sources for coins | | 1+ | tx\_out count | var\_int | Number of Transaction outputs | | 9+ | tx\_out | tx\_out\[] | A list of 1 or more transaction outputs or destinations for coins | | 4 | lock\_time | uint32\_t | The block number or timestamp at which this transaction is unlocked: 0 = Not locked, < 500000000 = Block number at which this transaction is unlocked, >= 500000000 = UNIX timestamp at which this transaction is unlocked | TxIn consists of the following fields: | Field Size | Description | Data type | Comments | | ---------- | ---------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | 36 | previous\_output | outpoint | The previous output transaction reference, as an OutPoint structure | | 1+ | script length | var\_int | The length of the signature script | | ? | signature script | uchar\[] | Computational Script for confirming transaction authorization | | 4 | sequence | uint32\_t | Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block. | The OutPoint structure consists of the following fields: | Field Size | Description | Data type | Comments | | ---------- | ----------- | --------- | -------------------------------------------------------------------------------- | | 32 | hash | char\[32] | The hash of the referenced transaction. | | 4 | index | uint32\_t | The index of the specific output in the transaction. The first output is 0, etc. | The Script structure consists of a series of pieces of information and operations related to the value of the transaction. (Structure to be expanded in the future… see script.h and script.cpp and Script for more information) The TxOut structure consists of the following fields: | Field Size | Description | Data type | Comments | | ---------- | ----------------- | --------- | --------------------------------------------------------------------- | | 8 | value | int64\_t | Transaction Value | | 1+ | pk\_script length | var\_int | Length of the pk\_script | | ? | pk\_script | uchar\[] | Contains the ScriptPubKey setting up conditions to claim this output. | Example **tx** message: 1. block The **block** message is sent in response to a getdata message which requests transaction information from a block hash. | Field Size | Description | Data type | Comments | | ---------- | ------------ | --------- | --------------------------------------------------------------------------------------------------------- | | 4 | version | int32\_t | Block version information (note, this is signed) | | 32 | prev\_block | char\[32] | The hash value of the previous block this particular block references | | 32 | merkle\_root | char\[32] | The reference to a Merkle tree collection which is a hash of all transactions related to this block | | 4 | timestamp | uint32\_t | A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!) | | 4 | bits | uint32\_t | The calculated difficulty target being used for this block | | 4 | nonce | uint32\_t | The nonce used to generate this block… to allow variations of the header and compute different hashes | | 1+ | txn\_count | var\_int | Number of transaction entries | | ? | txns | tx\[] | Block transactions, in format of "tx" command | The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev\_block, merkle\_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and *not* from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the *nonce* field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration. See Block hashing algorithm for details and an example. 1. headers The *headers* packet returns block headers in response to a *getheaders* packet. Payload: | Field Size | Description | Data type | Comments | | ---------- | ----------- | ---------------- | ----------------------- | | 1+ | count | var\_int | Number of block headers | | 81x? | headers | block\_header\[] | Block headers | Note that the block headers in this packet include a transaction count (a var\_int, so there can be more than 81 bytes per header) as opposed to the block headers that are hashed by miners. 1. getaddr The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours. No additional data is transmitted with this message. 2. mempool The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool. No additional data is transmitted with this message. It is specified in [BIP 35](https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki). Since [BIP 37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki), if a bloom filter is loaded, only transactions matching the filter are replied. 3. checkorder This message was used for IP Transactions. As IP transactions have been deprecated, it is no longer used. 4. submitorder This message was used for IP Transactions. As IP transactions have been deprecated, it is no longer used. 5. reply This message was used for IP Transactions. As IP transactions have been deprecated, it is no longer used. 6. ping The **ping** message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. Payload: | Field Size | Description | Data type | Comments | | ---------- | ----------- | --------- | ------------ | | 8 | nonce | uint64\_t | random nonce | 1. pong The **pong** message is sent in response to a **ping** message. In modern protocol versions, a **pong** response is generated using a nonce included in the ping. Payload: | Field Size | Description | Data type | Comments | | ---------- | ----------- | --------- | --------------- | | 8 | nonce | uint64\_t | nonce from ping | 1. reject The **reject** message is sent when messages are rejected. Payload: | Field Size | Description | Data type | Comments | | ---------- | ----------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1+ | message | var\_str | type of message rejected | | 1 | ccode | char | code relating to rejected message | | 1+ | reason | var\_str | text version of reason for rejection | | 0+ | data | char | Optional extra data provided by some errors. Currently, all errors which provide this field fill it with the TXID or block header hash of the object being rejected, so the field is 32 bytes. | CCodes | Value | Name | Description | | ----- | ----------------------- | ----------- | | 0x01 | REJECT\_MALFORMED | | | 0x10 | REJECT\_INVALID | | | 0x11 | REJECT\_OBSOLETE | | | 0x12 | REJECT\_DUPLICATE | | | 0x40 | REJECT\_NONSTANDARD | | | 0x41 | REJECT\_DUST | | | 0x42 | REJECT\_INSUFFICIENTFEE | | | 0x43 | REJECT\_CHECKPOINT | | 1. filterload, filteradd, filterclear, merkleblock These messages are related to Bloom filtering of connections and are defined in [BIP 0037](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki). The `filterload` command is defined as follows: | Field Size | Description | Data type | Comments | | ---------- | ----------- | ----------- | --------------------------------------------------------------------------------------------------------- | | ? | filter | uint8\_t\[] | The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes. | | 4 | nHashFuncs | uint32\_t | The number of hash functions to use in this filter. The maximum value allowed in this field is 50. | | 4 | nTweak | uint32\_t | A random value to add to the seed value in the hash function used by the bloom filter. | | 1 | nFlags | uint8\_t | A set of flags that control how matched items are added to the filter. | See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate. Upon receiving a `filterload` command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm. The `filteradd` command is defined as follows: | Field Size | Description | Data type | Comments | | ---------- | ----------- | ----------- | ---------------------------------------------- | | ? | data | uint8\_t\[] | The data element to add to the current filter. | The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object). The given data element will be added to the Bloom filter. A filter must have been previously provided using `filterload`. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity). The `filterclear` command has no arguments at all. After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the `merkleblock` message and is defined like this: | Field Size | Description | Data type | Comments | | ---------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------- | | 4 | version | int32\_t | Block version information, based upon the software version creating this block (note, this is signed) | | 32 | prev\_block | char\[32] | The hash value of the previous block this particular block references | | 32 | merkle\_root | char\[32] | The reference to a Merkle tree collection which is a hash of all transactions related to this block | | 4 | timestamp | uint32\_t | A timestamp recording when this block was created (Limited to 2106!) | | 4 | bits | uint32\_t | The calculated difficulty target being used for this block | | 4 | nonce | uint32\_t | The nonce used to generate this block… to allow variations of the header and compute different hashes | | 4 | total\_transactions | uint32\_t | Number of transactions in the block (including unmatched ones) | | 1+ | hash\_count | var\_int | The number of hashes to follow | | 32x? | hashes | char\[32] | Hashes in depth-first order | | 1+ | flag\_bytes | var\_int | The size of flags (in bytes) to follow | | ? | flags | byte\[] | Flag bits, packed per 8 in a byte, least significant bit first. Extra 0 bits are padded on to reach full byte size. | After a `merkleblock`, transactions matching the bloom filter are automatically sent in *tx* messages. A guide to creating a bloom filter, loading a merkle block, and parsing a partial merkle block tree can be found in the [Developer Examples](https://bitcoin.org/en/developer-examples#creating-a-bloom-filter). 1. sendheaders Request for Direct headers announcement. Upon receipt of this message, the node is be permitted, but not required, to announce new blocks by **headers** command (instead of **inv** command). This message is supported by the protocol version >= 70012 or Bitcoin Core version >= 0.12.0. See [BIP 130](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) for more information. No additional data is transmitted with this message. 2. feefilter The payload is always 8 bytes long and it encodes 64 bit integer value (LSB / little endian) of **feerate**. The value represents a minimal fee and is expressed in satoshis per 1000 bytes. Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte. The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters. Inv's generated from a mempool message are also subject to a fee filter if it exists. Feature discovery is enabled by checking protocol version >= 70013 See [BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki) for more information. 3. sendcmpct 4. The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == "sendcmpct". 5. The first integer SHALL be interpreted as a boolean (and MUST have a value of either 1 or 0) 6. The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1. 7. Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message. 8. Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130. 9. Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in 10. cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions. 11. Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages. 12. Nodes MUST NOT send a request for a MSG\_CMPCT\_BLOCK object to a peer before having received a sendcmpct message from that peer. This message is only supported by protocol version >= 70014 See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 13. cmpctblock 14. The cmpctblock message is defined as as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock". 15. Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the short transaction ID for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message. 16. After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message. 17. A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block. 18. A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing UTXO set entries. This message is only supported by protocol version >= 70014 See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 19. getblocktxn 20. The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn". 21. Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate blocktxn message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested. This message is only supported by protocol version >= 70014 See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 22. blocktxn 23. The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn". 24. Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by: 25. Taking the prefilledtxn transactions from the original cmpctblock and placing them in the marked positions. 26. For each short transaction ID from the original cmpctblock, in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block. 27. Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear. This message is only supported by protocol version >= 70014 See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for more information. 28. Scripting See Advanced Bitcoin Scripting. 29. See Also * Network 1. Attribution This content is based on content sourced from under [Creative Commons Attribution 3.0](https://creativecommons.org/licenses/by/3.0/). Although it may have been extensively revised and updated we acknowledge the original authors. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.bsvblockchain.org/wiki/the-network/the-bitcoin-network/peer-to-peer-protocol.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.