---
title: Block Chain
description: "# [Block](https://bitcoindevelopers.org/encyclopedia/block/) Chain The following subsections briefly document core [Block](https://bitcoindevelopers.org/encyclopedia/block/) details. ## [Block](https://bitcoindevelopers.org/encyclopedia/block/) Headers [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers are serialized in the 80-byte format described below and then hashed as part of Bitcoin’s proof-of-work algorithm, making the serialized [Header](https://bitcoindevelopers.org/encyclopedia/header/) format part of…"
url: "https://bitcoindevelopers.org/docs/reference/block-chain-ref/"
updated: "2025-05-13"
category: Reference
---

# Block Chain

# [Block](https://bitcoindevelopers.org/encyclopedia/block/) Chain

The following subsections briefly document core [Block](https://bitcoindevelopers.org/encyclopedia/block/) details.

## [Block](https://bitcoindevelopers.org/encyclopedia/block/) Headers

[Block](https://bitcoindevelopers.org/encyclopedia/block/) headers are serialized in the 80-byte format described below and then hashed as part of Bitcoin’s proof-of-work algorithm, making the serialized [Header](https://bitcoindevelopers.org/encyclopedia/header/) format part of the [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/).

| Bytes | Name | Data Type | Description |
| --- | --- | --- | --- |
| 4 | version | int32_t | The [Block](https://bitcoindevelopers.org/encyclopedia/block/) version number indicates which set of [Block](https://bitcoindevelopers.org/encyclopedia/block/) validation rules to follow. See the list of [Block](https://bitcoindevelopers.org/encyclopedia/block/) versions below. |
| 32 | [Previous block header hash](https://bitcoindevelopers.org/encyclopedia/previous-block-header-hash/) | char[32] | A SHA256(SHA256()) hash in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/) of the previous [Block](https://bitcoindevelopers.org/encyclopedia/block/)’s [Header](https://bitcoindevelopers.org/encyclopedia/header/). This ensures no previous [Block](https://bitcoindevelopers.org/encyclopedia/block/) can be changed without also changing this [Block](https://bitcoindevelopers.org/encyclopedia/block/)’s [Header](https://bitcoindevelopers.org/encyclopedia/header/). |
| 32 | [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) hash | char[32] | A SHA256(SHA256()) hash in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/). The [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) is derived from the hashes of all transactions included in this [Block](https://bitcoindevelopers.org/encyclopedia/block/), ensuring that none of those transactions can be modified without modifying the [Header](https://bitcoindevelopers.org/encyclopedia/header/). See the merkle trees section below. |
| 4 | time | uint32_t | The [Block](https://bitcoindevelopers.org/encyclopedia/block/) time is a Unix epoch time when the [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) started hashing the [Header](https://bitcoindevelopers.org/encyclopedia/header/) (according to the [Miner](https://bitcoindevelopers.org/encyclopedia/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](https://bitcoindevelopers.org/encyclopedia/nbits/) | uint32_t | An encoded version of the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold this [Block](https://bitcoindevelopers.org/encyclopedia/block/)’s [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash must be less than or equal to. See the [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) format described below. |
| 4 | nonce | uint32_t | An arbitrary number miners change to modify the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash in order to produce a hash less than or equal to the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold. If all 32-bit values are tested, the time can be updated or the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction can be changed and the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) updated. |

The hashes are in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/); the other values are all in little-endian order.

An example [Header](https://bitcoindevelopers.org/encyclopedia/header/) in hex:

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

b6ff0b1b1680a2862a30ca44d346d9e8
910d334beb48ca0c0000000000000000 ... Hash of previous Block's Header
9d10aa52ee949386ca9385695f04ede2
70dda20810decd12bc9b048aaab31471 ... Merkle root

24d95a54 ........................... Unix epoch time: 1415239972
30c31b18 ........................... Target: 0x1bc330 * 256**(0x18-3)
fe9f0864 ........................... Nonce
```

### [Block](https://bitcoindevelopers.org/encyclopedia/block/) Versions

- **Version 1** was introduced in the genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/) (January 2009).
- Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/). As described in BIP34, valid version 2 blocks require a [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) parameter in the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/). Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) in [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) at [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) 227,930.
- **Version 3** blocks were introduced in Bitcoin Core 0.10.0 (February 2015) as a soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/). When the [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) reached full enforcement (July 2015), it required strict DER encoding of all ECDSA signatures in new blocks as described in BIP66. Transactions that do not use strict DER encoding had previously been non-standard since Bitcoin Core 0.8.0 (February 2012).
- **Version 4** blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2 (November 2015) as a soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) became active in December 2015. These blocks now support the new `OP_CHECKLOCKTIMEVERIFY` [Opcode](https://bitcoindevelopers.org/encyclopedia/opcode/) described in that BIP.

The mechanism used for the version 2, 3, and 4 upgrades is commonly called IsSuperMajority() after the function added to Bitcoin Core to manage those soft forking changes. See BIP34 for a full description of this method.

As of this writing, a newer method called *version bits* is being designed to manage future soft forking changes, although it’s not known whether version 4 will be the last soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) to use the IsSuperMajority() function. Draft BIP9 describes the version bits design as of this writing, although it is still being actively edited and may substantially change while in the draft state.

### Merkle Trees

The [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) is constructed using all the TXIDs of transactions in this [Block](https://bitcoindevelopers.org/encyclopedia/block/), but first the TXIDs are placed in order as required by the [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/):

- The [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction’s [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) is always placed first.
- Any [Input](https://bitcoindevelopers.org/encyclopedia/input/) within this [Block](https://bitcoindevelopers.org/encyclopedia/block/) can spend an [Output](https://bitcoindevelopers.org/encyclopedia/output/) which also appears in this [Block](https://bitcoindevelopers.org/encyclopedia/block/) (assuming the spend is otherwise valid). However, the [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) corresponding to the [Output](https://bitcoindevelopers.org/encyclopedia/output/) must be placed at some point before the [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) corresponding to the [Input](https://bitcoindevelopers.org/encyclopedia/input/). This ensures that any program parsing [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain transactions linearly will encounter each [Output](https://bitcoindevelopers.org/encyclopedia/output/) before it is used as an [Input](https://bitcoindevelopers.org/encyclopedia/input/).

If a [Block](https://bitcoindevelopers.org/encyclopedia/block/) only has a [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction, the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) is used as the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) hash.

If a [Block](https://bitcoindevelopers.org/encyclopedia/block/) only has a [Coinbase](https://bitcoindevelopers.org/encyclopedia/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](https://bitcoindevelopers.org/encyclopedia/merkle-root/).

If a [Block](https://bitcoindevelopers.org/encyclopedia/block/) has three or more transactions, intermediate [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) rows are formed. The TXIDs are placed in order and paired, starting with the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction’s [Txid](https://bitcoindevelopers.org/encyclopedia/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](https://bitcoindevelopers.org/encyclopedia/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](https://bitcoindevelopers.org/encyclopedia/merkle-root/).

  ![Example Merkle Tree Construction](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-merkle-tree-construction.svg)

Example [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) Construction

TXIDs and intermediate hashes are always in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/) when they’re concatenated, and the resulting [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) is also in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/) when it’s placed in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/).

### [Target](https://bitcoindevelopers.org/encyclopedia/target/) [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/)

The [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold is a 256-bit unsigned integer which a [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash must be equal to or below in order for that [Header](https://bitcoindevelopers.org/encyclopedia/header/) to be a valid part of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. However, the [Header](https://bitcoindevelopers.org/encyclopedia/header/) field *[nBits](https://bitcoindevelopers.org/encyclopedia/nbits/)* provides only 32 bits of space, so the [Target](https://bitcoindevelopers.org/encyclopedia/target/) number uses a less precise format called “compact” which works like a base-256 version of scientific notation:

  ![Converting nBits Into A Target Threshold](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-nbits-overview.svg)

Converting [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) Into A [Target](https://bitcoindevelopers.org/encyclopedia/target/) Threshold

As a base-256 number, [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) can be quickly parsed as bytes the same way you might parse a decimal number in base-10 scientific notation:

  ![Quickly Converting nBits](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-nbits-quick-parse.svg)

Quickly Converting [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/)

Although the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold should be an unsigned integer, the original [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) implementation inherits properties from a signed data class, allowing the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold to be negative if the high bit of the significand is set. This is useless—the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash is treated as an unsigned number, so it can never be equal to or lower than a negative [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold. Bitcoin Core deals with this in two ways:

- When parsing [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/), Bitcoin Core converts a negative [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold into a [Target](https://bitcoindevelopers.org/encyclopedia/target/) of zero, which the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash can equal (in theory, at least).
- When creating a value for [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/), Bitcoin Core checks to see if it will produce an [nBits](https://bitcoindevelopers.org/encyclopedia/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.

Some examples taken from the Bitcoin Core test cases:

| [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) | [Target](https://bitcoindevelopers.org/encyclopedia/target/) | Notes |
| --- | --- | --- |
| 0x01003456 | 0x00 |  |
| 0x01123456 | 0x12 |  |
| 0x02008000 | 0x80 |  |
| 0x05009234 | 0x92340000 |  |
| 0x04923456 | -0x12345600 | High bit set (0x80 in 0x92). |
| 0x04123456 | 0x12345600 | Inverse of above; no high bit. |

[Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) 1, the minimum allowed [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/), is represented on [Mainnet](https://bitcoindevelopers.org/encyclopedia/mainnet/) and the current [Testnet](https://bitcoindevelopers.org/encyclopedia/testnet/) by the [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) value 0x1d00ffff. [Regtest](https://bitcoindevelopers.org/encyclopedia/regtest/) mode uses a different [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) 1 value—0x207fffff, the highest possible value below uint32_max which can be encoded; this allows near-instant building of blocks in [Regtest](https://bitcoindevelopers.org/encyclopedia/regtest/) mode.

## Serialized Blocks

Under current [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/), a [Block](https://bitcoindevelopers.org/encyclopedia/block/) is not valid unless its serialized size is less than or equal to 1 MB. All fields described below are counted towards the serialized size.

| Bytes | Name | Data Type | Description |
| --- | --- | --- | --- |
| 80 | [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) | block_header | The [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) in the format described in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) section. |
| *Varies* | txn_count | [CompactSize](https://bitcoindevelopers.org/encyclopedia/compactsize/) uint | The total number of transactions in this [Block](https://bitcoindevelopers.org/encyclopedia/block/), including the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction. |
| *Varies* | txns | [Raw transaction](https://bitcoindevelopers.org/encyclopedia/raw-transaction/) | Every transaction in this [Block](https://bitcoindevelopers.org/encyclopedia/block/), one after another, in [Raw transaction](https://bitcoindevelopers.org/encyclopedia/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](https://bitcoindevelopers.org/encyclopedia/merkle-tree/). See the [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) section for details. |

The first transaction in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) must be a [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction which should collect and spend any transaction fees paid by transactions included in this [Block](https://bitcoindevelopers.org/encyclopedia/block/).

All blocks with a [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) less than 6,930,000 are entitled to receive a [Block](https://bitcoindevelopers.org/encyclopedia/block/) subsidy of newly created bitcoin value, which also should be spent in the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction. (The [Block](https://bitcoindevelopers.org/encyclopedia/block/) subsidy started at 50 [Bitcoins](https://bitcoindevelopers.org/encyclopedia/bitcoins/) and is being halved every 210,000 blocks—approximately once every four years. As of November 2017, it’s 12.5 [Bitcoins](https://bitcoindevelopers.org/encyclopedia/bitcoins/).)

Together, the transaction fees and [Block](https://bitcoindevelopers.org/encyclopedia/block/) subsidy are called the [Block reward](https://bitcoindevelopers.org/encyclopedia/block-reward/). A [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction is invalid if it tries to spend more value than is available from the [Block reward](https://bitcoindevelopers.org/encyclopedia/block-reward/).