Bitcoin Cash Upgrade History

In 2010 and 2011 the discovery of serious bugs prompted the deactivation of many opcodes in the Bitcoin script language. Rather than simply re-enable the opcodes, the functionality that they provide has been re-examined and in some cases the opcodes have been re-designed or new opcodes have been added to address specific issues.

With the exception of the coinbase transaction, transactions within a block MUST be sorted in numerically ascending order of the transaction id, interpreted as 256-bit little endian integers. The coinbase transaction MUST be the first transaction in a block.

Context:
All nodes already have all the transactions in the mempool. When a block is found, it is sending all transactions to all nodes a second time. This delays block propagation and block validation. In order to improve this, Compact/Xthin(er) utilize shorter transaction IDs to minimize the data needing to be sent a second time when a block is found. Graphene takes this a step further by utilizing bloom filters to check which transactions are in which block. However, the bloom filters only allow knowledge of what transactions go into the block, not in what order. The ordering data makes up 80% of the data in a graphene block. By utilizing canonical ordering, 85% of the block data no longer needs to be sent, allowing for 7x faster block propagation and validation.

CTOR also enables better parallelization which enables far better scaling with technology. An additional benefit of faster block propagation and validation is the mitigation of selfish mining (where miners that find the first block have an advantage over others for the time it takes their nodes to receive and validate the recently found block).

MINIMALDATA flag, which restricts malleability vectors, has been active at the mempool layer of most nodes but not at the consensus layer. The upgrade converts the existing MINIMALDATA rules to consensus.

Although partly effective, there are well known issues with SigOps, which mainly stem from the fact that SigOps are judged by parsing scripts, rather than executing them. Bitcoin splits scripts into two transactions (the scriptPubKey of the transaction that creates a coin, and the scriptSig of the transaction that spends it), yet the actual CPU work of verifying a transaction solely happens in the spending transaction, and this leads to some paradoxical situations: a transaction/block that contains high SigOps might involve very little CPU work, and conversely a transaction with low SigOps may require very high CPU work.

The essential idea of SigChecks is to count actual executed signature check operations solely in the spending transaction.

When a transaction is first transmitted on the Bitcoin Cash network, it is considered “unconfirmed” until it is “mined” into a block. These transactions that are not yet mined are also referred to as “zero-conf” transactions. Transactions are dependent upon other transactions, such that they are chained together; the value allocated by one transaction is then spent by a subsequent transaction.

Until this upgrade, the Bitcoin Cash network only permitted transactions to be chained together 50 times before a block must include them. Transactions exceeding the 50th were often ignored by the network, despite being valid. Once a transaction is submitted to the network, it cannot be revoked. This situation, when encountered, can be extremely difficult to remedy with today’s available tools and simultaneously creates an unnecessary amount of complexity when being accounted for by network and applications developers.

The limit is now removed.

BCH virtual machine (VM) math operations were limited to signed 32-bit integers, preventing contracts from operating on values larger than 2147483647. Workarounds which allow contracts to emulate higher-precision math are often impractical, difficult to secure, and significantly increase transaction fees.

This unusually-low limit on arithmetic operations has been present since the earliest Bitcoin release to avoid standardizing a strategy for overflow handling (though 64-bit math was always used internally). Since the development of covenants, this unusual overflow-handling strategy has become a source of contract vulnerabilities and a barrier to real-world applications. Few remaining computing environments operate using 32-bit integers, and this limit has never been relevant to worst-case transaction validation performance.

This upgrade expands the integer range allowed in BCH contracts (from 32-bit to 64-bit numbers) and re-enables the multiplication opcode.

Bitcoin Cash contracts lacked primitives for issuing messages that can be verified by other contracts, preventing the development of decentralized application ecosystems on Bitcoin Cash. This upgrade introduced Byte-String Commitments and Numeric Commitments.

(Existing) Contract-Issued Commitments
In the context of the Bitcoin Cash virtual machine (VM), a commitment can be defined as an irrevocable message that was provably issued by a particular entity. Two forms of commitments were already available to Bitcoin Cash contracts:

• Transaction signatures: a commitment made by a private key attesting to the signing serialization of a transaction
• Data signatures: a commitment made by a private key attesting to the hash of an arbitrary message (introduced in 2018 by OP_CHECKDATASIG)

Each of these commitment types require the presence of a trusted private key. Because contracts cannot themselves hold a private key, any use case that requires a contract to issue a verifiable message must necessarily rely on trusted entities to provide signatures. This limitation prevented Bitcoin Cash contracts from offering or using decentralized oracles – multiparty consensus systems that produce verifiable messages upon which other contracts can act.

By providing a commitment primitive that can be used directly by contracts, the Bitcoin Cash contract system can support advanced, decentralized applications without increasing transaction or block validation costs.

Byte-String Commitments (“Non-Fungible Tokens” or “NFTs”)
The most general type of contract-issued commitment is a simple string of bytes. This type can be used to commit to any type of contract state: certifications of ownership, authorizations, credit, debt, contract-internal time or epoch, vote counts, receipts (e.g. to support refunds or future redemption), etc. Identities may commit to state within a hash structure (e.g. a merkle tree), or – to reduce transaction sizes – as a raw byte string (e.g. public keys, static numbers, boolean values).

Numeric Commitments (“Fungible Tokens” or “FTs”)
The BitcoinCash virtual machine (VM) supports two primary data types in VM bytecode evaluation: byte strings and numbers. Given the existence of a primitive allowing contracts to commit to byte strings, another commitment primitive can be inferred: numeric commitments.

Numeric commitments are a specialization of byte-string commitments – they are commitments with numeric values which can be divided and merged in the same way as the Bitcoin Cash currency. With numeric commitments, contracts can efficiently represent fractional parts of abstract concepts – shares, pegged assets, bonds, loans, options, tickets, loyalty points, voting outcomes, etc.

While many use cases for numeric commitments can be emulated with only byte-string commitments, a numeric primitive enables many contracts to reduce or offload state management altogether (e.g. shareholder voting), simplifying contract audits and reducing transaction sizes.