You've already forked specification
bitcoincashautist
76 lines
4.0 KiB
Markdown
76 lines
4.0 KiB
Markdown
# HF-20200515
|
|
|
|
layout: specification
|
|
title: 2020-MAY-15 Network Upgrade Specification
|
|
date: 2020-04-26
|
|
category: spec
|
|
activation: 1589544000
|
|
version: 0.4
|
|
|
|
## Summary
|
|
|
|
When the median time past [[1]](#references) of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1589544000 (May 15th, 2020, 12:00PM UTC),
|
|
Bitcoin Cash will execute an upgrade of the network consensus rules according to this specification.
|
|
Starting from the next block these consensus rules changes will take effect:
|
|
|
|
* Bitcoin Cash's SigOps counting and limiting system is replaced with a new system, referred to as SigChecks.
|
|
* A new opcode called OP_REVERSEBYTES has been added to the script system.
|
|
* Enforcement of the Infrastructure Funding Plan, subject to activation by [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) miner signalling.
|
|
(Post-activation note: the IFP was rejected and never activated on Bitcoin Cash network.)
|
|
|
|
The following are not consensus changes, but are recommended policy changes for Bitcoin Cash implementations:
|
|
|
|
* The default for max number of in-mempool ancestors is changed from 25 to 50.
|
|
* The default for max number of in-mempool descendants is changed from 25 to 50.
|
|
* Automatic replay protection for future upgrade.
|
|
|
|
## SigChecks
|
|
|
|
Enforcement of sigops limits is removed, and replaced with new limits based on the number of signature checks that are actually executed when running a script. This new system is called SigChecks.
|
|
|
|
Details can be found in the [full specification: SigChecks](/protocol/forks/2020-05-15-sigchecks).
|
|
|
|
## OP_REVERSEBYTES
|
|
|
|
This new opcode reverses the order of bytes in a string. It can be used to change endianness.
|
|
|
|
Details can be found in the [full specification: OP_REVERSEBYTES](/protocol/forks/2020-05-15-op_reversebytes).
|
|
|
|
## Infrastructure Funding Plan
|
|
|
|
(Post-activation note: the IFP was rejected and never activated on Bitcoin Cash network.)
|
|
|
|
The purpose of the Infrastructure Funding Plan (IFP) is to provide funding to development projects working on common Bitcoin Cash infrastructure.
|
|
If activated, it enforces that 5% of the block reward is spent to one of a set of specified addresses.
|
|
Activation is triggered via [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) version bits signalling prior to the May 15 upgrade.
|
|
|
|
More detailed can be found in the [full specification](/protocol/forks/2020-05-15-ifp).
|
|
|
|
## Automatic Replay Protection
|
|
|
|
The purpose of Automatic Replay Protection is to serve as a full node version-deprecation mechanism. It is intended to cause
|
|
full validating nodes which do not upgrade, to automatically separate themselves from the main network after the next
|
|
upgrade on 15 May 2020. Nodes which implement the next upgrade will remove this automatic replay protection, and thus all regular
|
|
wallets can continue using the default ForkID with no change to follow the main upgraded chain.
|
|
|
|
When the median time past [[1]](#references) of the most recent 11 blocks (MTP-11) is less than UNIX timestamp 1605441600 (Nov 2020 upgrade)
|
|
Bitcoin Cash full nodes MUST enforce the following rule:
|
|
|
|
* `forkid` [[2]](#references) to be equal to 0.
|
|
|
|
When the median time past [[1]](#references) of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1605441600
|
|
(Nov 2020 upgrade) Bitcoin Cash full nodes implementing the May 2020 consensus rules SHOULD enforce the following change:
|
|
|
|
* Update `forkid` [[2]](#references) to be equal to `0xFFXXXX`, where `XXXX` is some arbitrary hex value.
|
|
ForkIDs beginning with 0xFF will be reserved for future protocol upgrades.
|
|
|
|
This particular consensus rule MUST NOT be implemented by Bitcoin Cash wallet software. Wallets that follow the upgrade
|
|
should not have to change anything.
|
|
|
|
## References
|
|
|
|
[1] Median Time Past is described [here](/protocol/blockchain/transaction#median-time-past).
|
|
It is guaranteed by consensus rules to be monotonically increasing.
|
|
|
|
[2] The `forkId` is defined as per the [replay protected sighash](/protocol/forks/replay-protected-sighash) specification.
|