Block Header
Block headers serve an important intermediary role in the creation and transmission of blocks. They are a fixed-width (80-byte) representation of the entire block. With a block header, you can:
- Calculate the hash of the block.
- The double SHA-256 hash of the block header.
- Confirm the proof of work was executed correctly.
- Determine the relative location of the block in the blockchain.
- Using the previous block hash contained in the header
Since validation of all the transactions in the block can be expensive, the ability to perform these checks on the block before downloading and validating its transactions helps make denial-of-service attacks on the network significantly more expensive for attackers.
Block Header Format
| Field | Length | Format | Description |
|---|---|---|---|
| version | 4 bytes | signed integer(LE) | The block format version. Since BIP-65 (block 388381), the version must be at least 4 when interpreted as a signed 32-bit integer, so values with the most significant bit set are invalid. See Version Values in Practice. For more details refer to the block version history. |
| previous block hash | 32 bytes | block hash(LE) | The hash of the block immediately preceding this block in the blockchain. |
| merkle root | 32 bytes | merkle root(LE) | The merkle tree root of the transactions in the block. |
| timestamp | 4 bytes | unix timestamp(LE) | The epoch timestamp of the block in seconds. |
| target | 4 bytes | compressed target(LE) | The target that the block hash must be below to be valid. This value is determined by the timestamps of previously mined blocks. See Target for more information. |
| nonce | 4 bytes | bytes(LE) | A random value that is repeatedly changes during block mining in order to achieve the block hash requirements. |
Version Values in Practice
Note: The version of a recent block is generally not a meaningful format version. Consensus only requires it to be at least 4, and miners use the remaining freedom for signalling and as extra nonce space.
BIP-9 reinterprets the field as version bits: the top 3 bits are 001, giving integer values from 0x20000000 to 0x3FFFFFFF, and the remaining bits may signal soft-fork deployments.
BIP-320 reserves bits 13-28 (integer mask 0x1FFFE000) for general use, such as miners rolling them as additional nonce space.
For example, the integer value 0x20000000 is serialized as 00 00 00 20 (little-endian), and the integer value 4 is serialized as 04 00 00 00.
Compressed Target Format
Within the block header, the target uses a special floating-point representation that helps keep the size of the block header small. While the difficulty adjustment algorithm attempts to calculate the ideal target (i.e. the value the block hash must be "less than"), it undergoes a lossy conversion when put in the block header:
| Field | Length | Format | Description |
|---|---|---|---|
| exponent | 1 byte | byte | Used to calculate the offset for the signficand. The actual exponent is 8 * (exponent - 3). |
| significand | 3 byte | bytes | The significand, or mantissa, of the value. |
Ultimately, the target is equal to:
significand * 2(8 * (exponent - 3))