Candidate Block
Next block to be added to the blockchain
Download PDF
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.
In other words, a candidate block represents the next block of transactions to be added on to the blockchain.
Example
What does the current candidate block look like?
Here's what the current candidate block looks like according to my local node:
Block Header 
| Version | 0x20000000 |
|---|---|
| Previous Block | 000000000000000000008ad22f27c2bab4af6fcdfc3e05b1d195c3364573872d |
| Merkle Root | 34a16e5507a90fc3a8d153094289ca9690e977c767ee1339a1818d9c2cc54a64 |
| Time | |
| Bits | 1702c070 |
| Nonce | 0 |
Transactions
-
You can manually refresh this candidate block to check for changes every 3 seconds (roughly).
- If the merkle root changes, you know the transactions in the block have changed.
- The lower-fee transactions toward the bottom of the candidate block are more likely to change.
- I'm not actively trying to mine this block. If I was, I would be adjusting the nonce in the block header to try and get a block hash below the current target.
- I haven't put my own coinbase transaction in this candidate block either, so it wouldn't be valid if I mined it anyway. This example is here to show you what a current candidate block looks like.
Construction
How do you construct 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:
- Previous Block: This field is used to specify an existing block that the candidate block will be building on top of. A miner always wants to build on top of the tip of the blockchain, because they can only claim the block reward if the block they mine ends up becoming part of the longest chain.
- Merkle Root: The merkle root is a fingerprint for all the transactions included in the block. This is important, because it means that you cannot change the contents of the block without changing the fingerprint. So again, this is why we construct the block header after selecting the transactions for the candidate block.
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.
Requirements
What are 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
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
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
- The sigops limit can also be found in consensus.h
- Segregated Witness: Similar to how bytes in a legacy transaction are multiplied by 4 to calculate their equivalent weight, the count of signature operations in legacy transactions is also multiplied by 4. So whereas a single
OP_CHECKSIGcounts as 1 signature operation when in the Witness field (as expected), it actually counts as 4 signature operations when in the ScriptSig (see validation.cpp).
Transaction Selection
How do miners select transactions for their 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 Feerate
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 feerate 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?
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.
Commands
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.
Notes
- There is no "single" candidate block that all miners work on. Each miner selects transactions from their own mempool, so whilst there's usually a big overlap, there's typically slight differences between candidate blocks. So if you see that your transaction is currently sitting in a candidate block, it's not guaranteed to be included in the next block (although it's likely it will).