Block Validation Rules

A block arriving over the network is a claim: “here is the next chunk of valid history, please accept it.” Bitcoin’s defining property is that no one is trusted to make that claim — not the miner, not your peers, not a foundation. Instead, every full node independently re-checks every block against the same rulebook and accepts it only if it passes all checks. This page is that rulebook. Understanding it is understanding what “trustless” actually means in practice: not “trust no one,” but “verify everything yourself.” It builds directly on the UTXO set vs the chain.

Validation is local, total, and identical

Three properties make this work:

• Local — each node checks the block itself; it does not ask anyone whether the block is good.
• Total — a block is accepted only if it passes every rule; one failure means rejection.
• Identical — every node runs the same deterministic rules, so honest nodes always reach the same verdict on the same block.

That last property is subtle and crucial: because validation is deterministic, untrusting strangers who never communicate still converge on the same set of valid blocks. The rulebook is the shared agreement.

The checks, grouped

   INCOMING BLOCK
        │
        ▼
   ┌─────────────────────────────────────────────┐
   │ 1. Header / Proof of Work                    │
   │    - hash(header) ≤ target encoded in 'bits' │
   │    - 'bits' is the correct difficulty        │
   │    - prev-hash links to a known block        │
   ├─────────────────────────────────────────────┤
   │ 2. Structure                                 │
   │    - recomputed Merkle root == header's root │
   │    - first tx is a coinbase, only one        │
   │    - within weight limit (≤ 4,000,000 WU)    │
   ├─────────────────────────────────────────────┤
   │ 3. Every transaction                         │
   │    - inputs spend EXISTING, UNSPENT outputs  │
   │    - all scripts execute and PASS            │
   │    - Σ inputs ≥ Σ outputs (conservation)     │
   ├─────────────────────────────────────────────┤
   │ 4. Coinbase                                  │
   │    - value ≤ subsidy + total fees            │
   ├─────────────────────────────────────────────┤
   │ 5. Time                                      │
   │    - timestamp > median of last 11 blocks    │
   │    - timestamp not too far in the future     │
   └─────────────────────────────────────────────┘
        │
        ▼  all pass → accept & extend chain;  any fail → reject

1. Proof of work meets the target

The node hashes the 80-byte header and confirms the result is at or below the target encoded in the bits field — and that the bits value is itself the correct difficulty for this height per the retargeting rules (Proof of Work). A block without sufficient work is rejected outright, no matter who sent it. This is the energy receipt.

2. Valid Merkle root and structure

The node recomputes the Merkle root from the actual transactions and checks it equals the value in the header. This is what binds the header’s proof of work to these specific transactions — a miner can’t do the work on one transaction set and ship a different one. It also confirms the first transaction is a coinbase (and the only coinbase) and that the block is within the 4,000,000 weight-unit limit.

3. Every transaction is valid

For each non-coinbase transaction, the node checks the three pillars of transaction validity:

Check	Why it matters
Inputs exist and are unspent	Prevents double-spends — every input must reference an entry in the UTXO set
Scripts pass	The spender satisfies each output’s locking script (e.g. a valid signature) — proves authorization
Conservation	Sum of input values ≥ sum of output values — no coins created from thin air

The UTXO set is the key data structure here: it is the node’s index of every spendable coin. An input that names an output not in the UTXO set is either already spent or never existed — either way the transaction (and the whole block) is rejected. This is precisely the double-spend defense.

4. The coinbase doesn’t overpay

The miner’s coinbase output may pay at most the block subsidy plus the sum of all fees in the block (fees = total inputs − total outputs across the other transactions). Claim a single satoshi more and the block is invalid. The network’s monetary policy is enforced here, by every node, on every block — there is no separate authority minting coins.

5. Timestamp rules

The timestamp must be greater than the median of the previous 11 blocks’ timestamps (the “median-time-past” rule) and not too far in the future (roughly a couple of hours ahead of the node’s clock). These loose bounds stop miners from lying about time to game the difficulty adjustment, without requiring synchronized clocks across a global, leaderless network.

Why each node insists on checking itself

It would be far “cheaper” to just trust the miner, or to trust a few well-known peers. Bitcoin refuses, and that refusal is the whole point. If you trusted others to validate, you’d be back to trusting an authority — exactly what Bitcoin exists to remove. Independent validation is what lets you run a node, accept payments, and know the rules were followed without asking anyone’s permission. The cost of verification is the price of not needing trust.

