Candidate block

A candidate block is the block a miner is trying to add to the blockchain next. It holds transactions the miner has chosen, a coinbase transaction, and a block header that is not yet valid. It only becomes part of the chain once a hash of its header falls below the target. Every miner builds its own candidate, so there is no single one that all miners share.

How is a candidate block built?

Building a candidate takes three steps, and the order is deliberate.

1. Select the transactions

The miner picks transactions from its memory pool and puts them in the block. It usually picks the ones that pay the highest fees, because the fees add to its reward. Every transaction it picks must be valid.

2. Construct the coinbase transaction

The coinbase transaction comes first in the block, and it claims the block reward. It is built after the transactions are chosen, because a block that includes SegWit transactions must commit to them. The commitment is a hash built from the witness data of every transaction, so those transactions have to be known before it can be written.

3. Construct the block header

The block header is a short summary of the whole block, and it is the part a miner hashes. It holds six fields: version, previous block hash, merkle root, time, bits and nonce. Two of them matter most here.

• Previous block hash. This names the block the candidate builds on. A miner always builds on the tip of the chain, because a block only earns its reward if it ends up in the longest chain.
• Merkle root. This is a fingerprint of every transaction in the block. Change one transaction and the merkle root changes, which changes the header. That is why the header is built last, after the transactions are fixed.

What rules must a candidate block follow?

A candidate block is only as good as its validity. Every node checks it, and a block that breaks a rule is rejected, which wastes all the work that went into it. The main rules are these.

1. The coinbase comes first

The first transaction must be the coinbase transaction. That means every block has at least one transaction, even an empty block.

2. Every transaction must be valid

Each transaction can only spend coins that already exist and that are not spent elsewhere in the block. A single bad transaction makes the whole block invalid.

3. Parents come before children

If a transaction spends an output of another transaction in the same block, the parent must be higher up. Nodes check the block from top to bottom, so a child placed above its parent would appear to spend outputs that do not exist yet.

4. The block has a size limit

A block may weigh at most 4,000,000 weight units. Weight is how SegWit counts size: witness data counts a quarter as much as the rest of the transaction. The header and the transaction count count toward the limit too. The value is set in the consensus code.

5. The block has a signature limit

A block may contain at most 80,000 signature check operations. These are the script opcodes that verify a signature, such as OP_CHECKSIG and OP_CHECKMULTISIG. The limit exists because checking a signature takes time, and a block full of them would be slow for every node to validate. Under the SegWit rules, a signature check in a legacy scriptSig counts four times toward the limit, while one in a SegWit witness counts once.

How do miners choose transactions?

A miner can put any valid transactions in its block, but it wants the most fees it can get. When the memory pool holds more transactions than fit, the miner takes the highest-paying ones first. For a fee rate it compares fee against virtual size.

Ancestors make this harder. A transaction can only go in a block after its unconfirmed parents do. So a miner cannot judge a transaction by its own fee alone. It looks at the ancestor feerate, which is the average fee rate of the transaction and everything it depends on. A child with a large fee can lift a low-paying parent into a block. This is how child pays for parent works.

Finding the single best combination of transactions would mean checking every possible set, which is too slow. So most miners make a good attempt rather than a perfect one, and they keep the time spent on it short.

Why do some blocks come out empty?

Choosing transactions takes time. Some miners start hashing at once, on a candidate that holds only the coinbase transaction, and fill it in as they go. If that block is found first, it is mined empty. It happens rarely, but it explains why an empty block sometimes appears in the chain.

Block 828,012 is one example. It holds only its coinbase transaction, while the blocks on either side hold 4,385 and 5,639 transactions. A miner who mines an empty block still collects the subsidy. It only gives up the fees.

How do you see a candidate block?

Bitcoin Core builds one for you with the getblocktemplate RPC. It takes a template request, and you must ask for the segwit rule, following BIP 22:

bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'

The result contains the transactions chosen from your node's memory pool, the previous block hash, the bits, the time and the target. It does not contain a finished block. You still build the coinbase transaction, work out the merkle root, and do the hashing yourself. The template does the heavy job of choosing transactions for you.

Is a transaction in the candidate sure to be mined?

Not quite. Each miner selects from its own memory pool, and no two pools are identical. Most candidates overlap a great deal, so a transaction sitting in one is likely to be mined in the next block. It is not guaranteed.

If a transaction has a low fee, it can drop out of a candidate when a better-paying one arrives. For what happens when a transaction waits too long, see the mempool page. For speeding one up, see replace-by-fee.