Block Chain

The subsections below offer a concise overview of key block attributes.

Block Headers

Block headers are serialized in the 80-byte format described below and then hashed as part of BitcoinEvo’s proof-of-work algorithm, making the serialized header format part of the consensus rules.
Bytes Name Data Type Description
4 version int32_t The block version number indicates which set of block validation rules to follow. See the list of block versions below.
32 previous block header hash char[32] A SHA256(SHA256()) hash in internal byte order of the previous block’s header. This ensures no previous block can be changed without also changing this block’s header.
32 merkle root hash char[32] A SHA256(SHA256()) hash in internal byte order. The merkle root is derived from the hashes of all transactions included in this block, ensuring that none of those transactions can be modified without modifying the header. See the merkle trees section below.
4 time uint32_t The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
4 nBits uint32_t An encoded version of the target threshold this block’s header hash must be less than or equal to. See the nBits format described below.
4 nonce uint32_t 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 hashes use internal byte order, while all other values are encoded in little-endian format.

 Example block header in hexadecimal:

 02000000 ........................... Block version: 2

b6ff0b1b1680a2862a30ca44d346d9e8
910d334beb48ca0c0000000000000000 ... Hash of the previous block's header
9d10aa52ee949386ca9385695f04ede2
70dda20810decd12bc9b048aaab31471 ... Merkle root

24d95a54 ........................... [Unix timestamp]: 1415239972
30c31b18 ........................... Target: 0x1bc330 * 256**(0x18-3)
fe9f0864 ........................... Nonce

Merkle Trees

The merkle root is generated using the transaction IDs (TXIDs) of all transactions included in the block, though the TXIDs must be ordered according to consensus rules:

  • The TXID of the coinbase transaction is always listed first.
  • Any input within the block can spend an output that also exists in the block, provided the spend is valid. However, the output’s TXID must appear before the input’s TXID. This ensures any program reading block chain transactions sequentially will encounter outputs before they are spent as inputs.


If a block contains only the coinbase transaction, that transaction’s TXID becomes the merkle root hash.

If the block includes the coinbase transaction and one other transaction, the TXIDs of both transactions are placed in order, concatenated as 64 bytes, and hashed using SHA256(SHA256()) to create the merkle root.

For blocks containing three or more transactions, intermediate merkle tree rows are constructed. TXIDs are ordered and paired, starting with the coinbase transaction’s TXID. Each pair is concatenated into 64 bytes and hashed with SHA256(SHA256()) to create a second row of hashes. If the number of TXIDs is odd, the last one is duplicated and hashed with itself. The process repeats as necessary, until only two hashes remain. These are concatenated and hashed to form the final merkle root.


Example Merkle Tree Construction

TXIDs and intermediate hashes are always stored in internal byte order when concatenated, and the resulting merkle root is also stored in internal byte order when inserted into the block header.

Target nBits

The target threshold is a 256-bit unsigned integer that a header hash must be equal to or less than for the header to be valid within the blockchain. Since the nBits field in the header only provides 32 bits, the target is encoded in a more compact format, similar to base-256 scientific notation:


Converting nBits Into A Target Threshold

As a base-256 number, nBits can be quickly interpreted as bytes, similar to how decimal numbers are parsed in base-10 scientific notation:


Quickly Converting nBits

Although the target threshold is expected to be an unsigned integer, the original nBits implementation carries over some characteristics from a signed data class. This allows for a negative target threshold if the high bit of the significand is set. However, this is irrelevant, as the header hash is treated as an unsigned number, meaning it can never meet or fall below a negative threshold. BitcoinEvo Core addresses this in two ways:
  • When parsing nBits, BitcoinEvo Core converts any negative target threshold into a target of zero, theoretically allowing the header hash to equal zero.

  • When generating nBits, BitcoinEvo Core checks if the value would result in a negative interpretation. If so, it divides the significand by 256 and increments the exponent by 1 to represent the same number but with a different encoding.

Here are some examples from BitcoinEvo Core test cases:


nBits Target Notes
0x01003456 0x00
0x01123456 0x12
0x02008000 0x80
0x05009234 0x92340000
0x04923456 -0x12345600 High bit set (0x80 in 0x92).
0x04123456 0x12345600 Inverse of the above; no high bit.


For difficulty 1, which is the lowest possible difficulty, it is represented on mainnet and the current testnet by the nBits value 0x1d00ffff. Regtest mode uses a different difficulty 1 value — 0x207fffff, which is the highest possible value just below uint32_max. This allows blocks to be generated almost instantaneously in regtest mode.

Serialized Blocks

Under the current consensus rules, a block is considered invalid if its serialized size exceeds 1 MB. Every field outlined below contributes to the overall serialized size.


Bytes Name Data Type Description
80 block header block_header The block header, as detailed in the block header section.
Varies txn_count compactSize uint The total count of transactions within this block, including the coinbase transaction.
Varies txns raw transaction All transactions in the block, sequentially listed in raw transaction format. The order of transactions in the block must match the order of their TXIDs in the first row of the merkle tree. See the merkle tree section for further information.


The first transaction in the block must be a coinbase transaction, responsible for collecting and spending any transaction fees from the transactions within the block.

 Any block with a height below 6,930,000 is also entitled to a block subsidy, paid in newly minted bitcoinevo units, which should also be spent via the coinbase transaction. (This block subsidy began at 50 bitcoinevos and is halved every 210,000 blocks — roughly every four years.)

 The combination of transaction fees and the block subsidy is referred to as the block reward. A coinbase transaction is invalid if it attempts to spend more than the total available block reward.