You've already forked specification
Merge remote-tracking branch 'verde/master'
This commit is contained in:
@@ -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
|
||||
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
# 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).
|
||||
|
||||
## Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| 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. |
|
||||
@@ -0,0 +1,56 @@
|
||||
# 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.
|
||||
|
||||
## Format
|
||||
|
||||
The below format is referred to in [BIP-152](/protocol/forks/bip-0152) as `HeaderAndShortIDs`.
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| header | 80 bytes | [block header](/protocol/blockchain/block/block-header) | The header of the block being sent. |
|
||||
| nonce | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | A nonce used in the calculation of the short transaction IDs to follow. This is generated by the sender and must be unique per block but not necessary per peer. |
|
||||
| short id count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of short transaction IDs to follow. This will be the number of transaction in the block minus the number of "prefilled" transactions provided at the end of this message. |
|
||||
| short ids | `short_id_count* 6` bytes | `short_id_count` 6-byte unsigned integers<sup>[(LE)](/protocol/misc/endian/little)</sup> | The list of transactions in the block, referenced by [short transaction IDs](#short-transaction-ids). This includes every transaction in the block *except* the "prefilled" transactions to follow. |
|
||||
| prefilled transaction count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of prefilled transactions to follow. |
|
||||
| prefilled transactions | variable | `prefilled_transaction_count` [prefilled transactions](#prefilled-transactions) | The coinbase transaction and any other transactions in the block that the sender believes the peer may be missing. |
|
||||
|
||||
### Short Transaction IDs
|
||||
|
||||
Short transaction IDs are generated using the following steps:
|
||||
|
||||
1. Generate a key, `k`, as the little-endian single-SHA-256 hash of the block header concatenated with the little-endian compact block nonce generated by the sender (i.e. either a new random value or the one received from a peer).
|
||||
2. Calculate the [SipHash-2-4](https://en.wikipedia.org/wiki/SipHash) of the full transaction ID using `k` as the key. For implementations that expect two keys, use the first 64-bits of the little-endian hash as `k<sub>0</sub>` and the second 64-bits as `k<sub>1</sub>`.
|
||||
3. Drop the 2 most-significant bytes of the SipHash output to get the 6-byte short transaction ID.
|
||||
|
||||
For more information about the design of these short IDs, see [BIP-152:Short transaction ID calculation](/protocol/forks/bip-0152#short-transaction-id-calculation).
|
||||
For additional details on how the recipient should handle this message, see [reconstructing the block](#reconstructing-the-block).
|
||||
|
||||
### Prefilled Transactions
|
||||
|
||||
Prefilled transactions specify the full transaction data for transactions that are not expected to already be known by the recipient.
|
||||
The coinbase transaction is always such a transaction, while others may be included at the sender's discretion.
|
||||
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. |
|
||||
|
||||
## Differentially Encoded Indexes
|
||||
|
||||
Where compact-block-related messages reference the indexes of transactions within a block, they use a differential encoding to further minimize the amount of data used.
|
||||
In such a list of transactions with indexes, each index is interpreted as a relative index from the previous transaction in the list.
|
||||
That is, if the first transaction has an index of `0`, it is the first transaction in the block (true index `0`).
|
||||
If the second transaction also has an index of `0`, it is the second transaction in the block (true index `1`).
|
||||
|
||||
Generally, if `d<sub>n</sub>` is the differentially encoded index for the `n`-th transaction in a given list, and `t<sub>n</sub>` is that transactions true index within the block, `t<sub>n</sub> = t<sub>n-1</sub> + d<sub>n</sub> + 1`.
|
||||
Conversely, `d<sub>n</sub> = t<sub>n</sub> - t<sub>n-1</sub> - 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.
|
||||
|
||||
For more information on when `cmpctblock` messages should be sent and how they should be validated, see [BIP-152](/protocol/forks/bip-0152).
|
||||
@@ -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
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Request: GET_XBLOCKTX
|
||||
# Request: Get Xthin Block Transactions ("get_xblocktx")
|
||||
|
||||
This message is sent to remote peer to request the transations 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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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,12 +18,12 @@ 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.
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
# 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.
|
||||
|
||||
## Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| block hash | 32 bytes | bytes | The hash of the block containing the desired transactions. |
|
||||
| indexes count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of transactions being requested. |
|
||||
| indexes | variable | `indexes_count` [variable length integers](/protocol/formats/variable-length-integer) | The [differentially encoded indexes](/protocol/network/messages/cmpctblock#differentially-encoded-indexes) of the transactions within the block being requested. |
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -38,5 +38,5 @@ The type of the object that is available.
|
||||
| 0x0004 | Compact block
|
||||
| 0x0005 | Xthin block (Bitcoin Unlimited)
|
||||
| 0x0006 | Graphene Block (Bitcoin Unlimited)
|
||||
| 0x94A0 | [Double Spend Proof](/protocol/network/messages/dsproof-beta) |
|
||||
| 0x94A0 | [Double Spend Proof - Beta](/protocol/network/messages/dsproof-beta) |
|
||||
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
# 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.
|
||||
|
||||
The mempool message was defined in [BIP-35](/protocol/forks/bip-0035).
|
||||
|
||||
## Message Format
|
||||
This message has no contents.
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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<sup>[(LE)](/protocol/misc/endian/little.md)</sup> | An arbitrary value provided to connect the ping message with the pong reply
|
||||
| nonce | 8 bytes | unsigned 64 bit integer<sup>[(LE)](/protocol/misc/endian/little.md)</sup> | An arbitrary value provided to connect the ping message with the `pong` reply. |
|
||||
|
||||
@@ -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<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value provided by the [PING](/protocol/network/messages/ping.md) message.
|
||||
| nonce | 8 bytes | unsigned 64 bit integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value provided by the `ping` message.
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# 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.
|
||||
This message can indicate the High Bandwidth Relaying mode or Low Bandwidth Relaying mode by setting the `Mode` field.
|
||||
Upon recepit of this message from the peer, node should announce new block via `cmpctblock` message if `Mode = 1`, or node should announce new block via `inv` or `header` message as defined in BIP-0130.
|
||||
Upon receipt of this message from the peer, node should announce new block via `cmpctblock` message if `Mode = 1`, or node should announce new block via `inv` or `header` message as defined in BIP-0130.
|
||||
|
||||
## Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| Mode | 1 byte | Integer | 1: High Bandwidth Relaying mode;</br> 0: Low Bandwidth Relaying mode;</br> Other: Invalid |
|
||||
| Version | 8 bytes | Integer <sup>[LE](..\misc\endian\little)</sup> | Must set to 1, otherwise invalid.|
|
||||
| Version | 8 bytes | Integer <sup>[(LE)](/protocol/misc/endian/little)</sup> | Must set to 1, otherwise invalid.|
|
||||
|
||||
@@ -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.
|
||||
@@ -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 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.|
|
||||
| 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. |
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.|
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user