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

Merge verde/master into master

Browse Source
This commit is contained in:
TomZ
2024-09-05 20:40:59 +02:00
parent 44d179cc55 101847d976
commit 7059d1e45d
7 changed files with 76 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
home.md
-1
View File
@@ -29,7 +29,6 @@
### Network upgrades ### Network upgrades
#### Pre-BCH #### Pre-BCH
| Year (Creation) | BIPs | | Year (Creation) | BIPs |
|------|-------| |------|-------|
| 2012 | [Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [BIP-35](/protocol/forks/bip-0035) — [Bip-37](/protocol/forks/bip-0037) | | 2012 | [Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [BIP-35](/protocol/forks/bip-0035) — [Bip-37](/protocol/forks/bip-0037) |
protocol/blockchain/transaction/transaction-signing.md
+68 -21
View File
@@ -13,13 +13,15 @@ However, there are a number of issues with signing a transaction that must be ad
Points (1) and (2) mean that if the signature is changed, the transaction's hash will change. 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. 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. In addition, because signatures relate only to a single input to a transaction (i.e. spending an unspent transaction output or UTXO) there may be multiple signatures in a transaction potentially created by different private keys, or even different people.
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. 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). 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 Core (BTC) method](#bitcoin-core-signatures) to the [Bitcoin Cash (BCH) Signatures](#bitcoin-cash-signatures). In both cases, there is a signature preimage format (input) and a signature format (output). 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 Core (BTC) method](#bitcoin-core-signatures) to the [Bitcoin Cash (BCH) Signatures](#bitcoin-cash-signatures). In both cases, there is a signature preimage format (input) and a signature format (output).
With [HF-20230515](/protocol/forks/hf-20230515) protocol upgrade, the signature preimage format was extended to include spent and new outputs's token data, and a new hash type `SIGHASH_UTXOS` was introduced so signatures can commit to whole input's prevouts.
### Hash Type ### Hash Type
Parameters that change the way a signature hash is generated are encoded in the hash type field. Parameters that change the way a signature hash is generated are encoded in the hash type field.
@@ -36,19 +38,23 @@ In conjunction with the above values, the higher-order bits act as a bitmask wit
| Bit | Meaning | | Bit | Meaning |
|--|--| |--|--|
| `0x00000020` | `SIGHASH_UTXOS`. If set, the hash of whole UTXOs is inserted in the signing serialization algorithm immediately following hash of the previous outputs references. The hash is a 32-byte double SHA256 of the serialization of all referenced UTXOs, concatenated in input order, excluding output count. |
| `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. | | `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. | | `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. 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 | | Signature hash type | Value (hex) | LSB (bin) | Description |
| -------------------------------------------------------- | ----------- | ----------- | --------------------------------------------------------------------- | | -------------------------------------------------------- | ----------- | ---------- | ------------ |
| SIGHASH_ALL \| SIGHASH_FORKID | 0x00000041 | 0b01000001 | Signature applies to all inputs and outputs. | | 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_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_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_ALL \| SIGHASH_UTXOS \| SIGHASH_FORKID | 0x00000061 | 0b01100001 | Signature applies to all inputs and outputs. Signature preimage includes a hash of all referenced UTXOs. |
| SIGHASH_NONE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C2 | 0b11000010 | Signature applies to its own input and none of the outputs. | | SIGHASH_NONE \| SIGHASH_UTXOS \| SIGHASH_FORKID | 0x00000062 | 0b01100010 | Signature applies to all inputs and none of the outputs. Signature preimage includes a hash of all referenced UTXOs. |
| SIGHASH_SINGLE \| SIGHASH_ANYONECANPAY \| SIGHASH_FORKID | 0x000000C3 | 0b11000011 | Signature applies to its own input and the output with the same index.| | SIGHASH_SINGLE \| SIGHASH_UTXOS \| SIGHASH_FORKID | 0x00000063 | 0b01100011 | Signature applies to all inputs and the output with the same index. Signature preimage includes a hash of all referenced UTXOs. |
| 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. |
## Bitcoin Cash Signatures ## Bitcoin Cash Signatures
@@ -60,33 +66,37 @@ At a high level, the preimage format for a signature within a single input is a
1. Transaction version 1. Transaction version
2. Previous transaction outputs identifiers 2. Previous transaction outputs identifiers
3. Transaction input sequence numbers 3. If `SIGHASH_UTXOS` is set, whole content of all previous transaction outputs
4. The identifier of the output being spent 4. Transaction input sequence numbers
5. The locking script of the output being spent 5. The identifier of the output being spent
6. The value of the output being spent 6. Token content of the output being spent
7. The sequence number of the transaction input 7. The locking script of the output being spent
8. The created transaction outputs 8. The value of the output being spent
9. Transaction locktime 9. The sequence number of the transaction input being spent
10. The signature hash type 10. The created transaction outputs
11. Transaction locktime
12. The signature hash type
The following table specifies, in detail, the preimage format for a signature within a single input: The following table specifies, in detail, the preimage format for a signature within a single input:
| Field | Length | Format | Description | | Field | Length | Format | Description |
|--|--|--|--| |--|--|--|--|
| transaction version | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The value of transaction's version field. | | 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 "ANYONECANPAY" then this is all `0x00` bytes. | | previous outputs identifiers hash | 32 bytes | hash<sup>[(BE)](/protocol/misc/endian/big)</sup> | A double SHA-256 hash of the set of previous outputs identifiers (source transaction hash and output index) spent by the inputs of the transaction. See [Previous Outputs Identifiers](#previous-outputs-identifiers-hash) for the hash preimage format.<br/><br/>If hash type is "ANYONECANPAY" then this is all `0x00` bytes. |
| \[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. [Whole contents](../transaction#transaction-output) of the referenced outputs are concantenated and hashed. See [Previous Outputs](#previous-outputs-hash) for the hash preimage format.<br/><br/>If hash type doesn't have the "UTXOS" bit set, then this hash is omitted. |
| 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 "ANYONECANPAY", "SINGLE", or "NONE" 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 "ANYONECANPAY", "SINGLE", or "NONE" 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 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. | | previous output index | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The index of the output to be spent. |
| \[previous output token contents\] | \[variable\] | [token serialization](../transaction#token-output-format) | Previous output's token contents, including the PREFIX_TOKEN byte as the start. If the previous output doesn't have tokens then this is omitted. |
| modified locking script length | variable | [variable length integer](/protocol/format/variable-length-integer) | The number of bytes for `modified_locking_script`. | | 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) | | 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. | | 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. | | input sequence number | 4 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 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. | | 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. | | 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. |
#### Previous Outputs Hash #### Previous Outputs Identifiers Hash
The double-SHA256-hash of the following data is used. The double-SHA256-hash of the following data is used.
@@ -97,6 +107,24 @@ For each transaction input in the transaction, append the following information:
| 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. | | 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. | | 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. |
#### Previous Outputs Hash
The double-SHA256-hash of the following data is used.
For each transaction input in the transaction, 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. |
| \[token prefix and\] locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | If the output contains tokens then the combined size of full token prefix and the locking script in bytes, else just the locking script size in bytes. |
| \[PREFIX_TOKEN\] | 1 byte | constant | Magic byte defined at codepoint 0xef (239) and indicates the presence of a token prefix. |
| \[token category ID\] | 32 bytes | bytes | After the PREFIX_TOKEN byte, a 32-byte "token category ID" is required, encoded in OP_HASH256 byte order. |
| \[token bitfield\] | 1 byte | bitfield | A bitfield encoding two 4-bit fields is required. |
| \[NFT commitment length\] | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the NFT commitment in bytes. Present only if token bitfield bit 0x40 is set. |
| \[NFT commitment\] | variable | bytes | The contents of the NFT commitment. Present only if token bitfield bit 0x40 is set. |
| \[FT amount\] | variable | [variable length integer](/protocol/formats/variable-length-integer) | An amount of fungible tokens, present only if token bitfield bit `0x10` is set. |
| locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
#### Sequence Numbers Hash #### Sequence Numbers Hash
The double-SHA256-hash of the following data is used. The double-SHA256-hash of the following data is used.
@@ -107,6 +135,19 @@ For each transaction input in the transaction, append the following information:
|--|--|--|--| |--|--|--|--|
| sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number field of the transaction input. | | sequence number | 4 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The sequence number field of the transaction input. |
#### Token Contents
If the output being spent has tokens, append the following information:
| Field | Length | Format | Description |
|--|--|--|--|
| PREFIX_TOKEN | 1 byte | constant | Magic byte defined at codepoint 0xef (239) and indicates the presence of a token prefix. |
| token category ID | 32 bytes | bytes | After the PREFIX_TOKEN byte, a 32-byte "token category ID" is required, encoded in OP_HASH256 byte order. |
| token bitfield | 1 byte | bitfield | A bitfield encoding two 4-bit fields is required. |
| \[NFT commitment length\] | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the NFT commitment in bytes. Present only if token bitfield bit 0x40 is set. |
| \[NFT commitment\] | variable | bytes | The contents of the NFT commitment. Present only if token bitfield bit 0x40 is set. |
| \[FT amount\] | variable | [variable length integer](/protocol/formats/variable-length-integer) | An amount of fungible tokens, present only if token bitfield bit `0x10` is set. |
#### Modified Locking Script #### 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. The locking script included in the signature preimage is, first, dependent on the type of locking script included in the previous output.
@@ -136,7 +177,13 @@ For each transaction output to be signed (per the hash mode), append the followi
| Field | Length | Format | Description | | Field | Length | Format | Description |
|--|--|--|--| |--|--|--|--|
| value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. | | 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. | | \[token prefix and\] locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | If the output contains tokens then the combined size of full token prefix and the locking script in bytes, else just the locking script size in bytes. |
| \[PREFIX_TOKEN\] | 1 byte | constant | Magic byte defined at codepoint 0xef (239) and indicates the presence of a token prefix. |
| \[token category ID\] | 32 bytes | bytes | After the PREFIX_TOKEN byte, a 32-byte "token category ID" is required, encoded in OP_HASH256 byte order. |
| \[token bitfield\] | 1 byte | bitfield | A bitfield encoding two 4-bit fields is required. |
| \[NFT commitment length\] | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the NFT commitment in bytes. Present only if token bitfield bit 0x40 is set. |
| \[NFT commitment\] | variable | bytes | The contents of the NFT commitment. Present only if token bitfield bit 0x40 is set. |
| \[FT amount\] | variable | [variable length integer](/protocol/formats/variable-length-integer) | An amount of fungible tokens, present only if token bitfield bit `0x10` is set. |
| locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. | | locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
### Signature Format ### Signature Format
protocol/forks/bigint.md → protocol/forks/chips/2022-05-bigger-script-integers.md
View File
protocol/forks/native-introspection.md → protocol/forks/chips/2022-05-native-introspection-opcodes.md
View File
protocol/forks/hf-20201115.md
+1
View File
@@ -25,6 +25,7 @@ Bitcoin Cash's Difficulty Adjustment Algorithm (DAA) is replaced with a new algo
The specific implementation is called aserti3-2d. Details can be found in the [full specification: ASERT](/protocol/forks/2020-11-15-asert). The specific implementation is called aserti3-2d. Details can be found in the [full specification: ASERT](/protocol/forks/2020-11-15-asert).
## Automatic Replay Protection ## Automatic Replay Protection
The purpose of Automatic Replay Protection is to serve as a full node version-deprecation mechanism. It is intended to cause The purpose of Automatic Replay Protection is to serve as a full node version-deprecation mechanism. It is intended to cause
protocol/forks/hf-20220515.md
+4 -13
View File
@@ -1,19 +1,10 @@
# HF-20220515 # HF-20220515
The May 2022 protocol upgrade is to be comprised of [CHIPs](#chips). The May 2022 hard fork is the second upgrade to be comprised of [CHIPs](#chips).
## CHIPs
A CasH Improvement Proposal (CHIP) is a change request for the Bitcoin Cash protocol.
CHIPs can be written and published by any member of the Bitcoin Cash community.
They are evaluated publicly, giving the authors an opportunity to make any clarifications or adjustments based on feedback from the rest of the community.
Once there is sufficient support for a CHIP amongst node developers, it is scheduled for release in a future hard fork.
Changes from multiple CHIPs may be included in a single protocol upgrade
## Contents ## Contents
The May 2022 protocol upgrade is comprised the following CHIPs: The May 2022 hard fork is comprised the following CHIPs:
1. [CHIP-2021-03: Bigger Script Integers](./bigint).
2. [CHIP-2021-02: Native Introspection Opcodes](./native-introspection).
1. [Native Introspection Opcodes](/protocol/forks/chips/2022-05-native-introspection-opcodes)
2. [Bigger Script Integers](/protocol/forks/chips/2022-05-bigger-script-integers)
protocol/formats/variable-length-integer.md
+3 -1
View File
@@ -1,6 +1,8 @@
# Compact Variable Length Integer # Compact Variable Length Integer
A variable-width data format for unsigned integers allowing a more compact representation for smaller values. This is sometimes referred to as "compact size" or "var int". A variable-width data format for unsigned integers allowing a more compact representation for smaller values. This is sometimes referred to as "compact size" or "var int"\*.
\* - Caution should be used when refering to this integer format as "var int" (or "VarInt"), however, in that it may create an ambiguity. The "Core" family of software (BCHN, BU, and Flowee) all have an internal "VARINT" format that is distinct from this integer format. In that "Core" lineage of software, COMPACTSIZE or CompactSize is used to refer to the protocol's variable length integer format, while "VarInt" refers specifically to their internal variable length integer format and is *not* a part of the Bitcoin Cash P2P protocol.
## Format ## Format