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

minor changes.

Browse Source
This commit is contained in:
Christopher-Zeng
2020-11-04 09:49:02 -05:00
parent f680b201e8
commit e351915176
3 changed files with 18 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/Overview.md
+6 -6
View File
@@ -1,8 +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). Bitcoin Cash utilizes the Proof-of-work timestamping scheme with SHA-256 hash function, and targets a 10-minute block time. It also utilized the secp256k1 parameters with ECDSA and Schnorr algorithm for digital signatures. The ticker symbol for Bitcoin Cash is BCH.<br>
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). Bitcoin Cash utilizes the Proof-of-work timestamping scheme with SHA-256 hash function, and targets a 10-minute block time. It also utilizes the secp256k1 parameters with ECDSA and Schnorr algorithm for digital signatures. The ticker symbol for Bitcoin Cash is BCH.
## Design
```mermaid
graph RL
@@ -48,11 +49,10 @@ graph RL
Hash3 --> Hash23
```
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.<br>
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.
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. Due to the characteristics of hash functions, the content of any block cannot be altered without changes to all its subsequent blocks. The time and computation intensity of such change is near impossible. Therefore, the transaction history in the blockchain can be considered immutable even with public access.<br>
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. Due to the characteristics of hash functions, the content of any block cannot be altered without changes to all its subsequent blocks. The time and computation intensity of such change is near impossible. Therefore, the transaction history in the blockchain can be considered immutable even with public access.
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. <br>
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. The consensus of the blockchain is achieved through the proof-of-work mechanism, in which the chain with the most work is agreed on. <br>
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 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 results 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 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/blockchain/memory-pool.md
+3 -2
View File
@@ -4,11 +4,12 @@ The Bitcoin Cash memory pool, or mempool, is a staging area for valid Bitcoin Ca
Transactions in the mempool are usually treated as if they were in an imaginary block after the current highest block in the blockchain to apply relevant policies, such as double-spending prevention and maximum block size. Transactions in the mempool may also be tracked with respect to chaining. Transaction chaining happens when one transaction spends the output of another transaction in the same block. In such cases, the transactions that provide the said output are typically referred to as parent transactions, and the ones spend the said output as child transactions. The tracking of transaction chaining is vital for nodes to remove any dependent transactions in the mempool in the event that their parent transactions are removed and thus invalidate such transactions. Nodes may also limit the maximum depth of transaction chaining due to computational complexity concerns. However, more recent development on Bitcoin Cash saw such limits increased or removed due to functionality concerns.
Although this rarely occurs, mempools may reach their maximum capacity set by the node and may decline incoming transactions from the network or remove existing transactions from the mempool under such occasions. The policies regarding such scenarios are at the discretion of each node.Apart from the capacity reasons, transactions that once were considered valid may still be declined from adding to the mempool or removed from the mempool for other reasons.
Although this rarely occurs, mempools may reach their maximum capacity set by the node and may decline incoming transactions from the network or remove existing transactions from the mempool under such occasions. The policies regarding such scenarios are at the discretion of each node. Apart from the capacity reasons, transactions that once were considered valid may still be declined from adding to the mempool or removed from the mempool for other reasons.
## Declination of transactions to the mempool
Valid transactions may be declined by the node to enter the mempool for several typical reasons.
1. Transactions may be declined 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.
2. Transactions that double spend inputs of another transaction already in the mempool will be declined.
3. Non-standard transactions are often declined.
@@ -16,7 +17,7 @@ Valid transactions may be declined by the node to enter the mempool for several
## Removal of transactions from the mempool
Under few rare circumstances, transactions that are already admitted to the mempool may be removed without being mined into the blockchain.
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/spv.md
+2 -2
View File
@@ -8,10 +8,10 @@ The validity of transactions can not only be verified through checking the trans
## 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.
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. 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.
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.