BA-08 · LESSON 10

Mining lifecycle and candidate blocks

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.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
Proof-of-work target: The maximum header-hash value accepted for a block; lowering it makes valid hashes harder to find.
Hash rate: The number of mining hash attempts performed per second.
Block subsidy: New bitcoin that consensus permits a block's coinbase transaction to create at a particular height.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.

Follow mempool selection, ancestor packages, template construction, coinbase and witness commitments, target search, broadcast, and independent full-node validation.

45 min Difficulty 3/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 · mining lifecyclePackage selection becomes one candidate and one independently checked blockSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
MEMPOOLValid ancestor packages
A high fee cannot make an invalid dependency eligible.
02
COINBASEHeight, payout, and reserved value
The coinbase establishes extranonce space and permitted miner revenue.
03
ROOTSTxid and wtxid commitments
Changing the candidate requires rebuilding coinbase and roots.
04
SEARCHHeader hash <= target
An easier pool target result may earn credit without creating a network-valid block.
05
NODESValidate and relay
Every full node repeats proof, transaction, Script, issuance, and context checks.

Rule shown: Fees influence selection, proof of work orders the candidate, and full nodes enforce all validity rules.

STAGE 1 OF 5MEMPOOL: Valid ancestor packages

A high fee cannot make an invalid dependency eligible.

Governing relationship: Fees influence selection, proof of work orders the candidate, and full nodes enforce all validity rules. Complete path: 1. MEMPOOL, Valid ancestor packages. A high fee cannot make an invalid dependency eligible. 2. COINBASE, Height, payout, and reserved value. The coinbase establishes extranonce space and permitted miner revenue. 3. ROOTS, Txid and wtxid commitments. Changing the candidate requires rebuilding coinbase and roots. 4. SEARCH, Header hash <= target. An easier pool target result may earn credit without creating a network-valid block. 5. NODES, Validate and relay. Every full node repeats proof, transaction, Script, issuance, and context checks.

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

BEFORE

A 200 vB parent pays 200 satoshis and a 120 vB child pays 4,600 satoshis.

MECHANISM

Evaluate fee rate across ancestors and descendants, dependencies, conflicts, weight, sigops, finality, and local block-template policy. Parents must appear before children.

AFTER

Mining optimizes a candidate under constraints, then full nodes make the acceptance decision independently.

Text equivalent: Starting from A 200 vB parent pays 200 satoshis and a 120 vB child pays 4,600 satoshis. The mechanism begins when Evaluate fee rate across ancestors and descendants, dependencies, conflicts, weight, sigops, finality, and local block-template policy. Parents must appear before children. The resulting lesson is Mining optimizes a candidate under constraints, then full nodes make the acceptance decision independently.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Select transaction packages

Evaluate fee rate across ancestors and descendants, dependencies, conflicts, weight, sigops, finality, and local block-template policy. Parents must appear before children.

Complete path: 1. Select transaction packages: Evaluate fee rate across ancestors and descendants, dependencies, conflicts, weight, sigops, finality, and local block-template policy. Parents must appear before children. 2. Construct the coinbase: Create the height commitment, extranonce space, payout outputs, optional pool data, and a total claim no greater than height-specific subsidy plus selected transaction fees. 3. Build transaction and witness roots: Order coinbase first, compute every txid and Merkle root, compute the witness Merkle root when required, place the witness commitment in coinbase, then rebuild coinbase txid and the ordinary root. 4. Search the header space: Set version, previous hash, root, time, nBits, and nonce. Hash candidate headers, vary nonce, coinbase extranonce, time, or version bits as allowed, and compare each 256-bit result with the target. 5. Publish and survive validation: Peers parse and check header proof, parent, transaction structure, duplicate spends, Script, values, issuance, weight, commitments, and context before relaying or connecting the block.

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

ACCEPTED PATH

Every package and block must satisfy consensus, template policy, value conservation, block-resource limits, ordered commitments, target comparison, and independent node validation.

CHANGED CONDITION

A high-fee child cannot make an invalid parent valid, and a valid share at an easier pool target is not necessarily a network-valid block.

Important distinction: Miners simply hash the list of mempool transactions until one becomes a block. Miners build a structured candidate with coinbase, ordered transactions, commitments, target, and an 80-byte header, then vary header-linked data while nodes enforce the result.

Text equivalent: The accepted path is enforced by Every package and block must satisfy consensus, template policy, value conservation, block-resource limits, ordered commitments, target comparison, and independent node validation. If the required condition changes, A high-fee child cannot make an invalid parent valid, and a valid share at an easier pool target is not necessarily a network-valid block.

Loading lesson visuals...

Learn the idea

A mining lifecycle begins with a node's local transaction candidates and ends only when independently verifying nodes accept the published block. A miner chooses economically and technically valid packages, constructs coinbase and commitments, searches header variations below the target, broadcasts the result, and learns success from network acceptance rather than from hash rate alone.

GUIDED EXPLANATION1/5 ideas inspected

Select transaction packages

Evaluate fee rate across ancestors and descendants, dependencies, conflicts, weight, sigops, finality, and local block-template policy. Parents must appear before children.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Miners simply hash the list of mempool transactions until one becomes a block.”

Miners build a structured candidate with coinbase, ordered transactions, commitments, target, and an 80-byte header, then vary header-linked data while nodes enforce the result.

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.