Bitcoin Empty Blocks

[Picard78]

I was exploring the Blocks on https://www.blockchain.com/btc/blocks and noticed Block 644928 is only 217 bytes.  It only contains the Coinbase Transaction.  Same thing with Block 644937.

Why are these blocks empty?  It's hard to believe the memPool would be empty.

Thank you

[1715097193]

1715097193

[1715097193]

1715097193

[1715097193]

1715097193

[1715097193]

1715097193

[ranochigo]

It's perfectly normal and is usually a result of SPV mining.

When a block is discovered, time is taken for the block to propagate and for the miners to verify the entire block. This can take a few seconds and those time would be wasted if the ASICs and the miners were just to idle and wait for the pool to validate the block. Enter SPV mining, SPV mining takes the block header of the previous block and create a new block header without including any transactions so as to prevent any conflicting transactions.

After the block is fully validated, the pool goes ahead to do everything normally and compile the unconfirmed transactions from the mempool. These kinds of blocks are usually observed when the blocks are mined in quick succession.

[Picard78]

When a block is discovered, time is taken for the block to propagate and for the miners to verify the entire block. This can take a few seconds and those time would be wasted if the ASICs and the miners were just to idle and wait for the pool to validate the block.

I think I understand.  The mining Pool might as well do some Proof of Work just on the CoinBase Transaction with the received Hash from the just-solved block header while the block is validated and the memPool is updated for the mining Pool.  If the mining Pool doesn't discover a new Block with just the CoinBase transaction and the memPool is now updated, it now switches to performing Proof of Work on a newly formed block filled with valid transactions to get the extra transaction fees.

However, in the case of Block 644937, it was mined by the same pool (AntPool) as the prior block 644936.  Hence AntPool should be aware of what transactions were inserted into 644936.

[ranochigo]

However, in the case of Block 644937, it was mined by the same pool (AntPool) as the prior block 644936.  Hence AntPool should be aware of what transactions were inserted into 644936.

It's purely speculation because I don't own a mining pool and neither do I know the inner workings of antpool.

If what is stated on their website is correct, Antpool found the block after 4s of the previous block. My guess is that while they know exactly what is in the block and that it is accurate, the pool took some time to take out the transactions and repopulate their block headers with the relevant transactions. At this time, it is better to not mine any transactions in case the pool accidentally includes a transaction that was already in the previous block.

[Picard78]

That's the other puzzling thing, how is it possible that a block could be successfully mined within seconds when it should take on average 10 minutes? This should be a rare instance.  Two empty blocks were mined within 2 hours of each other:  Block 644937 and 644928.

[ranochigo]

That's the other puzzling thing, how is it possible that a block could be successfully mined within seconds when it should take on average 10 minutes? This should be a rare instance.  Two empty blocks were mined within 2 hours of each other:  Block 644937 and 644928.

It's really based on luck.  There's nothing dictating the intervals of the blocks being found. Mining is just the act of hashing a block header and changing the variables within it. With luck, a hash with the appropriate target can be found within seconds or hours.

As you said,  it's an average of 10 minutes.  So in a larger sample size, the average is still close to 10 minutes regardless.

[Upgrade00]

That's the other puzzling thing, how is it possible that a block could be successfully mined within seconds when it should take on average 10 minutes?

This is an average time range, it could be faster or slower depending on some factors such as the one given by @ranochigo; luck, cause finding a hash is based on randomness. The difficulty level is adjusted approximately every 2 weeks or 2016 blocks to maintain the average block time of 10 minutes.

[Picard78]

Today was the first time I looked at Block Sizes.  I guess I was super lucky to witness 2 empty blocks mined within 2 hours of each other.

[Picard78]

Latest empty blocks:

644,937
644,928
644,644
644,543
644,498
644,394
644,232

[Bitcoin_Arena]

That's the other puzzling thing, how is it possible that a block could be successfully mined within seconds when it should take on average 10 minutes? This should be a rare instance.  Two empty blocks were mined within 2 hours of each other:  Block 644937 and 644928.

Mining the next block is all based on probability/chance on which mining pool finds it next and at what time it's found. Just take it like playing a dice game where you could get a chance of hitting the side with 6 dots only after a single roll or after 2 consecutive rolls, or never after 40 consecutive rolls



When the next block is discovered a few seconds after the previous one has been mined. The likelihood of the new block being empty or having very few transactions in it is very high.

[barrysty1e]

