Topic: Bitcoin Empty Blocks (Read 533 times)

https://www.blockchain.com/btc/block/644927
https://www.blockchain.com/btc/block/644928
Observing two adjacent blocks 644927 and 644928, we can see them mined in the same minute. Block 644927 has 612 transactions and the next block 644928 has only 1 transaction.
Since the mining speed is too fast, transactions cannot be sent in this block, so only 1 transaction can be made.

no, because we are talking about finding the hash within a ~second and the chances of that happening is very small that it has happened very rarely in the past 646k blocks.

it is not that simple and there is already a much better solution: incentive. when the price is high and block reward is low and the total fee is a meaningful amount of money, it means if the miner finds an empty block they lose all that extra income.

the bitcoin design is that you get paid for the "work" you have done and you do pretty much the same amount of work for an empty block or for a full block so you get paid for it all the same, meaning the reward can not change.

But wouldn't this create many empty blocks eventually after the decades of transactions? I know right now the size limited by that single reward it gives out to the miners. But can't a sidechain be implemented for the rewards itself? I do count myself among those few members that think that empty blocks are indeed a waste of resources. All it would take to stop empty blocks from being mined is simply not allowing miners to solve a block's hash without downloading the entire content for that block. I think a simple line of code could even solve this. No?

I personally think the block reward should be stripped from empty or stuffed blocks. It's just causing inflation for now real benefit.

Since block 600,000 (Oct 19, 2019) or in the last 45,343 blocks:

The average block mining time is 9.892152041 min

Very nice.

Since block 600,000 (Oct 19, 2019) or in the last 45,343 blocks:

                   Blocks Mined  Percent   Empty Blocks
1   Unknown   8,448   18.63%     11
2   F2Pool   7,797   17.20%     56
3   BTC.com   5,765   12.71%     33
4   AntPool   5,078   11.20%     23
5   Poolin   4,475   9.87%        9
6   ViaBTC   2,818   6.21%        6
7   SlushPool   2,004   4.42%       10
8   Huobi   1,842   4.06%       14

Hmmm... this was formatted properly before I posted it.

Thank you ranochigo.  This is exactly what I was looking for.

Since block 600,000 (Oct 19, 2019) or in the last 45,343 blocks there were:

- 184 empty blocks which is ~ 0.4% of 45,343 blocks.

- Average block size of 1,116,072 bytes    

- Average block fees USD $3,145.  Average Block Coinbase reward USD $90,806.  Average profit from fees ~3.5% per block.

- Maximum USD $ / KB is $23 on 2020-02-01 and 2020-07-28.   (Note: Fees were over $100 / KB for many blocks in Dec 2017)

As in f2pool and Antpool mining 4 empty blocks in a row in 2015(?) that were off-chain thanks to their jumping the gun to be 1st out the gate to start a new (un-validated) block by using results from their previous also empty and un-validated block?

Turns out that someone else had won the Orphan race for that 1st empty & un-validated block that Antpool & f2 had based their chain on.... Oops. Thanks to the back-end monitoring that Kano has he was very quickly alerted to the issue and contacted Antpool ops about it who then quickly relayed the info to f2pool who promptly switched tracks back to the valid current chain and of course invalidating the off-chain blocks they found.

Kano.is uses a modified version of ckpool as its front-end in conjunction with KDB which also directly monitors the network via bitcoind. Most of the code is out there in gits. Mind you his changes to ckpool are not there despite him being one of the major developers of it (the 'k' stands for Kano) thanks to a certain someone kicking him off the ckpool github due to irreconcilable differences in their views on proper coding/testing & pool financial safety. Anywho, the core code is there for anyone to peruse & use but Kano's mods to ckpool and updates to his KDB remain private. Since he does not distribute his changes that does not violate the GPL .

Indeed. I remember Kano being an opponent of SPV mining and some drama between him and F2Pool. BIP152 would've improved the propagation timing further and the effects of SPV mining would've diminished from the past.

