Bitcoin Wiki - User contributions [en]

Peer-To-Peer Protocol

2023-01-09T16:41:34Z

Connor Murray:

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 [[Getminingcandidate]].

There have been a number of P2P protocol changes made since 2020. These changes are published on the [https://github.com/bitcoin-sv-specs/protocol/tree/master/p2p Bitcoin SV Node Github repository]

=== Message structure ===

{|class="wikitable"
! 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:

{|class="wikitable"
! 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.

{|class="wikitable"
! 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.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || length || [[Peer-To-Peer_Protocol#Variable_length_integer|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.

{|class="wikitable"
! 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|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 [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses 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

<pre>
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
</pre>

=== 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:

{|class="wikitable"
! 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:

{|class="wikitable"
! 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.

{|class="wikitable"
! 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 || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

cf. [[Block hashing algorithm]]

=== 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.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| index || [[Protocol#Variable_length_integer|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 [[Protocol#tx|tx messages]] || The transaction which is in the block at index index.
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki 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.

{|class="wikitable"
! 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 || [[Protocol#Variable_length_integer|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 [[Protocol#Short_transaction_ID|short transaction IDs]] calculated from the transactions which were not provided explicitly in prefilledtxn
|-
| prefilledtxn_length || [[Protocol#Variable_length_integer|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 [[Protocol#PrefilledTransaction|PrefilledTransaction]] definition, above || Used to provide the coinbase transaction and a select few which we expect a peer may be missing
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactionsRequest ===

A BlockTransactionsRequest structure is used to list transaction indexes in a block being requested.

{|class="wikitable"
! 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 || [[Protocol#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of transactions being requested
|-
| indexes || List of [[Protocol#Variable_length_integer|CompactSizes]] || 1 or 3 bytes*indexes_length || [[Protocol#Differential_encoding|Differentially encoded]] || The indexes of the transactions being requested in the block
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactions ===

A BlockTransactions structure is used to provide some of the transactions in a block, as requested.

{|class="wikitable"
! 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 || [[Protocol#Variable_length_integer|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 [[Protocol#tx|tx messages]] || The transactions provided
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! 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 || [[#Network address|net_addr]] || The network address of the node receiving this message
|-
|colspan="4"| Fields below require version ≥ 106
|-
| 26 || addr_from || [[#Network address|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 || [[#Variable length string|var_str]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki User Agent] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
|colspan="4"| Fields below require version ≥ 70001
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037]
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|-
| 2 || NODE_GETUTXO || See [https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki BIP 0064]
|-
| 4 || NODE_BLOOM || See [https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki BIP 0111]
|-
| 1024 || NODE_NETWORK_LIMITED || See [https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki BIP 0159]
|}

Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):
<pre>
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
</pre>

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".

<pre>

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
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''[[#version|version]]''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
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)
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + [[#Network address|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:
<pre>
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
</pre>

=== 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):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol#Inventory Vectors|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):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol#Inventory Vectors|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.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol#Inventory Vectors|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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Peer-To-Peer_Protocol#Variable_length_integer|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:

<pre>
// 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;
}
</pre>

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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Peer-To-Peer_Protocol#Variable_length_integer|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 [[Protocol#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''[[#getdata|getdata]]''. When a bloom filter is applied ''tx'' objects are sent automatically for matching transactions following the <code>merkleblock</code>.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Transaction data format version (note, this is signed)
|-
| 1+ || tx_in count || [[Peer-To-Peer_Protocol#Variable_length_integer|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 || [[Peer-To-Peer_Protocol#Variable_length_integer|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:
{|class="wikitable"
! Value !! Description
|-
| 0 || Not locked
|-
| < 500000000 || Block number at which this transaction is unlocked
|-
| >= 500000000 || UNIX 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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 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:

{|class="wikitable"
! 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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Contains the ScriptPubKey setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
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 ..@KL......v....
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
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! 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|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 || [[Peer-To-Peer_Protocol#Variable_length_integer|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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol#Block_Headers|block_header]][] || [[Protocol#Block_Headers|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 [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], if a [[Protocol#filterload.2C_filteradd.2C_filterclear.2C_merkleblock|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:

{|class="wikitable"
! 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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! 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

{|class="wikitable"
! 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 [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! 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 <code>filterload</code> 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 <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! 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 <code>filterload</code>. 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 <code>filterclear</code> 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 <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! 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 || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || The number of hashes to follow
|-
| 32x? || hashes || char[32] || Hashes in depth-first order
|-
| 1+ || flag_bytes || [[Peer-To-Peer_Protocol#Variable_length_integer|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 <code>merkleblock</code>, transactions matching the bloom filter are automatically sent in ''[[#tx|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 [https://bitcoin.org/en/developer-examples#creating-a-bloom-filter 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 [https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== cmpctblock ===

# The cmpctblock message is defined as as a message containing a serialized [[Protocol#HeaderAndShortIDs|HeaderAndShortIDs]] message and pchCommand == "cmpctblock".
# Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the [[Protocol#Short_transaction_ID|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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== getblocktxn ===

# The getblocktxn message is defined as as a message containing a serialized [[Protocol#BlockTransactionsRequest|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 [[Protocol#blocktxn|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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== blocktxn ===

# The blocktxn message is defined as as a message containing a serialized [[Protocol#BlockTransactions|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 [[Protocol#cmpctblock|cmpctblock]] and placing them in the marked positions.
# For each short transaction ID from the original [[Protocol#cmpctblock|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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Scripting ==

See [[Advanced Bitcoin Scripting]].

==See Also==

* [[Network]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Protocol_documentation under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated we acknowledge the original authors.

Peer-To-Peer Protocol

2023-01-09T16:38:27Z

Connor Murray:

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 [[Getminingcandidate]].

=== Message structure ===

{|class="wikitable"
! 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:

{|class="wikitable"
! 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.

{|class="wikitable"
! 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.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || length || [[Peer-To-Peer_Protocol#Variable_length_integer|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.

{|class="wikitable"
! 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|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 [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses 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

<pre>
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
</pre>

=== 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:

{|class="wikitable"
! 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:

{|class="wikitable"
! 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.

{|class="wikitable"
! 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 || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

cf. [[Block hashing algorithm]]

=== 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.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| index || [[Protocol#Variable_length_integer|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 [[Protocol#tx|tx messages]] || The transaction which is in the block at index index.
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki 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.

{|class="wikitable"
! 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 || [[Protocol#Variable_length_integer|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 [[Protocol#Short_transaction_ID|short transaction IDs]] calculated from the transactions which were not provided explicitly in prefilledtxn
|-
| prefilledtxn_length || [[Protocol#Variable_length_integer|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 [[Protocol#PrefilledTransaction|PrefilledTransaction]] definition, above || Used to provide the coinbase transaction and a select few which we expect a peer may be missing
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactionsRequest ===

A BlockTransactionsRequest structure is used to list transaction indexes in a block being requested.

{|class="wikitable"
! 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 || [[Protocol#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of transactions being requested
|-
| indexes || List of [[Protocol#Variable_length_integer|CompactSizes]] || 1 or 3 bytes*indexes_length || [[Protocol#Differential_encoding|Differentially encoded]] || The indexes of the transactions being requested in the block
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactions ===

A BlockTransactions structure is used to provide some of the transactions in a block, as requested.

{|class="wikitable"
! 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 || [[Protocol#Variable_length_integer|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 [[Protocol#tx|tx messages]] || The transactions provided
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! 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 || [[#Network address|net_addr]] || The network address of the node receiving this message
|-
|colspan="4"| Fields below require version ≥ 106
|-
| 26 || addr_from || [[#Network address|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 || [[#Variable length string|var_str]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki User Agent] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
|colspan="4"| Fields below require version ≥ 70001
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037]
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|-
| 2 || NODE_GETUTXO || See [https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki BIP 0064]
|-
| 4 || NODE_BLOOM || See [https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki BIP 0111]
|-
| 1024 || NODE_NETWORK_LIMITED || See [https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki BIP 0159]
|}

Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):
<pre>
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
</pre>

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".

<pre>

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
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''[[#version|version]]''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
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)
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + [[#Network address|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:
<pre>
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
</pre>

=== 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):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol#Inventory Vectors|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):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol#Inventory Vectors|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.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol#Inventory Vectors|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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Peer-To-Peer_Protocol#Variable_length_integer|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:

<pre>
// 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;
}
</pre>

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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Peer-To-Peer_Protocol#Variable_length_integer|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 [[Protocol#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''[[#getdata|getdata]]''. When a bloom filter is applied ''tx'' objects are sent automatically for matching transactions following the <code>merkleblock</code>.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Transaction data format version (note, this is signed)
|-
| 1+ || tx_in count || [[Peer-To-Peer_Protocol#Variable_length_integer|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 || [[Peer-To-Peer_Protocol#Variable_length_integer|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:
{|class="wikitable"
! Value !! Description
|-
| 0 || Not locked
|-
| < 500000000 || Block number at which this transaction is unlocked
|-
| >= 500000000 || UNIX 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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 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:

{|class="wikitable"
! 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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Contains the ScriptPubKey setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
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 ..@KL......v....
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
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! 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|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 || [[Peer-To-Peer_Protocol#Variable_length_integer|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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol#Block_Headers|block_header]][] || [[Protocol#Block_Headers|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 [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], if a [[Protocol#filterload.2C_filteradd.2C_filterclear.2C_merkleblock|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:

{|class="wikitable"
! 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:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! 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

{|class="wikitable"
! 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 [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! 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 <code>filterload</code> 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 <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! 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 <code>filterload</code>. 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 <code>filterclear</code> 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 <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! 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 || [[Peer-To-Peer_Protocol#Variable_length_integer|var_int]] || The number of hashes to follow
|-
| 32x? || hashes || char[32] || Hashes in depth-first order
|-
| 1+ || flag_bytes || [[Peer-To-Peer_Protocol#Variable_length_integer|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 <code>merkleblock</code>, transactions matching the bloom filter are automatically sent in ''[[#tx|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 [https://bitcoin.org/en/developer-examples#creating-a-bloom-filter 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 [https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki 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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== cmpctblock ===

# The cmpctblock message is defined as as a message containing a serialized [[Protocol#HeaderAndShortIDs|HeaderAndShortIDs]] message and pchCommand == "cmpctblock".
# Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the [[Protocol#Short_transaction_ID|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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== getblocktxn ===

# The getblocktxn message is defined as as a message containing a serialized [[Protocol#BlockTransactionsRequest|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 [[Protocol#blocktxn|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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== blocktxn ===

# The blocktxn message is defined as as a message containing a serialized [[Protocol#BlockTransactions|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 [[Protocol#cmpctblock|cmpctblock]] and placing them in the marked positions.
# For each short transaction ID from the original [[Protocol#cmpctblock|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 [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Scripting ==

See [[Advanced Bitcoin Scripting]].

==See Also==

* [[Network]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Protocol_documentation under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated we acknowledge the original authors.

Protocol

2022-12-19T15:20:48Z

Connor Murray: /* Immutable Rules */

==Bitcoin Protocol Rules==
The rules of the Bitcoin protocol are the rules that precisely define the Bitcoin system.

There are different classes of rule in the Bitcoin system including:
*[[Immutable]] rules
*Mutable rules
**Local Policies
**Standard Policies
*Communication rules

== Immutable Rules ==
The [[immutable]] rules are codified into Bitcoin node clients and must be strictly adhered to, in order to implement the Bitcoin specification in software [1]. They are a set of rules that define the format and constraints that transactions and blocks must follow.

These include:

*The sum of the value of the inputs of a transaction must be greater than or equal to the sum of the values of the outputs.
*The [[Block subsidy|block subsidy]] will drop by half at a scheduled rate of every 210,000 blocks, starting with a subsidy of 5,000,000,000 [[satoshis]] per block from the genesis block.
*The network will adjust the [[target]] for the [[difficulty]] of the [[Proof of Work]] needed for a valid block to maintain an approximate 10 minute block discovery rate.
*Only blocks that add to the [[blockchain]] formed by building upon the [[Genesis block]] are valid.
*The structure of the Bitcoin database as a timestamp server validating chains of transaction outputs.
*Transaction data formatting, including sizes of certain fields and their encoding schema.
*Block structure and header information including sizes of certain fields and their encoding schema.
* The [[Advanced Bitcoin Scripting|Bitcoin scripting language]] and its specification including:
**Lists of opcodes that are usable in script and the exact outcome of their execution

Forced changes to these protocol rules in the past have resulted in duplications of the Bitcoin database. In doing so, creating BTC which implemented 'Segregated Witness', removing the requirement for Bitcoin to be a chain of digital signatures. BCH enforced a transaction ordering schema onto the timestamping function of the system, and modified the scripting language to add op codes, with functionality outside the scope of the original design.

The Bitcoin SV philosophy is, where aspects of these rules have been changed in the past, they should be returned to be as close to the original rules as possible and then “set in stone”. Only changes needed to protect the security of the network such as, the migration to a new hash function should SHA256 be broken, will be allowed, with this rule being enforced through [[Nakamoto Consensus]].

== Mutable Rules ==
Mutable rules are consensus rules that mining clients implement but which are not hard coded into the BitcoinSV node client. Miners can change these at any time provided there is enough agreement among Miners to do so under [[Nakamoto Consensus]]. Miners who do not maintain these settings in-line with the rest of the network, risk having their blocks invalidated.
Examples of these include:
*The maximum script memory usage rule which governs how much memory a transaction can consume during the execution of its script.
*The maximum block-size rule.
*Transaction script rules such as the rule preventing the use of opcodes other than pushdata in ScriptSig.
It is important to note that these rules can be violated in special cases by Miners, through a negotiation process that ends with a transaction or block that violates these rules being accepted and built upon. This can only be achieved through Nakamoto consensus. No examples of this happening have yet been encountered.

When modifying these rules, Miners tend to act as a collective, changing a particular rule all at once (e.g. maximum transaction memory limits and maximum block size). Since the [[Genesis upgrade]], these changes no longer require hard forks or scheduled network upgrades, and the settings that govern these changes available to Miners through node client configuration tools. All that is required is a loose agreement between Miners to change the settings across the network at a particular date and time.

This means that Miners must be aware of the actions being taken by the rest of the network, lest they find themselves rejecting transactions or blocks that a majority of the network is accepting and become stuck on a non-productive chain-tip while the remainder of the network move forward.

===Local rules===
These rules are “local” by definition. They apply to the instance of software that is running, they do not apply to the validation of blocks, or the transactions within a block. A block accepted from another Miner may contain transactions that do not conform to local rules.
Local rules include:
*The “minimum fee” rule, which specifies that the node will only accept and/or relay unconfirmed transactions that pay above a certain fee.
*Dust rules which specify the smallest value output a transaction can contain that the node will accept and/or relay.
*Rules relating to inbound and outbound connections on the network, such as RPC responses, specific IP addresses to connect to, and more.

===Standard Policies===
Standard policies are local rules that are used by a significant proportion of network nodes. They are defined as a "Standard" to facilitate common application across independent software implementations, but it is important to note that, it is not required that software implement or adhere to these policies.

Bitcoin users who transact within the guidelines of standard policy will face the least issues with their transactions on the network. Some Miners can enact local rules outside of the standard policies however this can cause issues for the Miner, who may be attempting to mine blocks that carry large numbers of transactions which other Miners have rejected. This can lead to [[Orphan Block|orphan blocks]] due to slow propagation.

==Communication Rules==
The communication rules govern how transaction and block data is propagated across the Bitcoin network. Commonly referred to as the Bitcoin [[Peer-To-Peer Protocol|Peer-To-Peer (P2P) Protocol]], this current version is well defined method and used by the majority of Bitcoin nodes in the network to communicate. The P2P Protocol can be changed and there are plans among Miners to modify the implementation in future. It is conceivable that at a certain point, several different inter-node communication protocols may be in-use to propagate block and transaction information between Miners, and optimising this aspect of the network is strongly incentivised by the economics of Bitcoin mining. A large amount of the innovation that scales Bitcoin SV has been and will, in future, be done by improving the P2P protocol.

==See Also==
* [[The Bitcoin Network]]
* [[Nakamoto Consensus]]
* [[P2P Network]]

==References==
[1] - https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md

Metanet Protocol

2022-07-27T12:39:47Z

Connor Murray:

[[File:Metanet_graph.png|thumb|A typical Metanet graph.]]

The '''Metanet Protocol''' is a layer-2 overlay protocol that defines a method for creating data structure over Bitcoin SV. The protocol utilises [[Metanet_Protocol#Node and Edge Structure|nodes and edges]] to specify directed acyclic graph (DAG) data structures on the Bitcoin SV ledger. The Metanet protocol can be used to construct diverse systems such as file systems, internet domains, ownership structures and code repositories.

There are tools available to write and read Metanet graphs, and a growing range of projects that use the Metanet protocol to structure their application data.

==Node and Edge Structure==

The Metanet Protocol (MNP) is a protocol for creating graph structures comprising nodes and edges on the ledger. In the Metanet protocol the following definitions of node and edge are used:

* '''Metanet Node''' - A transaction using the Metanet protocol format.
* '''Metanet Edge''' - An input signature linking two Metanet nodes.

A Metanet node is a transaction that conforms to the Metanet transaction format specified in [https://www.bitcoinsv.io/files/metanet.pdf Metanet technical summary] document produced by nChain. The basic components of a Metanet transaction include a protocol flag, Metanet-specific data attributes, and any content data that is to be stored by a Metanet node transaction.

The protocol flag is a 4-byte [[hexadecimal]] prefix that signifies that a transaction is using the format of the Metanet protocol. The hexadecimal value of the prefix was chosen to be the hexademical encoding 0x4d455441 of the string 'meta' by [https://twitter.com/BitcoinAssn/status/1136232235798016001?s=20 public poll] on June 5th 2019.

The Metanet-specific data attributes of a Metanet node transaction include the following:

* '''<math>P_{node}</math>''' - the public key defining the node.
* '''<math>TxID_{node}</math>''' - the unique transaction ID of the node.
* '''<math>P_{parent}</math>''' - the public key defining a parent of the node.
* '''<math>SigP_{parent}</math>''' - a signature created using the private key associated with the public key defining a parent of the node.
* '''<math>TxID_{parent}</math>''' - the unique transaction ID of the parent of the node.

The Metanet-specific data attributes listed above are used collectively to define a Metanet node and its position within a larger graph structure of multiple Metanet nodes, known as a ''Metanet graph''.

It is possible that a node does not have any parents and such a node is termed a ''root node''. A root node will have null values for any <math>P_{parent}</math>, <math>SigP_{parent}</math>, and <math>TxID_{parent}</math> attributes, and can therefore use a valid signature from any public key in its input(s).

A Metanet transaction is defined as a transaction that contains an OP_FALSE OP_RETURN payload containing:

* The Metanet flag
[[File:Metanet_node.png|thumb|A Metanet node transaction.]]
* A node public key '''<math>P_{node}</math>'''
* A parent transaction ID '''<math>TxID_{parent}</math>''' (null if a root node).

In order to qualify as a Metanet-valid node, the transaction must also be signed by the public key corresponding to its parent '''<math>P_{parent}</math>'''.

Any content data and its encoding can be included following these core Metanet attributes in the OP_FALSE OP_RETURN payload. The Metanet protocol does not specify the use of any one scheme for content data and additional attributes, and any valued usage of the Metanet protocol attributes above constitute a Metanet node transaction.

A basic example of a Metanet node transaction that conforms to this format is shown in the diagram on the right.

The Metanet graph is formed by creating edges between parent Metanet nodes and child Metanet nodes. An edge is created between a parent and child by the creation and insertion of the signature '''<math>SigP_{parent}</math>''' in the child node, using the parent public key. [[File:Metanet_edge.png|thumb|The creation of a Metanet edge.]]

The fact that this signature is in a transaction input means that the signature itself may be validated by Miners. This means that attempts to spoof a Metanet node can be mitigated either by validating the signature explicitly or by confirming that the node is spending an appropriate previous output.

== Rules of the Metanet Protocol==

The Metanet protocol specifies a simple and extensible rule set for creating Metanet graphs and data structures. The base rule set is the following:

* Nodes are transactions.
* Edges are created by signatures.
* Each node is uniquely identified by the pair of attributes: '''<math>P_{node}</math>''', '''<math>TxID_{node}</math>'''.
* Each node must specify the node ID of itself and its parent: '''<math>ID_{node}</math>''', '''<math>ID_{parent}</math>'''.

The unique node identifier for a node is defined mathematically as '''<math>H(P_{node}||TxID_{node})</math>''', where '''<math>H()</math>''' is a cryptographic hash function.

Metanet graph structures may be created using this base rule set alone. It is also possible to impose additional rules to Metanet graph structures to achieve different properties for data structures.

A simple extension of the rule set is to impose the following [[constraint]]s:
[[File:Metanet_rules.png|thumb|A simple Metanet rule set.]]

* The [[in-degree]] of a node should be 0 (no parent) or 1 (one parent).
* The [[out-degree]] of a node should be a free parameter.

These additional rules allow domain-like structures to emerge as Metanet DAGs, which can be used to structure websites and file systems which inherit the permission structure of a Metanet graph.

Metanet Protocol

2022-07-27T12:39:30Z

Connor Murray:

[[File:Metanet_graph.png|thumb|A typical Metanet graph.]]

The '''Metanet Protocol''' is a layer-2 overlay protocol that defines a method for creating data structure over Bitcoin SV. The protocol utilises [[Metanet_Protocol#Node and Edge Structure|nodes and edges]] to specify directed acyclic graph (DAG) data structures on the Bitcoin SV ledger. The Metanet protocol can be used to construct diverse systems such as file systems, internet domains, ownership structures and code repositories.

There are tools available to write and read Metanet graphs, and a growing range of projects that use the Metanet protocol to structure their application data.

==Node and Edge Structure==

The Metanet Protocol (MNP) is a protocol for creating graph structures comprising nodes and edges on the ledger. In the Metanet protocol the following definitions of node and edge are used:

* '''Metanet Node''' - A transaction using the Metanet protocol format.
* '''Metanet Edge''' - An input signature linking two Metanet nodes.

A Metanet node is a transaction that conforms to the Metanet transaction format specified in [https://www.bitcoinsv.io/files/metanet.pdff Metanet technical summary] document produced by nChain. The basic components of a Metanet transaction include a protocol flag, Metanet-specific data attributes, and any content data that is to be stored by a Metanet node transaction.

The protocol flag is a 4-byte [[hexadecimal]] prefix that signifies that a transaction is using the format of the Metanet protocol. The hexadecimal value of the prefix was chosen to be the hexademical encoding 0x4d455441 of the string 'meta' by [https://twitter.com/BitcoinAssn/status/1136232235798016001?s=20 public poll] on June 5th 2019.

The Metanet-specific data attributes of a Metanet node transaction include the following:

* '''<math>P_{node}</math>''' - the public key defining the node.
* '''<math>TxID_{node}</math>''' - the unique transaction ID of the node.
* '''<math>P_{parent}</math>''' - the public key defining a parent of the node.
* '''<math>SigP_{parent}</math>''' - a signature created using the private key associated with the public key defining a parent of the node.
* '''<math>TxID_{parent}</math>''' - the unique transaction ID of the parent of the node.

The Metanet-specific data attributes listed above are used collectively to define a Metanet node and its position within a larger graph structure of multiple Metanet nodes, known as a ''Metanet graph''.

It is possible that a node does not have any parents and such a node is termed a ''root node''. A root node will have null values for any <math>P_{parent}</math>, <math>SigP_{parent}</math>, and <math>TxID_{parent}</math> attributes, and can therefore use a valid signature from any public key in its input(s).

A Metanet transaction is defined as a transaction that contains an OP_FALSE OP_RETURN payload containing:

* The Metanet flag
[[File:Metanet_node.png|thumb|A Metanet node transaction.]]
* A node public key '''<math>P_{node}</math>'''
* A parent transaction ID '''<math>TxID_{parent}</math>''' (null if a root node).

In order to qualify as a Metanet-valid node, the transaction must also be signed by the public key corresponding to its parent '''<math>P_{parent}</math>'''.

Any content data and its encoding can be included following these core Metanet attributes in the OP_FALSE OP_RETURN payload. The Metanet protocol does not specify the use of any one scheme for content data and additional attributes, and any valued usage of the Metanet protocol attributes above constitute a Metanet node transaction.

A basic example of a Metanet node transaction that conforms to this format is shown in the diagram on the right.

The Metanet graph is formed by creating edges between parent Metanet nodes and child Metanet nodes. An edge is created between a parent and child by the creation and insertion of the signature '''<math>SigP_{parent}</math>''' in the child node, using the parent public key. [[File:Metanet_edge.png|thumb|The creation of a Metanet edge.]]

The fact that this signature is in a transaction input means that the signature itself may be validated by Miners. This means that attempts to spoof a Metanet node can be mitigated either by validating the signature explicitly or by confirming that the node is spending an appropriate previous output.

== Rules of the Metanet Protocol==

The Metanet protocol specifies a simple and extensible rule set for creating Metanet graphs and data structures. The base rule set is the following:

* Nodes are transactions.
* Edges are created by signatures.
* Each node is uniquely identified by the pair of attributes: '''<math>P_{node}</math>''', '''<math>TxID_{node}</math>'''.
* Each node must specify the node ID of itself and its parent: '''<math>ID_{node}</math>''', '''<math>ID_{parent}</math>'''.

The unique node identifier for a node is defined mathematically as '''<math>H(P_{node}||TxID_{node})</math>''', where '''<math>H()</math>''' is a cryptographic hash function.

Metanet graph structures may be created using this base rule set alone. It is also possible to impose additional rules to Metanet graph structures to achieve different properties for data structures.

A simple extension of the rule set is to impose the following [[constraint]]s:
[[File:Metanet_rules.png|thumb|A simple Metanet rule set.]]

* The [[in-degree]] of a node should be 0 (no parent) or 1 (one parent).
* The [[out-degree]] of a node should be a free parameter.

These additional rules allow domain-like structures to emerge as Metanet DAGs, which can be used to structure websites and file systems which inherit the permission structure of a Metanet graph.

Pruning

2022-04-27T19:30:06Z

Connor Murray: Created page with "Pruning is a data compression technique for Merkle trees that reduces the size of the trees by removing sections of the tree that are non-critical and redundant."

Pruning is a data compression technique for Merkle trees that reduces the size of the trees by removing sections of the tree that are non-critical and redundant.

Provenance

2022-04-27T19:29:35Z

Connor Murray: Created page with "Provenance is the chronology of the ownership, custody or location of a particular object."

Provenance is the chronology of the ownership, custody or location of a particular object.

Pre-image

2022-04-27T19:28:29Z

Connor Murray: Created page with "The pre-image of a hash function is the set of all values that produce a specific hash when passed as an input into a hashing function."

The pre-image of a hash function is the set of all values that produce a specific hash when passed as an input into a hashing function.

Predicate

2022-04-27T19:28:04Z

Connor Murray: Created page with "A predicate is a logical function that upon evaluation by a computer resolves to either a 'true' or 'false' as the output of the function."

A predicate is a logical function that upon evaluation by a computer resolves to either a 'true' or 'false' as the output of the function.

Poisson Distribution

2022-04-27T19:27:35Z

Connor Murray: Created page with "A discrete probability function that means the variable can only take specific values in a given list of numbers, probably infinite."

A discrete probability function that means the variable can only take specific values in a given list of numbers, probably infinite.

Public key infrastructure

2022-04-27T19:26:59Z

Connor Murray: Created page with "A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificat..."

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.

Payment host

2022-04-27T19:25:22Z

Connor Murray: Created page with "The provider of the Point Of Sale device and network in order for a merchant to be able to receive particular payment types."

The provider of the Point Of Sale device and network in order for a merchant to be able to receive particular payment types.

Payments in Bitcoin

2022-04-27T19:25:08Z

Connor Murray:

The term ''payments'' in a Bitcoin context generally refers the process of a purchaser paying for a good or service from a vendor. Payments are an important aspect of Bitcoin and it is crucial that comprehensive standards exist that enable parties and software systems to process payments in ways that cover a wide variety of use cases.

There are several standards defined for Bitcoin SV that cover methods of requesting and performing payments.

==BIP270==
[https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a streamlined version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70 Payment Protocol] introduced in 2013. It is a protocol for communication between a [[payment host]] (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables:
* Improved user experience
* Simpler wallet infrastructure
* Multiple outputs
* Improved security against man-in-the-middle attacks

BIP270 is designed for wallets that use [[Simplified Payment Verification]] to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer directly between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).

This BIP is an optimisation of BIP70. Changes include:
* Moves all signature exchange and validation to the communication later (usually HTTPS)
* Add multiple outputs
* A library optimised for peer to peer transaction management

==BSVAlias==
[[BSVAlias]] is a set of standards for using email type identities with Bitcoin SV, with making and receiving payments as one of its first use-cases.

[[Paymail]] is the first practical implementation of BSVAlias.

==Payment Channels==
[[Payment Channels]] are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes: methods for establishing, or opening, updating, and finalising or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time.

Payment channels support extremely rapid transaction updates with only the final closing transaction being confirmed in the blockchain.

Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more.

==Legacy Payment Protocols==
Many of the legacy payment protocols used a mechanism where the payer is asked to broadcast a transaction to the network, and the payee would scan the network for relevant transactions rather than handling the transaction directly peer-to-peer as with [[Simplified_Payment_Verification|SPV]]. This mechanism does not scale when transaction volume increases and is inefficient.

===IP to IP payments===
The original version of the Bitcoin node client had the facility to conduct IP to IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the payee's client and request a public key for the payment to be addressed to.
This payment method had valid security concerns, but rather than addressing these concerns, the mechanism was removed.
New payment processes are in development which draw from this original idea and will allow network peers to interact securely using cryptographically verified IP addresses.

===BIP21===
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP21] has been one of the predominant means of making mobile payments in Bitcoin throughout its history. Almost all QR code based payment gateways used within Bitcoin are, or are an extension of, BIP21. BIP21 itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers).

===BIP70===
[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] was a payment protocol for reaching out to receivers using an extension of BIP21 that added a URL. The URL directed the device to reach out to a server which would provide it with a script, or an address linked to the QR code.

Out-degree

2022-04-27T19:00:34Z

Connor Murray: Created page with "The number of edges that go out of a node."

The number of edges that go out of a node.

Metanet Protocol

2022-04-27T19:00:21Z

Connor Murray:

[[File:Metanet_graph.png|thumb|A typical Metanet graph.]]

The '''Metanet Protocol''' is a layer-2 overlay protocol that defines a method for creating data structure over Bitcoin SV. The protocol utilises [[Metanet_Protocol#Node and Edge Structure|nodes and edges]] to specify directed acyclic graph (DAG) data structures on the Bitcoin SV ledger. The Metanet protocol can be used to construct diverse systems such as file systems, internet domains, ownership structures and code repositories.

There are tools available to write and read Metanet graphs, and a growing range of projects that use the Metanet protocol to structure their application data.

==Node and Edge Structure==

The Metanet Protocol (MNP) is a protocol for creating graph structures comprising nodes and edges on the ledger. In the Metanet protocol the following definitions of node and edge are used:

* '''Metanet Node''' - A transaction using the Metanet protocol format.
* '''Metanet Edge''' - An input signature linking two Metanet nodes.

A Metanet node is a transaction that conforms to the Metanet transaction format specified in [https://bitcoinsv.io/wp-content/uploads/2020/10/The-Metanet-Technical-Summary-v1.0.pdf Metanet technical summary] document produced by nChain. The basic components of a Metanet transaction include a protocol flag, Metanet-specific data attributes, and any content data that is to be stored by a Metanet node transaction.

The protocol flag is a 4-byte [[hexadecimal]] prefix that signifies that a transaction is using the format of the Metanet protocol. The hexadecimal value of the prefix was chosen to be the hexademical encoding 0x4d455441 of the string 'meta' by [https://twitter.com/BitcoinAssn/status/1136232235798016001?s=20 public poll] on June 5th 2019.

The Metanet-specific data attributes of a Metanet node transaction include the following:

* '''<math>P_{node}</math>''' - the public key defining the node.
* '''<math>TxID_{node}</math>''' - the unique transaction ID of the node.
* '''<math>P_{parent}</math>''' - the public key defining a parent of the node.
* '''<math>SigP_{parent}</math>''' - a signature created using the private key associated with the public key defining a parent of the node.
* '''<math>TxID_{parent}</math>''' - the unique transaction ID of the parent of the node.

The Metanet-specific data attributes listed above are used collectively to define a Metanet node and its position within a larger graph structure of multiple Metanet nodes, known as a ''Metanet graph''.

It is possible that a node does not have any parents and such a node is termed a ''root node''. A root node will have null values for any <math>P_{parent}</math>, <math>SigP_{parent}</math>, and <math>TxID_{parent}</math> attributes, and can therefore use a valid signature from any public key in its input(s).

A Metanet transaction is defined as a transaction that contains an OP_FALSE OP_RETURN payload containing:

* The Metanet flag
[[File:Metanet_node.png|thumb|A Metanet node transaction.]]
* A node public key '''<math>P_{node}</math>'''
* A parent transaction ID '''<math>TxID_{parent}</math>''' (null if a root node).

In order to qualify as a Metanet-valid node, the transaction must also be signed by the public key corresponding to its parent '''<math>P_{parent}</math>'''.

Any content data and its encoding can be included following these core Metanet attributes in the OP_FALSE OP_RETURN payload. The Metanet protocol does not specify the use of any one scheme for content data and additional attributes, and any valued usage of the Metanet protocol attributes above constitute a Metanet node transaction.

A basic example of a Metanet node transaction that conforms to this format is shown in the diagram on the right.

The Metanet graph is formed by creating edges between parent Metanet nodes and child Metanet nodes. An edge is created between a parent and child by the creation and insertion of the signature '''<math>SigP_{parent}</math>''' in the child node, using the parent public key. [[File:Metanet_edge.png|thumb|The creation of a Metanet edge.]]

The fact that this signature is in a transaction input means that the signature itself may be validated by Miners. This means that attempts to spoof a Metanet node can be mitigated either by validating the signature explicitly or by confirming that the node is spending an appropriate previous output.

== Rules of the Metanet Protocol==

The Metanet protocol specifies a simple and extensible rule set for creating Metanet graphs and data structures. The base rule set is the following:

* Nodes are transactions.
* Edges are created by signatures.
* Each node is uniquely identified by the pair of attributes: '''<math>P_{node}</math>''', '''<math>TxID_{node}</math>'''.
* Each node must specify the node ID of itself and its parent: '''<math>ID_{node}</math>''', '''<math>ID_{parent}</math>'''.

The unique node identifier for a node is defined mathematically as '''<math>H(P_{node}||TxID_{node})</math>''', where '''<math>H()</math>''' is a cryptographic hash function.

Metanet graph structures may be created using this base rule set alone. It is also possible to impose additional rules to Metanet graph structures to achieve different properties for data structures.

A simple extension of the rule set is to impose the following [[constraint]]s:
[[File:Metanet_rules.png|thumb|A simple Metanet rule set.]]

* The [[in-degree]] of a node should be 0 (no parent) or 1 (one parent).
* The [[out-degree]] of a node should be a free parameter.

These additional rules allow domain-like structures to emerge as Metanet DAGs, which can be used to structure websites and file systems which inherit the permission structure of a Metanet graph.

Digital signatures in Bitcoin

2022-04-27T18:55:28Z

Connor Murray:

The [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] describes an electronic coin as a chain of digital [[signatures]]. These digital signatures confer practical control, and in most cases, ownership over the coins held in any given script, and can be used as a record of custodial control to trace transfers of control back through the history of the ledger.

[[File:Chain_of_Signatures.png|frame|centre|alt=Electronic coins are defined as a chain of digital signatures]]

A digital signature isn't merely a message signed using a given keypair, but is a link to an identity. The European Union legislation on digital signatures states that signatures correspond to “data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication”. For more information, see [https://craigwright.net/blog/law-regulation/how-digital-signatures-work/ this article] from Dr Craig Wright.

Bitcoin script allows users to lock/unlock their bitcoin in different ways.

==Elliptical Curve Digital Signature Algorithm (ECDSA) ==
[[Elliptic Curve Digital Signature Algorithm]] is the most commonly used signature type in Bitcoin. It makes use of the elliptic curve cryptography keypairs referenced in [[Bitcoin address|Bitcoin addresses]] to generate secure signatures from a given message hash.

Using Bitcoin Script, it is possible to create novel systems that use elliptical curve digital signatures, including [[R-Puzzles]], [[multisignature scripts]] and [[Threshold Signatures]].

==Threshold Signatures==
There have also been practical implementations of [[Threshold Signatures]] in Bitcoin wallets and libraries, which extend Elliptic Curve signatures to enable multiple parties to participate in the creation of a signature, created from a private key that is never explicitly calculated or previously existed. When used in a transaction, a Threshold Signature is no different to a normal ECDSA signature and can be validated using [[OP_CHECKSIG]] and related signature check opcodes.

==Rabin Signatures==
Researchers at nChain have begun developing methods of validating [https://nchain.com/app/uploads/2018/09/Rabin-Signatures-in-Bitcoin-Cash-v2.pdf Rabin signatures] in Bitcoin script. These signatures could theoretically allow for data collected outside the Bitcoin SV ledger to be evaluated and signed, allowing [[oracle]] functionality within Bitcoin transactions.
Currently no practical implementation of a Rabin signature in Bitcoin Script exists.

Oracle

2022-04-27T18:55:03Z

Connor Murray: Created page with "An oracle is an abstract machine that can study behaviour from decision problems and provide information from these problems as input that can be interpreted within a Turing c..."

An oracle is an abstract machine that can study behaviour from decision problems and provide information from these problems as input that can be interpreted within a Turing complete system.

Open BSV License

2022-04-27T18:54:42Z

Connor Murray: Created page with "A license that grants permission to any person obtaining a copy of particular software and associated documentation files, to deal in the software without restriction subject..."

A license that grants permission to any person obtaining a copy of particular software and associated documentation files, to deal in the software without restriction subject to certain conditions which includes that it can only be used on the Bitcoin SV blockchain.

Compression function

2022-04-27T18:51:55Z

Connor Murray: Created page with "A one-way compression function is a function that transforms two fixed-length inputs into a fixed-length output."

A one-way compression function is a function that transforms two fixed-length inputs into a fixed-length output.

RIPEMD-160

2022-04-27T18:51:23Z

Connor Murray:

RIPEMD-160 is a cryptographic hash function based upon the Merkle–Damgård construction. It is used in the Bitcoin standard. It is a strengthened version of the RIPEMD algorithm which produces a 128 bit hash digest while the RIPEMD-160 algorithm produces a 160-bit output. The compression function is made up of 80 stages, made up of 5 blocks, that run 16 times each. This pattern runs twice, with the results being combined at the bottom using modulo 32 addition.

==Padding==

The [[compression function]] works upon 16 32-bit unsigned words. This requires the message to be padded to a multiple of 512 bits and the byte stream input to be padded into 32-bit words. The padding scheme is identical to MD4 using Merkle–Damgård strengthening to prevent length extension attacks. This consists of a one being added to the end of the message, and the length of the message (in bits) being added to the end of the block. The bytes are pushed into the word low end first. Here are 4 examples of messages being padded into a word to show the possible patterns for different message lengths:

[[File:Ripemd padding.png|300px|center|alt=Padding|]]

The length of the message should then be added to the second-to-last element (the length is saved as a 64-bit value across the last 2 words, but it is unlikely the message will be this long; 32-bits will certainly suffice for Bitcoin software.)

==Compression Function==

[[File:RIPEMD160 block.png|thumb|upright=1.2|alt=Sub block.|Sub block of the compression function.]]
[[File:RIPEMD160 compression function.png|thumb|upright=1.2|alt=Compression function.|The full compression function.]]

The compression function is made up of a variable sub block that the message block is passed through 16 times. There are 5 different variations for a total of 80 runs. This process occurs twice, with the data meeting at the bottom, to be moved on to the next block (if there is one), or added to the hash register if there isn't. The sub block can be varied by the design of, a nonlinear function, the order in which the message block is read in per round, the amount of a left rotate and a k constant. The design of the sub block and the overall layout of the compression function is shown to the right.

Pseudocode for the process:

for(i := 0 to blocks - 1) {
aLeft := h0
bLeft := h1
cLeft := h2
dLeft := h3
eLeft := h4

aRight := h0
bRight := h1
cRight := h2
dRight := h3
eRight := h4

for(int j := 0 to 79) {
t := rotleft(s[j]) (aLeft + f(bLeft, cLeft, dLeft) + X[r[i]]) + eLeft
aLeft := eLeft;
eLeft := dLeft
dLeft := rotleft(10) (c)
cLeft := bLeft
bLeft := t

Do same for right
}

t := h1 + cLeft + dRight
h1 := h2 + dLeft + eRight
h2 := h3 + eLeft + aRight
h3 := h4 + aLeft + bRight
h4 := h0 + bLeft + cRight
h0 := t
}

The nonlinear functions are applied in the opposite directions, up and down the left and right lines. The design of the functions from top to bottom, on the left, and bottom to top, on the right, are (Java syntax for operations):

# x ^ y ^ z
# (x & y) | (~x & z)
# (x | ~y) ^ z
# (x & z) | (y & ~z)
# z ^ (y | ~z)

The k values for left, from top to bottom are:

# 0x00000000
# 0x5A827999
# 0x6ED9EBA1
# 0X8F1BBCDC
# 0XA953FD4E

The k values for right, from top to bottom are:

# 0x50A28BE6
# 0x5C4DD124
# 0x6D703EF3
# 0x7A6D76E9
# 0x00000000

The order in which the words should be selected from the block array X for the left-hand-side are (each sub array within the 2D array represents a round. The array at the top, represents the round at the top, and the array at the bottom, represents the round at the bottom):

{{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}, //Round 1
{7, 4, 13, 1, 10, 6, 15, 3, 12, 0, 9, 5, 2, 14, 11, 8}, //Round 2
{3, 10, 14, 4, 9, 15, 8, 1, 2, 7, 0, 6, 13, 11, 5, 12}, //Round 3
{1, 9, 11, 10, 0, 8, 12, 4, 13, 3, 7, 15, 14, 5, 6, 2}, //Round 4
{4, 0, 5, 9, 7, 12, 2, 10, 14, 1, 3, 8, 11, 6, 15, 13}} //Round 5

The order in which the words should be selected from the array X for the right-hand-side are (following the same pattern as above):

{{5, 14, 7, 0, 9, 2, 11, 4, 13, 6, 15, 8, 1, 10, 3, 12}, //Round 1
{6, 11, 3, 7, 0, 13, 5, 10, 14, 15, 8, 12, 4, 9, 1, 2}, //Round 2
{15, 5, 1, 3, 7, 14, 6, 9, 11, 8, 12, 2, 10, 0, 4, 13}, //Round 3
{8, 6, 4, 1, 3, 11, 15, 0, 5, 12, 2, 13, 9, 7, 10, 14}, //Round 4
{12, 15, 10, 4, 1, 5, 8, 7, 6, 2, 13, 14, 0, 3, 9, 11}} //Round 5

The order of the left rotates on the left-hand-side are:

{{11, 14, 15, 12, 5, 8, 7, 9, 11, 13, 14, 15, 6, 7, 9, 8}, //Round 1
{7, 6, 8, 13, 11, 9, 7, 15, 7, 12, 15, 9, 11, 7, 13, 12}, //Round 2
{11, 13, 6, 7, 14, 9, 13, 15, 14, 8, 13, 6, 5, 12, 7, 5}, //Round 3
{11, 12, 14, 15, 14, 15, 9, 8, 9, 14, 5, 6, 8, 6, 5, 12}, //Round 4
{9, 15, 5, 11, 6, 8, 13, 12, 5, 12, 13, 14, 11, 8, 5, 6}} //Round 5

The order of the left rotates on the right-hand-side are:

{{8, 9, 9, 11, 13, 15, 15, 5, 7, 7, 8, 11, 14, 14, 12, 6}, //Round 1
{9, 13, 15, 7, 12, 8, 9, 11, 7, 7, 12, 7, 6, 15, 13, 11}, //Round 2
{9, 7, 15, 11, 8, 6, 6, 14, 12, 13, 5, 14, 13, 13, 7, 5}, //Round 3
{15, 5, 8, 11, 14, 14, 6, 14, 6, 9, 12, 9, 12, 5, 15, 8}, //Round 4
{8, 5, 12, 9, 12, 5, 14, 6, 8, 13, 6, 5, 15, 13, 11, 11}}; //Round 5

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/RIPEMD-160 under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Numeric Value Size

2022-04-27T18:48:44Z

Connor Murray: Created page with "A rule introduced in the Genesis upgrade whereby for a byte sequence to validly represent a numeric value, the length of the byte sequence must be less than or equal to 750,00..."

A rule introduced in the Genesis upgrade whereby for a byte sequence to validly represent a numeric value, the length of the byte sequence must be less than or equal to 750,000 bytes.

Genesis upgrade

2022-04-27T18:48:04Z

Connor Murray:

Genesis was a major update to the BitcoinSV mining client used by the majority of Miners on the BitcoinSV network at the time. Genesis went into effect at block height [https://whatsonchain.com/block-height/620538 620538] which was mined with a timestamp of 01:35:06 UTC on the 4th of February 2020.

The upgrade restored many aspects of the Bitcoin protocol that had been modified in previous software updates including the removal of most limit based consensus rules, replacing them with Miner configurable settings that give node operators the autonomy needed to set their own limits as they determine are practical.

The upgrade was locked in when [https://whatsonchain.com/tx/4ec3b63d764558303eda720e8e51f69bbcfe81376075657313fb587306f8a9b0 this transaction] was mined at block height 620539. The transaction uses a script that would previously have been considered to violate the protocol rules and rejected by network nodes running the BitcoinSV node client.

Further details on the changes made in the upgrade can be found [https://bitcoinsv.io/2020/01/15/changes-for-the-genesis-upgrade/ here] and the full specification is available [https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md here].

==Block Consensus Rules==
These consensus rules apply to blocks that are produced after Genesis activation.

* [[Block Size Rule]] - The consensus rule that restricts the maximum size of a block to a specific number of bytes has been converted into a configurable consensus rule. The size of a block is the size in bytes of the serialised form of the block including the block header and all of the transactions confirmed by the block. MINERS ARE EXPECTED TO REACH CONSENSUS ON THIS VALUE AND CONFIGURE IT MANUALLY.

* Number of CheckSig Operations per MB of Block Space - The consensus rule that limits the number of checksig operations per megabyte of block space has been removed.

==Transaction Consensus Rules==
These consensus rules apply to transactions that are confirmed in blocks after Genesis activation.

* Maximum Transaction Size - The size of a transaction is the size in bytes of the serialised form of the transaction. The maximum size of a transaction is 1GB (1,000,000,000 bytes). This limitation is expected to be lifted in the future.

* Maximum Number of CheckSig Operations per Transaction - The consensus rule that limits the number of checksig operations per transaction has been removed.

* nLockTime and nSequence - After Genesis activation, the functionality of the nLockTime field of a transaction and the nSequence fields of transaction inputs revert to their original purpose. The rules defined here only apply to transactions that are confirmed after Genesis activation.

==Script Language Rules==
This section contains changes to the Script Language Rules.
Bitcoin Script is the programming language that is used to lock and unlock transaction outputs. More can be found at: [https://wiki.bitcoinsv.io/index.php/Advanced_Bitcoin_Scripting Advanced Bitcoin Scripting]. The rules defined here apply to locking and unlocking scripts for transaction outputs that are created after the Genesis activation. The previous rules apply to transaction outputs created prior to Genesis activation.

===OP_RETURN Functionality===

The functionality of the OP_RETURN operation is being restored. OP_RETURN will cause termination of the script and the validity of the script is determined by the value of the top item on the stack. See [https://wiki.bitcoinsv.io/index.php/OP_RETURN OP_RETURN].

===Data Types===

All data items in Bitcoin Script are a byte sequence. Some operations interpret their parameters as numeric or boolean values and require the item to fulfill the requirements of those types. Some operations produce items on the stack which are valid numeric or boolean values.

===Bitcoin Script Formal Grammar===

Formal grammar has been defined for Bitcoin Script. More can be found at: [https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script Opcodes used in Bitcoin Scripting].

* Validity of Script Consensus Rule - The locking and unlocking scripts for every input of a transaction must be grammatically valid, as defined by the formal grammar above.

* PUSHDATA Only in Unlocking Script Consensus Rule - After Genesis activation, the unlocking scripts used in transaction inputs may only contain PUSHDATA operations, as defined by the formal grammar. In contrast to all the other updates in this section, this consensus rule is activated for all inputs of transactions that are, or will be, confirmed in a block after Genesis activation, regardless of the height of the UTXO being spent. This rule is a subset of the Validity of Script Consensus Rule defined above but is included separately because the activation conditions are different.

===Consensus Rule Replacement===

Functionality provided by these consensus rules is now covered by the Stack Memory Usage Consensus Rule.

<table>
<tr><td>Consensus Rule</td><td>Description</td></tr>
<tr><td>Script Element Size</td><td>Limits the maximum size of a script element.</td></tr>
<tr><td>Stack Size</td><td>Limits the combined number of elements that can be placed on the stack and the altstack.</td></tr>
<tr><td>Script Size*</td><td>The maximum size of the script</td></tr>
<tr><td>Number of Non-Push Operations per Script</td><td>Limits the number
of non-push operations per script. Other capabilities manage the cost of execution.</td></tr>
</table>
*functionality also covered by the Maximum Transaction Size Consensus Rule.

===Consensus Rule Changes===

<table>
<tr><td>Consensus Rule</td><td>Description</td></tr>
<tr><td>[[Numeric Value Size]]</td><td>For a byte sequence to represent validly a numeric value, the length of the byte sequence must be less than or equal to 750,000 bytes. A byte sequence that is larger than this is a valid byte sequence but is not a valid numeric value.</td></tr>
<tr><td>Number of Public Keys per Multisig Consensus Rule</td><td>Limits the number of public keys per multisig has been changed to be 2^31-1 (INT32_MAX).</td></tr>
<tr><td>Stack Memory Usage</td><td>Limits the amount of memory that can be used on the stacks. This rule is evaluated against the sum of the memory used by the stack and the memory used by the altstack.</td></tr>
</table>

===Sunsetting===

* P2SH, OP_CHECKLOCKTIMEVERIFY, and OP_CHECKSEQUENCEVERIFY - The P2SH capability is being removed by the Genesis upgrade and the presence of a P2SH script template in an output will invalidate a transaction. The opcode operations revert to NOPs, which have no effect.

* Disabling Operations Consensus Rule - OP_2MUL, OP_2DIV, OP_VERIF, OP_VERNOTIF. If they are present in un-executed script, the script execution may succeed.

==Standard Local Policies==

Policies are settings that are configured by software operators. These settings are generally required by software implementations.

Policies control which transactions the software will propagate across the P2P network or include in a block. However, policies are not Bitcoin Rules or Consensus Rules and are not used to determine the validity of blocks or the transactions confirmed by the block.

Standard Local Transaction Policies
* Maximum Acceptable Transaction Size Policy - The maximum acceptable transaction size is a standard policy that configures the largest transactions that the software will propagate across the P2P network or include in a block.
* Transaction Evaluation Timeout - The transaction evaluation timeout is a standard policy that defines the maximum amount of time that the software will allow for the evaluation of a transaction, before terminating the evaluation and rejecting the it. This setting is always defined with a time unit and the default value 1 second.

Standard Local Script Language Policies
* Numeric Value Length - the length of numeric value policy defines the maximum length of a byte sequence to be considered a valid numeric value. The default value for this value is 250,000 bytes.
* Stack Memory Usage - The stack memory usage policy limits the amount of memory that can be used on the stacks. This policy is evaluated against the sum of memory used by the stack and the altstack.

Standard Local P2P Network Policies
* Propagation of non-Standard Transactions - After Genesis activation, the default setting for this policy is that non-standard transactions will be propagated across the P2P network. Before Genesis activation, the default setting for this policy was non-standard transactions were not propagated by the P2P Network. Policies such as Maximum Acceptable Transaction Size Policy still apply.

NFT

2022-04-27T18:46:46Z

Connor Murray: Created page with "A Non-Fungible Token (NFT) is a token with a unique attribute, creation and existence. It cannot be substituted for any other token."

A Non-Fungible Token (NFT) is a token with a unique attribute, creation and existence. It cannot be substituted for any other token.

Non-custodial

2022-04-27T16:34:22Z

Connor Murray: Created page with "A service or client that stores a digital asset for which either no one, or only you have access to the private keys that can sign transactions and messages or generate a rece..."

A service or client that stores a digital asset for which either no one, or only you have access to the private keys that can sign transactions and messages or generate a receiving alias.

Custodial

2022-04-27T16:34:06Z

Connor Murray:

A custodial service is a service that stores a digital asset on your behalf for which you can send and receive transactions from it, yet cannot access the [[private key]]s.

This differs from a [[non-custodial]] service in which the service or client that stores the digital asset cannot access the keys, but provides a service from which users can send and receive transactions.

Block chain

2022-01-08T15:05:05Z

Connor Murray:

The Bitcoin '''blockchain''' is the transaction database that is extended by nodes participating in the [[mining]] process on the Bitcoin network. The blockchain contains [[transactions]] validated and processed by nodes on the network. Using the blockchain anyone can add and verify a record of all of the [[confirmation|confirmed]] transactions that have taken place on the ledger up until the most recent block was found.

Every [[block]] contains a reference to the block it builds upon. This has the effect of creating a chain of blocks from the [[genesis block]] to the current block. Modifying blocks that have been added to is an economic consideration that becomes impractical once they have been extended for longer periods of time due to the amount of [[Proof of Work|work]] that would need to be regenerated.

Nodes extend the blockchain by building on what they consider to be the most recent valid block, in the longest chain of proof of work. Nodes can dispute blocks by choosing ''not'' to build upon them. Any block that does not become part of the longest chain of work is referred to as an [[Orphan Block]].

For any block on the chain, there is only one path back to the genesis block. Coming from the genesis block, however, there can be divergence in the chain. Forks are created from time to time when two valid blocks are created just a few seconds apart, sparking what's known as an orphan race. When this occurs, each node will attempt to build a new block upon whichever of the competing blocks they received first. This has the effect of creating a very strong incentive for nodes to form a [[Nearly Complete Graph]] as a means to minimise the propagation time of blocks. When a new block is found, the block it was built upon has a much greater chance of becoming part of the longest chain and orphaning its competitor.

If a node detects the creation of a longer chain than the one it is working on, all valid transactions of the block template inside the shorter chain are re-added to the pool of queued transactions to be included in a new block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for spending [[coinbase|coinbase transactions]] exists.

Because the protocol specifies that a block must only reference one previous block, it is impossible for two forked chains to merge.

Blocks are broadcast to all nodes on the network using the [[Bitcoin Network]] protocol.

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Block_chain under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Dust Limit

2021-07-20T19:34:26Z

Connor Murray:

In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people from creating outputs that could become unspendable. In short, the Dust Limit is a threshold of satoshis that cannot be spent in an output.

A typical Bitcoin transaction looks something like this:

[[File:Bitcoin_transaction_example.png|centre|alt=Bitcoin transaction with multiple inputs and outputs]]

In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:

[[File:Dust_limit_transaction.png|centre|alt=Dust Limit Transaction Not Allowed]]

In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.

<h2>Consolidation Transactions</h2>

Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.

[[File:Consolidation_transaction_example.png|centre|alt=Consolidation Transaction Example]]

Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.

In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries.

In order for a transaction to be classified as consolidation by the Bitcoin SV software, some strict conditions must be met. A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.

The conditions for a consolidation transaction are as follows:

*The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)

*The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor

*All inputs must have a confirmation count of at least minconsolidationinputmaturity.

*scriptSig sizes of the consolidation transaction have an upper limit of maxconsolidationinputscriptsize bytes long to prevent gaming.

*Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0

*The default value for maxconsolidationinputscriptsize is 150 bytes.

*The default value for minconsolidationfactor is 20

*The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)

*The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed

*Setting minconsolidationfactor to 0 disables the free consolidation transactions feature

The condition as the formula is:

c = minconsolidationfactor
m = minconsolidationinputmaturity
s = maxconsolidationinputscriptsize
a = acceptnonstdconsolidationinput
isFree = nInputs >= c * nOutputs
&& confirmationCount(input) >= m for all inputs
&& sum(inputTxScriptPubKeyBytesLen[]) >= c * sum(outputTxScripPubKeytBytesLen[])
&& inputTxScriptSig <= s for all inputTxScriptSig
&& isStandardInput(input) for all inputs unless a == 1

As a general rule of thumb:

*Consolidate at least 100 inputs to one output.

*Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.

*Only use inputs confirmed for at least 6 blocks.

**This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.

Dust Limit

2021-07-20T19:33:54Z

Connor Murray:

In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people from creating outputs that could become unspendable. In short, the Dust Limit is a threshold of satoshis that cannot be spent in an output.

A typical Bitcoin transaction looks something like this:

[[File:Bitcoin_transaction_example.png|centre|alt=Bitcoin transaction with multiple inputs and outputs]]

In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:

[[File:Dust_limit_transaction.png|centre|alt=Dust Limit Transaction Not Allowed]]

In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.

Consolidation Transactions

Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.

[[File:Consolidation_transaction_example.png|centre|alt=Consolidation Transaction Example]]

Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.

In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries.

In order for a transaction to be classified as consolidation by the Bitcoin SV software, some strict conditions must be met. A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.

The conditions for a consolidation transaction are as follows:

*The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)

*The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor

*All inputs must have a confirmation count of at least minconsolidationinputmaturity.

*scriptSig sizes of the consolidation transaction have an upper limit of maxconsolidationinputscriptsize bytes long to prevent gaming.

*Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0

*The default value for maxconsolidationinputscriptsize is 150 bytes.

*The default value for minconsolidationfactor is 20

*The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)

*The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed

*Setting minconsolidationfactor to 0 disables the free consolidation transactions feature

The condition as the formula is:

c = minconsolidationfactor
m = minconsolidationinputmaturity
s = maxconsolidationinputscriptsize
a = acceptnonstdconsolidationinput
isFree = nInputs >= c * nOutputs
&& confirmationCount(input) >= m for all inputs
&& sum(inputTxScriptPubKeyBytesLen[]) >= c * sum(outputTxScripPubKeytBytesLen[])
&& inputTxScriptSig <= s for all inputTxScriptSig
&& isStandardInput(input) for all inputs unless a == 1

As a general rule of thumb:

*Consolidate at least 100 inputs to one output.

*Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.

*Only use inputs confirmed for at least 6 blocks.

**This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.

Dust Limit

2021-07-20T19:33:07Z

Connor Murray:

In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people from creating outputs that could become unspendable. In short, the Dust Limit is a threshold of satoshis that cannot be spent in an output.

A typical Bitcoin transaction looks something like this:

[[File:Bitcoin_transaction_example.png|centre|alt=Bitcoin transaction with multiple inputs and outputs]]

In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:

[[File:Dust_limit_example.png|centre|alt=Dust Limit Transaction Not Allowed]]

In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.

Consolidation Transactions

Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.

[[File:Consolidation_transaction_example.png|centre|alt=Consolidation Transaction Example]]

Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.

In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries.

In order for a transaction to be classified as consolidation by the Bitcoin SV software, some strict conditions must be met. A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.

The conditions for a consolidation transaction are as follows:

*The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)

*The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor

*All inputs must have a confirmation count of at least minconsolidationinputmaturity.

*scriptSig sizes of the consolidation transaction have an upper limit of maxconsolidationinputscriptsize bytes long to prevent gaming.

*Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0

*The default value for maxconsolidationinputscriptsize is 150 bytes.

*The default value for minconsolidationfactor is 20

*The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)

*The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed

*Setting minconsolidationfactor to 0 disables the free consolidation transactions feature

The condition as the formula is:

c = minconsolidationfactor
m = minconsolidationinputmaturity
s = maxconsolidationinputscriptsize
a = acceptnonstdconsolidationinput
isFree = nInputs >= c * nOutputs
&& confirmationCount(input) >= m for all inputs
&& sum(inputTxScriptPubKeyBytesLen[]) >= c * sum(outputTxScripPubKeytBytesLen[])
&& inputTxScriptSig <= s for all inputTxScriptSig
&& isStandardInput(input) for all inputs unless a == 1

As a general rule of thumb:

*Consolidate at least 100 inputs to one output.

*Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.

*Only use inputs confirmed for at least 6 blocks.

**This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.

File:Consolidation transaction example.png

2021-07-20T19:32:57Z

Connor Murray: Consolidation Transaction Example

== Summary ==
Consolidation Transaction Example

File:Dust limit transaction.png

2021-07-20T19:31:40Z

Connor Murray: Dust Limit Transaction

== Summary ==
Dust Limit Transaction

File:Bitcoin transaction example.png

2021-07-20T19:30:20Z

Connor Murray: Example Bitcoin transaction with multiple inputs and outputs

== Summary ==
Example Bitcoin transaction with multiple inputs and outputs

Dust Limit

2021-07-20T19:29:06Z

Connor Murray: Created page with "In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people f..."

In Bitcoin’s past developers implemented a protective mechanism for Bitcoin transactions called the Dust Limit. This limit was put in place as an attempt to prevent people from creating outputs that could become unspendable. In short, the Dust Limit is a threshold of satoshis that cannot be spent in an output.

A typical Bitcoin transaction looks something like this:

In this typical Bitcoin transaction, the values paid (in satoshis) is very large in comparison to the fee. Microtransactions are possible in Bitcoin because the fee paid is so low that small outputs can be created that are still large in proportion to the fees paid. However, there does exist a lower bound to what makes sense economically when creating outputs in transactions. If an output is small enough, any fee required to spend that output could be higher than the amount of satoshis in the output:

In the above example, the dust limit, set by the node to be higher than 10 satoshis, prevents 10 satoshi outputs from being created to prevent a situation where an output is unspendable due to fee requirements. The dust limit is entirely set by miner policy, meaning it is not a consensus limitation, but instead is configurable by miners.

Consolidation Transactions

Beginning in Bitcoin SV Node software v1.0.5, the software automatically allows for the creation of “consolidation transactions” where dust outputs can be consolidated for free into larger usable inputs. Outputs below the dust limit are accepted if the node parameter acceptnonstdconsolidationinput is set to 1.

Because miners have to store the entire UTXO set, it is in their interest to reduce the size of the UTXO set whenever possible. It is for this reason that allowing these transactions without a fee is in both the customer and miners' interests.

In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries.

In order for a transaction to be classified as consolidation by the Bitcoin SV software, some strict conditions must be met. A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.

The conditions for a consolidation transaction are as follows:

*The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)

*The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor

*All inputs must have a confirmation count of at least minconsolidationinputmaturity.

*scriptSig sizes of the consolidation transaction have an upper limit of maxconsolidationinputscriptsize bytes long to prevent gaming.

*Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0

*The default value for maxconsolidationinputscriptsize is 150 bytes.

*The default value for minconsolidationfactor is 20

*The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)

*The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed

*Setting minconsolidationfactor to 0 disables the free consolidation transactions feature

The condition as the formula is:

c = minconsolidationfactor
m = minconsolidationinputmaturity
s = maxconsolidationinputscriptsize
a = acceptnonstdconsolidationinput
isFree = nInputs >= c * nOutputs
&& confirmationCount(input) >= m for all inputs
&& sum(inputTxScriptPubKeyBytesLen[]) >= c * sum(outputTxScripPubKeytBytesLen[])
&& inputTxScriptSig <= s for all inputTxScriptSig
&& isStandardInput(input) for all inputs unless a == 1

As a general rule of thumb:

*Consolidate at least 100 inputs to one output.

*Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.

*Only use inputs confirmed for at least 6 blocks.

**This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.

Ancestor Limit

2021-07-20T18:03:35Z

Connor Murray:

In the first iteration of the Bitcoin software, bitcoind v0.1.0 handled the creation of blocks fairly simply. Once a second or so, the software would take a memory map of all the transactions it had received, check any new ones to ensure they met the minimum fee requirement set for the node and if so, add them to the block template which was basically an ordered list of valid transactions. It would then calculate a merkle tree from that set of transactions and build a block header to start doing proof of work upon.

Because of the arbitrary 1MB block size limit imposed on the software at a later time, the software was then optimized to select transactions for block building with the highest fee rates until the 1MB block size limit was filled. Due to this accounting and other policy based limitations, the software inefficiently added transactions to block templates.

This inefficiency manifested in a big way when creating long chains of descendant transactions prior to a block being found. Descendant transactions refers to transactions that are added to a node's mempool that are dependent on previous transactions that are also in that node's mempool. Because the older Bitcoin software was designed around 1MB blocks, situations arose where these long chains of transactions had to be split across multiple blocks.

Starting in October 2015, the BTC Core developers introduced a rule in bitcoin v0.12 to account for this inefficiency by limiting the number of descendants a coin could have to 25. This limit, also called the Ancestor Limit, rejected any transactions that violated this rule with error code 64: too-long-mempool-chain. Bitcoin SV Node v1.0.7 raised this default limit to 1000, and plan to remove the limit entirely soon. Since this restriction is miner policy, miners are free to raise this limit themselves as well.

[[File:ancestor_limit.gif|centre|alt=Ancestor Limit Performance Comparison for Bitcoin SV Node 1.0.7]]

In the above graphic, you can see the performance increase for long chain submission to the node software in v1.0.7.

File:Ancestor limit.gif

2021-07-20T18:01:17Z

Connor Murray: Comparisons when submitting long chains of transactions to the mempool in Bitcoin SV Node v1.0.7

== Summary ==
Comparisons when submitting long chains of transactions to the mempool in Bitcoin SV Node v1.0.7

Ancestor Limit

2021-07-20T18:00:17Z

Connor Murray: Created page with "In the first iteration of the Bitcoin software, bitcoind v0.1.0 handled the creation of blocks fairly simply. Once a second or so, the software would take a memory map of all..."

In the first iteration of the Bitcoin software, bitcoind v0.1.0 handled the creation of blocks fairly simply. Once a second or so, the software would take a memory map of all the transactions it had received, check any new ones to ensure they met the minimum fee requirement set for the node and if so, add them to the block template which was basically an ordered list of valid transactions. It would then calculate a merkle tree from that set of transactions and build a block header to start doing proof of work upon.

Because of the arbitrary 1MB block size limit imposed on the software at a later time, the software was then optimized to select transactions for block building with the highest fee rates until the 1MB block size limit was filled. Due to this accounting and other policy based limitations, the software inefficiently added transactions to block templates.

This inefficiency manifested in a big way when creating long chains of descendant transactions prior to a block being found. Descendant transactions refers to transactions that are added to a node's mempool that are dependent on previous transactions that are also in that node's mempool. Because the older Bitcoin software was designed around 1MB blocks, situations arose where these long chains of transactions had to be split across multiple blocks.

Starting in October 2015, the BTC Core developers introduced a rule in bitcoin v0.12 to account for this inefficiency by limiting the number of descendants a coin could have to 25. This limit, also called the Ancestor Limit, rejected any transactions that violated this rule with error code 64: too-long-mempool-chain. Bitcoin SV Node v1.0.7 raised this default limit to 1000, and plan to remove the limit entirely soon. Since this restriction is miner policy, miners are free to raise this limit themselves as well.

In the above graphic, you can see the performance increase for long chain submission to the node software in v1.0.7.

Home Page

2021-07-20T03:39:29Z

Connor Murray: Created page with "Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality. ===What is Bitcoin?=== '''Bitcoin''' is a peer..."

Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.

===What is Bitcoin?===

'''Bitcoin''' is a peer to peer electronic cash system created by [https://craigwright.net/ Dr. Craig Wright] under the pseudonym [[Satoshi Nakamoto]]. It was first detailed in the [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Block chain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.

Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds.

The leaderless structure of the network is viewed as a resolution to [[The Byzantine Generals Problem]] allowing disconnected entities to follow a common direction without centralised instruction. This solves several issues previously seen as unsolvable in distributed networks, including the problem of preventing [[Double-spending]] of coins.

Bitcoin Satoshi Vision (Bitcoin SV) was created to maintain the integrity of the Bitcoin public ledger by reverting back to the original Bitcoin protocol with the intention of keeping it stable and secure, and allowing it to scale massively in order to accommodate global demand for open public ledger technology.

BitcoinSV will maintain the vision set out by Satoshi Nakamoto’s visionary 2008 white paper titled Bitcoin: A Peer-to-Peer Electronic Cash System which includes:
*Scaling network systems and developing robust mining client software in order to accommodate global demand for ledger space.

*Allowing a distributed small world network to form at the center of a Mandala network connecting billions of people through their devices.

*Elevating Miners into their role as service provider.

*Generating on-chain economic activity sufficient to allow transaction fees to supplant block subsidies as their primary funding mechanism.

*Driving a culture of using transaction fees to price transactions as a service.

*Leveraging economic incentives to build network security.

*Allowing the Bitcoin network to become a global infrastructure platform for financial and information exchange processes.

{| id="mp-right" style="width:100%; vertical-align:top; background:#ffdb65;"
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#eab300; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:center; color:#000; padding:0.2em 0.4em;">Topic central</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">
{|cellpadding="2" style="background-color: inherit;"
|-
| scope="col" style="width: 750px;" |
* '''Wallets
** Handcash
** Moneybutton
** Centbee
** RelayX
** Simply Cash
** ElectrumSV
* '''Node Software
** [https://bitcoinsv.io Bitcoin SV]
* '''Development Tools
** bsv JS library
** gobitcoinsv.com
| scope="col" style="width: 750px;" |
* '''Helpful Links
** [[Opcodes used in Bitcoin Script]]
** [[Bitcoin Transactions]]
** Bitcoin Whitepaper
** Block Explorers
*** Whatsonchain

|}
</div>