the stratum chooses whichever transactions it likes out of the mempool to include in a block. generally all the open source stratums will just include as many as they can (example: https://github.com/tpruvot/yiimp/blob/next/stratum/coind_template.cpp#L390-L487), however the big mining pools which run their own software know this isnt always economical and will select a set that results in them netting the most coins. there is no penalty for doing this and is encouraged almost; as it creates a fee market. even with the yiimp example, you can see the total amount of transactions included can be adjusted (https://github.com/tpruvot/yiimp/blob/next/stratum/coind_template.cpp#L428-L432).

the 'spv mining' answer is incorrect; as the stratum is additionally free to refresh the merkleroot hash at any time (generally this is done every 30-40s), regardless of whether a new block has been sighted on the network. it does this by issuing a mining.notify broadcast to all miners (https://slushpool.com/help/stratum-protocol#example) which includes the updated data.

around 3-4 years ago, some of the big pools would not include any transactions in a block, as well as not relaying the block as it was found. this gives them an advantage over the rest of the network, as they can begin mining a new block ahead of everyone else. after they had mined 2 or 3 blocks whilst 'isolated' from the network; they would reappear on the network and solve an additional block on their hidden chain, but this time in public; which would immediately cause all other nodes to request the brand new blocks, as it would have significantly more chainwork than the existing chain. having zero transactions in the block, besides the coinbase transaction, ensures the blocks are propogated quickly and increases the chance that they will be accepted by the network.

james

[ranochigo]

however the big mining pools which run their own software know this isnt always economical and will select a set that results in them netting the most coins. there is no penalty for doing this and is encouraged almost; as it creates a fee market. even with the yiimp example, you can see the total amount of transactions included can be adjusted (https://github.com/tpruvot/yiimp/blob/next/stratum/coind_template.cpp#L428-L432).

Yes, most mining pool are able to choose their own transactions. But there isn't any rational mining pool which would intentionally include only the coinbase transaction when they are trying to maximize their profits.

the 'spv mining' answer is incorrect; as the stratum is additionally free to refresh the merkleroot hash at any time (generally this is done every 30-40s), regardless of whether a new block has been sighted on the network. it does this by issuing a mining.notify broadcast to all miners (https://slushpool.com/help/stratum-protocol#example) which includes the updated data.

The scenario given is a block being mined 4 seconds after the previous block. It's true that mining pools can issue a message to update the data but in this case, the mining pool likely wanted to utilise the small amount of time that it took to reconstruct their merkle root. My hunch is that they did issue a mining.notify and that they didn't include any transactions as of yet. You can observe how only the blocks with quick succession are empty but the others are populated (to a reasonable capacity).

around 3-4 years ago, some of the big pools would not include any transactions in a block, as well as not relaying the block as it was found. this gives them an advantage over the rest of the network, as they can begin mining a new block ahead of everyone else. after they had mined 2 or 3 blocks whilst 'isolated' from the network; they would reappear on the network and solve an additional block on their hidden chain, but this time in public; which would immediately cause all other nodes to request the brand new blocks, as it would have significantly more chainwork than the existing chain. having zero transactions in the block, besides the coinbase transaction, ensures the blocks are propogated quickly and increases the chance that they will be accepted by the network.

Yep, selfish mining. Would it work for Antpool though? They only have an estimated 9% of the network's hashrate, they're more likely to lose out from this attack.

[barrysty1e]

Yes, most mining pool are able to choose their own transactions. But there isn't any rational mining pool which would intentionally include only the coinbase transaction when they are trying to maximize their profits.

this topic gets quite deep, you're correct - but if a pool isnt mining fairly, referring to the SPV/selfish mining paradigm before; segwit actually causes interference in this situation due to the signature data - as there are no other nodes present when calculating the witness, so it is easier to just not include any transactions at all. a lot of the chinese pools run a 'dead miner' on the stratums of their competitors, as this is the only way to ensure they have the latest prevhash when a network node may not have relayed it to the network.

if you search the forums here for a fairly famous incident involving kano's pool and f2pool (i think), was 2016-2017.. some good reading to be had there

The scenario given is a block being mined 4 seconds after the previous block. It's true that mining pools can issue a message to update the data but in this case, the mining pool likely wanted to utilise the small amount of time that it took to reconstruct their merkle root. My hunch is that they did issue a mining.notify and that they didn't include any transactions as of yet. You can observe how only the blocks with quick succession are empty but the others are populated (to a reasonable capacity).

four seconds is more than enough time for the stratum to issue getblocktemplate to the daemon and receive a response (template containing the txlist as well). not to mention custom setups where they just query the mempool directly via getrawmempool etc. in fact this could be done in as little as 125ms (or less) depending on the daemon's network load etc.

Yep, selfish mining. Would it work for Antpool though? They only have an estimated 9% of the network's hashrate, they're more likely to lose out from this attack.

antpool used to be much closer to 40-45% of the network hashrate back then.
i personally witnessed antpool mine three blocks in quick succession without relaying any of them to the network; as i was monitoring the stratum mining.notify broadcasts - but they lost all of them as another (honest) pool found and submitted a block as they were going for the fourth.. and another pool quickly followed suit.. they would've easily lost $75k USD in moments, due to their own greed 

james

[ranochigo]

this topic gets quite deep, you're correct - but if a pool isnt mining fairly, referring to the SPV/selfish mining paradigm before; segwit actually causes interference in this situation due to the signature data - as there are no other nodes present when calculating the witness, so it is easier to just not include any transactions at all. a lot of the chinese pools run a 'dead miner' on the stratums of their competitors, as this is the only way to ensure they have the latest prevhash when a network node may not have relayed it to the network.

Interesting, I'll have to do more read up on that aspect.

if you search the forums here for a fairly famous incident involving kano's pool and f2pool (i think), was 2016-2017.. some good reading to be had there

IIRC, quite a few pools still do SPV mining up until now.

four seconds is more than enough time for the stratum to issue getblocktemplate to the daemon and receive a response (template containing the txlist as well). not to mention custom setups where they just query the mempool directly via getrawmempool etc. in fact this could be done in as little as 125ms (or less) depending on the daemon's network load etc.

With the validation of the block and everything? Won't the pool have to validate and remove the transactions from their mempool first? I'm not sure how much time it takes for it to be done, given all the overheads with the communication with the miners included.

Though the antpool site states that it's 4 seconds, the actual time might be faster.

antpool used to be much closer to 40-45% of the network hashrate back then.
i personally witnessed antpool mine three blocks in quick succession without relaying any of them to the network; as i was monitoring the stratum mining.notify broadcasts - but they lost all of them as another (honest) pool found and submitted a block as they were going for the fourth.. and another pool quickly followed suit.. they would've easily lost $75k USD in moments, due to their own greed  

Given how most pools actually monitor each other's stratum server, I doubt it could be done easily right now.

[CardCoins]

Empty blocks can mean a lot of things, many of them mentioned in the thread here.

Right now the block subsidy significantly outweighs the fees in a block. If miners feel that the additional weight in the block may cause them to lose a block race, they may choose to put very few or no transactions in a block. Over time you imagine this will be untenable as fees becomes a more significant proportion of miner income. The unfortunate side effect of that new paradigm is that if there is not a significant backlog of transactions in the mempool, miners may attempt to "fee snipe" transactions from the tip and re-mine the top most transactions instead of pushing the chain forward. There are some partial mitigations to this in Bitcoin Core by tweaking a transaction's locktime to the current block height so miners are incentivized to push the chain forward to capture fees from these types of transactions.

When it comes to validating a block, depending on the composition of transactions, it can take upwards of a few seconds (even more in some pathological/adversarial scenarios) to complete. Given the miner income ratio right now, it makes sense to mine an empty block before you have fully validated the tip because you can't be sure exactly what block template you can construct without possibly making it invalid (unless the block only includes transactions from the miner or their direct associates in some out-of-band transaction confirmation deal). This has sometimes been called header-first/validation-less or SPV mining, because the miners have only validated the proof of work, not any of the transactions.

There is also Spy mining, where competing pools connect to one another and monitor for discovered blocks. When one of a pool's clients find a block, it immediately publishes the header of that block to all the other clients so it can begin mining right away. In this case if you are a competing pool and hear about this block you will not know its composition, so you have no choice but to tell your clients to mine an empty block on top of it.

The obvious danger with the above strategies is that you are building on an invalid block. While this is exceedingly rare, it can and has happened. Here is a historical example: https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa

Another phenomena that may cause near-empty blocks but is largely irrelevant now is covert-ASICBOOST, where miners attempt to compose transactions in the block in a certain way that allows them to increase their efficiency by causing collisions in the midstate of the first chunk of the block header when it is being hashed. In effect they can re-use some of the proof of work. It was already mentioned in the thread, but segwit significantly undermined the covert-ASICBOOST strategy by adding an additional merkle root in the coinbase transaction for witness txids, so the strategy of reordering transactions become more computationally difficult.

I saw a mention of selfish mining in the thread, but to clarify: there are a few different strategies for selfish mining, but the most common one is to withhold a single block that you have mined and wait for a competing pool to discover a block, then force a block race. It is not a common strategy to wait for the selfish pool to mine multiple blocks and then broadcast the chain. That would be highly detectable by the network. As is, we very rarely see "stale" blocks that have lost block races today. When it comes to races, you want your block to propagate as quickly as possible so you will want to be extremely well connected to the rest of the network and also for the block to be as small as possible so it propagates quickly. 

Of course there is also the possibility that there are no transactions in the mempool, although that is fairly rare these days. There are even transactions that have been evicted from the mempool that may be stored by some miners in the event that there are no other transactions to mine.

[pooya87]

When it comes to validating a block, depending on the composition of transactions, it can take upwards of a few seconds (even more in some pathological/adversarial scenarios) to complete.

that is the main reason for empty blocks but keep in mind that miners (or any node for that matter) don't have to download or even verify the whole block 99% of the time because when their node has been online and receiving transactions that means it already has all the transactions in that block too (unless the other miner included transactions that weren't broadcast to the network which would be a small portion of all transactions) and has already verified them when they received the transaction in its mempool.
which is why the number of empty blocks like this has decreased drastically compared to 3-4+ years ago (eg BIP-152 was introduced in mid 2016).

[CardCoins]

When it comes to validating a block, depending on the composition of transactions, it can take upwards of a few seconds (even more in some pathological/adversarial scenarios) to complete.

that is the main reason for empty blocks but keep in mind that miners (or any node for that matter) don't have to download or even verify the whole block 99% of the time because when their node has been online and receiving transactions that means it already has all the transactions in that block too (unless the other miner included transactions that weren't broadcast to the network which would be a small portion of all transactions) and has already verified them when they received the transaction in its mempool.
which is why the number of empty blocks like this has decreased drastically compared to 3-4+ years ago (eg BIP-152 was introduced in mid 2016).

Compact Blocks (BIP 152), a standardized form of Greg's efficient block relay, a modified version of which is used in the FIBRE network, is mainly designed to reduce the amount of bandwidth required to propagate blocks. It does have the side effect of lowering latency during propagation when High Bandwidth mode is enabled, but ultimately validation of the block is still required: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#pre-validation-relay-and-consistency-considerations

FIBRE of course improves propagation speeds even above HB mode of Compact Blocks. Extremely careful selection of relay points, no validation and forward error correction.

But yes stale rates are very significantly down. This has less to do with validation speeds and more to do with improvements in propagation techniques. Once upon a time everyone pooled up in btcguild, GHASH etc. to deal with this exact problem.

In terms of actually building a block template as quickly as possible, one thing that has improved the speed by which miners can do this is a tighter relationship between CreateNewBlock and the current state of the mempool. This doesn't help you validate the inbound block any faster, but does help you build the next block with greater efficiency: https://github.com/bitcoin/bitcoin/pull/6898

[pooya87]

Compact Blocks (BIP 152), a standardized form of Greg's efficient block relay, a modified version of which is used in the FIBRE network, is mainly designed to reduce the amount of bandwidth required to propagate blocks. It does have the side effect of lowering latency during propagation when High Bandwidth mode is enabled, but ultimately validation of the block is still required:

true but what i meant was that technically the mining node receiving a new block still doesn't have to verify the whole block ie. verification of each transaction inside that block because it has already verified them before when it received those transactions in its mempool. and that is the same principle as BIP-152.
considering the fact that verification takes more time than downloading (specially for legacy transactions with multiple inputs since they have multiple ECDSA and lots of hashing) things could be significantly optimized that way.

[Picard78]

Once again 2 empty blocks within 1-2 hours of each other (8 blocks apart)

645,098
645,090

[CardCoins]

Compact Blocks (BIP 152), a standardized form of Greg's efficient block relay, a modified version of which is used in the FIBRE network, is mainly designed to reduce the amount of bandwidth required to propagate blocks. It does have the side effect of lowering latency during propagation when High Bandwidth mode is enabled, but ultimately validation of the block is still required:

true but what i meant was that technically the mining node receiving a new block still doesn't have to verify the whole block ie. verification of each transaction inside that block because it has already verified them before when it received those transactions in its mempool. and that is the same principle as BIP-152.
considering the fact that verification takes more time than downloading (specially for legacy transactions with multiple inputs since they have multiple ECDSA and lots of hashing) things could be significantly optimized that way.

You might be interested in the concept of Weak Blocks which is a "pre-consensus" process by which miners propagate blocks with PoW below the target difficulty with the general assumption the composition of that block will remain the same in the event that miner satisfies the PoW. It increases bandwidth but would allow for validation to be front-loaded. It would be trust-full and not consensus enforced, presumably. There is a lot of skepticism of this idea, for various reasons related to incentives etc.

Once again 2 empty blocks within 1-2 hours of each other (8 blocks apart)

Appears both of those blocks were found immediately (within a second) after the block that preceded them.