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

wiki commit

Browse Source
This commit is contained in:
AndrewStone
2020-11-04 13:23:02 -05:00
committed by buwiki
parent 7cb8fa7a00
commit f1fb956302
46 changed files with 611 additions and 350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/blockchain/block.md
-6
View File
@@ -40,9 +40,3 @@ This requirement was added with version 2 blocks as a part of [BIP-34](/protocol
Each coinbase transaction may only have one transaction input.
Each coinbase transaction's unlocking script must be less than or equal to 100 bytes.
## Block Size
The maximum block size for blocks is 32MB (32 * 1000 * 1000 bytes).
The maximum number of transactions within a block is a function of this limit divided by the minimum transaction size, of 100 bytes.
Other rules limit the number of transactions that may be within a block, including the number of signature operations ("sigops") within a block.
protocol/blockchain/chainwork-proof.md
+2 -2
View File
@@ -2,7 +2,7 @@
The idea of chainwork is intrinsic to blockchains. Nodes switch to the chain tip with the most cumulative "work" to help preserve the blockchain assumption that the majority of the miners on a chain are honest. Chainwork is calculated by summing the "work" done in each block in the chain.
Is summing work a valid operation?
Is summing work a valid operation?
More formally, *is the expected number of hashes to solve one block candidate with work W is equal to the expected number of hashes to solve N block candidates with work W/N?*
@@ -103,4 +103,4 @@ $$
$$
= work
$$
$$
protocol/blockchain/hash.md
+5 -6
View File
@@ -5,6 +5,7 @@ This specification does not explain what hashes are, nor the details of the spec
Instead, this page will focus on which hashing algorithms are used, where they are used, and why they are used there.
## SHA-256
[SHA-256](https://en.wikipedia.org/wiki/SHA-2) is widely used throughout the Bitcoin Cash protocol to identify blocks and transactions along with a variety of purposes in transaction scripts.
The most notable uses of SHA-256 are:
@@ -24,16 +25,14 @@ Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be
- `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
- `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
In contrast to many other protocols, Bitcoin Cash sometimes treats block and transaction hashes as a number, for example when comparing with block difficulty during block validation or mining.
In these situations, the output byte array of the hashing algorithm is interpreted as a 256 bit number in little-endian format, particularly when transmitted over the network.
This is the opposite of standard protocol design, so it may be simpler to think of hashes as byte arrays that occasionally are turned into little-endian numbers, than as numbers with a lot of display/encoding caveats.
## RIPEMD-160
[RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.
Since its brevity is also a potential liability for the anonymity it provides (since shorter hashes generally provide less collision-resistance), it is used in conjunction with SHA-256 when generating an address from a public key.
That is, `(public key) -> SHA-256 -> RIPEMD-160 -> (address)`.
This SHA-256 then RIPEMD-160 process has its own operation for ease-of-use, [OP_HASH160](/protocol/blockchain/script/op-codes/op-hash160).
## Murmur
## Murmur
[MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter).
The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer.
The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer.
protocol/blockchain/proof-of-work.md
+3 -14
View File
@@ -22,25 +22,14 @@ For more details on how the target is calculated, see [Difficulty Adjustment Alg
## Difficulty
Though the term difficulty is often used colloquially to refer generally to the changes to the target as blocks are mined, it can also refer specifically to the integer value of one target divided by another.
Generally, the numerator is a base target, e.g. the [genesis block](/protocol/blockchain#genesis-block) target, while the denominator is the target of the block whose "difficulty" is to be calculated.
This results in two benefits relative to using targets directly:
Though the term difficulty is often used colloquially to refer generally to the changes to the target as blocks are mined, it can also refer specifically to the integer value of one target divided by another. Generally, the numerator is a base target, e.g. the [genesis block](/protocol/blockchain#genesis-block) target, while the denominator is the target of the block whose "difficulty" is to be calculated. This results in two benefits relative to using targets directly:
- **More Intuitive:** Higher numbers mean the block required more hashing power to mine, while lower number mean less hashing power was required. Increased difficulty is easier to understand than decreased target, even though these means the same thing.
- **More Manageable:** The difficulty calculation produces much more human-readable numbers than trying to interpret targets as an integer directory.
## Chainwork
Chainwork is a representation of the work performed through a block's entire history.
It is the [expected](https://en.wikipedia.org/wiki/Expected_value) number of hashes required to re-solve every block in the chain.
It is calculated using the difficulties of each of the blocks in the chain.
The work for a single block is calculated as <code>2<sup>256</sup> / (target + 1)</code>, or equivalently in 256-bit two's-complement arithmetic, <code>(~target / (target + 1)) + 1</code>, where `~` is the bitwise NOT operation.
The chainwork for a block is the sum of its work with the work of all the blocks preceeding it.
As such, when a new block is mined, its chainwork is simply its work plus the chainwork of the block before it.
This algorithm implies that summing chainwork makes sense.
More formally, the expected number of hashes to solve one block candidate with work `W` is equal to the expected number of hashes to solve `N` block candidates with work `W/N`.
This, and that chainwork is the expected number of hashes, is proved [here](/protocol/blockchain/chainwork-proof).
Chainwork is a representation of the work performed through a block's entire history. It is calculated using the difficulties of each of the blocks in the chain. The work for a single block is calculated as <code>2<sup>256</sup> / (target + 1)</code>, or equivalently in 256-bit two's-complement arithmetic, <code>(~target / (target + 1)) + 1</code>, where `~` is the bitwise NOT operation. The chainwork for a block is the sum of its work with the work of all the blocks preceeding it. As such, when a new block is mined, its chainwork is simply its work plus the chainwork of the block before it.
## Extra Nonce
@@ -51,4 +40,4 @@ 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.
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-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/proof-of-work/mining.md
+2 -4
View File
@@ -6,8 +6,7 @@ Primarily, the `nonce` field is modified and can take any of its 2<sup>32</sup>
Then, as needed, the merkle root is changed by modifying the [coinbase message](/protocol/blockchain/block#coinbase-transaction) to include an [extra nonce](/protocol/blockchain/proof-of-work#extra-nonce).
In addition, the block timestamp is also updated occasionally to ensure that it remains reasonably current.
As the two nonces are rapidly and systematically changed, and the resulting block hash rapidly changes to seemingly random values each time, there is an increasing likelihood that one of the hashes will be below the specified target.
Once such a hash is found, the block is then broadcast to the network in hopes that no one else found a suitable block in the passing time.
As the two nonces are rapidly and systematically changed, and the resulting block hash rapidly changes to seemingly random values each time, there is an increasing likelihood that one of the hashes will be below the specified target. Once such a hash is found, the block is then broadcast to the network in hopes that no one else found a suitable block in the passing time.
## Types of Mining
@@ -15,5 +14,4 @@ Due to the various incentives for mining blocks, miners have employed a variety
- **CPU Mining:** This was the initial approach, simply running the mining algorithm on a computer's processor, ideally multi-threaded so that for a CPU with N-cores (or [threads](https://en.wikipedia.org/wiki/Simultaneous_multithreading)), N candidate blocks could be hashed at a time, improving the throughput.
- **[GPU](https://en.wikipedia.org/wiki/Graphics_processing_unit) Mining:** Since GPUs are particularly well-suited to parallel-processing, the use of GPUs allowed for significantly increased hashing power and, for a time, heavily increased the demand for high-end graphics cards.
- **[ASIC](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) Mining:** Ultimately, purpose-built devices were created to perform mining as fast as physically possible.
These devices rapidly consume power and produce a considerable amount of heat and the people that run then often seek out the lowest available power prices and invest in cooling solutions that keep their mining devices (often just referred to as "miners") running at peek performance.
- **[ASIC](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) Mining:** Ultimately, purpose-built devices were created to perform mining as fast as physically possible. These devices rapidly consume power and produce a considerable amount of heat and the people that run then often seek out the lowest available power prices and invest in cooling solutions that keep their mining devices (often just referred to as "miners") running at peek performance.
protocol/blockchain/script.md
+10 -10
View File
@@ -84,13 +84,13 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
| OP_TOALTSTACK | 107 | 0x6b | x1 | (alt) x1 | Puts the input onto the top of the alt stack. Removes it from the main stack. |
| OP_FROMALTSTACK | 108 | 0x6c | (alt) x1 | x1 | Puts the input onto the top of the main stack. Removes it from the alt stack. |
| OP_IFDUP | 115 | 0x73 | x | x / x x | If the top stack value is not 0, duplicate it. |
| OP_DEPTH | 116 | 0x74 | Nothing | &lt;stack size&gt; | Puts the number of stack items onto the stack. |
| OP_DEPTH | 116 | 0x74 | Nothing | <stack size> | Puts the number of stack items onto the stack. |
| OP_DROP | 117 | 0x75 | x | Nothing | Removes the top stack item. |
| OP_DUP | 118 | 0x76 | x | x x | Duplicates the top stack item. |
| OP_NIP | 119 | 0x77 | x1 x2 | x2 | Removes the second-to-top stack item. |
| OP_OVER | 120 | 0x78 | x1 x2 | x1 x2 x1 | Copies the second-to-top stack item to the top. |
| OP_PICK | 121 | 0x79 | xn ... x2 x1 x0 n | xn ... x2 x1 x0 xn | The item *n* back in the stack is copied to the top. |
| OP_ROLL | 122 | 0x7a | xn ... x2 x1 x0 n | x(n-1) ... x2 x1 x0 xn | The item *n* back in the stack is moved to the top. |
| OP_PICK | 121 | 0x79 | xn ... x2 x1 x0 <n> | xn ... x2 x1 x0 xn | The item *n* back in the stack is copied to the top. |
| OP_ROLL | 122 | 0x7a | xn ... x2 x1 x0 <n> | x(n-1) ... x2 x1 x0 xn | The item *n* back in the stack is moved to the top. |
| OP_ROT | 123 | 0x7b | x1 x2 x3 | x2 x3 x1 | The top three items on the stack are rotated to the left. |
| OP_SWAP | 124 | 0x7c | x1 x2 | x2 x1 | The top two items on the stack are swapped. |
| OP_TUCK | 125 | 0x7d | x1 x2 | x2 x1 x2 | The item at the top of the stack is copied and inserted below the second-to-top item. |
@@ -110,7 +110,6 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
|OP_NUM2BIN |128 |0x80|a b |out |Converts numeric value *a* into byte sequence of length *b*. Known as OP_LEFT before 2018-05-15. |
|OP_BIN2NUM |129 |0x81|x |out |Converts byte sequence *x* into a numeric value. Known as OP_RIGHT before 2018-05-15. |
|OP_SIZE |130 |0x82|x |x size |Pushes the string length of the top element of the stack (without popping it). |
|OP_REVERSEBYTES |188 |0xbc |x |out |Reverses the order of the bytes in byte sequence *x* so that the first byte is now its last byte, the second is now its second-to-last, and so forth. Enabled in [HF-20200515](/protocol/forks/hf-20200515). |
### Bitwise logic
@@ -167,17 +166,17 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
| OP_CODESEPARATOR | 171 | 0xab | Nothing | Nothing | Makes `OP_CHECK(MULTI)SIG(VERIFY)` use the subset of the script of everything after the most recently-executed OP_CODESEPARATOR when computing the sighash. |
| OP_CHECKSIG | 172 | 0xac | sig pubkey | true / false | The last byte (=sighash type) of the signature is removed. The sighash for this input is calculated based on the sighash type. The truncated signature used by OP_CHECKSIG must be a valid ECDSA or Schnorr signature for this hash and public key. If it is valid, 1 is returned, if it is empty, 0 is returned, otherwise the operation fails. |
| OP_CHECKSIGVERIFY | 173 | 0xad | sig pubkey | Nothing / *fail* | Same as OP_CHECKSIG, but OP_VERIFY is executed afterward. |
| OP_CHECKMULTISIG | 174 | 0xae | dummy sig1 sig2 ... &lt;#-of-sigs&gt; pub1 pub2 ... &lt;#-of-pubkeys&gt; | true / false | Signatures are checked against public keys. Signatures must be placed in the unlocking script using the same order as their corresponding public keys were placed in the locking script or redeem script. If all signatures are valid, 1 is returned, 0 otherwise. All elements are removed from the stack. For more information on the execution of this opcode, see [Multisignature](/protocol/blockchain/cryptography/multisignature). |
| OP_CHECKMULTISIGVERIFY | 175 | 0xaf | dummy sig1 sig2 ... &lt;#-of-sigs&gt; pub1 pub2 ... &lt;#-of-pubkeys&gt; | Nothing / *fail* | Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward. |
| OP_CHECKMULTISIG | 174 | 0xae | dummy sig1 sig2 ... <# of sigs> pub1 pub2 ... <# of pubkeys> | true / false | Signatures are checked against public keys. Signatures must be placed in the unlocking script using the same order as their corresponding public keys were placed in the locking script or redeem script. If all signatures are valid, 1 is returned, 0 otherwise. All elements are removed from the stack. For more information on the execution of this opcode, see [Multisignature](/protocol/blockchain/cryptography/multisignature). |
| OP_CHECKMULTISIGVERIFY | 175 | 0xaf | dummy sig1 sig2 ... <# of sigs> pub1 pub2 ... <# of pubkeys> | Nothing / *fail* | Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward. |
| OP_CHECKDATASIG | 186 | 0xba | sig msg pubkey | true / false | Check if signature is valid for message and a public key. [See spec](/protocol/forks/op_checkdatasig) |
| OP_CHECKDATASIGVERIFY | 187 | 0xbb | sig msg pubkey | nothing / *fail* | Same as OP_CHECKDATASIG, but runs OP_VERIFY afterward. |
| OP_CHECKDATASIGVERIFY | 187 | 0xbb | sig msg pubkey | nothing / *fail* | Same as OP_CHECKDATASIG, but runs OP_VERIFY afterward. |
### Locktime
| Word | Value | Hex | Input |Output | Description |
| ---------------------- | ------- | --------- | ----- | --------- | ----------------------------------------------- |
| OP_CHECKLOCKTIMEVERIFY | 177 | 0xb1 | x |x / *fail* | Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [BIP65](/protocol/forks/bip-0065). |
| OP_CHECKSEQUENCEVERIFY | 178 | 0xb2 | x |x / *fail* | Marks transaction as invalid if the relative lock time of the input (enforced by BIP68 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [BIP112](/protocol/forks/bip-0112). |
| OP_CHECKLOCKTIMEVERIFY | 177 | 0xb1 | x |x / *fail* | Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in BIP65. |
| OP_CHECKSEQUENCEVERIFY | 178 | 0xb2 | x |x / *fail* | Marks transaction as invalid if the relative lock time of the input (enforced by BIP68 with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in BIP112. |
### Reserved
@@ -188,7 +187,7 @@ Op codes marked with **(do not use)** are disallowed and will make a transaction
### Uncategorized
Please help improve this article by categorizing and describing the following op codes.
Please help improve this article by catigorizing and describing the following up codes.
| Hex | Word |
| ---- | ---- |
@@ -198,6 +197,7 @@ Please help improve this article by categorizing and describing the following op
| 0x66 | OP_VERNOTIF **(do not use)** |
| 0x89 | OP_RESERVED1 **(do not use)** |
| 0x8A | OP_RESERVED2 **(do not use)** |
| 0xBC | OP_REVERSEBYTES **(disabled)** |
| 0xBD - 0xFF | Unused **(disabled)** |
### Node-Specific Behavior
protocol/blockchain/transaction-validation.md
-1
View File
@@ -25,4 +25,3 @@ Furthermore, this coinbase's output is not considered an unspent transaction out
Coinbases may only have one transaction input.
All coinbase unlocking script must be less than or equal to 100 bytes in size.
protocol/blockchain/transaction.md
+4 -4
View File
@@ -15,10 +15,10 @@ Verification of a transaction ensures that:
|--|--|--|--|
| version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The version of the transaction format. Currently `0x02000000`. |
| input count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of inputs in the transaction. |
| transaction inputs | variable | `input_count` [transaction inputs](#transaction-inputs) | Each of the transaction's inputs serialized in order. |
| transaction inputs | variable | `input count` [transaction inputs](#transaction-inputs) | Each of the transaction's inputs serialized in order. |
| output count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of output in the transaction. |
| transaction outputs | variable | `output_count` [transaction outputs](#transaction-outputs) | Each of the transaction's outputs serialized in order. |
| lock-time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The block height or timestamp after which this transaction is allowed to be included in a block. If less than `500,000,000`, this is interpreted as a block height. If equal or greater than `500,000,000`, this is interpreted as a unix timestamp in seconds. Ignored if all of the transaction input sequence numbers are `0xFFFFFFFF`.<br/><br/>Note that at 10 minutes per block, it will take over 9,500 years to reach block height 500,000,000. Also note that when Bitcoin was created the unix timestamp was well over 1,000,000,000.<br/><br/>Additionally, since [BIP-113](/protocol/forks/bip-0113), when the lock-time is intepreted as a time, it is compared to the [median-time-past](#median-time-past) of a block, not it's timestamp. |
| transaction outputs | variable | `output count` [transaction outputs](#transaction-outputs) | Each of the transaction's outputs serialized in order. |
| lock-time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The block height or timestamp after which this transaction is allowed to be included in a block. If less than `500,000,000`, this is interpreted as a block height. If more than `500,000,000`, this is interpreted as a unix timestamp in seconds. Ignored if all of the transaction input sequence numbers are `0xFFFFFFFF`.<br/><br/>Note that at 10 minutes per block, it will take over 9,500 years to reach block height 500,000,000. Also note that when Bitcoin was created the unix timestamp was well over 1,000,000,000.<br/><br/>Additionally, since [BIP-113](/protocol/forks/bip-0113), when the lock-time is intepreted as a time, it is compared to the [median-time-past](#median-time-past) of a block, not it's timestamp. |
### Median-Time-Past
@@ -74,7 +74,7 @@ A Transaction Output that is being spent by a Transaction Input is often referre
| Field | Length | Format | Description |
|--|--|--|--|
| value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the locking script in bytes. |
| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the unlocking script in bytes. |
| locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
## Transaction Fee
protocol/blockchain/transaction/transaction-signing.md
+46 -111
View File
@@ -1,130 +1,65 @@
# Transaction Signing
# Transaction Signatures
Generally, every input of a [transaction](/protocol/blockchain/transaction) require one or more signature. The signatures enforce (sign) what the transaction looks like and make it impossible for a third party to temper with without invalidating the transaction.
Transaction signatures are central to how [Bitcoin Cash transactions](/protocol/blockchain/transaction) are generally secured, preventing people other than the intended recipient of funds from spending them. Bitcoin Cash signatures are created using [asymmetric cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) and involve generating a [hash](/protocol/blockchain/hash) of the transaction and performing a signature operation using the sender's private key. Anyone with the corresponding public key can then verify the validity of the signature. As described in [Standard Scripts](/protocol/blockchain/transaction/locking-script#standard-scripts), the [OP_CHECKSIG and related operations](/protocol/blockchain/script#cryptography) are used to validate signatures included in the unlocking script of a future transaction input.
This applies to any input whose previous output [locking script](/protocol/blockchain/transaction/locking-script) includes one of the following [operation codes](/protocol/blockchain/script#operation-codes-opcodes): `OP_CHECKSIG`, `OP_CHECKSIGVERIFY`, `OP_CHECKMULTISIG`, `OP_CHECKMULTISIGVERIFY`. In scripts using these opcodes, *signatures* are checked against *public keys* and the transaction signature (as described below).
However, there are a number of issues with signing a transaction that must be addressed:
The `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` opcodes require a sigle signature which is checked against a single public key:
1. Transactions are identified by hashes of the full contents of the transaction
2. The signatures are a part of the transaction data
3. The signatures are created from a hash of the transaction's data
```
<sig> <pubkey> CHECKSIG(VERIFY)
```
Points (1) and (2) mean that if the signature is changed, the transaction's hash will change. Points (2) and (3) mean that the data that the signature hash preimage (i.e. the data that is hashed and signed) must not be the full transaction data. In addition, because signatures relate only to a single input to a transaction (i.e. spending an unspent transaction output or UTXO) the may be multiple signatures in a transaction potentially created by different private keys, or even different people.
For `OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` behavior, see [Multisignature spec](/protocol/blockchain/cryptography/multisignature).
As a consequence of these factors, signatures have more parameters than may be immediately obvious, and the details of how signatures are generated can be, and have been, changed in a number of ways. These parameters are encoded in the [Hash Type](#hash-type).
In addition, as a part of [BCH-UAHF](/protocol/forks/bch-uahf) (activated in block 478,559), the transaction signed format changed from the legacy [Bitcoin (BTC) method](#btc-signatures) to the [Bitcoin Cash (BCH) Signatures](#bch-signatures). In both cases, there is a signature preimage format (input) and a signature format (output).
### Hash Type
Parameters that change the way a signature hash is generated are encoded in the hash type field.
This field (which is always included in the preimage), is contained in 4 bytes.
The two least significant bits have the following collective meaning:
| Value | Meaning |
|--|--|
| `0x01` | `SIGHASH_ALL`. This is the default and indicates that all outputs are included in the signature preimage. |
| `0x02` | `SIGHASH_NONE`. Indicates that no outputs are included in the signature preimage. |
| `0x03` | `SIGHASH_SINGLE`. Indicates that only the output with the same index as the input the signature is being generated for will be included in the signature preimage. |
In conjunction with the above values, the higher-order bits act as a bitmask with the following meaning:
| Bit | Meaning |
|--|--|
| `0x00000040` | `SIGHASH_FORKID`. If set, indicates that this signature is for a Bitcoin Cash transaction. Required following BCH-UAHF, to prevent transactions from being valid on both the BTC and BCH chains. |
| `0x00000080` | `SIGHASH_ANYONECANPAY`. Indicates that only information about the input the signature is for will be included, allowing other inputs to be added without impacting the signature for the current input. |
Combining these, there are 6 valid signature hash types in Bitcoin Cash. Only the least significant byte (LSB) is shown in binary, since the rest of the bits are zero.
| Signature hash type | Value (hex) | LSB (bin) | Description |
| -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- |
| SIGHASH_ALL \| SIGHASH_FORKID | 0x00000041 | 0b01000001 | Signature applies to all inputs and outputs. |
| SIGHASH_NONE \| SIGHASH_FORKID | 0x00000042 | 0b01000010 | Signature applies to all inputs and none of the outputs. |
| SIGHASH_SINGLE \| SIGHASH_FORKID | 0x00000043 | 0b01000011 | Signature applies to all inputs and the output with the same index. |
| SIGHASH_ALL \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C1 | 0b11000001 | Signature applies to its own input and all outputs. |
| SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C2 | 0b11000010 | Signature applies to its own input and none of the outputs. |
| SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C3 | 0b11000011 | Signature applies to its own input and the output with the same index.|
## BCH Signatures
## Transaction Digest Algorithm (Preimage Format)
In Bitcoin Cash, transaction signature uses the transaction digest algorithm described in [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), in order to minimize redundant data hashing in verification and to cover the input value by the signature.
### Preimage Format
Since it is impossible to sign signatures themselves, it is necessary to have a *preimage* which represents the transaction without signatures. Therefore, a preimage must be built for any input which requires a transaction signature.
| Field | Length | Format | Description |
|--|--|--|--|
| transaction version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of transaction's version field. |
| previous outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of previous outputs spent by the inputs of the transaction. See [Previous Outputs](#previous-outputs-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes. |
| sequence numbers hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of sequence numbers of the inputs of the transaction. See [Sequence Numbers](#sequence-numbers-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONE CAN PAY" then this is all `0x00` bytes. |
| previous output hash | 32 bytes | hash<sup>[(LE)](/protocol/misc/endian/little)</sup> | The transaction ID of the previous output being spent. |
| previous output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent. |
| modified locking script length | variable | [variable length integer](/protocol/format/variable-length-integer) | The number of bytes for `modified_locking_script`. |
| modified locking script | `modified_locking_script_length` bytes | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The subset of the locking script used for signing. See [Modified Locking Script](#modified-locking-script) |
| previous output value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of the transaction output being spent. |
| input sequence number | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number of the input this signature is for. |
| transaction outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the outputs of the transaction. See [Transaction Outputs](#transaction-outputs-hash) for the hash preimage format. |
| transaction lock time | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The lock time of the transaction. |
| hash type | 4 bytes | [Hash Type](#hash-type)<sup>[(LE)](/protocol/misc/endian/little)</sup> | Flags indicating the rules for how this signature was generated. |
The preimage consists of the following elements:
#### Previous Outputs Hash
| Field | Length | Format | Description |
| ----------------------------------- | -------- | -------------------------------------------------------------------- | ----------------------------------------------------------- |
| version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The version of the transaction format. Currently `1` or `2`. |
| previous outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | The double SHA256 of the serialization of **all** input outpoints (txids + indexes) of the transaction. If the `SIGHASH_ANYONECANPAY` flag is set, it is `0x00...00`. |
| sequences hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | The double SHA256 of the serialization of **all** input sequences of the transaction. If `SIGHASH_ANYONECANPAY`, `SIGHASH_SINGLE` or `SIGHASH_NONE` is used, this field is `0x00...00`. |
| previous output transaction id | 32 bytes | hash<sup>[(LE)](/protocol/misc/endian/big)</sup> | The identifier of the transaction containing the previous output, i.e., the output spent by this input. |
| previous output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the previous output inside the transaction. |
| previous output locking script size | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the previous locking script in bytes. |
| previous output locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The locking script of the output spent by this input. If the previous output is a P2SH output, then this field must be the redeem script. |
| previous output value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value in satoshis of the output spent by this input. |
| sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number of this input. |
| outputs hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | The double SHA256 of the serialization of **all** output values and locking scripts (including size) of the transaction. If `SIGHASH_SINGLE` is used: if this input index is smaller than the number of outputs, this field is the double SHA256 of the output value and locking script of the same index as the input; otherwise it is `0x00...00`. If `SIGHASH_NONE` is used, this field is `0x00...00`. |
| locktime | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The locktime of the transaction. |
| signature hash type | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The signature hash type used to sign this input. See description below. |
The double-SHA256-hash of the following data is used.
The signing algorithm (whether it is ECDSA or Schnorr algorithm) is applied to **the double SHA256 hash of this preimage**.
For each transaction input in the transaction, append the following information:
## Signature Hash Type
| Field | Length | Format | Description |
|--|--|--|--|
| previous transaction hash | 32 bytes | bytes<sup>[(LE)](/protocol/misc/endian/little)</sup> | The hash of the transaction that generated the output to be spent. |
| output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent from the specified transaction. |
A signature (ECDSA or Schnorr) is ALWAYS followed by the signature hash type used to sign the input. Signature hash type indicates which part of the transaction is hashed to be signed.
#### Sequence Numbers Hash
Version and locktime are always signed. All inputs are included unless the `SIGHASH_ANYONECANPAY` flag is set.
The double-SHA256-hash of the following data is used.
The signature hash flags are:
For each transaction input in the transaction, append the following information:
| Flag | Value (hex) | Value (bin) | Description |
| -------------------- | ----------- | ----------- | ---------------------------------------- |
| SIGHASH_ALL | 0x01 | 0b00000001 | Sign all outputs. |
| SIGHASH_NONE | 0x02 | 0b00000010 | Sign none of the outputs. |
| SIGHASH_SINGLE | 0x03 | 0b00000011 | Sign only the ouput with the same index. |
| SIGHASH_ANYONECANPAY | 0x80 | 0b10000000 | Sign only its own input. |
| SIGHASH_FORKID | 0x40 | 0b01000000 | Bitcoin Cash modifier flag. |
| Field | Length | Format | Description |
|--|--|--|--|
| sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number field of the transaction input. |
#### Modified Locking Script
The locking script included in the signature preimage is, first, dependent on the type of locking script included in the previous output. For non-[P2SH](/protocol/blockchain/transaction/locking-script#pay-to-script-hash-p2sh) outputs, the locking script itself is used. However, for P2SH outputs, the redeem script is used instead.
Second, the selected script (locking script or redeem script) is modified as follows.
* Find the [`OP_CODESEPARATOR`](/protocol/blockchain/script#cryptography) operation in the script preceding the expected [signature-verification operation](/protocol/blockchain/script#cryptography) (e.g. `OP_CHECKSIG`).
* Remove all operations before this point.
* Remove any remaining `OP_CODESEPARATOR` operations.
The resulting script is what is included in the signature preimage.
#### Transaction Outputs Hash
If the hash type is `SIGHASH_NONE` then the hash should be all `0x00` bytes.
If hash type is `SIGHASH_SINGLE` then only the output with the same index as the input being signed is included.
If no such output exists (i.e. there are fewer outputs than the index of the input to be signed), this is again all `0x00` bytes.
Otherwise, all outputs of the transaction should be signed (i.e. `SIGHASH_ALL`).
For each transaction output to be signed (per the hash mode), append the following information:
| Field | Length | Format | Description |
|--|--|--|--|
| value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
| locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the locking script in bytes. |
| locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
### Signature Format
## BTC Signatures
### Preimage Format
### Signature Format
Signature hash flags are combined using the bitwise OR operator (`|`) in order to get the **signature hash type** of the input. There are 6 valid signature hash types in Bitcoin Cash:
| Signature hash type | Value (hex) | Value (bin) | Description |
| -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- |
| SIGHASH_ALL \| SIGHASH_FORKID | 0x41 | 0b01000001 | Signature applies to all inputs and outputs. |
| SIGHASH_NONE \| SIGHASH_FORKID | 0x42 | 0b01000010 | Signature applies to all inputs and none of the outputs. |
| SIGHASH_SINGLE \| SIGHASH_FORKID | 0x43 | 0b01000011 | Signature applies to all inputs and the output with the same index. |
| SIGHASH_ALL \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc1 | 0b11000001 | Signature applies to its own input and all outputs. |
| SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc2 | 0b11000010 | Signature applies to its own input and none of the outputs. |
| SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0xc3 | 0b11000011 | Signature applies to its own input and the output with the same index.|
protocol/blockchain/transaction/unlocking-script.md
+1 -1
View File
@@ -5,4 +5,4 @@ This is accomplished by first executing the unlocking script and then executing
If this execution triggers no failures and leaves a single non-zero (TRUE) value on the stack, the UTXO has been successfully unlocked.
One way to look at this is that the unlocking script provides an initial state that acts as an inverse to the previously published locking script.
For more information about how script execution works, see [Script](/protocol/blockchain/script). For information on how signatures (which typically go in the unlocking script) are generated, see [Transaction Signatures](/protocol/blockchain/transaction/signatures).
For more information about how script execution works, see [Script](/protocol/blockchain/script).