diff --git a/protocol/p2p/get_xblocktx.md b/protocol/p2p/get_xblocktx.md new file mode 100644 index 0000000..53f9445 --- /dev/null +++ b/protocol/p2p/get_xblocktx.md @@ -0,0 +1,10 @@ +# 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. + +## 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. | diff --git a/protocol/p2p/get_xthin.md b/protocol/p2p/get_xthin.md new file mode 100644 index 0000000..90f1df5 --- /dev/null +++ b/protocol/p2p/get_xthin.md @@ -0,0 +1,10 @@ +# 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. + +## 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.| diff --git a/protocol/p2p/sendcmpct.md b/protocol/p2p/sendcmpct.md new file mode 100644 index 0000000..e69de29 diff --git a/protocol/p2p/thinblock.md b/protocol/p2p/thinblock.md new file mode 100644 index 0000000..b1acb00 --- /dev/null +++ b/protocol/p2p/thinblock.md @@ -0,0 +1,11 @@ +# 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. + +## 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. | \ No newline at end of file diff --git a/protocol/p2p/xblocktx.md b/protocol/p2p/xblocktx.md new file mode 100644 index 0000000..08b60c8 --- /dev/null +++ b/protocol/p2p/xblocktx.md @@ -0,0 +1,10 @@ +# 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. + +## 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. | \ No newline at end of file diff --git a/protocol/p2p/xthinblock.md b/protocol/p2p/xthinblock.md new file mode 100644 index 0000000..0014a93 --- /dev/null +++ b/protocol/p2p/xthinblock.md @@ -0,0 +1,11 @@ +# 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. + +## 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. | \ No newline at end of file diff --git a/protocol/spv.md b/protocol/spv.md new file mode 100644 index 0000000..c187155 --- /dev/null +++ b/protocol/spv.md @@ -0,0 +1,17 @@ +# SPV + +Simplified Payment Verification (SPV) is an alternative method for Bitcoin Cash clients to verify [transactions](blockchain\transaction) without access to the entire [blockchain](blockchain). Clients that implement SPV typically do not store, validate, or broadcast most of the [blocks](blockchain\block) on the chain, and thus, significantly reduce the resources needed for operation. In contrast, nodes that store the full blockchain are often referred to as full nodes. + +## Theory + +The validity of transactions can not only be verified through checking the transactions against the public ledger, but can also be demonstrated through the facts that they have been accepted by the Bitcoin Cash network and admitted into the blockchain. SPV relies on the latter method mentioned and verifies transactions by querying other network nodes for de facto proof that the blocks containing the transactions are valid. The clients can keep their own copy of the [block header](blockchain\block\block-header) chain and verify that the blocks referred are included in the blockchain. The clients can further increase their confidence for the validity of the said transactions, as the confirmations go up due to the increased difficulty to forge the additional blocks and the decreased likelihood of a [blockchain reorganization](blockchain#blockchain-reorganization). + +## Design + +The support for the SPV was proposed in [BIP-0037](forks\bip-0037). Clients that wish to operate in the SPV mode should utilize the [`filterload`](network\messages\filterload) and [`filteradd`](network\messages\filteradd) messages to request the remote peers to install and add content to the bloom filter on its connection with the client. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives. Upon receipt of these messages, the remote peers are expected to only announce transactions selected by the filter, with the matching algorithm proposed in [BIP-0037](forks\bip-0037). Nodes that accept a filterload message are expected to only send [inventory messages](network\messages\inv) containing transactions that match the client's bloomfilter, or blocks that contain transactions that match the client's Bloom filter. When blocks are requested by the client, they are sent not as [`block`](network\messages\block) messages, but as [`merkle block`](network\messages\merkleblock) messages, which contain the partial [merkle trees](blockchain\block\merkle-tree) of the blocks as the proof of the inclusion for the transactions announced. The transactions can be transmitted to the clients normally, via [`tx`](network\messages\tx) messages. The clients can utilize the [`filterclear`](network\messages\filterclear) message to clear the Bloom filter on the connection, to revert the connection to its typical state. + +## Advantages and Disadvantages + +SPV allows the clients to only receive, store, and validate parts of the blockchain without hampering their ability to verify the transactions they care about, and thus, significantly reduce the storage space, computational power and network traffic needed for operation. Such characteristics make them ideal for environments with meagre performance, or on metered networks, such as mobile wallets. + +However, the SPV method typically requires more confirmation times to build up confidence for transactions, and in the event of an attack, such clients will not be able to detect the fabricated transactions as long as the attacker can overpower the network. In addition, the SPV also has known flaws that weaken the security and privacy of clients and allow denial-of-service attack vectors on full nodes that support the SPV.