BitcoinCash/specification
1
Fork 0
Code Issues Pull Requests Releases Activity

style changes and fixed a few links

Browse Source
This commit is contained in:
Christopher-Zeng
2020-11-04 10:28:50 -05:00
parent 2a44088e07
commit 38441cc43c
9 changed files with 100 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/p2p/get_xblocktx.md
+4 -3
View File
@@ -1,10 +1,11 @@
# Request: 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 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.
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 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
| Field | Length | Format | Description |
|--|--|--|--|
| Block hash | 32 Bytes | Bytes | The hash of the block being reconstructed. |
| Short transaction hashes | # of transactions * 8 bytes | vector | The 64-bit hashes of the transactions still needed for block reconstruction. |
| Block hash | 32 Bytes | Bytes | The hash of the block being reconstructed.|
| Short transaction hashes | # of transactions * 8 bytes | vector | The 64-bit hashes of the transactions still needed for block reconstruction.|
protocol/p2p/get_xthin.md
+6 -3
View File
@@ -1,10 +1,13 @@
# Request: 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`](..\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.
## Format
| Field | Length | Format | Description |
|--|--|--|--|
| inventory message | variable | inventory message | An inventory message of type MSG_XTHINBLOCK. |
| Bloom filter | varaible | serialized object | A serialized Bloom filter seeded with contents of the mempool.|
| inventory message | variable | inventory message | An inventory message of type MSG_XTHINBLOCK.|
| Bloom filter | varaible | serialized object | A serialized Bloom filter seeded with contents of the mempool.|
protocol/p2p/sendcmpct.md
+5 -3
View File
@@ -1,11 +1,13 @@
# Request: 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.
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.
## 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](..\misc\endian\little)</sup> | Must set to 1, otherwise invalid.|
protocol/p2p/thinblock.md
+7 -4
View File
@@ -1,11 +1,14 @@
# Response: 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. 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.
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.
## 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](..\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.|
protocol/p2p/xblocktx.md
+4 -3
View File
@@ -1,10 +1,11 @@
# Response: XBLOCKTX
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.
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
| Field | Length | Format | Description |
|--|--|--|--|
| Block hash | 32 Bytes | Bytes | The hash of the block being reconstructed. |
| Transactions | variable | vector | The transactions still needed for block reconstruction. |
| Block hash | 32 Bytes | Bytes | The hash of the block being reconstructed.|
| Transactions | variable | vector | The transactions still needed for block reconstruction.|
protocol/p2p/xthinblock.md
+7 -4
View File
@@ -1,11 +1,14 @@
# Response: 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. 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.
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.
## 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 * 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. |
| Block header | 80 bytes | [block header](..\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.|