Protocol documentation - Revision history

Fresheneesz: /* Common structures */ add that All field sizes are numbers of bytes.

2021-07-30T18:08:27Z

Common structures: add that All field sizes are numbers of bytes.

← Older revision		Revision as of 18:08, 30 July 2021
Line 93:		Line 93:
	== Common structures ==		== Common structures ==

	Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.		Almost all integers are encoded in little endian. Only IP or port number are encoded big endian. All field sizes are numbers of bytes.

	=== Message structure ===		=== Message structure ===

Sonazuma: message header checksums are internal byte order (https://developer.bitcoin.org/reference/p2p_networking.html#message-headers)

2021-07-30T11:26:25Z

message header checksums are internal byte order (https://developer.bitcoin.org/reference/p2p_networking.html#message-headers)

← Older revision		Revision as of 11:26, 30 July 2021
Line 436:		Line 436:
	76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command		76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
	64 00 00 00 - Payload is 100 bytes long		64 00 00 00 - Payload is 100 bytes long
	35 8d 49 32 - payload checksum (~~little endian~~)		35 8d 49 32 - payload checksum (internal byte order)

	Version message:		Version message:
Line 463:		Line 463:
	76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command		76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
	00 00 00 00 - Payload is 0 bytes long		00 00 00 00 - Payload is 0 bytes long
	5D F6 E0 E2 - Checksum (~~little endian~~)		5D F6 E0 E2 - Checksum (internal byte order)
	</pre>		</pre>

Line 492:		Line 492:
	61 64 64 72 00 00 00 00 00 00 00 00 - "addr"		61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
	1F 00 00 00 - payload is 31 bytes long		1F 00 00 00 - payload is 31 bytes long
	ED 52 39 9B - payload checksum (~~little endian~~)		ED 52 39 9B - payload checksum (internal byte order)

	Payload:		Payload:
Line 719:		Line 719:
	74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command		74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
	02 01 00 00 - payload is 258 bytes long		02 01 00 00 - payload is 258 bytes long
	E2 93 CD BE - payload checksum (~~little endian~~)		E2 93 CD BE - payload checksum (internal byte order)

	Transaction:		Transaction:

934: /* version */ Clarify that the 26 bytes of "addr_from" in the version message can be ignored

2021-07-09T11:32:54Z

version: Clarify that the 26 bytes of "addr_from" in the version message can be ignored

← Older revision		Revision as of 11:32, 9 July 2021
Line 354:		Line 354:
	\|colspan="4"\| Fields below require version ≥ 106		\|colspan="4"\| Fields below require version ≥ 106
	\|-		\|-
	\| 26 \|\| addr_from \|\| [[#Network address\|net_addr]] \|\| ~~The~~ network address of the node emitting this message		\| 26 \|\| addr_from \|\| [[#Network address\|net_addr]] \|\| Field can be ignored. This used to be the network address of the node emitting this message, but most P2P implementations send 26 dummy bytes. The "services" field of the address would also be redundant with the second field of the version 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.		\| 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.

Luke-jr: /* tx */ tx.version is technically unsigned, actually

2021-04-12T19:28:47Z

tx: tx.version is technically unsigned, actually

← Older revision		Revision as of 19:28, 12 April 2021
Line 623:		Line 623:
	! Field Size !! Description !! Data type !! Comments		! Field Size !! Description !! Data type !! Comments
	\|-		\|-
	\| 4 \|\| version \|\| ~~int32_t~~ \|\| Transaction data format version ~~(note, this is signed)~~		\| 4 \|\| version \|\| uint32_t \|\| Transaction data format version
	\|-		\|-
	\| 0 or 2 \|\| flag \|\| optional uint8_t[2] \|\| If present, always 0001, and indicates the presence of witness data		\| 0 or 2 \|\| flag \|\| optional uint8_t[2] \|\| If present, always 0001, and indicates the presence of witness data

Darosior: /* version */ Add missing service flags. XTHIN was never really a thing, but listed for hysterical raisins.

2020-12-14T19:59:23Z

version: Add missing service flags. XTHIN was never really a thing, but listed for hysterical raisins.

← Older revision		Revision as of 19:59, 14 December 2020
Line 381:		Line 381:
	\|-		\|-
	\| 8 \|\| NODE_WITNESS \|\| See [https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP 0144]		\| 8 \|\| NODE_WITNESS \|\| See [https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP 0144]
			\|-
			\| 16 \|\| NODE_XTHIN \|\| Never formally proposed (as a BIP), and discontinued. Was historically sporadically seen on the network.
			\|-
			\| 64 \|\| NODE_COMPACT_FILTERS \|\| See [https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki BIP 0157]
	\|-		\|-
	\| 1024 \|\| NODE_NETWORK_LIMITED \|\| See [https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki BIP 0159]		\| 1024 \|\| NODE_NETWORK_LIMITED \|\| See [https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki BIP 0159]

Stevenroose: Added witness inv types

2020-11-16T00:34:27Z

Added witness inv types

← Older revision		Revision as of 00:34, 16 November 2020
Line 215:		Line 215:
	\| 2 \|\| MSG_BLOCK \|\| Hash is related to a data block		\| 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.		\| 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. See BIP 37 for more info.
	\|-		\|-
	\| 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.		\| 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.
			\|-
			\| 0x40000001 \|\| MSG_WITNESS_TX \|\| Hash of a transaction with witness data. See BIP 144 for more info.
			\|-
			\| 0x40000002 \|\| MSG_WITNESS_BLOCK \|\| Hash of a block with witness data. See BIP 144 for more info.
			\|-
			\| 0x40000003 \|\| MSG_FILTERED_WITNESS_BLOCK \|\| Hash of a block with witness data. 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. See BIP 144 for more info.
	\|}		\|}

Benthecarman: Add signet to magic network bytes, clarify for regtest magic network bytes

2020-09-25T01:04:17Z

Add signet to magic network bytes, clarify for regtest magic network bytes

← Older revision		Revision as of 01:04, 25 September 2020
Line 119:		Line 119:
	\| main \|\| 0xD9B4BEF9 \|\| F9 BE B4 D9		\| main \|\| 0xD9B4BEF9 \|\| F9 BE B4 D9
	\|-		\|-
	\| testnet \|\| 0xDAB5BFFA \|\| FA BF B5 DA		\| testnet/regtest \|\| 0xDAB5BFFA \|\| FA BF B5 DA
	\|-		\|-
	\| testnet3 \|\| 0x0709110B \|\| 0B 11 09 07		\| testnet3 \|\| 0x0709110B \|\| 0B 11 09 07
			\|-
			\| signet(default) \|\| 0x40CF030A \|\| 0A 03 CF 40
	\|-		\|-
	\| namecoin \|\| 0xFEB4BEF9 \|\| F9 BE B4 FE		\| namecoin \|\| 0xFEB4BEF9 \|\| F9 BE B4 FE

934: /* Variable length integer */ Replace CVarInt with VARINT. CVarInt has been removed in commit 2f1b2f4ed044fe005e5a6c1b55e95822e83c16df, but VARINT exists since the new varint was introduced

2020-08-22T15:43:49Z

Variable length integer: Replace CVarInt with VARINT. CVarInt has been removed in commit 2f1b2f4ed044fe005e5a6c1b55e95822e83c16df, but VARINT exists since the new varint was introduced

← Older revision		Revision as of 15:43, 22 August 2020
Line 144:		Line 144:
	\|}		\|}

	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.		If you're reading the Satoshi client code (BitcoinQT) it refers to this encoding as a "CompactSize". Modern Bitcoin Core also has the VARINT macro which implements an even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). VARINT is not a part of the protocol.

	=== Variable length string ===		=== Variable length string ===

