Topic: Bitcoin Empty Blocks - page 2. (Read 531 times)

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.

Interesting, I'll have to do more read up on that aspect.
IIRC, quite a few pools still do SPV mining up until now.
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.
Given how most pools actually monitor each other's stratum server, I doubt it could be done easily right now.

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


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.


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

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 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).

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.

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

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.

Latest empty blocks:

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

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.

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.

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.

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 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.

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.

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.

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