TERM_DEF // BLOCK / BLOCK_VALIDATION
BLOCK
VALIDATION
VALIDATION
block-validation/">Block Validation. Verifying header PoW, timestamp rules, transaction validity, Merkle root, and consensus limits.
This page sits in the Block section — The 80-byte header and the transaction batch beneath it — what miners actually produce. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Block section — The 80-byte header and the transaction batch beneath it — what miners actually produce. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_BLOCK_VALIDATION_IS
Block Validation — at a glance
BLOCK
Block Validation is part of the structure of a single Bitcoin block — the container that batches confirmed transactions and chains them to the previous block via cryptographic hash. Verifying header PoW, timestamp rules, transaction validity, Merkle root, and consensus limits. Understanding block anatomy unlocks how mining, validation, and SPV proofs work.
Why it exists
DESIGN
Transactions arrive at the network constantly, but consensus needs a synchronisation point — a moment when everyone agrees on a specific batch and ordering. The block is that batch. Its 80-byte header is what miners actually hash, and its Merkle root commits to every transaction inside, so changing any transaction breaks the whole block's identity. Without this structure there would be no proof-of-work and no canonical history.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
A block is a binary serialisation: an 80-byte header followed by a varint transaction count and the transactions themselves. The header has 6 fields totalling exactly 80 bytes: version (4), previous hash (32), merkle root (32), timestamp (4), bits/target (4), nonce (4). Block Validation is one of those moving parts.
1. Miner assembles candidate block: coinbase tx first, then fee-paying txs sorted by fee-per-weight.
2. Merkle root computed bottom-up over all txid pairs — single 32-byte commitment to the entire block body.
3. Header populated: previous block hash, merkle root, current time, current target ("bits"), starting nonce.
4. Miner double-SHA-256s the 80-byte header, checks hash < target, increments nonce, repeats until success.
5. Valid block broadcast; nodes re-validate header + every transaction + every script before accepting.
6. Accepted block becomes the new chain tip; its hash is what the *next* block's header will commit to.
WORKED_EXAMPLE
An 80-byte block header — every field, every byte
EXAMPLE
Offset Bytes Field Example value (little-endian where applicable)
─────────────────────────────────────────────────────────────────────────────
0 4 version 02 00 00 00 (block version)
4 32 prev_block_hash ab cd … ef 00 00 00 … (previous block's hash)
36 32 merkle_root 11 22 … 33 44 55 66 … (commits to all txs)
68 4 timestamp 6f 00 ed 65 (Unix seconds)
72 4 bits ff 0f 03 17 (compact target)
76 4 nonce 41 a8 27 cd (the magic 4 bytes miners search)
─────────────────────────────────────────────────────────────────────────────
80 0+ followed by the block body: tx_count + transactions
Block hash = SHA256(SHA256(header)) — must be ≤ target to be valid.
KEY_PROPERTIES
FIXED HEADER SIZE
The header is always exactly 80 bytes — by design, so mining hardware can ASIC-optimise the hash loop.
COINBASE FIRST
The first transaction in every block is the coinbase (miner reward). The rest follow in fee-priority order.
COMMITTED ORDER
Transaction order inside the block is fixed by the Merkle root — you cannot reorder without changing the block hash.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- "Block size" and "block weight" are different — SegWit introduced the weight metric (witness data counts ¼) to expand effective capacity without a fork/">hard fork.
- The block timestamp is approximate, not authoritative — miners pick it. Consensus only requires it within a small window of network-perceived time.
- An "orphan block" was a valid block that lost the race; transactions inside return to the mempool and usually re-confirm in the next block.
WHERE_YOU'LL_SEE_IT
Pages on this site that cover Block Validation in more depth:
RELATED_CONCEPTS
Other terms from Block — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Block Validation
Verifying header PoW, timestamp rules, transaction validity, Merkle root, and consensus limits.
Block Header
An 80-byte structure containing version, previous block hash, Merkle root, timestamp, bits, and nonce — the input miners hash.
Block Hash
HASH256 of the 80-byte header; the value miners must drive below the target.
Block Height
Zero-based index of a block from genesis; not part of the header — derived by counting.
Block Reward
Coinbase output value: subsidy + transaction fees.
Block Subsidy
The newly-minted bitcoin in the coinbase, halving every 210,000 blocks.
Block Time (10 minutes)
Target average interval between blocks, maintained by the difficulty-adjustment/">difficulty adjustment.
Block Size
The serialized byte length of a block; SegWit replaced this with weight as the consensus limit.