Furunodo at 12:49, 27 June 2020

2020-06-27T12:49:56Z

← Older revision		Revision as of 12:49, 27 June 2020
Line 1,083:		Line 1,083:
	# 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.		# 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 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.		# 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		This message is only supported by protocol version >= 70014

Ddustin at 15:12, 26 December 2018

2018-12-26T15:12:07Z

← Older revision		Revision as of 15:12, 26 December 2018
Line 153:		Line 153:
	! Field Size !! Description !! Data type !! Comments		! Field Size !! Description !! Data type !! Comments
	\|-		\|-
	\| ? \|\| length \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Length of the string		\| 1+ \|\| length \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Length of the string
	\|-		\|-
	\| ? \|\| string \|\| char[] \|\| The string itself (can be empty)		\| ? \|\| string \|\| char[] \|\| The string itself (can be empty)
Line 501:		Line 501:
	! Field Size !! Description !! Data type !! Comments		! Field Size !! Description !! Data type !! Comments
	\|-		\|-
	\| ? \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of inventory entries		\| 1+ \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of inventory entries
	\|-		\|-
	\| 36x? \|\| inventory \|\| [[Protocol specification#Inventory Vectors\|inv_vect]][] \|\| Inventory vectors		\| 36x? \|\| inventory \|\| [[Protocol specification#Inventory Vectors\|inv_vect]][] \|\| Inventory vectors
Line 515:		Line 515:
	! Field Size !! Description !! Data type !! Comments		! Field Size !! Description !! Data type !! Comments
	\|-		\|-
	\| ? \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of inventory entries		\| 1+ \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of inventory entries
	\|-		\|-
	\| 36x? \|\| inventory \|\| [[Protocol specification#Inventory Vectors\|inv_vect]][] \|\| Inventory vectors		\| 36x? \|\| inventory \|\| [[Protocol specification#Inventory Vectors\|inv_vect]][] \|\| Inventory vectors
Line 527:		Line 527:
	! Field Size !! Description !! Data type !! Comments		! Field Size !! Description !! Data type !! Comments
	\|-		\|-
	\| ? \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of inventory entries		\| 1+ \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of inventory entries
	\|-		\|-
	\| 36x? \|\| inventory \|\| [[Protocol specification#Inventory Vectors\|inv_vect]][] \|\| Inventory vectors		\| 36x? \|\| inventory \|\| [[Protocol specification#Inventory Vectors\|inv_vect]][] \|\| Inventory vectors
Line 774:		Line 774:
	\| 4 \|\| nonce \|\| uint32_t \|\| The nonce used to generate this block… to allow variations of the header and compute different hashes		\| 4 \|\| nonce \|\| uint32_t \|\| The nonce used to generate this block… to allow variations of the header and compute different hashes
	\|-		\|-
	\| ? \|\| txn_count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of transaction entries		\| 1+ \|\| txn_count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of transaction entries
	\|-		\|-
	\| ? \|\| txns \|\| tx[] \|\| Block transactions, in format of "tx" command		\| ? \|\| txns \|\| tx[] \|\| Block transactions, in format of "tx" command
Line 791:		Line 791:
	! Field Size !! Description !! Data type !! Comments		! Field Size !! Description !! Data type !! Comments
	\|-		\|-
	\| ? \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of block headers		\| 1+ \|\| count \|\| [[Protocol_documentation#Variable_length_integer\|var_int]] \|\| Number of block headers
	\|-		\|-
	\| 81x? \|\| headers \|\| [[Protocol_documentation#Block_Headers\|block_header]][] \|\| [[Protocol_documentation#Block_Headers\|Block headers]]		\| 81x? \|\| headers \|\| [[Protocol_documentation#Block_Headers\|block_header]][] \|\| [[Protocol_documentation#Block_Headers\|Block headers]]