Candidate Block

Next block to be added to the blockchain

Diagram showing a candidate block as a collection of transactions from the memory pool.

A candidate block is a block of transactions a miner attempts to add to the blockchain.

During the mining process, each miner will collect transactions from their memory pool in to a candidate block. They will then repeatedly hash this block to try and get a block hash below the target.

If a miner can get a block hash below the target, their candidate block can be added on to the blockchain.

They will then broadcast this "mined" candidate block to the other nodes on the network, where each node will verify and add it to their blockchain too.

Diagram showing a miner broadcasting their mined candidate block to the other nodes on the network.

In other words, a candidate block represents the next block of transactions to be added on to the blockchain.


What does the current candidate block look like?

Here's what the current candidate block looks like according to my local node:

Block Header Candidate Block Header Refreshing

Version 0x20000000
Previous Block 000000000000000000003eb740be632a4246f58f15822e9341faf6b056f2e419
Merkle Root 6ef5d9f70995ab091e64bf9f3f8be4fbb059939cd19c3e2c03064bab415d04f3
Bits 17034219
Nonce 0

Transactions Candidate Block Transactions Refreshing

Show Transactions Loading Transactions


How do you construct a candidate block?

Diagram showing the steps for constructing a candidate block.

There are three basic steps to constructing a candidate block:

1. Select transactions

The first step is to select transactions from the memory pool that you want to include in your candidate block.

A miner will typically fill their candidate block with the highest-fee transactions to maximize the amount they can claim from the block reward.

2. Construct the coinbase transaction

The coinbase transaction is the very first transaction in a block, and it's used by the miner to claim the block reward.

The reason for constructing the coinbase transaction after selecting the transactions is because it needs to contain a witness root hash, which is calculated based on the transactions that have been included in the block.

3. Construct the block header

The block header is a small amount of metadata the summarizes all the data inside the block. This is what a miner will be hashing as they attempt to mine the candidate block.

The block header contains six different fields (version, previous block, merkle root, time, bits, nonce), but these two are the most pertinent:

And that's the construction of the candidate block complete.

From here a miner can now start work on mining the candidate block to try and add it on to the blockchain.


What are the requirements for a candidate block?

Diagram showing the requirements for a candidate block.

A candidate block has a few basic requirements:

1. Coinbase transaction

The first transaction in the candidate block must be the coinbase transaction.

This transaction is placed in the block by the miner to claim the block reward.

This means that all blocks will always contain at least one transaction.

2. Valid transactions

All the transactions a miner includes in their candidate block must be valid.

For example, each transaction can only spend coins that already exist.

If a miner mines a block containing invalid transactions and broadcasts it to the network, all of the nodes will reject it, and all of their effort for mining the block will be wasted.

3. Transaction parents

Diagram showing a parent transaction coming before a child transaction in a block.

The parent(s) of a transaction must always come before the child transaction.

For example, if a transaction has ancestors that are currently in the mempool, those ancestors must be included above it in the candidate block.

Each node validates the transactions in a block from top to bottom, so if you include a parent after a child, it will appear as though that child transaction is spending outputs that do not already exist (and would therefore be invalid).

4. Size limit

Diagram showing the block size limit in terms of weight.

The maximum size of a block is 4,000,000 weight units.

So the transactions you include in your candidate block (including the size of the block header and transaction count) must be within this size limit.

The block size limit can be found in consensus.h

5. Signature operations

A block is limited to a maximum of 80,000 signature check operations. So the transactions you include in your candidate block must be within this limit.

This is because signature verification is time-consuming, so this limit prevents miners from creating blocks that would be exceptionally slow to validate.

Signature check operations are performed by Script opcodes such as: OP_CHECKSIG, OP_CHECKMULTISIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIGVERIFY

Transaction Selection

How do miners select transactions for their candidate block?

Diagram showing the highest fee transactions being selected from the memory pool for inclusion in a candidate block.

A miner can fill their candidate block with any transactions they like from the memory pool.

However, miners will typically look to fill their candidate block with the highest-fee transactions available to maximize the amount they can claim from the block reward.

So if there are more transactions in the memory pool than can fit in to a candidate block, a miner will prioritize the transactions with the highest fees for inclusion in their block.

Ancestor Fee Rate

Diagram showing a miner working out the ancestor fee rate for the transactions in their memory pool.

There is one important rule that miners must follow when selecting transactions:

You can only include a transaction in a block if you also include all of its parents first.

Therefore, if a memory pool transaction has ancestors, a miner will calculate the ancestor fee rate to work out whether it's worth including that transaction compared to another transaction that doesn't have any ancestors.

When you've got ancestors in the memory pool, the process selecting the optimum combination of transactions is complex, and the only way to get the "perfect" block in terms of maximizing fees is to try all possible combinations. Therefore, most miners will make a best-effort attempt at constructing a block with high-fee transactions, without wasting time on trying to calculate the "perfect" block each time.

Empty Blocks

Why do miners mine empty blocks of transactions?

Diagram showing a miner constructing an empty candidate block to work on while they select the optimum combination of transactions from the memory pool to fill it with.

You sometimes find "empty blocks" appearing in the blockchain with only one transaction in them.

For example, block 828,012 doesn't contain any transactions (other than the required coinbase transaction), whereas the blocks above and below it are full of transactions:

Height Block Hash Time (UTC) Size Txs Avg Fee Rate AFR
828,015 828,015 00000000000000000000a9c619c4af8c09f10c11a8262bcde576450e45a126ca 1.60 MB 3,142 31
828,014 828,014 000000000000000000015b4c953a7636418316bee66575d79edf407a3f9640ae 1.88 MB 5,222 30
828,013 828,013 000000000000000000023cbbedc89f62a4e38db462bb45b5214d12f0f85f1972 1.80 MB 4,385 33
828,012 828,012 00000000000000000003eb119d2115448bea2d14e18bf19c00020dd23fee79cb 0.00 MB 1 0
828,011 828,011 0000000000000000000300773e6ec30fbed5d49a07568114c5824c7f89401fc9 1.98 MB 5,639 29
828,010 828,010 000000000000000000004cdc62634f083ec10dffc7bb4777c792d67c0aefbf8b 1.71 MB 3,881 29
828,009 828,009 00000000000000000000ce872172185086c9c6cfbedd0e78e90b6d0a7bd93f07 1.59 MB 2,557 38

This is because miners will typically start working on an empty candidate block while they select transactions from the memory pool.

Because as mentioned, it takes a moment for a miner to calculate an optimal combination of transactions to maximize the amount in fees they can claim. So instead of doing nothing while they calculate which transactions to include in their block, they will immediately start work on mining an empty block first.

Consequently, a miner will sometimes get lucky and mine their empty block before they get around to working on a candidate block that has been filled with transactions.

It doesn't happen very often, but that explains why you sometimes see "empty blocks" in the blockchain.

Whilst a miner will miss out on claiming transaction fees by mining an empty block, it's more profitable for them to start work on mining an empty block for the opportunity to claim the block subsidy in the meantime.


bitcoin-cli getblocktemplate [template_request]

Returns transactions from your node's memory pool that you can use to construct a candidate block.

Annoyingly you also have to provide an awkward array to specify the kind of block template you want (see BIP22). This is what I typically use: bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'

You will need to construct the block header manually from this block template before you start mining. For example, you will need to construct your own coinbase transaction, as well as calculate the merkle root. So it's more of a "starting point", but it does the hard work of selecting an optimum combination of transactions from the memory pool for maximizing the fees you can claim.