Important: This document is an in-progress draft, and may change prior to the 2020-05-15 upgrade

Summary

When the median time past [1] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1589544000, 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 miner signalling.

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.

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.

Infrastructure Funding Plan

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. The IFP has the following features:

  • Activation is triggered via BIP 9 version bits signalling.
  • Activation is signalled separately for each of the addresses.
  • Activation occurs if, in a 2-week period, 66% (1344 of 2016) of blocks signal the version bits for that address.
  • If activated, the coinbase transaction in each block must contain an output sending 5% of the block reward to one of the activated addresses.

A more detailed specification of the IFP is in progress

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] 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] to be equal to 0.

When the median time past [1] 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] 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 in bitcoin.it wiki. It is guaranteed by consensus rules to be monotonically increasing.

[2] The forkId is defined as per the replay protected sighash specification.