An empty block is still a valid block
A block described as empty still contains its header and coinbase transaction; it simply contains no additional user transactions. Full nodes judge it by the same proof-of-work and consensus rules as any other block.
Bitcoin's consensus rules do not require a miner to include every available transaction, or any particular transaction. Mempools are local and policy-dependent, so a node cannot prove from the block alone exactly which transactions its miner had available.
Several causes can produce the same on-chain result
A miner might briefly work from the newest valid header while constructing or receiving an updated transaction template. A pool may also use unusual policy, lack suitable transactions or intentionally exclude them.
The block itself does not prove motive. Calling every empty block an attack confuses an observable result with several possible operational or strategic causes.
Template construction separates selection from proof of work
Mining software works on a candidate block assembled from a previous block hash, a coinbase transaction and selected transactions. Interfaces such as getblocktemplate let a miner or pool construct and update that candidate.
A pool can choose the template while individual hashers search for proof of work. This concentration of transaction selection is different from consensus control: every resulting block still has to satisfy the rules enforced by full nodes.
Censorship can delay valid transactions, not make invalid rules valid
A miner can refuse to include a transaction in its own blocks. If other miners include it, the transaction can still confirm; sustained censorship becomes more effective as the censor controls more hashpower or is willing to reorganise blocks that include the target.
Even dominant hashpower cannot forge a valid signature, spend an output without meeting its script or create supply beyond the rules accepted by full nodes. It can influence ordering and confirmation history, not redefine validity for correctly validating nodes.
Fees create an opportunity cost
When an empty block excludes fee-paying transactions, its miner gives up those fees. The cost depends on current block-space demand, the available transactions and the miner's actual template information.
As the subsidy declines, fees form a larger potential share of miner revenue. That can strengthen the incentive to include paying transactions, but it does not guarantee neutral selection or eliminate political, legal and strategic pressures.
Visual recap
What an empty block does—and does not—prove
Nodes can verify block validity and contents, but motive must be inferred cautiously.
Build template
Select transactions
Search for proof
Publish block
Nodes validate
Fees accepted or forgone
Key takeaways
- An empty block contains a coinbase transaction but no ordinary transactions.
- Consensus does not force miners to include specific mempool transactions.
- The same empty result can have operational, policy or strategic causes.
- Hashpower can delay or reorder valid transactions but cannot override node-enforced validity rules.
- Excluding paying transactions creates an opportunity cost equal to the forgone fees.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
Does an empty block prove that the miner attacked Bitcoin or had no transactions available?
References
