Candidate Blocks: How Miners Assemble Transactions in Memory

A Candidate Block is a temporary block structure created by a miner or mining pool that contains a selection of unconfirmed transactions from their local mempool. It represents a potential addition to the blockchain, which will only become permanent if the miner successfully resolves the Proof of Work hashing target.

This guide details the structural differences between candidate and validated blocks, and the prioritization algorithms miners run to maximize fee revenue.

🏗️ 1. Candidate Blocks vs. Validated Blocks

• Candidate Block: A work-in-progress ledger page. It has a completed list of transactions and a valid Merkle root, but its block header contains a placeholder or random Nonce value that does not yet satisfy the consensus network difficulty target.
• Validated Block: A finalized candidate block. A miner has found a valid Nonce that, when hashed with the rest of the 80-byte header, produces a double-SHA256 value below the network's active cryptographic Target. Once validated, it is instantly propagated across P2P sockets for inclusion in nodes' blockchains.

🗂️ 2. The Transaction Selection Pipeline

Miners are financially incentivized to maximize their fee yields. However, selecting transactions is not as simple as sorting the mempool by the highest individual feerate.

                       CANDIDATE BLOCK TRANSACTION SELECTION

                       ┌──────────────────────────────────┐
                       │      Local Node Mempool RAM      │
                       └────────────────┬─────────────────┘
                                        │
                                        ▼  [Build Ancestor Packages]
                       ┌──────────────────────────────────┐
                       │     Compute Ancestor Feerates     │
                       │  • Group parents + children      │
                       │  • Sum fees / Sum virtual sizes  │
                       └────────────────┬─────────────────┘
                                        │
                                        ▼  [Sort Packages Greedily]
                       ┌──────────────────────────────────┐
                       │      Prioritized Queue List      │
                       │  • Highest package feerate first │
                       └────────────────┬─────────────────┘
                                        │
                                        ▼  [Fill Candidate Block]
                       ┌──────────────────────────────────┐
                       │    Include Coinbase Transaction  │
                       │    Add high-scoring packages     │
                       │    Verify Weight & SigOp Bounds  │
                       └──────────────────────────────────┘

The Selection Steps:

1. Coinbase Prep: The miner reserves Leaf 0 of the block's Merkle tree for the Coinbase Transaction, which awards them the block subsidy plus the combined fees of all chosen transactions.
2. CPFP Package Awareness: The miner's block-builder engine evaluates unconfirmed transaction dependency trees. If a low-fee parent transaction is required to validate a high-fee child, they are evaluated together as a single package using the Ancestor Feerate formula: $$F_{\text{package}} = \frac{\sum \text{Fees}}{\sum \text{Sizes}}$$
3. Greedy Packing: The engine sorts packages in descending order of their package feerate and starts stuffing them into the block workspace.
4. Dependency Checks: If a transaction is selected, all of its unconfirmed ancestors must be pulled into the block ahead of it. If an ancestor violates block limits or fails validation, the child transaction is bypassed.
5. Limit Auditing: Packing continues until the addition of another transaction package would breach the block's weight capacity (4,000,000 Weight Units) or signature operation capacity (20,000 SigOps).