BA-08 · LESSON 04

Block validation

KEY DEFINITIONS

Terms used in this lesson

Coinbase transaction: The special first transaction in a Bitcoin block, which claims permitted subsidy and fees and has no ordinary prior-output input.
UTXO: Unspent transaction output: one discrete chunk of bitcoin that can be used as a transaction input.
Block subsidy: New bitcoin that consensus permits a block's coinbase transaction to create at a particular height.
Proof-of-work target: The maximum header-hash value accepted for a block; lowering it makes valid hashes harder to find.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.

Full nodes independently check proof of work, transactions, scripts, issuance, weight, and contextual consensus rules.

65 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · proof of workTransactions become an independently validated proof-of-work historySelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
CANDIDATESValid transactions
A miner selects transactions while each node retains its own validation rules.
02
MERKLE ROOTOrdered commitment
Transaction identifiers are reduced to one header commitment.
03
HEADERPrevious hash, target, nonce
The header commits to the parent block, transactions, time, target, and nonce.
04
WORKBlock validation
The Block validation mechanism determines how costly the candidate is to replace.
05
CHAINValid most-work branch
Temporary forks resolve by accumulated work among branches that pass every rule.

Rule shown: Miners propose ordered blocks; full nodes accept only valid blocks and select the valid chain with most accumulated work.

STAGE 1 OF 5CANDIDATES: Valid transactions

A miner selects transactions while each node retains its own validation rules.

Governing relationship: Miners propose ordered blocks; full nodes accept only valid blocks and select the valid chain with most accumulated work. Complete path: 1. CANDIDATES, Valid transactions. A miner selects transactions while each node retains its own validation rules. 2. MERKLE ROOT, Ordered commitment. Transaction identifiers are reduced to one header commitment. 3. HEADER, Previous hash, target, nonce. The header commits to the parent block, transactions, time, target, and nonce. 4. WORK, Block validation. The Block validation mechanism determines how costly the candidate is to replace. 5. CHAIN, Valid most-work branch. Temporary forks resolve by accumulated work among branches that pass every rule.

1. State transitionWhat exists, what changes, and what results

BEFORE

A block has valid work and three ordinary transactions. The second transaction spends an output already consumed by the first transaction in the same block.

MECHANISM

Check known parent, expected target, proof-of-work hash, permitted timestamp, version rules, and chain linkage.

AFTER

Block connection is all or nothing; valid proof and some valid transactions cannot rescue one consensus-invalid spend.

Text equivalent: Starting from A block has valid work and three ordinary transactions. The second transaction spends an output already consumed by the first transaction in the same block. The mechanism begins when Check known parent, expected target, proof-of-work hash, permitted timestamp, version rules, and chain linkage. The resulting lesson is Block connection is all or nothing; valid proof and some valid transactions cannot rescue one consensus-invalid spend.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Validate header context

Check known parent, expected target, proof-of-work hash, permitted timestamp, version rules, and chain linkage.

Complete path: 1. Validate header context: Check known parent, expected target, proof-of-work hash, permitted timestamp, version rules, and chain linkage. 2. Validate block structure: Check size or weight, exactly one first-position coinbase, transaction count, Merkle root, and witness commitment when required. 3. Validate transactions in order: For each input, find an existing unspent output from prior chainstate or an earlier transaction in the block and execute its spending rules. 4. Check value and issuance: Outputs cannot create value from ordinary inputs. Coinbase output total cannot exceed the permitted subsidy plus all block fees. 5. Commit state atomically: Only after all checks pass does the node connect the block, remove spent outputs, add new outputs, and update the accepted tip.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Header, commitment, transaction, script, value, issuance, and contextual checks all pass against one temporary UTXO view before an atomic state commit.

CHANGED CONDITION

Bad proof, wrong root, duplicate spend, value creation, or excessive coinbase rejects the entire block and preserves prior chainstate.

Important distinction: A miner's block is trusted because producing proof of work gives the miner temporary authority over validation. Proof selects costly history among valid candidates. Each node still applies every consensus rule before accepting state.

Text equivalent: The accepted path is enforced by Header, commitment, transaction, script, value, issuance, and contextual checks all pass against one temporary UTXO view before an atomic state commit. If the required condition changes, Bad proof, wrong root, duplicate spend, value creation, or excessive coinbase rejects the entire block and preserves prior chainstate.

Loading lesson visuals...

Learn the idea

Block validation is the deterministic process a full node uses before accepting a candidate block. Header checks cover proof, target, time, and parent context. Transaction checks cover syntax, UTXO availability, scripts, values, issuance, lock conditions, and block-wide limits. Passing relay policy is not required for a mined transaction, but passing consensus is.

GUIDED EXPLANATION1/5 ideas inspected

Validate header context

Check known parent, expected target, proof-of-work hash, permitted timestamp, version rules, and chain linkage.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A miner's block is trusted because producing proof of work gives the miner temporary authority over validation.”

Proof selects costly history among valid candidates. Each node still applies every consensus rule before accepting state.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.