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

wiki commit

Browse Source
This commit is contained in:
1HXb9KMAtwNJqz4egi6hJx08EQgJajiBTH
2020-01-02 15:12:53 -05:00
committed by buwiki
parent 158c5ef968
commit 8294c17c71
2 changed files with 10 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/blockchain/proof-of-work.md
+6 -2
View File
@@ -1,7 +1,7 @@
# Proof of Work # Proof of Work
Bitcoin Cash uses a [hashcash](https://en.wikipedia.org/wiki/Hashcash)-like algorithm as a primary metric for validating new blocks. Bitcoin Cash uses a [hashcash](https://en.wikipedia.org/wiki/Hashcash)-like algorithm as a primary metric for validating new blocks.
The [block header](/protocol/blockchain/block/block-header) is hashed, its nonce is changed, and it is hashed again, until the resulting hash begins with an expected number of zero-bits. The [block header](/protocol/blockchain/block/block-header) is hashed, its nonce is changed, and it is hashed again, until the resulting hash begins with an expected number of zero-bits or, more precisely, is below a certain [target difficulty](#target-difficulty).
This repeated hashing with an updated nonce is referred to as mining. This repeated hashing with an updated nonce is referred to as mining.
For more information on how the number of zero-bits required is determined, see [Difficulty Adjustment Algorithm](/protocol/blockchain/proof-of-work/difficulty-adjustment-algorithm). For more information on how the number of zero-bits required is determined, see [Difficulty Adjustment Algorithm](/protocol/blockchain/proof-of-work/difficulty-adjustment-algorithm).
For more information on how mining is performed in practice, see [Mining](/protocol/blockchain/proof-of-work/mining). For more information on how mining is performed in practice, see [Mining](/protocol/blockchain/proof-of-work/mining).
@@ -14,6 +14,10 @@ Because SHA-256 is used to hash block headers, and it is not known how to find a
This is only quasi-random because the likelihood of building a block with an appropriate hash is directly proportional to the computational power (often referred to as hashing power), available to each individual mining blocks. This is only quasi-random because the likelihood of building a block with an appropriate hash is directly proportional to the computational power (often referred to as hashing power), available to each individual mining blocks.
## Target Difficulty
## Extra Nonce ## Extra Nonce
Ideally in such a proof-of-work system, the dynamic parameters of the data being hashed (i.e. the block header) would provide enough variability to guarantee any possible output of the hash function used. Ideally in such a proof-of-work system, the dynamic parameters of the data being hashed (i.e. the block header) would provide enough variability to guarantee any possible output of the hash function used.
@@ -22,5 +26,5 @@ As a result, there was a need for additional data to be varied.
The only other parameter of the block header that a miner has any power over is the merkle root. The only other parameter of the block header that a miner has any power over is the merkle root.
In order to change the merkle root, the transactions in the block would need to be changed. In order to change the merkle root, the transactions in the block would need to be changed.
But since the [coinbase transaction](/protocol/blockchain/block#Coinbase%20Transaction) is already created by the miner of the block, and updating its hash would allow for efficient re-calculation of the merkle root, putting this "extra nonce" in the coinbase transaction was the logical conclusion. But since the [coinbase transaction](/protocol/blockchain/block#coinbase-transaction) is already created by the miner of the block, and updating its hash would allow for efficient re-calculation of the merkle root, putting this "extra nonce" in the coinbase transaction was the logical conclusion.
Ultimately, the extra nonce is included as a part of the coinbase message, usually following the block height that is required to be first. Ultimately, the extra nonce is included as a part of the coinbase message, usually following the block height that is required to be first.
protocol/blockchain/transaction-validation/network-level-validation-rules.md
+4 -4
View File
@@ -9,13 +9,13 @@ Custom transactions are defined as those which are not considered standard.
Standard transactions are those that: Standard transactions are those that:
- Only have outputs that use [standard locking scripts](/protocol/blockchain/transaction/locking-script#Standard%20Scripts) - Only have outputs that use [standard locking scripts](/protocol/blockchain/transaction/locking-script#standard-scripts)
- Are below the maximum transaction size of 100,000 bytes - Are below the maximum transaction size of 100,000 bytes
- Have a valid version number (currently only version 2 is valid) - Have a valid version number (currently only version 2 is valid)
- Have input scripts that only contain push operations - Have input scripts that only contain push operations
- Have input scripts with unlocking scripts below the 1650 byte maximum - Have input scripts with unlocking scripts below the 1650 byte maximum
- Have at most one [data output](/protocol/blockchain/transaction/locking-script#Data%20Output) - Have at most one [data output](/protocol/blockchain/transaction/locking-script#data-output)
- For [multisig](/protocol/blockchain/transaction/locking-script#Multisig) outputs, must have at most 3 parties and at least 1 required party (i.e. 1-of-1 through 3-of-3). - For [multisig](/protocol/blockchain/transaction/locking-script#multisig) outputs, must have at most 3 parties and at least 1 required party (i.e. 1-of-1 through 3-of-3).
- Have non-data outputs with amount above the [dust](#dust) threshold - Have non-data outputs with amount above the [dust](#dust) threshold
Be aware, however, that these rules may vary from node-to-node as they are often configurable. Be aware, however, that these rules may vary from node-to-node as they are often configurable.
@@ -68,4 +68,4 @@ Bitcoin Verde performs a similar calculation to Bitcoin ABC but with two differe
This is accompanied by the comment: This is accompanied by the comment:
> For the common default _satoshisPerByteFee (1), the dust threshold is 546 satoshis. > For the common default _satoshisPerByteFee (1), the dust threshold is 546 satoshis.