You've already forked specification
Changes related to transaction signing semantics.
This commit is contained in:
Andrew Groot
@@ -8,7 +8,7 @@
|
||||
[Blockchain Basics](/protocol/blockchain) — [Protocol Hashing Algorithms](/protocol/blockchain/hash) — Memory Pool
|
||||
|
||||
### Transactions
|
||||
[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script)— [Locking Script](/protocol/blockchain/transaction/locking-script)
|
||||
[Bitcoin Transaction](/protocol/blockchain/transaction) — [Unlocking Script](/protocol/blockchain/transaction/unlocking-script) — [Locking Script](/protocol/blockchain/transaction/locking-script) — [Transaction Signatures](/protocol/blockchain/transaction/signatures)
|
||||
|
||||
### Blocks
|
||||
[Bitcoin Blocks](/protocol/blockchain/block) —
|
||||
@@ -31,7 +31,7 @@ Pay To Public Key (P2PK) — Pay To Public Key Hash (P2PKH) — Pay To Script Ha
|
||||
Secp256k1 — Public Key — Private Key — ECDSA Signatures — Schnorr Signatures — [Multisignature (M-of-N multisig)](/protocol/blockchain/cryptography/multisignature)
|
||||
|
||||
### Network upgrades
|
||||
[Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — BCH-UAHF (BUIP-55) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115
|
||||
[Bip-16](/protocol/forks/bip-0016) — [Bip-34](/protocol/forks/bip-0034) — [Bip-37](/protocol/forks/bip-0037) — [Bip-64](/protocol/forks/bip-0064) — [Bip-65](/protocol/forks/bip-0065) — [Bip-66](/protocol/forks/bip-0066) — [Bip-68](/protocol/forks/bip-0068) — [Bip-112](/protocol/forks/bip-0112) — [Bip-113](/protocol/forks/bip-0113) — [Bip-157](/protocol/forks/bip-0157) — [Bip-158](/protocol/forks/bip-0158) — [Bip-159](/protocol/forks/bip-0159) — [BCH-UAHF (BUIP-55)](/protocol/forks/bch-uahf) — [HF-20171113](/protocol/forks/hf-20171113) — HF-20180515 — HF-20181115 — HF-20190515 — HF-20191115
|
||||
|
||||
### Network protocol
|
||||
|
||||
|
||||
@@ -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 unlocking script in bytes. |
|
||||
| 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. |
|
||||
|
||||
## Transaction Fee
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
|
||||
# Transaction Signatures
|
||||
|
||||
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.
|
||||
|
||||
However, there are a number of issues with signing a transaction that must be addressed:
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
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. |
|
||||
|
||||
For example, a hash type of `0x000000C2`, would indicate a signature generated for a Bitcoin Cash transaction with an anyone-can-pay, no-outputs-included preimage.
|
||||
|
||||
## BCH Signatures
|
||||
|
||||
### Preimage Format
|
||||
|
||||
| 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 | bytes<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 | bytes<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 | bytes<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 | bytes<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. |
|
||||
|
||||
#### Previous Outputs Hash
|
||||
|
||||
For each transaction input in the transaction, append the following information:
|
||||
|
||||
| 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. |
|
||||
|
||||
#### Sequence Numbers Hash
|
||||
|
||||
For each transaction input in the transaction, append the following information:
|
||||
|
||||
| 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
|
||||
|
||||
@@ -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 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).
|
||||
|
||||
@@ -0,0 +1,284 @@
|
||||
<pre>
|
||||
layout: specification
|
||||
title: UAHF Technical Specification
|
||||
category: spec
|
||||
date: 2017-07-24
|
||||
activation: 1501590000
|
||||
version: 1.6
|
||||
</pre>
|
||||
|
||||
## Introduction
|
||||
|
||||
This document describes proposed requirements for a block size Hard Fork (HF).
|
||||
|
||||
BUIP 55 specified a block height fork. This UAHF specification is
|
||||
inspired by the idea of a flag day, but changed to a time-based fork due
|
||||
to miner requests. It should be possible to change easily to a height-based
|
||||
fork - the sense of the requirements would largely stay the same.
|
||||
|
||||
|
||||
## Definitions
|
||||
|
||||
MTP: the "median time past" value of a block, calculated from its nTime
|
||||
value, and the nTime values of its up to 10 immediate ancestors.
|
||||
|
||||
"activation time": once the MTP of the chain tip is equal to or greater
|
||||
than this time, the next block must be a valid fork block. The fork block
|
||||
and subsequent blocks built on it must satisfy the new consensus rules.
|
||||
|
||||
"fork block": the first block built on top of a chain tip whose MTP is
|
||||
greater than or equal to the activation time.
|
||||
|
||||
"fork EB": the user-specified value that EB shall be set to at
|
||||
activation time. EB can be adjusted post-activation by the user.
|
||||
|
||||
"fork MG": the user-specified value that MG shall be set to at activation
|
||||
time. It must be > 1MB. The user can adjust MG to any value once the
|
||||
fork has occurred (not limited to > 1MB after the fork).
|
||||
|
||||
"Large block" means a block satisfying 1,000,000 bytes < block
|
||||
size <= EB, where EB is as adjusted by REQ-4-1 and a regular block
|
||||
is a block up to 1,000,000 bytes in size.
|
||||
|
||||
"Core rules" means all blocks <= 1,000,000 bytes (Base block size).
|
||||
|
||||
"Extended BU tx/sigops rules" means the existing additional consensus rules (1) and
|
||||
(2) below, as formalized by BUIP040 [1] and used by the Bitcoin Unlimited
|
||||
client's excessive checks for blocks larger than 1MB, extended with rule
|
||||
(3) below:
|
||||
1. maximum sigops per block is calculated based on the actual size of
|
||||
a block using
|
||||
max_block_sigops = 20000 * ceil((max(blocksize, 1000000) / 1000000))
|
||||
2. maximum allowed size of a single transaction is 1,000,000 bytes (1MB)
|
||||
3. maximum allowed number of sigops for a single transaction is 20k .
|
||||
|
||||
NOTE 1: In plain English, the maximum allowed sigops per block is
|
||||
20K sigops per the size of the block, rounded up to nearest integer in MB.
|
||||
i.e. 20K if <= 1MB, 40K for the blocks > 1MB and up to 2MB, etc.
|
||||
|
||||
|
||||
## Requirements
|
||||
|
||||
### REQ-1 (fork by default)
|
||||
|
||||
The client (with UAHF implementation) shall default to activating
|
||||
a hard fork with new consensus rules as specified by the remaining
|
||||
requirements.
|
||||
|
||||
RATIONALE: It is better to make the HF active by default in a
|
||||
special HF release version. Users have to download a version capable
|
||||
of HF anyway, it is more convenient for them if the default does not
|
||||
require them to make additional configuration.
|
||||
|
||||
NOTE 1: It will be possible to disable the fork behavior (see
|
||||
REQ-DISABLE)
|
||||
|
||||
|
||||
### REQ-2 (configurable activation time)
|
||||
|
||||
The client shall allow a "activation time" to be configured by the user,
|
||||
with a default value of 1501590000 (epoch time corresponding to Tue
|
||||
1 Aug 2017 12:20:00 UTC)
|
||||
|
||||
RATIONALE: Make it configurable to adapt easily to UASF activation
|
||||
time changes.
|
||||
|
||||
NOTE 1: Configuring a "activation time" value of zero (0) shall disable
|
||||
any UAHF hard fork special rules (see REQ-DISABLE)
|
||||
|
||||
|
||||
### REQ-3 (fork block must be > 1MB)
|
||||
|
||||
The client shall enforce a block size larger than 1,000,000 bytes
|
||||
for the fork block.
|
||||
|
||||
RATIONALE: This enforces the hard fork from the original 1MB
|
||||
chain and prevents a re-organization of the forked chain to
|
||||
the original chain.
|
||||
|
||||
|
||||
### REQ-4-1 (require "fork EB" configured to at least 8MB at startup)
|
||||
|
||||
If UAHF is not disabled (see REQ-DISABLE), the client shall enforce
|
||||
that the "fork EB" is configured to at least 8,000,000 (bytes) by raising
|
||||
an error during startup requesting the user to ensure adequate configuration.
|
||||
|
||||
RATIONALE: Users need to be able to run with their usual EB prior to the
|
||||
fork (e.g. some are running EB1 currently). The fork code needs to adjust
|
||||
this EB automatically to a > 1MB value. 8MB is chosen as a minimum since
|
||||
miners have indicated in the past that they would be willing to support
|
||||
such a size, and the current network is capable of handling it.
|
||||
|
||||
|
||||
### REQ-4-2 (require user to specify suitable *new* MG at startup)
|
||||
|
||||
If UAHF is not disabled (see REQ-DISABLE), the client shall require
|
||||
the user to specify a "fork MG" (mining generation size) greater than
|
||||
1,000,000 bytes.
|
||||
|
||||
RATIONALE: This ensures a suitable MG is set at the activation time so
|
||||
that a mining node would produce a fork block compatible with REQ-3.
|
||||
It also forces the user (miner) to decide on what size blocks they want to
|
||||
produce immediately after the fork.
|
||||
|
||||
NOTE 1: The DEFAULT_MAX_GENERATED_BLOCK_SIZE in the released client needs
|
||||
to remain 1,000,000 bytes so that the client will not generate invalid
|
||||
blocks before the fork activates. At activation time, however, the "fork MG"
|
||||
specified by the user (default: 2MB) will take effect.
|
||||
|
||||
|
||||
### REQ-5 (max tx / max block sigops rules for blocks > 1 MB)
|
||||
|
||||
Blocks larger than 1,000,000 shall be subject to "Extended BU tx/sigops rules"
|
||||
as follows:
|
||||
|
||||
1. maximum sigops per block shall be calculated based on the actual size of
|
||||
a block using
|
||||
`max_block_sigops = 20000 * ceil((max(blocksize_bytes, 1000000) / 1000000))`
|
||||
|
||||
2. maximum allowed size of a single transaction shall be 1,000,000 bytes
|
||||
|
||||
NOTE 1: Blocks up to and including 1,000,000 bytes in size shall be subject
|
||||
to existing pre-fork Bitcoin consensus rules.
|
||||
|
||||
NOTE 2: Transactions exceeding 100,000 bytes (100KB) shall remain
|
||||
non-standard after the activation time, meaning they will not be relayed.
|
||||
|
||||
NOTE 3: BU treats both rules (1) and (2) as falling under the Emergent
|
||||
Consensus rules (AD). Other clients may choose to implement them as
|
||||
firm rules at their own risk.
|
||||
|
||||
|
||||
### REQ-6-1 (disallow special OP_RETURN-marked transactions with sunset clause)
|
||||
|
||||
Once the fork has activated, transactions consisting exclusively of a single OP_RETURN output, followed by a single minimally-coded data push with the specific magic data value of
|
||||
|
||||
Bitcoin: A Peer-to-Peer Electronic Cash System
|
||||
|
||||
(46 characters, including the single spaces separating the words, and
|
||||
without any terminating null character) shall be considered invalid until
|
||||
block 530,000 inclusive.
|
||||
|
||||
RATIONALE: (DEPRECATED - see NOTE 2) To give users on the legacy chain (or other fork chains)
|
||||
an opt-in way to exclude their transactions from processing on the UAHF
|
||||
fork chain. The sunset clause block height is calculated as approximately
|
||||
1 year after currently planned UASF activation time (Aug 1 2017 00:00:00 GMT),
|
||||
rounded down to a human friendly number.
|
||||
|
||||
NOTE 1: Transactions with such OP_RETURNs shall be considered valid again
|
||||
for block 530,001 and onwards.
|
||||
|
||||
NOTE 2: With the changes in v1.6 of this specification, mandatory use
|
||||
of SIGHASH_FORKID replay protection on UAHF chain makes the use of this
|
||||
opt-out protection unnecessary. Clients should nevertheless implement this
|
||||
requirement, as removing it would constitute a hard fork vis-a-vis the
|
||||
existing network. The sunset clause in this requirement will take care
|
||||
of its expiry by itself.
|
||||
|
||||
|
||||
### REQ-6-2 (mandatory signature shift via hash type)
|
||||
|
||||
Once the fork has activated, a transaction shall be deemed valid only if
|
||||
the following are true in combination:
|
||||
- its nHashType has bit 6 set (SIGHASH_FORKID, mask 0x40)
|
||||
- a magic 'fork id' value is added to the nHashType before the hash is
|
||||
calculated (see note 4)
|
||||
- it is digested using the new algorithm described in REQ-6-3
|
||||
|
||||
RATIONALE: To provide strong protection against replay of existing
|
||||
transactions on the UAHF chain, only transactions signed with the new
|
||||
hash algorithm and having SIGHASH_FORKID set will be accepted, by consensus.
|
||||
|
||||
NOTE 1: It is possible for other hard forks to allow SIGHASH_FORKID-protected
|
||||
transactions on their chain by implementing a compatible signature.
|
||||
However, this does require a counter hard fork by legacy chains.
|
||||
|
||||
NOTE 2: (DEPRECATED) ~~The client shall still accept transactions whose signatures~~
|
||||
~~verify according to pre-fork rules, subject to the additional OP_RETURN~~
|
||||
~~constraint introduced by REQ-6-1.~~
|
||||
|
||||
NOTE 3: (DEPRECATED) ~~If bit 6 is not set, only the unmodified nHashType will be used~~
|
||||
~~to compute the hash and verify the signature.~~
|
||||
|
||||
NOTE 4: The magic 'fork id' value used by UAHF-compatible clients is zero.
|
||||
This means that the change in hash when bit 6 is set is effected only by
|
||||
the adapted signing algorithm (see REQ-6-3).
|
||||
|
||||
NOTE 5: See also REQ-6-4 which introduces a requirement for use of
|
||||
SCRIPT_VERIFY_STRICTENC.
|
||||
|
||||
|
||||
### REQ-6-3 (use adapted BIP143 hash algorithm for protected transactions)
|
||||
|
||||
Once the fork has activated, any transaction that has bit 6 set in its
|
||||
hash type shall have its signature hash computed using a minimally revised
|
||||
form of the transaction digest algorithm specified in BIP143.
|
||||
|
||||
RATIONALE: see Motivation section of BIP143 [2].
|
||||
|
||||
NOTE 1: refer to [3] for the specificaton of the revised transaction
|
||||
digest based on BIP143. Revisions were made to account for non-Segwit
|
||||
deployment.
|
||||
|
||||
|
||||
### REQ-6-4 (mandatory use of SCRIPT_VERIFY_STRICTENC)
|
||||
|
||||
Once the fork has activated, transactions shall be validated with
|
||||
SCRIPT_VERIFY_STRICTENC flag set.
|
||||
|
||||
RATIONALE: Use of SCRIPT_VERIFY_STRICTENC also ensures that the
|
||||
nHashType is validated properly.
|
||||
|
||||
NOTE: As SCRIPT_VERIFY_STRICTENC is not clearly defined by BIP,
|
||||
implementations seeking to be compliant should consult the Bitcoin C++
|
||||
source code to emulate the checks enforced by this flag.
|
||||
|
||||
|
||||
### REQ-7 Difficulty adjustement in case of hashrate drop
|
||||
|
||||
In case the MTP of the tip of the chain is 12h or more after the MTP 6 block
|
||||
before the tip, the proof of work target is increased by a quarter, or 25%,
|
||||
which corresponds to a difficulty reduction of 20% .
|
||||
|
||||
RATIONALE: The hashrate supporting the chain is dependent on market price and
|
||||
hard to predict. In order to make sure the chain remains viable no matter what
|
||||
difficulty needs to adjust down in case of abrupt hashrate drop.
|
||||
|
||||
### REQ-DISABLE (disable fork by setting fork time to 0)
|
||||
|
||||
If the activation time is configured to 0, the client shall not enforce
|
||||
the new consensus rules of UAHF, including the activation of the fork,
|
||||
the size constraint at a certain time, and the enforcing of EB/AD
|
||||
constraints at startup.
|
||||
|
||||
RATIONALE: To make it possible to use such a release as a compatible
|
||||
client with legacy chain / i.e. to decide to not follow the HF on one's
|
||||
node / make a decision at late stage without needing to change client.
|
||||
|
||||
|
||||
### OPT-SERVICEBIT (NODE_BITCOIN_CASH service bit)
|
||||
|
||||
A UAHF-compatible client should set service bit 5 (value 0x20).
|
||||
|
||||
RATIONALE: This service bit allows signaling that the node is a UAHF
|
||||
supporting node, which helps DNS seeders distinguish UAHF implementations.
|
||||
|
||||
NOTE 1: This is an optional feature which clients do not strictly have to
|
||||
implement.
|
||||
|
||||
NOTE 2: This bit is currently referred to as NODE_BITCOIN_CASH and displayed
|
||||
as "CASH" in user interfaces of some Bitcoin clients (BU, ABC).
|
||||
|
||||
|
||||
## References
|
||||
|
||||
[1] https://bitco.in/forum/threads/buip040-passed-emergent-consensus-parameters-and-defaults-for-large-1mb-blocks.1643/
|
||||
|
||||
[2] https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Motivation
|
||||
|
||||
[3] [Digest for replay protected signature verification accross hard forks](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md)
|
||||
|
||||
[4] https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-test-plan.md
|
||||
|
||||
|
||||
END
|
||||
@@ -8,4 +8,4 @@ The recipient node may, but is not required to, begin to perform this filtering
|
||||
|
||||
| Field | Length | Format | Description |
|
||||
|--|--|--|--|
|
||||
| minimum fee per byte | 8 bytes | unsigned 64 bit integer<sup>[(LE)](/protocol/misc/endian/little.md)</sup> | The minimum number of satoshis per byte in fees desired by the sender.
|
||||
| minimum fee per byte | 8 bytes | unsigned 64 bit integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The minimum number of satoshis per byte in fees desired by the sender.
|
||||
Reference in New Issue
Block a user