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

Fixing links and other merge issues.

Browse Source
This commit is contained in:
Andrew Groot
2020-11-05 10:26:59 -05:00
parent f74cc51632
commit 629c886f87
4 changed files with 31 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
home.md
+2 -2
View File
@@ -5,7 +5,7 @@
[Style Guide](/style-guide) — [Contributors](/contributors) — [Target Audience](/target-audience) — [Project History](/project-history)
### Basics
[Overview](protocol\Overview.md) — [Blockchain Basics](/protocol/blockchain) — [Protocol Hashing Algorithms](/protocol/blockchain/hash) — Memory Pool
[Overview](/protocol/overview) — [Blockchain Basics](/protocol/blockchain) — [Protocol Hashing Algorithms](/protocol/blockchain/hash) — [Memory Pool](/protocol/blockchain/memory-pool)
### Transactions
[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script) — [Locking Script](/protocol/blockchain/transaction/locking-script) — [Transaction Signing](/protocol/blockchain/transaction/transaction-signing)
@@ -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/network/messages/xupdate) — [xversion](/protocol/network/messages/xversion) — [xverack](/protocol/network/messages/xverack)
[sendcmpct](/protocol/network/messages/sendcmpct) — [get_xthin](/protocol/network/message/get_xthin) — [xthinblock](/protocol/network/messages/xthinblock) — [thinblock](/protocol/network/messages/thinblock) — [get_xblocktx](/protocol/network/messages/get_xblocktx) — [xblocktx](/protocol/network/messages/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)
protocol/blockchain/memory-pool.md
+5 -4
View File
@@ -1,7 +1,7 @@
# Memory Pool
The Bitcoin Cash memory pool, or mempool, is a staging area for valid Bitcoin Cash [transactions](protocol\blockchain\transaction) waiting to be added to the [blockchain](protocol\blockchain).
[Valid transactions](protocol\blockchain\transaction-validation) received from the network are usually cached in the mempool and are removed once they are mined into a [block](protocol\blockchain\block).
The Bitcoin Cash memory pool, or mempool, is a staging area for valid Bitcoin Cash [transactions](/protocol/blockchain/transaction) waiting to be added to the [blockchain](/protocol/blockchain).
[Valid transactions](/protocol/blockchain/transaction-validation) received from the network are usually cached in the mempool and are removed once they are mined into a [block](/protocol/blockchain/block).
Bitcoin Cash nodes typically employ mempools to increase their responsiveness, enabling them to accept and validate transactions anytime even though new blocks are only mined once per 10 minutes on average.
Mining nodes are also incentivized to do so in order to collect larger amounts of transaction fees from groups of transactions for every block mined.
@@ -22,9 +22,9 @@ Apart from the capacity reasons, transactions that once were considered valid ma
Valid transactions may be rejected by the node to enter the mempool for several typical reasons.
1. Transactions may be rejected if they fail to meet the minimum transaction fee set by the node.
This usually happens if the mempool is approaching its capacity or if the transactions are considered [dust transactions](transaction-validation\network-level-validation-rules#dust).
This usually happens if the mempool is approaching its capacity or if the transactions are considered [dust transactions](/protocol/blockchain/transaction-validation/network-level-validation-rules#dust).
2. Transactions that double spend inputs of another transaction already in the mempool will be rejected.
3. [Non-standard](transaction-validation\network-level-validation-rules#standard-transactions) transactions are often rejected.
3. [Non-standard](/protocol/blockchain/transaction-validation/network-level-validation-rules#standard-transactions) transactions are often rejected.
## Removal of transactions from the mempool
@@ -34,4 +34,5 @@ The reasons for such removal may include but not limited to:
1. Nodes may remove the transactions that are no longer valid after a blockchain reorg, such as transactions that double spend inputs of existing transactions in the blockchain or transactions that spend outputs that are now time-locked due to reduced block height or earlier median time-past (MTP) after the blockchain reorg.
2. Transactions may be removed when new blocks are received, such as transactions included in the received blocks or transactions that double spend inputs of transactions in the new blocks.
3. Nodes may remove transactions due to performance or capacity constraints.
Typically, transactions that provide low fees may be removed when the mempool is approaching its capacity or after prolonged periods in the mempool without being mined.
protocol/Overview.md → protocol/overview.md
+8 -8
View File
@@ -1,9 +1,9 @@
# Overview
Bitcoin Cash is a decentralized cryptocurrency with a public distributed ledger.
Transactions are validated and transmitted over the Bitcoin Cash peer-to-peer (P2P) network, and stored in the [blockchain](protocol\blockchain).
Transactions are validated and transmitted over the Bitcoin Cash peer-to-peer (P2P) network, and stored in the [blockchain](/protocol/blockchain).
Bitcoin Cash utilizes the Proof-of-work timestamping scheme with SHA-256 hash function, and targets a 10-minute block time.
It also utilizedzz the secp256k1 parameters with ECDSA and Schnorr algorithm for digital signatures.
It also utilizes the secp256k1 parameters with ECDSA and Schnorr algorithm for digital signatures.
The ticker symbol for Bitcoin Cash is BCH.
## Design
@@ -54,9 +54,9 @@ graph RL
```
Bitcoin Cash operates on the blockchain which is distributed among the Bitcoin Cash network.
[Transactions](protocol\blockchain\transaction) in bitcoin are submitted to network nodes, which will [validate the transaction](protocol\blockchain\transaction-validation) against the transaction history in the blockchain.
Once transactions are considered valid, they will be grouped into blocks through [Merkle Trees](protocol\blockchain\block\merkle-tree).
Through rigorous hash computation, blocks can be mined into the blockchain by the network nodes and are subsequently broadcasted to the Bitcoin Cash network.
[Transactions](/protocol/blockchain/transaction) in Bitcoin are submitted to network nodes, which will [validate the transaction](/protocol/blockchain/transaction-validation) against the transaction history in the blockchain.
Once transactions are considered valid, they will be grouped into blocks through [Merkle Trees](/protocol/blockchain/block/merkle-tree).
Through rigorous hash computation, blocks can be mined into the blockchain by the network nodes and are subsequently broadcast to the Bitcoin Cash network.
The blockchain serves as the public ledger for Bitcoin Cash.
It consists of one single chain of blocks and each block contains the hash of its previous block.
@@ -66,9 +66,9 @@ Therefore, the transaction history in the blockchain can be considered immutable
The transactions on the Bitcoin Cash is pseudonymous.
The blockchain does not keep records of coin ownerships for users.
Instead, each transaction refers to the unspent results of previous transactions.
The results of the transaction is then locked through [locking scripts](protocol\blockchain\transaction\locking-script) and whoever holds the correct [unlocking scripts](protocol\blockchain\transaction\unlocking-script) can use the results in their future transactions.
Instead, each transaction refers to the unspent outputs of previous transactions.
The outputs of the transaction is then locked through [locking scripts](/protocol/blockchain/transaction/locking-script) and whoever holds the correct [unlocking scripts](/protocol/blockchain/transaction/unlocking-script) can use the outputs in their future transactions.
The Bitcoin Cash network is an ad-hoc decentralized network of volunteers, in which Bitcoin Cash transactions are transmitted and validated.
Messages on the network are usually broadcasted on the best-effort basis.
Messages on the network are usually broadcast on a best-effort basis.
The consensus of the blockchain is achieved through the proof-of-work mechanism, in which the chain with the most work is agreed on.
protocol/spv.md
+11 -11
View File
@@ -1,31 +1,31 @@
# 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.
Simplified Payment Verification (SPV) is an alternative method for Bitcoin Cash clients to verify [transactions](/protocol/blockchain/transaction) without access to the entire [blockchain](/protocol/blockchain).
Clients that implement SPV typically do not store, validate, or broadcast most of the [blocks](/protocol/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 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 SPV was proposed in [BIP-0037](forks\bip-0037).
Clients that wish to operate in 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.
The support for SPV was proposed in [BIP-0037](/protocol/forks/bip-0037).
Clients that wish to operate in SPV mode should utilize the [`filterload`](/protocol/network/messages/filterload) and [`filteradd`](/protocol/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.
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](/protocol/forks/bip-0037).
Nodes that accept a filterload message are expected to only send [inventory messages](/protocol/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`](/protocol/network/messages/block) messages, but as [`merkle block`](/protocol/network/messages/merkleblock) messages, which contain the partial [merkle trees](/protocol/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`](/protocol/network/messages/tx) messages.
The clients can utilize the [`filterclear`](/protocol/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.
Such characteristics make them ideal for environments with meager performance, or on metered networks, such as mobile wallets.
However, 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, 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 SPV.