diff --git a/protocol/network/messages.md b/protocol/network/messages.md index e239d5c..2eb6a9e 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -72,7 +72,7 @@ Messages with an unrecognized `command string` are ignored by most implementatio | [ping](/protocol/network/messages/ping) | *Requests a confirmation (pong) that the peer is still active* | | [sendheaders](/protocol/network/messages/sendheaders) | *Requests that new blocks are sent as headers instead of hashes* | | [version](/protocol/network/messages/version) | *Describes peer capabilities, particularly through the [Services Bitfield](/protocol/network/messages/version#services-bitfield)* | -| mempool | *Request mempool contents* | +| [mempool](/protocol/network/messages/mempool) | *Request mempool contents* | #### Responses diff --git a/protocol/network/messages/addr.md b/protocol/network/messages/addr.md index 1c25396..18ec09f 100644 --- a/protocol/network/messages/addr.md +++ b/protocol/network/messages/addr.md @@ -5,7 +5,7 @@ # Response: Addresses ("addr") -Provide information about other prospective P2P protocol peers. Peers SHOULD not send this message unsolicited (see [getaddr](/protocol/network/messages/getaddr)), and nodes that receive an unsolicited addr message MUST ignore it. This behavior helps prevent eclipse and partitioning attacks by not allowing an attacker to aggressively seed peer connection tables with its own nodes. +Provide information about other prospective P2P protocol peers. Peers SHOULD not send this message unsolicited (see [`getaddr`](/protocol/network/messages/getaddr)), and nodes that receive an unsolicited `addr` message MUST ignore it. This behavior helps prevent eclipse and partitioning attacks by not allowing an attacker to aggressively seed peer connection tables with its own nodes. ## Message Format diff --git a/protocol/network/messages/blocktxn.md b/protocol/network/messages/blocktxn.md index b8c5ce6..f08c9a7 100644 --- a/protocol/network/messages/blocktxn.md +++ b/protocol/network/messages/blocktxn.md @@ -1,8 +1,8 @@ -# Response: BLOCKTXN +# Response: Block Transactions ("blocktxn") Transmits a group of transactions from a block to a peer. -A blocktxn message is sent in response to a [getblocktxn](/protocol/network/messages/getblocktxn) message, and must include exactly the set of transactions requested, in the order requested (i.e. in the order they appear in the block). +A `blocktxn` message is sent in response to a [`getblocktxn`](/protocol/network/messages/getblocktxn) message, and must include exactly the set of transactions requested, in the order requested (i.e. in the order they appear in the block). ## Format @@ -10,4 +10,4 @@ A blocktxn message is sent in response to a [getblocktxn](/protocol/network/mess |--|--|--|--| | block hash | 32 bytes | bytes | The hash of the block that contains the transactions to follow. | | transaction count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of transactions being provided. | -| transactions | variable | `transaction count` [transactions](/protocol/blockchain/transaction) | The transactions, in order, serialized as though in a [tx](/protocol/network/messages/tx) message. | +| transactions | variable | `transaction count` [transactions](/protocol/blockchain/transaction) | The transactions, in order, serialized as though in a [`tx`](/protocol/network/messages/tx) message. | diff --git a/protocol/network/messages/cmpctblock.md b/protocol/network/messages/cmpctblock.md index 9af18e3..033ed62 100644 --- a/protocol/network/messages/cmpctblock.md +++ b/protocol/network/messages/cmpctblock.md @@ -1,8 +1,8 @@ -# Announcement: CMPCTBLOCK +# Announcement: Compact Block ("cmpctblock") Transmits a compact block to a peer. -This message is automatically sent to "high bandwidth relaying" peers, or in response to a [getdata](/protocol/network/messages/getdata) request specifying the [compact block inventory type](/protocol/network/messages/inv#inventory-types) and block hash. +This message is automatically sent to "high bandwidth relaying" peers, or in response to a [`getdata`](/protocol/network/messages/getdata) request specifying the [compact block inventory type](/protocol/network/messages/inv#inventory-types) and block hash. ## Format @@ -37,7 +37,7 @@ The format is as follows: | Field | Length | Format | Description | |--|--|--|--| | index | variable | [variable length integer](/protocol/formats/variable-length-integer) | The ["differentially encoded"](#differentially-encoded-indexes) position of the transaction with in the block. | -| transaction | variable | [transaction](/protocol/blockchain/transaction#format) | The full transaction contents, as in a [tx](/protocol/network/messages/tx) message. | +| transaction | variable | [transaction](/protocol/blockchain/transaction#format) | The full transaction contents, as in a [`tx`](/protocol/network/messages/tx) message. | ## Differentially Encoded Indexes @@ -51,6 +51,6 @@ Conversely, `dn = tn - tn-1 - 1`. ## Reconstructing the Block -Upon receipt of a cmpctblock message, the recipient must first determine whether it now has all the transactions needed to reconstruct the block. First, all prefilled transactions should be processed. If some transactions are still unknown, the recipient may request then using a [getblocktxn](/protocol/network/messages/getblocktxn) message. Once the recipient has all of the necessary transactions, the block's [merkle tree](/protocol/blockchain/block/merkle-tree) can be re-built by adding the transactions in the order specified by the indexes. NOTE: since [HF-20181115](/protocol/forks/hf-20181115), [CTOR](/protocol/forks/hf-20181115#canonical-transaction-order) means that this the same order can also be achieved by sorting the transactions by their hashes. +Upon receipt of a `cmpctblock` message, the recipient must first determine whether it now has all the transactions needed to reconstruct the block. First, all prefilled transactions should be processed. If some transactions are still unknown, the recipient may request then using a [`getblocktxn`](/protocol/network/messages/getblocktxn) message. Once the recipient has all of the necessary transactions, the block's [merkle tree](/protocol/blockchain/block/merkle-tree) can be re-built by adding the transactions in the order specified by the indexes. NOTE: since [HF-20181115](/protocol/forks/hf-20181115), [CTOR](/protocol/forks/hf-20181115#canonical-transaction-order) means that this the same order can also be achieved by sorting the transactions by their hashes. -For more information on when cmpctblock messages should be sent and how they should be validated, see [BIP-152](/protocol/forks/bip-0152). \ No newline at end of file +For more information on when `cmpctblock` messages should be sent and how they should be validated, see [BIP-152](/protocol/forks/bip-0152). \ No newline at end of file diff --git a/protocol/network/messages/filterload.md b/protocol/network/messages/filterload.md index 5560226..16beb14 100644 --- a/protocol/network/messages/filterload.md +++ b/protocol/network/messages/filterload.md @@ -9,7 +9,7 @@ Inserts a transaction and merkle block filter into the receiving peer, overwriti ### Effect on Transactions -This message installs a [bloom filter](/protocol/spv/bloom-filter) into the peer. Subsequent [inv](/protocol/network/messages/inv) and [merkleblock](/protocol/network/messages/merkleblock) messages only provide transactions that in match this bloom filter in some manner. The following items in a transaction are checked against the bloom filter: +This message installs a [bloom filter](/protocol/spv/bloom-filter) into the peer. Subsequent [`inv`](/protocol/network/messages/inv) and [`merkleblock`](/protocol/network/messages/merkleblock) messages only provide transactions that in match this bloom filter in some manner. The following items in a transaction are checked against the bloom filter: - The transaction hash - Each data field in every [locking script](/protocol/blockchain/transaction/locking-script) in the transaction diff --git a/protocol/network/messages/get_xblocktx.md b/protocol/network/messages/get_xblocktx.md index f8a2410..533d20f 100644 --- a/protocol/network/messages/get_xblocktx.md +++ b/protocol/network/messages/get_xblocktx.md @@ -1,6 +1,6 @@ -# Request: GET_XBLOCKTX +# Request: Get Xthin Block Transactions ("get_xblocktx") -This message is sent to remote peer to request the transactions still needed to reconstruct the block from the mempool after receipt of the previous [`XTHINBLOCK`](xthinblock) or [`THINBLOCK`](thinblock) message. +This message is sent to remote peer to request the transactions still needed to reconstruct the block from the mempool after receipt of the previous [`xthinblock`](xthinblock) or [`thinblock`](thinblock) message. This message should start with the hash of the block that is intended to be reconstructed, followed by a list of short hashes of the transactions still needed. ## Format diff --git a/protocol/network/messages/get_xthin.md b/protocol/network/messages/get_xthin.md index 8fc3fe1..61fce35 100644 --- a/protocol/network/messages/get_xthin.md +++ b/protocol/network/messages/get_xthin.md @@ -1,9 +1,9 @@ -# Request: GET_XTHIN +# Request: Get Xthin Block ("get_xthin") -Request the [`XTHINBLOCK`](xthinblock) from the peer that was anoounced via the previous [`INV`](..\network\messages\inv) message. -The message should start with an inventory message that indicates the `XTHINBLOCK` requested, followed by the Bloom filter generated from the mempool. -Upon receipt of this request, the peer should loads the attached Bloom filter, creates and responds with `XTHINBLOCK`. -If the `XTHINBLOCK` cannot be created without hash collisions, the peer may repond with `THINBLOCK` or full blocks. +Request the [`xthinblock`](xthinblock) from the peer that was anoounced via the previous [`inv`](/protocol/network/messages/inv) message. +The message should start with an inventory message that indicates the `xthinblock` requested, followed by the Bloom filter generated from the mempool. +Upon receipt of this request, the peer should loads the attached Bloom filter, creates and responds with `xthinblock`. +If the `xthinblock` cannot be created without hash collisions, the peer may respond with `thinblock` or full blocks. ## Format diff --git a/protocol/network/messages/getaddr.md b/protocol/network/messages/getaddr.md index cab40a5..48ad92a 100644 --- a/protocol/network/messages/getaddr.md +++ b/protocol/network/messages/getaddr.md @@ -1,6 +1,6 @@ # Request: Get Addresses (“getaddr”) -Request the information about active peers on the network. The recipient may reply with peer IP addresses using an [addr](/protocol/network/messages/addr) message. +Request the information about active peers on the network. The recipient may reply with peer IP addresses using an [`addr`](/protocol/network/messages/addr) message. ## Message Format This message has no contents. \ No newline at end of file diff --git a/protocol/network/messages/getblocks.md b/protocol/network/messages/getblocks.md index d4dd6c8..fdcf125 100644 --- a/protocol/network/messages/getblocks.md +++ b/protocol/network/messages/getblocks.md @@ -5,7 +5,7 @@ # Request: Get Blocks (“getblocks”) -Request the sequence of blocks that occur after a specific block. If the specified block is on the server's most-work chain, the server responds with a set of up to 500 [INV](/protocol/network/messages/inv.md) messages identifying the next blocks on that chain. If the specified block is not on the most-work chain, the server uses block information in the *locator* structure to determine the fork point and provides [INV](/protocol/network/messages/inv.md) messages from that point. +Request the sequence of blocks that occur after a specific block. If the specified block is on the server's most-work chain, the server responds with a set of up to 500 [`inv`](/protocol/network/messages/inv.md) messages identifying the next blocks on that chain. If the specified block is not on the most-work chain, the server uses block information in the *locator* structure to determine the fork point and provides [`inv`](/protocol/network/messages/inv.md) messages from that point. ## Message Format @@ -18,15 +18,15 @@ Request the sequence of blocks that occur after a specific block. If the specif ### Locator -See [GETHEADERS](/protocol/network/messages/getheaders.md) for a detailed description of the Locator object. +See [`getheaders`](/protocol/network/messages/getheaders) for a detailed description of the Locator object. The response will begin at **the child of** the first hash in the locator list that matches a block hash identifier held by the responder. If no hashes match, there will be no INV messages sent. -*Use an empty locator to get an INV for block 1, and GETHEADERS that block to discover the genesis block hash in the prevBlock field* +*Use an empty locator to get an `inv` for block 1, and `getheaders` that block to discover the genesis block hash in the prevBlock field* ### Stop At Hash -The sender will stop sending INVs if it encounters this hash. If the hash is never encountered, the sender will stop after 500 INV messages or when it hits the blockchain tip. +The sender will stop sending inventory messages if it encounters this hash. If the hash is never encountered, the sender will stop after 500 inventory messages or when it hits the blockchain tip. ## Server Implementations diff --git a/protocol/network/messages/getblocktxn.md b/protocol/network/messages/getblocktxn.md index d836328..49f3866 100644 --- a/protocol/network/messages/getblocktxn.md +++ b/protocol/network/messages/getblocktxn.md @@ -1,9 +1,9 @@ -# Request: GETBLOCKTXN +# Request: Get Block Transactions ("getblocktxn") Requests unknown transactions in a block from a peer. -Upon receiving a [cmpctblock](/protocol/network/messages/cmpctblock) message, a node may determine it is still missing some transactions from the recent block, which it can request using a getblocktxn message. -A node receiving a getblocktxn message, that has recently sent a cmpctblock message for the specified block to this peer, must respond with either a [blocktxn](/protocol/network/messages/blocktxn) message or a [block](/protocol/network/messages/block) message. +Upon receiving a [`cmpctblock`](/protocol/network/messages/cmpctblock) message, a node may determine it is still missing some transactions from the recent block, which it can request using a `getblocktxn` message. +A node receiving a `getblocktxn` message, that has recently sent a `cmpctblock` message for the specified block to this peer, must respond with either a [`blocktxn`](/protocol/network/messages/blocktxn) message or a [`block`](/protocol/network/messages/block) message. ## Format diff --git a/protocol/network/messages/getdata.md b/protocol/network/messages/getdata.md index 517f56c..dfd6f80 100644 --- a/protocol/network/messages/getdata.md +++ b/protocol/network/messages/getdata.md @@ -5,7 +5,7 @@ # Request: Get Data (“getdata”) -Requests information (generally previously announced via an [inv](/protocol/network/messages/inv) message) from a peer. +Requests information (generally previously announced via an [`inv`](/protocol/network/messages/inv) message) from a peer. As such, a getdata request carries the same general format as an inventory message and is used to request any items that the node was previously unaware. ## Message Format diff --git a/protocol/network/messages/inv.md b/protocol/network/messages/inv.md index 4aea7cd..b60fdd2 100644 --- a/protocol/network/messages/inv.md +++ b/protocol/network/messages/inv.md @@ -7,9 +7,9 @@ Notifies peers about the existence of some information (block or transaction). -Based on selected services in the [version](/protocol/network/messages/version) message, inventory messages may not be sent. +Based on selected services in the [`version`](/protocol/network/messages/version) message, inventory messages may not be sent. -If a bloom filter has been sent to this node via [filterload](/protocol/network/messages/filterload), a transaction inventory will only be sent for transactions that match the bloom filter. +If a bloom filter has been sent to this node via [`filterload`](/protocol/network/messages/filterload), a transaction inventory will only be sent for transactions that match the bloom filter. ## Message Format @@ -18,7 +18,7 @@ If a bloom filter has been sent to this node via [filterload](/protocol/network/ | inventory count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of inventory items in this message. | | inventory items | `inventory_count` * 36 bytes | `inventory_count` [inventory items](#inventory-item-format) | The set of inventory items being transmitted. Up to 50,000 inventory items can be sent in a single inventory message.| -NOTE: Since a block header is a relatively small data structure, and block propagation speed is an important network metric, a peer may send [headers](/protocol/network/messages/headers) messages in place of inventory messages when a block arrives. This behavior can be requested using the [sendheaders](/protocol/network/messages/sendheaders) message. +NOTE: Since a block header is a relatively small data structure, and block propagation speed is an important network metric, a peer may send [`headers`](/protocol/network/messages/headers) messages in place of inventory messages when a block arrives. This behavior can be requested using the [`sendheaders`](/protocol/network/messages/sendheaders) message. #### Inventory Item Format diff --git a/protocol/network/messages/mempool.md b/protocol/network/messages/mempool.md new file mode 100644 index 0000000..a46ceed --- /dev/null +++ b/protocol/network/messages/mempool.md @@ -0,0 +1,8 @@ +# Request: Mempool ("mempool") + +Requests that the recipient notify the sender of transactions that are currently in its [mempool](/protocol/blockchain/memory-pool). +Recipients of a `mempool` message MAY respond with a set of transaction hashes currently in their mempool via an [`inv`](/protocol/network/messages/inv) message. + +## Message Format +This message has no contents. + diff --git a/protocol/network/messages/merkleblock.md b/protocol/network/messages/merkleblock.md index 1095015..835a0b2 100644 --- a/protocol/network/messages/merkleblock.md +++ b/protocol/network/messages/merkleblock.md @@ -7,9 +7,9 @@ Provides a block header and partial merkle proof tree to show that the selected transaction [hashes](/protocol/blockchain/hash) exist in the block. -Transactions are selected by honest servers if they match the bloom filter installed by the client. However, note that servers can omit transactions and this cannot be detected except by receiving a merkleblock message from an honest server. +Transactions are selected by honest servers if they match the bloom filter installed by the client. However, note that servers can omit transactions and this cannot be detected except by receiving a `merkleblock` message from an honest server. -All selected transactions are subsequently sent as separate [tx](/protocol/network/messages/tx) messages. Due to multi-threading on the server, clients should not assume that these transaction messages directly follow the merkleblock message. +All selected transactions are subsequently sent as separate [`tx`](/protocol/network/messages/tx) messages. Due to multi-threading on the server, clients should not assume that these transaction messages directly follow the `merkleblock` message. ## Message Format @@ -24,7 +24,7 @@ All selected transactions are subsequently sent as separate [tx](/protocol/netwo #### Partial Merkle Tree Flag Bits -The partial merkle tree flag bits effectively create a variable-width bitfield, indicating which transaction hashes from the block the merkleblock message pertains to actually matched the client's bloom filter. +The partial merkle tree flag bits effectively create a variable-width bitfield, indicating which transaction hashes from the block the `merkleblock` message pertains to actually matched the client's bloom filter. If you picture the merkle tree root at the top, the flag bits represent a top-down yes/no approach to whether the a given branch (or leaf node) of the tree includes any matching transactions. For full details, see [BIP-37: Partial Merkle Branch Format](/protocol/forks/bip-0037#partial-merkle-branch-format). diff --git a/protocol/network/messages/ping.md b/protocol/network/messages/ping.md index 4ee531c..1e11cd4 100644 --- a/protocol/network/messages/ping.md +++ b/protocol/network/messages/ping.md @@ -8,11 +8,11 @@ Connection keep-alive, "aliveness" and latency discovery. -If a node receives a PING message, it replies as quickly as possible with a [PONG](/protocol/network/messages/pong.md) message with the provided *nonce*. +If a node receives a `ping` message, it replies as quickly as possible with a [`pong`](/protocol/network/messages/pong.md) message with the provided *nonce*. ## Message Format | Field | Length | Format | Description | |--|--|--|--| -| nonce | 8 bytes | unsigned 64 bit integer[(LE)](/protocol/misc/endian/little.md) | An arbitrary value provided to connect the ping message with the pong reply +| nonce | 8 bytes | unsigned 64 bit integer[(LE)](/protocol/misc/endian/little.md) | An arbitrary value provided to connect the ping message with the `pong` reply. | diff --git a/protocol/network/messages/pong.md b/protocol/network/messages/pong.md index b6c1332..28e708b 100644 --- a/protocol/network/messages/pong.md +++ b/protocol/network/messages/pong.md @@ -6,10 +6,10 @@ # Response: Pong ("pong") -Connection keep-alive, "aliveness" and latency discovery. This message is sent in response to a [PING](/protocol/network/messages/ping.md) message. +Connection keep-alive, "aliveness" and latency discovery. This message is sent in response to a [`ping`](/protocol/network/messages/ping) message. ## Message Format | Field | Length | Format | Description | |--|--|--|--| -| nonce | 8 bytes | unsigned 64 bit integer[(LE)](/protocol/misc/endian/little) | The value provided by the [PING](/protocol/network/messages/ping.md) message. +| nonce | 8 bytes | unsigned 64 bit integer[(LE)](/protocol/misc/endian/little) | The value provided by the `ping` message. diff --git a/protocol/network/messages/sendcmpct.md b/protocol/network/messages/sendcmpct.md index 83c0d02..a713b26 100644 --- a/protocol/network/messages/sendcmpct.md +++ b/protocol/network/messages/sendcmpct.md @@ -1,4 +1,4 @@ -# Request: SENDCMPCT +# Request: Send Compact Blocks ("sendcmpct") This message notifies the peer that this node support Compact Block Relay. Node should only send this message after protocol version >= 70014. diff --git a/protocol/network/messages/sendheaders.md b/protocol/network/messages/sendheaders.md index 1d48069..134a1ed 100644 --- a/protocol/network/messages/sendheaders.md +++ b/protocol/network/messages/sendheaders.md @@ -1,6 +1,6 @@ # Request: Send Headers (“sendheaders”) -Requests that new blocks are sent to the sender as a [header](/protocol/network/messages/headers) message instead of as a block hash [inv](/protocol/network/messages/inv) message. +Requests that new blocks are sent to the sender as a [`header`](/protocol/network/messages/headers) message instead of as a block hash [`inv`](/protocol/network/messages/inv) message. ## Message Format This message has no contents. \ No newline at end of file diff --git a/protocol/network/messages/thinblock.md b/protocol/network/messages/thinblock.md index a67631b..e951235 100644 --- a/protocol/network/messages/thinblock.md +++ b/protocol/network/messages/thinblock.md @@ -1,14 +1,14 @@ -# Response: THINBLOCK +# Response: Thin Block ("thinblock") -This message delivers an `THINBLOCK` to the remote peer. -The `THINBLOCK` starts with the block header, followed by the hashes of all the transactions in the block. +This message delivers an `thinblock` to the remote peer. +The `thinblock` starts with the block header, followed by the hashes of all the transactions in the block. The transaction hashes are in the same order as they are in the actual block. -All the transactions that are in the block, but not matched by the Bloom filter inlcuded in the previous [`GET_XTHIN`](get_xthin) mesaage should be appended, which should include at least the coinbase transaction. +All the transactions that are in the block, but not matched by the Bloom filter included in the previous [`get_xthin`](get_xthin) message should be appended, which should include at least the coinbase transaction. ## Format | Field | Length | Format | Description | |--|--|--|--| -| Block header | 80 bytes | [block header](..\blockchain\block\block-header) | The header of the block transmitted.| -| Transaction hashes | # of tx * 32 bytes | vector | The hashes of all the transactions included in the block.| -| Missing transactions | variable | vector | Transactions that are included in the blocks but are not matched by the Bloom filter.| +| Block header | 80 bytes | [block header](/protocol/blockchain/block/block-header) | The header of the block transmitted. | +| Transaction hashes | # of tx * 32 bytes | vector | The hashes of all the transactions included in the block. | +| Missing transactions | variable | vector | Transactions that are included in the blocks but are not matched by the Bloom filter. | diff --git a/protocol/network/messages/verack.md b/protocol/network/messages/verack.md index 4dc31f0..40cdde1 100644 --- a/protocol/network/messages/verack.md +++ b/protocol/network/messages/verack.md @@ -1,12 +1,10 @@ # Handshake: Version Acknowledgement ("verack") -The `verack` message is sent in reply to a [version](/protocol/network/messages/version) message. +The `verack` message is sent in reply to a [`version`](/protocol/network/messages/version) message. Sending a `verack` in response to a `version` message indicates to the remote that its connection and version has been accepted. There is no version negotiation functionality between nodes; therefore if the node does not accept the version supplied by the remote then the node disconnects instead of responding with a `verack`. -This `verack` message consists of only a message header; the command string is "verack". - ## Message Format This message has no contents. diff --git a/protocol/network/messages/version.md b/protocol/network/messages/version.md index 5bb8518..a98f71f 100644 --- a/protocol/network/messages/version.md +++ b/protocol/network/messages/version.md @@ -3,7 +3,7 @@ The version message is a part of the node connection [handshake](/protocol/network/node-handshake) and indicates various connection settings, networking information, and the services provided by the sending node (see Services Bitfield [below](#services-bitfield)). -The node connection is not considered established until both nodes have sent and received both a `version` and [verack](/protocol/network/messages/verack) message. +The node connection is not considered established until both nodes have sent and received both a `version` and [`verack`](/protocol/network/messages/verack) message. ## Message Format diff --git a/protocol/network/messages/xblocktx.md b/protocol/network/messages/xblocktx.md index 68d2537..e715fbe 100644 --- a/protocol/network/messages/xblocktx.md +++ b/protocol/network/messages/xblocktx.md @@ -1,6 +1,6 @@ -# Response: XBLOCKTX +# Response: Xthin Block Transactions ("xblocktx") -This message delivers the transactions specified in the previous [`GET_XBLOCKTX`](get_xblocktx) message to the remote peer. +This message delivers the transactions specified in the previous [`get_xblocktx`](get_xblocktx) message to the remote peer. This message starts with the hash of the block being reconstructed, followed by a list of transactions requested. ## Format diff --git a/protocol/network/messages/xthinblock.md b/protocol/network/messages/xthinblock.md index 5fb71c3..7088029 100644 --- a/protocol/network/messages/xthinblock.md +++ b/protocol/network/messages/xthinblock.md @@ -1,14 +1,14 @@ -# Response: XTHINBLOCK +# Response: Xthin Block ("xthinblock") -This message delivers an `XTHINBLOCK` to the remote peer. -The `XTHINBLOCK` starts with the block header, followed by the truncated hashes of all the transactions in the block. +This message delivers an `xthinblock` to the remote peer. +The `xthinblock` starts with the block header, followed by the truncated hashes of all the transactions in the block. The transaction hashes are truncated to the first 64 bits and are in the same order as they are in the actual block. -All the transactions that are in the block, but not matched by the Bloom filter inlcuded in the previous [`GET_XTHIN`](get_xthin) mesaage should be appended, which should include at least the coinbase transaction. +All the transactions that are in the block, but not matched by the Bloom filter included in the previous [`get_xthin`](get_xthin) message should be appended, which should include at least the coinbase transaction. ## Format | Field | Length | Format | Description | |--|--|--|--| -| Block header | 80 bytes | [block header](..\blockchain\block\block-header) | The header of the block transmitted.| +| Block header | 80 bytes | [block header](/protocol/blockchain/block/block-header) | The header of the block transmitted.| | Transaction hashes | # of tx * 8 bytes | vector | The truncated hashes of all the transactions included in the block.| | Missing transactions | variable | vector | Transactions that are included in the blocks but are not matched by the Bloom filter.| diff --git a/protocol/network/messages/xupdate.md b/protocol/network/messages/xupdate.md index e870f93..5342a9a 100644 --- a/protocol/network/messages/xupdate.md +++ b/protocol/network/messages/xupdate.md @@ -5,7 +5,10 @@ # Handshake Extension: XVersion (“xversion”) -This message notifies a peer about changes to protocol parameters. It follows the same format as [xversion](/protocol/network/messages/xversion) protocol parameters. Implementations **SHOULD** only send changed parameters, rather than every parameter. Note that some XVERSION parameters are not changeable and therefore will be ignored if they appear in this message. +This message notifies a peer about changes to protocol parameters. +It follows the same format as [`xversion`](/protocol/network/messages/xversion) protocol parameters. +Implementations SHOULD only send changed parameters, rather than every parameter. +Note that some `xversion` parameters are not changeable and therefore will be ignored if they appear in this message. See the [xversion fields](/protocol/network/messages/xversion#xversion-fields) for detailed information about each parameter. diff --git a/protocol/network/messages/xverack.md b/protocol/network/messages/xverack.md index 1725460..cb133c0 100644 --- a/protocol/network/messages/xverack.md +++ b/protocol/network/messages/xverack.md @@ -1,7 +1,7 @@ # Handshake Extension: XVersion Acknowledgement (“xverack”) -The `xverack` message is sent in reply to an [xversion](/protocol/network/messages/xversion) message. -Sending an `xverack` in response to a `version` message indicates to the remote that its XVersion values have been accepted. +The `xverack` message is sent in reply to an [`xversion`](/protocol/network/messages/xversion) message. +Sending an `xverack` in response to an `xversion` message indicates to the remote that its XVersion values have been accepted. ## Message Format diff --git a/protocol/network/messages/xversion.md b/protocol/network/messages/xversion.md index 36ee743..1653682 100644 --- a/protocol/network/messages/xversion.md +++ b/protocol/network/messages/xversion.md @@ -5,7 +5,7 @@ # Handshake Extension: XVersion (“xversion”) -This message notifies a peer about extended protocol parameters. This message MAY be sent during connection initialization. If sent, it MUST be sent immediately subsequent to the receipt of the [verack](/protocol/network/messages/verack.md) message, and before other non-initialization messages are sent. +This message notifies a peer about extended protocol parameters. This message MAY be sent during connection initialization. If sent, it MUST be sent immediately subsequent to the receipt of the [`verack`](/protocol/network/messages/verack) message, and before other non-initialization messages are sent. ## Message Format @@ -38,7 +38,7 @@ XVersion field identifiers are 32 bits and split into a 16 bit prefix and 16 bit See [xversionkeys.dat](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/xversionkeys.dat) for the most up-to-date field definitions defined by the BitcoinUnlimited full node. Note that: * *u64c* refers to a [variable length integer](/protocol/formats/variable-length-integer). -* *Changeable* fields MAY be changed during the course of a connection via the [xupdate](/protocol/network/messages/xupdate) message. +* *Changeable* fields MAY be changed during the course of a connection via the [`xupdate`](/protocol/network/messages/xupdate) message. ### Support