When the median time past [1] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1557921600, 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:
* Enable Schnorr signatures.
* Allow Segwit recovery.
The following are not consensus changes, but are recommended changes for Bitcoin Cash implementations:
* Automatic replay protection for future upgrade
## Enable Schnorr signatures
Support Schnorr signatures in CHECKSIG and CHECKDATASIG per [2019-05-15-schnorr.md](2019-05-15-schnorr.md).
## Allow Segwit recovery
-In the last upgrade, coins accidentally sent to Segwit P2SH addresses were made unspendable by the CLEANSTACK rule. This upgrade will make an exemption for these coins and return them to the previous situation, where they are spendable. This means that once the P2SH redeem script pre-image is revealed (for example by spending coins from the corresponding BTC address), any miner can take the coins.
+In the last upgrade, coins accidentally sent to Segwit P2SH addresses were made unspendable by the CLEANSTACK rule. This upgrade will make an exemption for these coins and return them to the previous situation, where they are spendable. This means that once the P2SH redeem script pre-image is revealed (for example by spending coins from the corresponding BTC address), any miner can take the coins.
When the median time past [1] of the most recent 11 blocks (MTP-11) is less than UNIX timestamp 1573819200 (Nov 2019 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 1573819200 (Nov 2019 upgrade) Bitcoin Cash full nodes implementing the May 2019 consensus rules SHOULD enforce the following change:
* Update `forkid` [2] to be equal to 0xFF0002. 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](https://en.bitcoin.it/wiki/Block_timestamp). It is guaranteed by consensus rules to be monotonically increasing.
[2] The `forkId` is defined as per the [replay protected sighash](replay-protected-sighash.md) specification.
OP_REVERSEBYTES reverses the bytes of the top stackitem.
Rationale
---------
Bitcoin's protocol almost exclusively uses little-endian encoding [8], and Script provides various tools for using integers encoded in little endian, such as `OP_NUM2BIN` and `OP_BIN2NUM` [11]. Using covenants [2], sophisticated smart contracts can be created, and Script already has a great arsenal of arithmetic operators (opcodes 139 to 165) to enforce e.g. how input and output amounts of transactions have to be related.
However, many protocols do not use little endian encoding, and it is by no means clear that one is superior to the other. Both AMQP [12] and Apache Thrift [13], for instance, use big-endian encoding. The Simple Ledger Protocol (SLP) uses big-endian encoding as well [1]. Bitdb, when using the `hN` elements, returns stack items in a format that can be directly interpreted as base16 big-endian encoded numbers, and to use this feature, it has to be possible to encode values as big-endian.
Further, now that oracles using OP_CHECKDATASIG are possible, likely used to retrieve numeric data, it would be unnecessarily limiting to assume all oracles will use little-endian encoding.
Among the mentioned protocols, SLP tokens are likely the most important ones. Various new use cases combining the power of covenants and looping transactions [5] emerge, among them:
* Decentralized exchanges (such as SLP Agora or SLPDEX) [3] [6] [4]
* Donation mintable tokens
* DAOs, which charge a fee for services and distribute revenue proportional to shares [7]
* Native tokens (not yet possible)
Note that values can be converted to big-endian encoding if the size of the encoding is both fixed and not too large. Currently, Script only supports 32-bit integers, and they can be encoded in big-endian using OP_SPLIT, OP_SWAP and OP_CAT:
However, if with OP_REVERSEBYTES, this becomes trivial:
```
// convert to bytes
PUSH 4 // <SLP value> 4
OP_NUM2BIN // <SLP value 4-byte little endian>
OP_REVERSEBYTES // <SLP value 4-byte big endian>
```
-That's 11 bytes (9 operations and 3 pushdata) saved.
+That's 11 bytes (9 operations and 3 pushdata) saved.
There are multiple reasons why the second version would be preferable:
* Covenants and looping scripts usually take the script code of the preimage [9] as input, which means every operation counts twice: Once for the stack item containing the script code, and once for the P2SH script stack item [10]. For a conversion to 8-byte big-endian, this would save 32 bytes per conversion, and if there's, say, three of those conversions in a script, it would already amount to 96 bytes - a non-trivial number of bytes for a transaction.
* The cognitive load of developing scripts using the larger snippet above is increased unnecessarily. Developing scripts, by hand or by using tools such as macros or Spedn, already puts a lot of cognitive load on developers, and errors can be devastating to the community. A prominent example of such a failure is the contentious hard-fork on the Ethereum blockchain that was caused by a bug in The DAO smart contract.
* The first version assumes that Script uses 32-bit numbers, however, once integers with larger width are implemented, the script gets linearly longer (4 bytes/byte) with each additional byte. For 256-bit numbers, it would require a whopping 124 bytes (93 operations and 31 pushdata) to convert to big-endian. As the opcode limit currently is 201, that wouldn't leave much room for other operations. In contrast, `<N> OP_NUM2BIN OP_REVERSEBYTES` always encodes integers as N-byte big-endian number, with a constant script size independent of N.
Also, suppose an oracle returns an ordered list of 1-byte items (e.g. indices), however, if the script requires the bytes to be in the reversed order, then OP_REVERSEBYTES would allow to do this trivially.
### A Note On Signs
For unsigned integers, the behavior is always the expected one: the number will be encoded as unsigned big-endian integer. However, as integers in Script are encoded rather curiously, signed integers might result in unexpected behavior:
Here, the sign bit is the first bit of the resulting stackitem. Usually, negative numbers are encoded in two's complement, and the number should be `{0xff, 0xff, 0xff, 0xff}`. However, as long as developers are aware of this quite Script specific encoding, there's no issue at hand.
OP_REVERSEBYTES Specification
-----------------------------
This specification uses the same syntax for the stack/stackitems as [11].
### Semantics
`a OP_REVERSEBYTES -> b`.
OP_REVERSEBYTES fails immediately if the stack is empty.
Otherwise, the top stack item is removed from the stack, and a byte-reversed version is pushed onto the stack.
-OP_REVERSEBYTES proposes to use the previously unused opcode with number 188 (0xbc in hex encoding), which comes after the most recently added opcode, `OP_CHECKDATASIGVERIFY`.
+OP_REVERSEBYTES proposes to use the previously unused opcode with number 188 (0xbc in hex encoding), which comes after the most recently added opcode, `OP_CHECKDATASIGVERIFY`.
### Name
The naming of this opcode turned out to become a bit of a bikeshed. In a previous proposal, this opcode has been named `OP_REVERSE`. After that, it has been renamed to `OP_BSWAP`, as that is a more technically accurate term, which is commonly used for reversing the byteorder of integers [14] [15]. However, after some more consideration, it has been renamed to `OP_ENDIAN_REVERSE` following Boost‘s nomenclature [16], then to `OP_REVERSEENDIAN` and finally to `OP_REVERSEBYTES`, which are both more consistent with Script‘s opcode naming system. However, as, “endian” is usually used for numbers which are a power of two—which isn‘t the case for this opcode—`OP_REVERSEBYTES` is the prefered choice here.
`OP_REVERSEBYTES` is preferable to `OP_BSWAP` because `OP_BSWAP` is lexically very similar to the already existing `OP_SWAP` and would make Script harder to read. Also, while the technical term for the instruction is indeed `bswap`, it isn‘t well known for developers of higher level languages and could thus spark confusion that would be avoided by using the name `OP_REVERSEBYTES`, which is more self-descriptive.
### Activation
The opcode will be activated during the 15th May 2020 hardfork.
### Unit Tests
The following unit tests are used by the ABC implementation of the opcode as of Feb 17th 2020.
- `<item> OP_REVERSEBYTES` fails if 15th May 2020 protocol upgrade is not yet activated.
When the median time past [1] 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.
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](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2020-05-15-sigchecks.md).
## 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](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2020-05-15-op_reversebytes.md).
## 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 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](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2020-05-15-ifp.md).
## Automatic Replay Protection
-The purpose of Automatic Replay Protection is to serve as a full node version-deprecation mechanism. It is intended to cause
+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](https://en.bitcoin.it/wiki/Block_timestamp).
It is guaranteed by consensus rules to be monotonically increasing.
[2] The `forkId` is defined as per the [replay protected sighash](replay-protected-sighash.md) specification.
When the median time past [1] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1605441600 (Nov 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 Difficulty Adjustment Algorithm (DAA) is replaced with a new system, referred to as aserti3-2d.
* The addition of a new coinbase rule.
The following are not consensus changes, but are recommended policy changes for Bitcoin Cash implementations:
* Automatic replay protection for future upgrade.
## Difficulty Adjustment Algorithm
Bitcoin Cash's Difficulty Adjustment Algorithm (DAA) is replaced with a new algorithm called [ASERT](http://toom.im/files/da-asert.pdf).
The specific implementation is called aserti3-2d. Details can be found in the [full specification: ASERT](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2020-11-15-asert.md).
## Coinbase Rule
The purpose of the new coinbase rule is to provide funding to development projects working on common Bitcoin Cash infrastructure.
-
+
The coinbase rule enforces that at least 8% of the block reward must be spent as a single output to the following Bitcoin Cash address:
title: Block Spec for Bitcoin Cash ⚠️ out of date ⚠️
category: spec
date: 2017-08-26
activation: 1515888000
version: 1.0
---
This section of the Bitcoin Cash (BCH) specification ("spec") documents the **block data structure** for implementing a compatible BCH client, including the block header, block serialization, and coinbase transaction formats.
This spec is based on the Bitcoin ABC implementation of the [Bitcoin Cash](https://www.bitcoincash.org/) protocol.
-A **block** is one of the two base primitives in the BCH system, the other being a **transaction**. Primitive in this context means it is one of the data structures for which the BCH software provides built-in support.
+A **block** is one of the two base primitives in the BCH system, the other being a **transaction**. Primitive in this context means it is one of the data structures for which the BCH software provides built-in support.
Nodes collect new transactions into a **block**, hash them into a hash tree (**merkle root hash**), and scan through **nonce** values to make the block's hash satisfy proof-of-work requirements.
When a miner solves the proof-of-work, it broadcasts the block to network nodes and if the block is valid it is added to the block chain. The first transaction in the block is the **coinbase transaction** that creates a new coin owned by the creator of the block. An algorithm ensures that a new block is generated every 10 minutes (600 seconds) on average.
-The block validation rules described here ensure that BCH nodes stay in consensus with other nodes. There are several rules that must be respected for a block to be valid. A node is responsible for processing, validating, and relaying the block and its transactions.
+The block validation rules described here ensure that BCH nodes stay in consensus with other nodes. There are several rules that must be respected for a block to be valid. A node is responsible for processing, validating, and relaying the block and its transactions.
A node is distinct on the network from miners and wallets. A BCH node is a piece of software that connects to other nodes in a network and communicates via peer-to-peer messages. Nodes use the `verack` protocol to communicate and perform full validation checks, including:
Block headers are serialized in the 80-byte format comprising six fields: [version](#version), [previous block hash](#previous-block-hash), [merkle root hash](#merkle-root-hash), [timestamp](#time), [difficulty target](target), and [nonce](#nonce).
The block header is hashed as part of the proof-of-work algorithm, making the serialized header format part of the consensus rules. The hash of the block header is the unique signature of the block. The block header hash is included in the next block that is mined. The block header includes a pointer to the previous block that links them in the blockchain.
The block header requires the following six fields. Note that the hashes are in internal byte order; all other values are in little-endian order.
`nVersion` | 4 | int32_t | The block version number indicates which set of block validation rules to follow.
`hashPrevBlock` | 32 | uint256 | The SHA256(SHA256(Block_Header)) message digest of the previous block’s header.
`hashMerkleRoot`| 32 | uint256 | The message digest of the Merkle root.
`nTime` | 4 | uint32_t | Current timestamp in seconds since 1970-01-01T00:00 UTC (Unix time).
`nBits` | 4 | uint32_t | Difficulty target for the proof-of-work for this block.
`nNonce` | 4 | uint32_t | 32-bit number (starts at 0) used to generate this block (the "nonce").
### Block Version
The block version number is a signed 4 byte integer (`int32_t`) that indicates which set of block validation rules to follow. BCH version >= 4 is valid.
### Previous Block Hash
-The SHA256(SHA256(Block_Header)) message digest (hash) of the previous block’s header in internal byte order. This ensures no previous block can be changed without also changing this block’s header.
+The SHA256(SHA256(Block_Header)) message digest (hash) of the previous block’s header in internal byte order. This ensures no previous block can be changed without also changing this block’s header.
### Merkle Root Hash
The Merkle tree is data structure that provides a record of all transactions in the block. Each transaction in the block is a leaf in the Merkle tree and includes a hash of the previous transaction hash. The Merkle root is derived from the hashes of all transactions included in this block. The hash of the Merkle root ensures that no transaction can be modified without modifying the block header.
The Merkle root is constructed from the list of transaction IDs in the order the transactions appear in the block.
* The coinbase transaction TXID is always placed first.
* Any input within this block can spend an output which also appears in this block (assuming the spend is otherwise valid). However, the TXID corresponding to the output must be placed at some point before the TXID corresponding to the input. This ensures that any program parsing block chain transactions linearly will encounter each output before it is used as an input.
If a block only has a coinbase transaction, the coinbase TXID is used as the Merkle root hash.
If a block only has a coinbase transaction and one other transaction, the TXIDs of those two transactions are placed in order, concatenated as 64 raw bytes, and then SHA256(SHA256()) hashed together to form the Merkle root.
If a block has three or more transactions, intermediate Merkle tree rows are formed. The TXIDs are placed in order and paired, starting with the coinbase transaction's TXID. Each pair is concatenated together as 64 raw bytes and SHA256(SHA256()) hashed to form a second row of hashes. If there are an odd (non-even) number of TXIDs, the last TXID is concatenated with a copy of itself and hashed. If there are more than two hashes in the second row, the process is repeated to create a third row (and, if necessary, repeated further to create additional rows). Once a row is obtained with only two hashes, those hashes are concatenated and hashed to produce the Merkle root.
TXIDs and intermediate hashes are always in internal byte order when they're concatenated, and the resulting Merkle root is also in internal byte order when it's placed in the block header.
Note that the Merkle root makes it possible in the future to securely verify that a transaction has been accepted by the network using just the block header (which includes the Merkle tree), eliminating the current requirement to download the entire blockchain.
Refer to the source code for more details on security issues: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/consensus/merkle.cpp.
### Block Timestamp
The block timestamp is Unix epoch time when the miner started hashing the header according to the miner's clock. The block timestamp must be greater than the median time of the previous 11 blocks. Note that when validating the first 11 blocks of the chain, you will need to know how to handle arrays of less than length 11 to get a median. A node will not accept a block with a timestamp more than 2 hours ahead of its view of network-adjusted time.
### Difficulty Target
The difficulty target is a 256-bit unsigned integer which a header hash must be less than or equal to for that header to be a valid part of the block chain. The header field *nBits* provides only 32 bits of space, so the target number uses a less precise format called "compact" which works like a base-256 version of scientific notation. As a base-256 number, nBits can be parsed as bytes the same way you might parse a decimal number in base-10 scientific notation.
-Although the target threshold should be an unsigned integer, the class from which the original nBits implementation inherits properties from a signed data class, allowing the target threshold to be negative if the high bit of the significand is set.
+Although the target threshold should be an unsigned integer, the class from which the original nBits implementation inherits properties from a signed data class, allowing the target threshold to be negative if the high bit of the significand is set.
* When parsing nBits, the system converts a negative target threshold into a target of zero, which the header hash can equal (in
theory, at least).
* When creating a value for nBits, the system checks to see if it will produce an nBits which will be interpreted as negative; if so, it divides the significand by 256 and increases the exponent by 1 to produce the same number with a different encoding.
Difficulty is a measure of how difficult it is to find a hash below a given target. The BCH network has a global block difficulty. Valid blocks must have a hash below the difficulty target calculated from the `nBits` value. The current difficulty target is available here: https://blockexplorer.com/api/status?q=getDifficulty.
### Nonce
To be valid, a block include a **nonce** value that is the solution to the mining process. This proof-of-work is verified by other BCH nodes each time they receive a block.
**NOTE:** The original purpose of the nonce was to manipulate it to find a solution to the mining process. However, because mining devices now have hashrates in the terahash range, the `nonce` field is too small. In practice, most block headers do not include a solution to the mining process in the `nonce`. Instead, miners have try many different Merkle root hashes, which is typically done by changing the coinbase TX. A `nonce` value is nonetheless required.
The `nonce` is a 32-bit (4-byte) field whose value is arbitrarily set by miners to modify the header hash and produce a hash that is less than the difficulty target with the required number of leading zeros (currently 32) satisfies the proof-of-work.
-An arbitrary number miners change to modify the header hash in order to produce a hash less than or equal to the target threshold. If all 32-bit values are tested, the time can be updated or the coinbase transaction can be changed and the Merkle root updated.
+An arbitrary number miners change to modify the header hash in order to produce a hash less than or equal to the target threshold. If all 32-bit values are tested, the time can be updated or the coinbase transaction can be changed and the Merkle root updated.
The nonce is an arbitrarily changed by miners to modify the header hash and produce a hash less than the difficulty target. If all 32-bit values are tested, the time can be updated or the coinbase transaction can be changed and the Merkle root updated.
Any change to the nonce will make the block header hash completely different. Since it is virtually impossible to predict which combination of bits will result in the right hash, many different nonce values are tried, and the hash is recomputed for each value until a hash containing the required number of zero bits as set by the difficulty target is found. The resulting hash has to be a value less than the current difficulty and so will have to have a certain number of leading zero bits to be less than that. As this iterative calculation requires time and resources, the presentation of the block with the correct nonce value constitutes proof-of-work.
It is important to note that the proof-of-work can be verified by computing one hash with the proper content, and is therefore very cheap. The fact that the proof is cheap to verify is as important as the fact that it is expensive to compute.
## Coinbase Transaction
-The first transaction in the body of each block is a special transaction called the **coinbase transaction** which is used to pay miners of the block. The coinbase transaction is required, and must collect and spend any transaction fees paid by transactions included in the block.
+The first transaction in the body of each block is a special transaction called the **coinbase transaction** which is used to pay miners of the block. The coinbase transaction is required, and must collect and spend any transaction fees paid by transactions included in the block.
A valid block is entitled to receive a block subsidy of newly created bitcoincash value, and it must also be spent in the coinbase transaction. Together, the transaction fees and block subsidy are called the **block reward**. A coinbase transaction is invalid if it tries to spend more value than is available from the block reward. The subsidy plus fees is the maximum coinbase payout, but note that it is valid for the coinbase to pay less.
The coinbase transaction must have one input spending from 000000000000000. The field used to provide the signature can contain arbitrary data up to 100 bytes. The coinbase transaction must start with the block height to ensure no two coinbase transactions have the same transaction id (TXID).
The coinbase transaction has the following format:
| 32 | hash (null) | char[32] | A 32-byte null, as a coinbase has no previous outpoint.
| 4 | index (UINT32_MAX) | uint32_t | 0xffffffff, as a coinbase has no previous outpoint.
| *Varies* | script bytes | compactSize uint | The number of bytes in the coinbase script, up to a maximum of 100 bytes.
| *Varies* (4) | height | script | The block height of this block. Required parameter. Uses the script language: starts with a data-pushing opcode that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected. The data-pushing opcode is 0x03 and the total size is four bytes.
| *Varies* | coinbase script | *None* | The coinbase field and input parameter: Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header Merkle root during hashing.
| 4 | sequence | uint32_t | Sequence number.
Although the coinbase script is arbitrary data, if it includes the bytes used by any signature-checking operations such as `OP_CHECKSIG`,
those signature checks will be counted as signature operations (sigops) towards the block's sigop limit. To avoid this, you can prefix all data with the appropriate push operation. See [Transaction format](#transaction) for details on opcodes.
## Block Serialization
Blocks must be serialized in binary format for transport on the network. Under current BCH consensus rules, a BCH block is valid if its serialized size is not more than 32MB (32,000,000 bytes). All fields described below count towards the serialized size limit.
| 80 | block header | block_header | The block header in the proper format. See [Block Header](#block-header).
| Varies | txn_count | compactSize uint | Total number of transactions in this block, including the coinbase transaction.
| Varies | txns | raw transaction | Each transaction in this block in this block, one after another, in raw transaction format. Transactions must appear in the data stream in the same order their TXIDs appeared in the first row of the [Merkle tree](#merkle-root-hash).
The serialized (raw) form of each block header is hashed as part of the proof-of-work, making the serialized block header part of the BCH consensus rules. As part of the mining process, the block header is hashed repeatedly to create proof-of-work.
BCH uses SHA256(SHA256(Block_Header)) to hash the block header. You must ensure that the block header is in the proper byte-order before hashing. The following serialization rules apply to the block header:
- Both hash fields use double-hashing (`SHA256(SHA256(DATA))`) and are serialized in internal byte order, which means the standard order in which hash message digests are displayed as strings.
- The values for all other fields in the block header are serialized in little-endian order. Note that when displayed via a block browser or query, the ordering is big-endian.
title: Transaction Spec for Bitcoin Cash ⚠️ out of date ⚠️
category: spec
date: 2017-08-26
activation: 1515888000
version: 1.0
---
This section of the Bitcoin Cash (BCH) specification ("spec") documents the **transaction data structure** for implementing a compatible BCH client, including transaction format, opcodes, and examples.
This spec is based on the Bitcoin ABC implementation of the [Bitcoin Cash](https://www.bitcoincash.org/) protocol.
A transaction is one of the two base primitives in the BCH system, the other being a block. Primitive in this context means that it is one of the data types for which the BCH spec provides built-in support.
A transaction is a transfer of BCH that is broadcast to the network and collected into blocks. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoincash values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions are buried under enough confirmations they can be considered irreversible.
Transaction comprises a signature and redeem script pair, which provides flexibility in releasing outputs. A serialized transaction contains an input and an output.
A transaction that meets the criteria documented here is said to be standard. Standard transactions are accepted into the mempool and relayed by nodes on the network. This ensures that nodes have a similar looking mempool so that the system behave predictably. Standard transaction outputs nominate addresses, and the redemption of any future inputs requires a relevant signature.
Transaction requirements:
- Transaction size: < 100k
- Version must be 1 or 2
- Signature script must be data push only
- Script size must be 1650 or less
NOTE: A BCH node should be able to process non-standard transactions as well. Even if a node cannot successfully relay a non-standard transaction, it should not crash if it ends up having to process one of those transactions.
### Transaction Input
Inputs to a transaction include the outpoint, signature script, and sequence.
An input is a reference to an output from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any transaction fee) is completely used by the outputs of the new transaction. Previous tx is a hash of a previous transaction. Index is the specific output in the referenced transaction. scriptSig is the first half of a script (discussed in more detail later).
### Transaction Output
Outputs from a transaction include the BCH amount and redeem script which is used to spend the output and sets up parameters for the signature script. Redeem scripts should not use OP_CODES.
## OpCodes
-The opcodes used in the pubkey scripts of standard transactions are as follows.
+The opcodes used in the pubkey scripts of standard transactions are as follows.
See also the source code: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/script/script.h.
### 0x00 to 0x4e
-There are arious data pushing opcodes from 0x00 to 0x4e (1--78) that must be used must be used to push signatures and public keys onto the stack.
+There are arious data pushing opcodes from 0x00 to 0x4e (1--78) that must be used must be used to push signatures and public keys onto the stack.
### OP_TRUE/OP_1, OP_2 through OP_16
`OP_TRUE`/`OP_1` (0x51) and `OP_2` through `OP_16` (0x52--0x60) push the values 1 through 16 to the stack.
### OP_CHECKSIG
`OP_CHECKSIG` consumes a signature and a full public key, and pushes true onto the stack if the transaction data specified by the SIGHASH flag was converted into the signature using the same ECDSA private key that generated the public key. Otherwise, it pushes false onto the stack.
### OP_DUP
`OP_DUP` pushes a copy of the topmost stack item on to the stack.
### OP_HASH160
`OP_HASH160` consumes the topmost item on the stack, computes the RIPEMD160(SHA256()) hash of that item, and pushes that hash onto the stack.
-### OP_EQUAL
+### OP_EQUAL
`OP_EQUAL` consumes the top two items on the stack, compares them, and pushes true onto the stack if they are the same, false if not.
### OP_VERIFY
`OP_VERIFY` consumes the topmost item on the stack. If that item is zero (false) it terminates the script in failure.
### OP_EQUALVERIFY
`OP_EQUALVERIFY` runs `OP_EQUAL` and then `OP_VERIFY` in sequence.
### OP_CHECKMULTISIG
`OP_CHECKMULTISIG` consumes the value (n) at the top of the stack, consumes that many of the next stack levels (public keys), consumes the value (m) now at the top of the stack, and consumes that many of the next values (signatures) plus one extra value.
The "one extra value" it consumes is the result of an off-by-one error in the original Bitcoin implementation. This value is not used in Bitcoincash, so signature scripts prefix the list of secp256k1 signatures with a single OP_0 (0x00).
`OP_CHECKMULTISIG` compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result.
-Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the signature script using the same order as their corresponding public keys were placed in the pubkey script or redeem script.
+Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the signature script using the same order as their corresponding public keys were placed in the pubkey script or redeem script.
-The `OP_CHECKMULTISIG` verification process requires that signatures in the signature script be provided in the same order as their corresponding public keys in the pubkey script or redeem script.
+The `OP_CHECKMULTISIG` verification process requires that signatures in the signature script be provided in the same order as their corresponding public keys in the pubkey script or redeem script.
### OP_RETURN
`OP_RETURN` terminates the script in failure when executed.
## Address Conversion
The hashes used in P2PKH and P2SH outputs are commonly encoded as Bitcoincash addresses. This is the procedure to encode those hashes and decode the addresses.
First, get your hash. For P2PKH, you RIPEMD-160(SHA256()) hash a ECDSA public key derived from your 256-bit ECDSA private key (random data). For P2SH, you RIPEMD-160(SHA256()) hash a redeem script serialized in the format used in raw transactions.
Taking the resulting hash:
1. Add an address version byte in front of the hash. The version bytes commonly used by Bitcoincash are:
* 0x00 for P2PKH addresses on the main Bitcoincash network (mainnet)
* 0x6f for P2PKH addresses on the Bitcoincash testing network (testnet)
* 0x05 for P2SH addresses on mainnet
* 0xc4 for P2SH addresses on testnet
2. Create a copy of the version and hash; then hash that twice with SHA256: `SHA256(SHA256(version . hash))`
3. Extract the first four bytes from the double-hashed copy. These are used as a checksum to ensure the base hash gets transmitted
correctly.
4. Append the checksum to the version and hash, and encode it as a base58 string: <!--[-->`BASE58(version . hash . checksum)`<!--]-->
-
+
The code can be traced using the [base58 header file][core base58.h].
To convert addresses back into hashes, reverse the base58 encoding, extract the checksum, repeat the steps to create the checksum and compare it against the extracted checksum, and then remove the version byte.
## Raw Transaction Format
Bitcoincash transactions are broadcast between peers in a serialized byte format, called raw format. It is this form of a transaction which is SHA256(SHA256()) hashed to create the TXID and, ultimately, the merkle root of a block containing the transaction---making the transaction format part of the consensus rules.
Bitcoincash Core and many other tools print and accept raw transactions encoded as hex.
A raw transaction has the following top-level format:
| 4 | version | `uint32_t` | Transaction version number; currently version 1. Programs creating transactions using newer consensus rules may use higher version numbers.
| *Varies* | tx_in count | `compactSize uint` | Number of inputs in this transaction.
| *Varies* | tx_in | `txIn` | Transaction inputs. See description of txIn below.
| *Varies* | tx_out count | `compactSize uint` | Number of outputs in this transaction.
| *Varies* | tx_out | `txOut` | Transaction outputs. See description of txOut below.
-| 4 | lock_time | `uint32_t` | A time (Unix epoch time) or block number.
+| 4 | lock_time | `uint32_t` | A time (Unix epoch time) or block number.
A transaction may have multiple inputs and outputs, so the txIn and txOut structures may recur within a transaction. CompactSize unsigned
integers are a form of variable-length integers; they are described in CompactSize unsigned integer.
## TxIn: Transaction Input
Each non-coinbase input spends an outpoint from a previous transaction.
The outpoint is a reference to an output from a previous transaction. Because a single transaction can include multiple outputs, the outpoint structure includes both a TXID and an output index number to refer to the specific part of a specific output.
| Bytes | Name | Data Type | Description
|-------|-------|-----------|--------------
| 32 | hash | char[32] | The TXID of the transaction holding the output to spend. The TXID is a hash provided here in internal byte order.
| 4 | index | uint32_t | The output index number of the specific output to spend from the transaction. The first output is 0x00000000.
-## TxOut: Transaction Output
+## TxOut: Transaction Output
Each output spends a certain number of Satoshis, placing them under control of anyone who can satisfy the provided pubkey script.
| 8 | value | int64_t | Number of Satoshis to spend. May be zero; the sum of all outputs may not exceed the sum of Satoshis previously spent to the outpoints provided in the input section. (Exception: coinbase transactions spend the block subsidy and collected transaction fees.)
| 1+ | pk_script bytes | compactSize uint | Number of bytes in the pubkey script. Maximum is 10,000 bytes.
| *Varies* | pk_script | char[] | Defines the conditions which must be satisfied to spend this output.
## CompactSize Unsigned Integers
The raw transaction format and several peer-to-peer network messages use a type of variable-length integer to indicate the number of bytes in a following piece of data.
The source code and this document refers to these variable length integers as compactSize. Because it's used in the transaction format, the format of compactSize unsigned integers is part of the consensus rules.
For numbers from 0 to 252, compactSize unsigned integers look like regular unsigned integers. For other numbers up to 0xffffffffffffffff, a byte is prefixed to the number to indicate its length---but otherwise the numbers look like regular unsigned integers in little-endian order. For example, the number 515 is encoded as 0xfd0302.
| >= 253 && <= 0xffff | 3 | 0xfd followed by the number as uint16_t
| >= 0x10000 && <= 0xffffffff | 5 | 0xfe followed by the number as uint32_t
| >= 0x100000000 && <= 0xffffffffffffffff | 9 | 0xff followed by the number as uint64_t
## Signature Script
The purpose of the signature script (scriptSig) is to ensure that the spender is a legitimate spender, that is, evidence of private key held.
The scriptSig contains two components: a signature and a public key. The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question.
Signature scripts are not signed, so anyone can modify them. This means signature scripts should only contain data and data-pushing opcodes which can't be modified without causing the pubkey script to fail. Placing non-data-pushing opcodes in the signature script currently makes a transaction non-standard, and future consensus rules may forbid such transactions altogether. (Non-data-pushing opcodes are already forbidden in signature scripts when spending a P2SH pubkey script.)
-
+
## Sequence
Check lock time verify (s4)
Check sequence verify (s4)
## Standard Transaction Format Examples
### P2SH
23-bytes
OP_HASH160
<reedem script hash>
OP_EQUAL
Use address version=1 and hash=<reedem script hash>
### P2PKH
25 bytes
OP_DUP
OP_HASH160
<public key hash>
OP_EQUALVERIFY
OP_CHECKSIG
- Use address version=0 and hash=<public key hash>
+ Use address version=0 and hash=<public key hash>
### P2PK
35 or 67 bytes
<public key>
OP_CHECKSIG
Use address version=0 and hash=HASH160(<public key>)
### Bare multisig
<n: [0-20]>
<pubkey 0>
…
<pubkey n>
<(null)>
OP_CHECKMULTISIG
NOTE: Bare multisig (which isn't wrapped into P2SH) is limited to 3-of-3.