Protocol
DISCLAIMER
This article is a direct copy of the original https://en.bitcoin.it/wiki/Protocol_documentation and has not been checked for correctness or edited. 24 September 2019 Expected review by: 15 October 2019
This page describes the Bitcoin Network Protocol used by nodes running the BitcoinSV node client to communicate transaction and block information on the BitcoinSV 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 GetBlockTemplate interface.
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 |
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 |
|---|---|---|
| < 0xFD | 1 | uint8_t |
| <= 0xFFFF | 3 | 0xFD followed by the length as uint16_t |
| <= 0xFFFF FFFF | 5 | 0xFE followed by the length as uint32_t |
| - | 9 | 0xFF followed by the length as uint64_t |
If you're reading the Satoshi client code (BitcoinQT) it refers to this encoding as a "CompactSize". Modern BitcoinQT also has the CVarInt class which implements an even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.
Variable length string
Variable length string can be stored using a variable length integer followed by the string itself.
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 1+ | length | var_int | Length of the string |
| ? | string | char[] | The string itself (can be empty) |
Network address
When a network address is needed somewhere, this structure is used. Network addresses are not prefixed with a timestamp in the version message.
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 4 | time | uint32 | the Time (version >= 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
(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
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0010 00 00 FF FF 0A 00 00 01 20 8D ........ . Network address: 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command) 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1 20 8D - Port 8333
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.
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<ref>https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time</ref>) |
| 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 |
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.
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 for more information.
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 for more information.
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 for more information.
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 for more information.
Short transaction ID
Short transaction IDs are used to represent a transaction without sending a full 256-bit hash. They are calculated by:
- single-SHA256 hashing the block header with the nonce appended (in little-endian)
- 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.
- Dropping the 2 most significant bytes from the SipHash output to make it 6 bytes.
See BIP 152 for more information.
Message types
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 (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 |
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 |
| 4 | NODE_BLOOM | See BIP 0111 |
| 1024 | NODE_NETWORK_LIMITED | See BIP 0159 |
Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...
Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
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".
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version..... 0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b....... 0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................ 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................ 0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh 0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>.. Message Header: F9 BE B4 D9 - Main network magic bytes 76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command 64 00 00 00 - Payload is 100 bytes long 35 8d 49 32 - payload checksum (little endian) Version message: 62 EA 00 00 - 60002 (protocol version 60002) 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services) 11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address 3B 2E B3 5D 8C E6 17 65 - Node ID 0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long) C0 3E 03 00 - Last block sending node has is block #212672
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:
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack...... 0010 00 00 00 00 5D F6 E0 E2 ........ Message header: F9 BE B4 D9 - Main network magic bytes 76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command 00 00 00 00 - Payload is 0 bytes long 5D F6 E0 E2 - Checksum (little endian)
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 |
|---|---|---|---|
| 1+ | count | var_int | Number of address entries (max: 1000) |
| 30x? | addr_list | (uint32_t + net_addr)[] | Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below). |
Note: Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.
Hexdump example of addr message:
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........ 0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M... 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................ 0030 FF 0A 00 00 01 20 8D ..... . Message Header: F9 BE B4 D9 - Main network magic bytes 61 64 64 72 00 00 00 00 00 00 00 00 - "addr" 1F 00 00 00 - payload is 31 bytes long ED 52 39 9B - payload checksum (little endian) Payload: 01 - 1 address in this message Address: E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402) 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message) 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address) 20 8D - port 8333
inv
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to getblocks.
Payload (maximum 50,000 entries, which is just over 1.8 megabytes):
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 1+ | count | var_int | Number of inventory entries |
| 36x? | inventory | inv_vect[] | Inventory vectors |
getdata
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an inv packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).
Payload (maximum 50,000 entries, which is just over 1.8 megabytes):
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 1+ | count | var_int | Number of inventory entries |
| 36x? | inventory | inv_vect[] | Inventory vectors |
notfound
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 1+ | count | var_int | Number of inventory entries |
| 36x? | inventory | inv_vect[] | Inventory vectors |
getblocks
Return an inv packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.
The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the inv message and the remaining locators are ignored, no matter if the requested limit was reached, or not.
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients may provide blocks which are invalid if the block locator object contains a hash on the invalid branch.
Payload:
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 4 | version | uint32_t | the protocol version |
| 1+ | hash count | var_int | number of block locator hash entries |
| 32+ | block locator hashes | char[32] | block locator object; newest back to genesis block (dense to start, but then sparse) |
| 32 | hash_stop | char[32] | hash of the last desired block; set to zero to get as many blocks as possible (500) |
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indexes(size_t top_height)
{
std::vector<size_t> indexes;
// Modify the step in the iteration.
int64_t step = 1;
// Start at the top of the chain and work backwards.
for (auto index = (int64_t)top_height; index > 0; index -= step)
{
// Push top 10 indexes first, then back off exponentially.
if (indexes.size() >= 10)
step *= 2;
indexes.push_back((size_t)index);
}
// Push the genesis block index.
indexes.push_back(0);
return indexes;
}
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.
getheaders
Return a headers packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. Keep in mind that some clients may provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.
Payload:
| Field Size | Description | Data type | Comments |
|---|---|---|---|
| 4 | version | uint32_t | the protocol version |
| 1+ | hash count | var_int | number of block locator hash entries |
| 32+ | block locator hashes | char[32] | block locator object; newest back to genesis block (dense to start, but then sparse) |
| 32 | hash_stop | char[32] | hash of the last desired block header; set to zero to get as many blocks as possible (2000) |
For the block locator object in this packet, the same rules apply as for the getblocks packet.
tx
tx describes a bitcoin transaction, in reply to getdata. When a bloom filter is applied tx objects are sent automatically for matching transactions following the merkleblock.
| 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:
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see NLockTime). |
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:
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx.......... 000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m.. 000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f. 000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)... 000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r... 000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.: 000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y..... 000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN... 000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A.... 000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!... 0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ... 0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q... 0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K..... 0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 [email protected].... 0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........ 0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v.. 000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^... 000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R...... Message header: F9 BE B4 D9 - main network magic bytes 74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command 02 01 00 00 - payload is 258 bytes long E2 93 CD BE - payload checksum (little endian) Transaction: 01 00 00 00 - version Inputs: 01 - number of transaction inputs Input 1: 6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint) 12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 00 8B - script is 139 bytes long 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig) 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF FF - sequence Outputs: 02 - 2 Output Transactions Output 1: 40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000) 19 - pk_script is 25 bytes long 76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script A9 D9 EA 1A FB 22 5E 88 AC Output 2: 80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000) 19 - pk_script is 25 bytes long 76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script FD A0 B7 8B 4E CC 52 88 AC Locktime: 00 00 00 00 - lock time
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.
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.
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.
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. Since BIP 37, if a bloom filter is loaded, only transactions matching the filter are replied.
checkorder
This message was used for IP Transactions. As IP transactions have been deprecated, it is no longer used.
submitorder
This message was used for IP Transactions. As IP transactions have been deprecated, it is no longer used.
reply
This message was used for IP Transactions. As IP transactions have been deprecated, it is no longer used.
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 |
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 |
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 |
filterload, filteradd, filterclear, merkleblock
These messages are related to Bloom filtering of connections and are defined in BIP 0037.
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.
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 for more information.
No additional data is transmitted with this message.
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 for more information.
sendcmpct
- The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == "sendcmpct".
- The first integer SHALL be interpreted as a boolean (and MUST have a value of either 1 or 0)
- The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.
- 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.
- 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.
- 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
- 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.
- Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
- 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 for more information.
cmpctblock
- The cmpctblock message is defined as as a message containing a serialized HeaderAndShortIDs message and pchCommand == "cmpctblock".
- 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.
- 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.
- 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.
- 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 for more information.
getblocktxn
- The getblocktxn message is defined as as a message containing a serialized BlockTransactionsRequest message and pchCommand == "getblocktxn".
- 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 for more information.
blocktxn
- The blocktxn message is defined as as a message containing a serialized BlockTransactions message and pchCommand == "blocktxn".
- Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by:
- Taking the prefilledtxn transactions from the original cmpctblock and placing them in the marked positions.
- 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.
- 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 for more information.
Scripting
See script.