"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.
"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))
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.
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).
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.
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.
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.
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))`
### 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
(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 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.
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 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.~~
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.
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.
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%.
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.
