You've already forked specification
wiki commit
This commit is contained in:
AndrewStone
@@ -0,0 +1,5 @@
|
||||
The block header appears in several P2P messages. It's serialization format is as follows:
|
||||
|
||||
| 4 bytes | 32 bytes | 32 bytes | 4 bytes | 4 bytes | 4 bytes
|
||||
|----|---------------|-----------|------------|---------|------
|
||||
| version | hash of previous block | hash of merkle root | block time in epoch seconds | difficulty in "bits" format | nonce
|
||||
@@ -0,0 +1,20 @@
|
||||
A "compact int" is serialized as follows:
|
||||
|
||||
*If the number < 253, store it in 1 byte
|
||||
*If the number fits in 16 bits: store a 1 byte value 253, and the 2 byte little-endian number.
|
||||
|
||||
| 0 | 1 | 2 |
|
||||
|--------|---------|---------|
|
||||
| 0xfd | val&255 | val>>8 |
|
||||
|
||||
* If the number fits in 32 bits (but not 8 or 16): store a 1 byte value 254, and the 4 byte little-endian number
|
||||
|
||||
| 0 | 1 | 2 | 3 | 4 |
|
||||
|--------|---------|---------|---------|---------|
|
||||
| 0xfe | val&255 | (val>>8)&255 | (val>>16)&255 | (val>>24)&255 |
|
||||
|
||||
* If the number fits in 64 bits (but not 8, 16, or 32): store a 1 byte value 255 and the 8 byte little-endian number
|
||||
|
||||
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|
||||
|--------|---------|---------|---------|---------|---------|---------|---------|--------|
|
||||
| 0xff | val&255 | val>>8 | val>>16 | val>>24 | val>>32 | val>>40 | val>>48 | val>>56 |
|
||||
@@ -0,0 +1,40 @@
|
||||
|
||||
The services field is an 8 byte little-endian-serialized bitfield that described peer capabilities. The following capabilities are defined, by bit position:
|
||||
|
||||
* 0: NODE_NETWORK
|
||||
The node is capable of serving the complete block chain. It is currently set by all full nodes, and is unset by SPV clients or other peers that just want network services but don't provide them.
|
||||
|
||||
* 1: NODE_GETUTXO
|
||||
The node is capable of responding to the getutxo protocol request. See [BIP 64](https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki) for details on how this is implemented. *Supported by Bitcoin XT only*
|
||||
|
||||
* 2: NODE_BLOOM
|
||||
The node is capable and willing to handle bloom-filtered connections.
|
||||
|
||||
* 3: NODE_WITNESS
|
||||
Indicates that a node can be asked for blocks and transactions including witness data.
|
||||
*Bitcoin Cash nodes do not have witness data so this flag should be ignored on receipt and set to 0 when sent*
|
||||
|
||||
|
||||
* 4: NODE_XTHIN
|
||||
The node supports Xtreme Thinblocks
|
||||
*Supported by Bitcoin Unlimited only*
|
||||
|
||||
* 5: NODE_BITCOIN_CASH
|
||||
The node supports the BCH chain. This is intended to be just a temporary service bit until the BTC/BCH fork actually happens.
|
||||
|
||||
* 6: NODE_GRAPHENE
|
||||
The node supports Graphene blocks. If this is turned off then the node will not service graphene requests nor make graphene requests.
|
||||
*Supported by Bitcoin Unlimited only*
|
||||
|
||||
* 7: NODE_WEAKBLOCKS
|
||||
The node supports Storm weak block (currently no node supports these in production, so this is a placeholder).
|
||||
|
||||
* 8: NODE_CF
|
||||
Indicates the node is capable of serving compact block filters to SPV clients, AKA the "Neutrino" protocol ([BIP157](https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki), and [BIP158](https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki)).
|
||||
|
||||
* 9: NODE_NETWORK_LIMITED
|
||||
This means the same as NODE_NETWORK with the limitation of only serving a small subset of the blockchain. See [BIP159](https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki) for details on how this is implemented.
|
||||
|
||||
* 24-31: Experimental
|
||||
These bits are reserved for temporary experiments. Just pick a bit that isn't getting used, or one not being used much, and notify the community. Remember that service bits are just unauthenticated advertisements, so your code must be robust against collisions and other cases where nodes may be advertising a service they do not actually support.
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
Vectors (and arrays, lists, maps, etc) are serialized by first serializing the number of elements and then serializing each element. The number of elements is serialized in [compact int](/protocol/p2p/compact__int) format.
|
||||
|
||||
| vector element count | object #0 | object #1 | ... | object #count-1 |
|
||||
|-------------|--------------|-------------|----------------|------------|
|
||||
| [compact int](/protocol/p2p/compact__int) | object specific serialization | ... | ... | ... |
|
||||
|
|
||||
@@ -0,0 +1,18 @@
|
||||
<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**
|
||||
@@ -0,0 +1,11 @@
|
||||
<div class="cwikmeta">{
|
||||
"title":"XVERACK",
|
||||
"related":["/protocol","/protocol/p2p/xversion","/protocol/p2p/xupdate"]
|
||||
}</div>
|
||||
|
||||
*Notifies peers that an XVERSION message was received*.
|
||||
|
||||
This message has no *contents*.
|
||||
|
||||
### Support
|
||||
Supported by: **Bitcoin Unlimited**
|
||||
@@ -0,0 +1,27 @@
|
||||
<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**
|
||||
@@ -0,0 +1,24 @@
|
||||
<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