You've already forked specification
X[version/update/verack] consolidation/updates.
Also fixing some additional formatting/linking inconsistencies.
This commit is contained in:
Andrew Groot
@@ -53,7 +53,7 @@ Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signat
|
||||
|
||||
#### Other messages (extensions)
|
||||
|
||||
sendcmpct — get_xthin — xthinblock — thinblock — get_xblocktx — xblocktx — [xupdate](/protocol/p2p/xupdate) — [xversion](/protocol/p2p/xversion) —xverack
|
||||
sendcmpct — get_xthin — xthinblock — thinblock — get_xblocktx — xblocktx — [xupdate](/protocol/network/messages/xupdate) — [xversion](/protocol/network/messages/xversion) — [xverack](/protocol/network/messages/xverack)
|
||||
|
||||
### Simple Payment Verification (SPV)
|
||||
[Bloom Filters](/objects/bloom__filter)
|
||||
|
||||
@@ -17,7 +17,6 @@ These design decisions were made with consideration to communication with untrus
|
||||
The P2P network has a variety of message types.
|
||||
All P2P messages follow a binary format with the following structure:
|
||||
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| net magic | 4 bytes | byte array<sup>[(BE)](/protocol/misc/endian/big)</sup> | See [net magic](#net-magic). |
|
||||
@@ -26,6 +25,8 @@ All P2P messages follow a binary format with the following structure:
|
||||
| payload checksum | 4 bytes | byte array<sup>[(BE)](/protocol/misc/endian/big)</sup> | The message checksum is the first 4 bytes of a double-sha256 hash of the payload. |
|
||||
| payload | variable | message-specific | See [message types](#message-types) for links to message-specific page, which describe the payload for each message. |
|
||||
|
||||
See [Example Message](#example-message) for a concrete example of this with a message that does not contain an extended payload.
|
||||
|
||||
### Net Magic
|
||||
|
||||
The network identifier is used to separate blockchains and test networks.
|
||||
@@ -91,11 +92,23 @@ Messages with an unrecognized `command string` are ignored by most implementatio
|
||||
| thinblock | | |
|
||||
| xblocktx | | |
|
||||
| xthinblock | | |
|
||||
| [xupdate](/protocol/p2p/xupdate) | *Communicates a change in peer capabilities* | BCHUnlimited
|
||||
| [xversion](/protocol/p2p/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited
|
||||
| xverack | *Response to an [xversion](/protocol/p2p/xversion) message* | BCHUnlimited
|
||||
| [xupdate](/protocol/network/messages/xupdate) | *Communicates a change in peer capabilities* | BCHUnlimited
|
||||
| [xversion](/protocol/network/messages/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited
|
||||
| [xverack](/protocol/network/messages/xverack) | *Response to an [xversion](/protocol/network/messages/xversion) message* | BCHUnlimited
|
||||
|
||||
# Example message
|
||||
## Example message
|
||||
|
||||
The below segments, when concatenated in order, create a sample [verack](/protocol/network/message/verack) message.
|
||||
|
||||
| Label | Sample Value (Hexadecimal Representation) |
|
||||
|-------|------|
|
||||
| Net Magic<sup>[(BE)](/protocol/misc/endian/little)</sup> | `E3E1F3E8` |
|
||||
| Command String ("verack")<sup>[(BE)](/protocol/misc/endian/big)</sup> | `76657261636B000000000000` |
|
||||
| Payload Byte Count<sup>[(LE)](/protocol/misc/endian/little)</sup> | `00000000` |
|
||||
| Payload Checksum<sup>[(LE)](/protocol/network/messages/message-checksum)</sup> | `5DF6E0E2` |
|
||||
|
||||
### Full Sample Message (Hexadecimal)
|
||||
`E3E1F3E876657261636B000000000000000000005DF6E0E2`
|
||||
|
||||
# Node Specific Behavior
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Handshake: Acknowledge ("verack")
|
||||
# Handshake: Version Acknowledgement ("verack")
|
||||
|
||||
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.
|
||||
@@ -7,16 +7,6 @@ There is no version negotiation functionality between nodes; therefore if the no
|
||||
|
||||
This `verack` message consists of only a message header; the command string is "verack".
|
||||
|
||||
## Example Serialized Data
|
||||
## Message Format
|
||||
|
||||
Net Magic<sup>[(BE)](/protocol/misc/endian/little)</sup>
|
||||
`E3E1F3E8`
|
||||
|
||||
Command String ("verack")<sup>[(BE)](/protocol/misc/endian/big)</sup>
|
||||
`76657261636B000000000000`
|
||||
|
||||
Payload Byte Count<sup>[(LE)](/protocol/misc/endian/little)</sup>
|
||||
`00000000`
|
||||
|
||||
Payload Checksum<sup>[(LE)](/protocol/network/messages/message-checksum)</sup>
|
||||
`5DF6E0E2`
|
||||
This message has no contents.
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
<div class="cwikmeta">{
|
||||
"title":"XUPDATE",
|
||||
"related":["/protocol/network/messages","/protocol/network/messages/xversion"]
|
||||
}</div>
|
||||
|
||||
# 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.
|
||||
|
||||
See the [xversion fields](/protocol/network/messages/xversion#xversion-fields) for detailed information about each parameter.
|
||||
|
||||
## Message Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| number of values | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of values being sent. |
|
||||
| values | variable | `number_of_values` * [xversion values](/protocol/network/messages/xversion#xversion-value-format) | The list of values to communicate. |
|
||||
|
||||
|
||||
### Support
|
||||
Supported by: **Bitcoin Unlimited**
|
||||
@@ -0,0 +1,8 @@
|
||||
# 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.
|
||||
|
||||
## Message Format
|
||||
|
||||
This message has no contents.
|
||||
@@ -0,0 +1,45 @@
|
||||
<div class="cwikmeta">{
|
||||
"title":"XVERSION",
|
||||
"related":["/protocol/network/messages","/protocol/network/messages/xupdate","/protocol/network/messages/xverack"]
|
||||
}</div>
|
||||
|
||||
# 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.
|
||||
|
||||
## Message Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| number of values | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of values being sent. |
|
||||
| values | variable | `number_of_values` * [xversion values](#xversion-value-format) | The list of values to communicate. |
|
||||
|
||||
### XVersion Value Format
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| field | variable | [variable length integer](/protocol/formats/variable-length-integer) | Indicates the field type of the value to follow. See [XVersion Fields](#xversion-fields). |
|
||||
| size of value | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the value to follow. |
|
||||
| value | `size_of_value` bytes | bytes | The value for the preceding field type (`key`). The format of the value is defined by the `field`, but must be the specified number of bytes. |
|
||||
|
||||
#### XVersion Fields
|
||||
|
||||
XVersion field identifiers are 32 bits and split into a 16 bit prefix and 16 bit suffix. Each development group is assigned a prefix so that new identifiers do not accidentally conflict. Once a field identifier is created by group A, it should be used by other software both to receive that information from A and to present that information to other software. Therefore, group A **MUST NOT** change the syntax or semantics of a field once defined. To change a field, create a new identifier and deprecate (by no longer using the original identifier).
|
||||
|
||||
#### Prefix and Suffix Assignments
|
||||
|
||||
##### Prefix Assignments
|
||||
| Group | Value |
|
||||
|-------------------------|-------|
|
||||
| Reserved for versioning | 0 |
|
||||
| Bitcoin Cash Node | 1 |
|
||||
| Bitcoin Unlimited | 2 |
|
||||
|
||||
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.
|
||||
|
||||
### Support
|
||||
|
||||
Supported by: **Bitcoin Unlimited**
|
||||
@@ -1,18 +0,0 @@
|
||||
<div class="cwikmeta">{
|
||||
"title":"XUPDATE",
|
||||
"related":["/protocol","/protocol/p2p/xversion" ,"/protocol/p2p/xversionkeys"]
|
||||
}</div>
|
||||
|
||||
*Notifies peers about an XVERSION configuration value update*
|
||||
|
||||
This message notifies a peer about changes to protocol parameters. It follows the same format as [XVERSION](/protocol/p2p/xversion.md) 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](/protocol/p2p/xversion.md) message for detailed information about each parameter.
|
||||
|
||||
| compact int | compact int | variable bytes |... | compact int | 32 bytes |
|
||||
|----------|---------|----------|---|---------|----------|
|
||||
|[vector](/protocol/p2p/vector) size N of| key 1 | [vector](/protocol/p2p/vector) of bytes | | key N | [vector](/protocol/p2p/vector) of bytes
|
||||
|
||||
|
||||
### Support
|
||||
Supported by: **Bitcoin Unlimited**
|
||||
@@ -1,27 +0,0 @@
|
||||
<div class="cwikmeta">{
|
||||
"title":"XVERSION",
|
||||
"related":["/protocol","/protocol/p2p/xupdate","/protocol/p2p/xversionkeys"]
|
||||
}</div>
|
||||
|
||||
*Notifies peers about a protocol configuration value*
|
||||
|
||||
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/p2p/verack.md) message, and before other non-initialization messages are sent.
|
||||
|
||||
| compact int | compact int | variable bytes |... | compact int | variable bytes |
|
||||
|----------|---------|----------|---|---------|----------|
|
||||
|[vector](/protocol/p2p/vector) size N of| key 1 | value 1 [vector](/protocol/p2p/vector) of bytes | | key N | value N [vector](/protocol/p2p/vector) of bytes
|
||||
|
||||
The *value* is a vector of bytes. These bytes can be an object that is itself serialized, but **MUST** exist within the vector "envelope" so that implementations that do not recognize a field can skip it. The serialization format of the bytes inside the "envelope" is defined by the creator of the key, however, Bitcoin P2P network serialization is recommended since it is also used to encode/decode all the messages of this protocol.
|
||||
|
||||
See [XVERSION specification](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/doc/xversionmessage.md) for additional details.
|
||||
|
||||
### XVERSION Fields
|
||||
|
||||
XVERSION field identifiers are 32 bits and split into a 16 bit prefix and 16 bit suffix. Each development group is assigned a prefix so that new identifiers do not accidentally conflict. Once a field identifier is created by group A, it should be used by other software both to receive that information from A and to present that information to other software. Therefore, group A **MUST NOT** change the syntax or semantics of a field once defined. To change a field, create a new identifier and deprecate (by no longer using the original identifier).
|
||||
|
||||
#### Prefix and Suffix Assignments
|
||||
See [xversionkeys](/protocol/p2p/xversionkeys.md) for a full list of assigned prefixes and field definitions.
|
||||
|
||||
### Support
|
||||
|
||||
Supported by: **Bitcoin Unlimited**
|
||||
@@ -1,24 +0,0 @@
|
||||
<div class="cwikmeta">{
|
||||
"title":"XVERSIONKEYS",
|
||||
"related":["/protocol","/protocol/p2p/xversion","/protocol/p2p/xupdate"]
|
||||
}</div>
|
||||
|
||||
|
||||
### Prefix Assignments
|
||||
| Group | Value |
|
||||
|-------------------------|-------|
|
||||
| Reserved for versioning | 0 |
|
||||
| Bitcoin Cash Node | 1 |
|
||||
| Bitcoin Unlimited | 2 |
|
||||
|
||||
|
||||
#### Field Assignments
|
||||
|
||||
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 [compact int](/protocol/p2p/compact__int.md) serialization of an unsigned 64-bit value.
|
||||
* *Changeable* fields MAY be changed during the course of a connection via the [XUPDATE](/protocol/p2p/xupdate) message.
|
||||
|
||||
### Support
|
||||
|
||||
Supported by: **Bitcoin Unlimited**
|
||||
Reference in New Issue
Block a user