I can't comment too much on how Kano and Antpool handles their mining code nor the efficacy of their code because I can't have access to either. He does have sound arguments against SPV mining and miners are mining less empty blocks in the years after that incident.

---

Blockchair has database dumps here but you need to parse it to have anything useful :https://blockchair.com/dumps

I just remembered,  LoyceV has everything: https://bitcointalksearch.org/topic/bitcoin-block-data-available-in-csv-format-5246271

One has to wonder about the date of that video.
Per-Kano it takes around 120-150ms to fully validate blocks. Being the operator of a pool that only uses fully validated blocks and has NEVER mined an empty one, he knows what it takes.

Andreas Antonopoulos discusses the reason for the Empty Blocks in the below video from 0 - 3:15 min.  According to him "it takes about 15 - 20 seconds to validate" a block.  He says this at the start of the video.

https://www.youtube.com/watch?v=dizF2S63RXY

There are 11 empty blocks in 966 blocks or 1.13% of the blocks are empty from Block 645,198 to 644,232 = 966.

645,198
645,098
645,090
645,027
644,937
644,928
644,644
644,543
644,498
644,394
644,232

Is it possible to download Block Header Data for analysis in a tool like Excel or MS Access?  I would like to analyze the average Block Size for the past 50,000 blocks.  Average Block Fee in satoshis for the past 100,000 blocks etc...   Also I am very curious how many Empty Blocks there are for the past 50,000 blocks.

Thank you
 

In perfect circumstances block validation is quite fast, that's correct!

There are adversarial cases where block validation can take quite a bit longer then the block you have presented here. In fact, one of the most significant improvements that segwit introduced was designed to partially address this exact issue, as the signature hashing algorithm was O(n^2). Now it is O(n): https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#motivation

While segwit addresses one of these complexities, there are still others (albeit much less vicious): https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/

Even if you don't assume the block is intentionally adversarial, there are lots of other factors which can effect validation time, including how much of the UTXO set the validator has cached, and how much of the block's content is in that cache. The libraries and hardware they use is also an important factor. Sipa has a great stackexchange post which details some of this stuff here, he suggests blocks can take multiple seconds to validate: https://bitcoin.stackexchange.com/questions/50349/how-long-does-block-validation-take/50407#50407

Still reigns true now (https://github.com/bitcoin/bitcoin/blob/0.20/src/chain.h#L18-L30), unsure of the exact rational behind it..

perhaps if you use a commodore64..

doublesha of the raw transaction data per transaction in block,
store in list, then hash the list,
then compare this hash with the one provided in the blockheader,
then hash the blockheader and ensure its below target,
we're talking milliseconds here..

heres an example from dash (x11 is a bit more harsh than sha256d, only enforcing the point)..

I did some quick checks based on the earliest blocks (0  to 119,964 contained in blk00000.dat just because I had them handy).  Comparing the time deltas based on sequential blocks from the beginning of (blockchain) time the delta ranges from -119 to  7,719 minutes, but sure enough the average is ~10 minutes!  That is surprising because the difficulty didn't change until the end of 2009, but the first dat file covers from Jan 03 2009 (Genesis block 0) to April 24 2011 (119,964) so I guess maybe it compensated later if the average was off initially?

Maybe so...I checked the metrics from blocks 1 to 38,091 (Feb 4, 2010) around the time of the first difficulty change from 1 to 2:  Min -65 mins, Max 7,719 min (FYI delta 0 to 1 was an anomaly next largest was 1509 min)  and the average was close to 15 minutes versus target 10 minutes. This means the average after that must have been less than 10 minutes for a while to compensate.

Interestingly the timestamps for follow on blocks can be earlier in time...that was a bit of surprise to me at first, but I learned I can't assume sequential blocks are in temporal order.  For example:

https://www.blockchain.com/btc/block/32649  -->  2010-01-02 04:49
https://www.blockchain.com/btc/block/32650  -->  2010-01-02 02:50

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.


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

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

645,098
645,090

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.

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

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

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