Bitcoin Forum

A couple of years ago empty blocks started to pop up and i never heard a good reason that this would ever happen. The best argument was that it was slightly faster so miners would do it.

I am curious does mining an empty block provide an advantage in solving blocks in any way. For example, maybe the block header is unchanged for an empty block even as new blocks are mined. A miner could simply try and solve the same block indefinitely until the solution is found and they they can stick the empty block into the chain and receive the reward.... Would this somehow provide an advantage over people trying to solve full blocks?

Mining empty blocks is not a good idea. It can happen when nSubsidy = 0 in the following code located in verification.cpp
With Bitcoin 0.18, this would create an orphan, an empty block. It is a consensus rejection. So doing this would block the wallet at starting when synchronizing at the specific transaction and a fork (bug fix) would be necessary to allows Bitcoin to accept the transaction.
You can try on testnet by changing the following code and return 0; see what happens  ::)

No, this is not going to work.

You need the block header hash for the latest mined block to include it in the block you are working on or it will be invalid.

Each time a new block is found and broadcasted to the network, you have to update your block and start from scratch.

Let's say you have Miner A and Miner B.  

Miner A is the honest miner and miner B is the (Empty miner)

When Miner A finds a block miner B starts to work on a new block but try's to mine it without including any transactions.

miner B must start to mine as soon as possible, they take the prev block header but before you get the entire block from the miner who found it.
The issue being if you only have the header and you don't know what transactions were in the block you are building on. If you put any translation in it then you risk including a translation from the prev block. If you do that other miners will not validate your block.

Bitcoin dose not force miners to include transaction in the protocol it is a frowned upon process as many feel it takes away from the honest miners the only thing that really stops miners producing more empty blocks is the extra reward they get from the transactions fees.

When a miner gets a new block from a the network it will a number of actions
1. download the full block
2.validate its transactions and define a new block.

So miners do not waste hashing power and time the miner will start to mine on a new block that only includes the coinbase transaction this is to ensure the previous block does not invalidate theirs with a duplicate transaction.

By default they are frowned upon in the mining world but there is not rule that ban's empty blocks as such.

It is indeed faster to mine a empty block. It takes time to validate a new block and construct the next one. A  miner may choose to start mining an empty block while they are doing that.

As others have noted, a block header contains the hash of the previous block, so it must change with every new block.


Empty blocks are not rejected. Blocks with 0 reward are not rejected. If you change GetBlockSubsidy to always returns 0, then your wallet will reject all blocks.

here's a visualisation of the above from Magic Byt3:


                                                                                                                                                                                    Mine full block N+1, as tx's in
                                                                                                                                                                                   block N are known. Now a valid
                   Mine empty block N+1, as do not yet know which tx's are confirmed in block N                                set of tx's to confirm into
                                                                                                                                                                                        our solution for block N+1
                                                                                                                                                                                             can be constructed
<-------------------------------------------------------------------------------------------------------------------------------------> <--------------------------->>>>>>>>>>>
 x milliseconds                       3x milliseconds                                             3x milliseconds                                      
|--------------------|---------------------------------------------------------|----------------------------------------------------------|----------------------------->>>>>>>>>>>
   Receive &                       Receive, then verify                                   Build block template for                               Attempt solution for 
    verify new                      transactions included                               N+1 as now we know which                          block N+1, now with  
  block header                          in block N                                            transactions are included                            transactions included
   of block N                                                                                                         in block N                                                 (a full block)

the proportion of the times are wrong, but that's not the most important thing here.

your ASIC that is actually mining the blocks doesn't validate blocks or construct next ones, it just hashes the 80 bytes that it receives. while it is hashing, your node can easily construct the next one before it reaches the end of nonces and fails to find and requires a different change in extranonce or something. and while you are at it you might as well add new transactions and construct the merkle root too. and since this is done elsewhere (not in ASIC) then there is no difference in time it takes to mine an empty block or a block with 3000 transactions!

@OP It wasn't just a couple of years ago that empty blocks started to pop up. It's actually only logical that the earliest blocks were most likely to be empty, since there couldn't be any transactions to fill them up if they were just a handful of users! As the network grew, and more users transacted, empty blocks became more uncommon, and txs in fact started to join a queue, to the point that empty ones were noticed, hence the criticism/debate/discussions surrounding them.


I've always understood that you can't check if block N txs are valid without seeing block N first... and you still need to validate N if you want to include txs in N+1, and that is why they don't include them, and solve it and add asap. I think the difference is minuscule but enough for an advantage. Perhaps that advantage is negligible today?

That's true. You still need to parse the transaction to compare them to your own mempool. The idea is that the miner mines an empty block while validating the new block simultaneously.

SPV mining was fairly common in the past and that is also what caused the fork in 2015[1]. Miners would connect to each other's pool and obtain the hash of the newly generated block. Since they don't have the full block yet, they would only construct an empty block with the coinbase transaction so as to avoid mining an invalid block. It has caused quite a few problems and it was a fairly controversial issue at that time.

No matter what happens, the overheads with the propagation of blocks still exist. Even with the much faster internet speeds and the improved verification of blocks, miners would still waste some time trying to validate it. Since it wouldn't actually be that much of a hassle to implement SPV mining, miners would still do it.

[1] https://bitcoin.org/en/alert/2015-07-04-spv-mining