Invalid blocks are simply ignored

A node that finds a block invalid doesn’t punish anyone or raise an alarm — it just drops the block and keeps building on the chain it already trusts. Because every honest node applies the same rules, an invalid block finds no home anywhere on the honest network. The miner who produced it forfeits the electricity they spent. Bad blocks aren’t outlawed; they’re worthless.

It actually happened — the inflation bug hiding in Bitcoin Core (CVE-2018-17144, 2018)

Validation rules are only as good as the code enforcing them. In September 2018 a bug was disclosed in Bitcoin Core (affecting roughly versions 0.14.0 through 0.16.2): a performance refactor had quietly removed the check for a transaction that spends the same input twice within itself. The visible symptom was a crash — a denial-of-service assertion failure — but the latent danger was far worse: under the right conditions a miner could have created coins from nothing, breaking the conservation rule and inflating the supply. It was responsibly disclosed and patched in 0.16.3 before anyone exploited it. This is exactly why the page insists that each node validate independently: consensus code is fragile, and the more diverse and carefully-reviewed the implementations checking every block, the harder a single silent bug is to weaponize. See famous incidents & attacks.

The thread

How does this help untrusting strangers agree on one ledger? Block validation is the mechanism of agreement itself. Because the rules are deterministic and every node runs them independently, a block that is valid is valid for everyone, and a block that is invalid is rejected by everyone — with no coordination, no voting, and no trusted referee. Strangers who share nothing but the rulebook end up holding the identical ledger, because each of them computed it from the same data with the same rules. The blockchain isn’t a thing you’re told to believe; it’s a result you can derive.

The architect’s lens

Step back from the five groups of checks and answer the five questions that turn an implementer into an architect:

• Why does it exist? To replace trust with verification — every full node independently re-checks every block against one deterministic rulebook (PoW, Merkle root, transaction validity, conservation, limits, timestamps) and accepts it only if it passes all of them.
• What problem does it solve? It makes the ledger a result you derive, not a claim you’re told to believe: because the rules are local, total, and identical, untrusting strangers who never communicate still converge on the exact same set of valid blocks.
• What are the trade-offs? Validation is expensive and duplicated — every node redoes the same work, recomputing the Merkle root and re-checking every signature against the UTXO set — and it is only as sound as the consensus code, as CVE-2018-17144 showed.
• When is a different design better? When you don’t need to remove a trusted authority — a permissioned ledger can let known validators sign blocks and have everyone else trust them, skipping the cost of universal independent re-validation.
• What breaks if I remove it? Stop validating locally and you’re back to trusting the miner or a few peers — the very authority Bitcoin exists to remove; invalid blocks would no longer be worthless, so coins could be conjured past the subsidy and double-spends would slip through.

Check your understanding

1. What three properties (local, total, identical) describe how nodes validate, and why does “identical” cause strangers to converge on the same ledger?
2. Why does a node recompute the Merkle root rather than trusting the one in the header?
3. What are the three validity checks applied to every non-coinbase transaction, and which one is the double-spend defense?
4. How is Bitcoin’s monetary policy enforced during block validation, and by whom?
5. Why does Bitcoin insist that each node validate independently instead of trusting the miner or a few peers? What is the cost, and what is bought with it?

Show answers

1. Local — each node checks the block itself, asking no one. Total — a block is accepted only if it passes every rule. Identical — every node runs the same deterministic rules. Because validation is deterministic and identical, untrusting strangers who never communicate still converge on the same set of valid blocks — the rulebook is the shared agreement.
2. To bind the header’s proof of work to these specific transactions. A miner could do the work on one transaction set and ship a different one; recomputing the Merkle root from the actual transactions and checking it matches the header catches that.
3. (a) Inputs exist and are unspent — every input must reference an entry in the UTXO set; (b) scripts pass — the spender satisfies each locking script; (c) conservation — Σ inputs ≥ Σ outputs. The first is the double-spend defense: an input naming an output not in the UTXO set is already spent or never existed.
4. The coinbase may pay at most the block subsidy plus the sum of all fees; claim one satoshi more and the block is invalid. It is enforced by every full node, on every block — there is no separate minting authority.
5. Trusting others to validate would put you back to trusting an authority — exactly what Bitcoin exists to remove. The cost is the work of verifying everything yourself; what’s bought is the ability to accept payments and know the rules were followed without asking anyone’s permission.