BA-00 · LESSON 03

Blocks, mining, difficulty, and 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.
Proof-of-work target: The maximum header-hash value accepted for a block; lowering it makes valid hashes harder to find.
SHA-256: A cryptographic hash function used throughout Bitcoin to produce fixed-size 256-bit digests.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.

See how a candidate block is assembled, how proof of work is found, how difficulty is encoded, and why full nodes still decide whether the block is valid.

55 min Difficulty 1/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 · candidate blockCandidate transactions become a node-validated proof-of-work blockSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
CANDIDATECoinbase and valid packages
The miner orders parents before children and begins with exactly one coinbase.
02
MERKLE ROOTRoot A
Any changed transaction or ordering changes the transaction commitment.
03
HEADER80 bytes
Version, parent, root, time, nBits, and nonce form the proof-of-work message.
04
HASH VS TARGETHash <= target
Proof is an exact numeric comparison under the height-specific target.
05
NODEValidate and connect
Work cannot bypass invalid transactions, issuance, scripts, weight, or context.

Rule shown: A miner rebuilds commitments and searches below the target; full nodes independently validate every committed rule.

STAGE 1 OF 5CANDIDATE: Coinbase and valid packages

The miner orders parents before children and begins with exactly one coinbase.

Governing relationship: A miner rebuilds commitments and searches below the target; full nodes independently validate every committed rule. Complete path: 1. CANDIDATE, Coinbase and valid packages. The miner orders parents before children and begins with exactly one coinbase. 2. MERKLE ROOT, Root A. Any changed transaction or ordering changes the transaction commitment. 3. HEADER, 80 bytes. Version, parent, root, time, nBits, and nonce form the proof-of-work message. 4. HASH VS TARGET, Hash <= target. Proof is an exact numeric comparison under the height-specific target. 5. NODE, Validate and connect. Work cannot bypass invalid transactions, issuance, scripts, weight, or context.

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

BEFORE

A miner has a valid header for a candidate block, then adds one higher-fee transaction.

MECHANISM

A miner chooses transactions from its local mempool, respects parent before child order, begins with exactly one coinbase transaction, and commits the ordered transaction ide…

AFTER

Mining proposes expensive ordering; full-node validation decides whether the proposal can change accepted state.

Text equivalent: Starting from A miner has a valid header for a candidate block, then adds one higher-fee transaction. The mechanism begins when A miner chooses transactions from its local mempool, respects parent before child order, begins with exactly one coinbase transaction, and commits the ordered transaction identifiers into a Merkle root. The resulting lesson is Mining proposes expensive ordering; full-node validation decides whether the proposal can change accepted state.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Assemble a candidate

A miner chooses transactions from its local mempool, respects parent before child order, begins with exactly one coinbase transaction, and commits the ordered transaction identifiers into a Merkle root.

Complete path: 1. Assemble a candidate: A miner chooses transactions from its local mempool, respects parent before child order, begins with exactly one coinbase transaction, and commits the ordered transaction identifiers into a Merkle root. 2. Build the 80-byte header: The header contains version, previous-block hash, Merkle root, time, compact target called nBits, and nonce. Changing the coinbase or transaction order changes the root and therefore the header hash. 3. Search below the target: The miner hashes header variations twice with SHA-256 and interprets the result as a 256-bit number. Proof of work passes only when that number is at or below the target decoded from nBits. 4. Retarget every 2,016 blocks: Nodes compare the actual retarget timespan with two weeks and adjust the target within defined bounds. Faster blocks make the next target smaller and the work harder; slower blocks do the opposite. 5. Validate before changing chainstate: A node verifies the parent, target, proof of work, Merkle and witness commitments, transaction syntax, input availability, Script results, weight, and permitted coinbase value. Any failure rejects the whole block.

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

ACCEPTED PATH

The exact header hash must meet the height-specific target and every committed transaction must pass all consensus checks.

CHANGED CONDITION

Proof of work on one header cannot be copied to a header with a changed transaction, parent, time, target, version, or nonce.

Important distinction: A miner that finds enough proof of work can include an invalid transaction. Full nodes reject an invalid block even when its header hash satisfies proof of work. Work orders valid history; it does not replace validity rules.

Text equivalent: The accepted path is enforced by The exact header hash must meet the height-specific target and every committed transaction must pass all consensus checks. If the required condition changes, Proof of work on one header cannot be copied to a header with a changed transaction, parent, time, target, version, or nonce.

Loading lesson visuals...

Learn the idea

Mining packages valid transactions into candidate blocks and searches for proof of work. The target states how small the block-header hash must be. Difficulty is a comparison scale derived from that target. Finding proof of work lets a miner propose a block, but every full node independently recomputes the header, transactions, issuance, scripts, and state transition before accepting it.

GUIDED EXPLANATION1/5 ideas inspected

Assemble a candidate

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A miner that finds enough proof of work can include an invalid transaction.”

Full nodes reject an invalid block even when its header hash satisfies proof of work. Work orders valid history; it does not replace validity rules.

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.