Bitcoin's Empty Blocks Analaysis.

[mikeywith]

I was trying to find a recent analysis of empty blocks and I couldn't find any, It seems like most of the analysis is outdated, so I decided to make one using blockchair explorer with some filters.


The analysis is based on 5 years, starting from the first day of 2015 ending on the last day of 2019, I have purposely ignored 2020 since we don't have enough data for it.


I started by analyzing the monthly empty blocks.


Chart 1: Numbers of blocks found per month (total of 60 months)

Added a more detailed chart showing the total of empty blocks per year.


Chart 2: Numbers of blocks found per year 2015-2019


The following figure is similar to figure 2 but in a pie chart, showing the exact number of blocks found per year


Chart 3: Number of blocks found per year between 2015-2019


Now comes the interesting part, below is a chart of total empty blocks per mining pool.


Chart 4: Number of blocks per mining pool 2015-2019

A different representation of the same chart


Chart 5: Number of blocks per mining pool 2015-2019


Since we have a total of 26 mining pools, and most of them have a very small number of empty blocks, I have excluded 16 of them and kept only the top 10 mining pools, showing the number of empty blocks they found and the percentage (share)


Chart 6: Number of blocks and total share (%) per mining pool 2015-2019 for top 10 mining pools


To get a better idea in regards to mining pools: time ratio, the chart below shows the number of blocks per year for each mining pool.

Chart 7: Number of blocks a per mining pool per the year 2015-2019


Excluding 16 mining pools and keeping only the top 10 we get a clearer chart.


Chart 8: Number of blocks a per mining pool per the year 2015-2019 top 10 mining pools.




My interpretation:

1- The unusual numbers of empty block found during certain periods based on chart 1 does show some evidence that "someone" did use Covert Asicboost, and based on the fact that Bitmain pools (Antpool+BTC.com) found nearly 55% of those empty blocks, I don't believe that bitmain only tried Covert Asicboost on Testnet.

2- Aside from Covert Asicboost, there is a good possibility that some mining pools were purposely refusing to include transactions in the blocks they mined, causing a delay in transactions confirmation probably to give the impression of bitcoin "block is too small and we must increase it", this perfectly coincides with the spam attacks on the blockchain which happened in 2017, to be more accurate, May 2017 as shown in the chart below.



Comparing this chart against chart number 1, you can clearly see that May 2017 had a huge spike in empty blocks, it had exactly 75 empty blocks which is twice as high compared to the average number of empty blocks around that period, the majority of those empty blocks were obviously mined by Antpool and BTC.com (Bitmain), while the transactions went from 10-50k to just a bit over 150k during that month, someone was really trying to "prove" something, it's most likely Bitmain wanting larger blocks.


3- The number of empty blocks is decreasing, and since there is no more obvious drama coming from Bitmain and the big-blockers, taking 2019 numbers which had a total of 314 empty blocks or 0.86 blocks every day or a block every 1.16 days, the numbers in 2020 look even better, so it seems like the mining infrastructure is improving in terms of routing protocols, block propagation time, the confirmation of the transactions in the last block, speed of constructing blocks, etc.

4- Judging based on the point above, it seems like the time needed to validate block transactions for miners is well below 10 seconds.  


I would love to hear your interpretations/thoughts regarding the data shown in this topic.

Mikey.

 
I could do a 10 years analysis instead of just 5, the only issue is scraping the data from blockchair.com, it took me very long to get 5 years worth of data, however, if someone (maybe LoyceV or DdmrDdmr) can help me scrape the data I'll be willing to make a 10 years analysis.

[1715229212]

1715229212

[1715229212]

1715229212

[philipma1957]

  Just today there was a fee free block.

Let me pull it up.

628428 came in 1 second after 628427

they ripped off 3 in a row

628426  fees were 1.0282xxx

https://www.blockchain.com/btc/block/0000000000000000000254d12f670a0e5f3bdf579ce961f23295b0f7f1a6a783

628427  fees were 0.9683
https://www.blockchain.com/btc/block/00000000000000000007a4504c9d9aa57510a66ae0c995da60cfbf7cee451d84

628428 fees were zero 0.0

https://www.blockchain.com/btc/block/00000000000000000008c8fa0d79f31b44e6df494d20da165bf0f0b291e13d9a

here is bitmain's stats page

https://www.antpool.com/poolStats.htm

[mikeywith]

 Just today there was a fee free block.

Let me pull it up.

628428 came in 1 second after 628427

True block 628428 was empty and was mined by Antpool, there is a more recent empty block 628603, the block you mentioned was found yesterday unless of course, you are in the U.S or somewhere very west then it's "today".

Below is a list of empty blocks for the past few days

628603   2020-05-02 18:22   1THash&58COIN   
628428   2020-05-01 15:15   AntPool      
628336   2020-04-30 22:30   BTC.com   
628017   2020-04-28 15:34   BTC.com   
627867   2020-04-27 14:53   F2Pool   
https://blockchair.com/


it's pretty normal to find 1 empty block every day.

[philipma1957]

bitmain had a 1 second block as per their stat page

 a normal block should be 600 seconds  odds for the network would be high  for any given block to be a 1 second block

you bring up an interesting point in saying we get 1 empty block a day.

that would be 1 in 144.

628603 came at 14:22:59
https://btc.com/000000000000000000015c0f2df9276237da03c568231b4f67d367ebdee91cd5


628602 came at 14:22:48

https://btc.com/00000000000000000003cdbcc1ed3d99bfb8c6db73a8db671a42a62624c30f7c


this is 11 seconds with zero fees

but ant pool block
628,428  came at 11:15:53

https://btc.com/00000000000000000008c8fa0d79f31b44e6df494d20da165bf0f0b291e13d9a

and block 628,427 came at 11:15:47

https://btc.com/00000000000000000007a4504c9d9aa57510a66ae0c995da60cfbf7cee451d84

this is 6 seconds or about 6/11 time to earn as the other example.

although on their stats page they claim it took 1 second.

I would love to know  the time gaps for every one  and how many per day.

____________________________________________________________________-
See below 32 second no earnings
_______________________________________________________________-
628336  18:30:32
https://btc.com/00000000000000000005fa95deb4a7815d38974c9aa55205794c21fae092c7da

628335 18:30:00
https://btc.com/0000000000000000000eef2b53bf510184ae045ee4ef9f8fffbed3a4bcb66bf2

that seems really long time to earn 0 tx fees

I checked the first 3 you listed

11  seconds 0 fees
 6   seconds 0 fees
32  seconds 0 fees



seems to me  if a pool is under 10 seconds it is not a big deal but 32 seconds seems really bad.

Obviously you need to check more then 3 to get a feel for fucked up issues.

A huge pool with 25% of the blocks could do a 10 second block vs 600 seconds that would not be unusual due to their hash amounts.  How many of those 10 second blocks are empty ?

a 25% pool makes 36 blocks a day or one every 40 minutes if they do a 10 second block every once in a while it will be empty.


I would love to see

1 second block
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
up to
60 second blocks    and tx fees they get.

[ranochigo]

Great analysis. Could you factor in the timestamp/the timing received by blockchair into the graph? It would be a lot clearer to see the timings between the empty blocks and the block before it.

[philipma1957]

Great analysis. Could you factor in the timestamp/the timing received by blockchair into the graph? It would be a lot clearer to see the timings between the empty blocks and the block before it.

I am interested in time breakdowns  I would love to see how many zero fee blocks are due to the sheer size of the pool

ie lets say under 10 seconds
vs something seems wrong lets say 30 seconds.

JUST a fast check of three shows  a big difference in time 6 to 32 seconds.

people scream empty blocks are  pools being bad actors

is it simply the pools are really big?


@ mikey thanks you thread made me consider that size is a bigger factor then I realize.

BTW  I think covert asic was done bigly back in the day.

I also think if someone uses  time analysis along with empty block like you did you can get a better idea of what was happening.

[nc50lc]

people scream empty blocks are  pools being bad actors

is it simply the pools are really big?

The fact that the time to mine those blocks is within seconds and the number of transaction is '1' (Coinbase TX) tell that those are probably mined with 'Covert ASICBoost'.
Because not including any transaction is the easiest way to generate a Merkle Root Hash (hashMerkleRoot) with fixed last 4 bytes.

But there's no evidence so I'll leave it with "probably"  

[mikeywith]

Great analysis. Could you factor in the timestamp/the timing received by blockchair into the graph? It would be a lot clearer to see the timings between the empty blocks and the block before it.

I could but there are two problems, the first one is scraping the data of blockchain,took me forever to extract the data for empty blocks which is nothing compared to the total number of blocks, but if someone has a better way of getting those data, put them in a table format like excel and send them to me, I can do it and even more perhaps.

The second problem is that time-stamping isn't exactly accurate, they are accurate enough to be used to adjust the difficulty, but not accurate enough in a sense that we can use them to reach to any conclusions, maybe if we find empty blocks coming after a long enough time (enough to actually validate the transactions of the previous block) and still come in empty, we would confirm that a certain pool did actually have enough time but did not include transactions on purpose, however, since the time-stamp is actually put in the header of the block by whoever mines it, they can manipulate it, say I find a block 60 seconds after the last block was propagated (nobody knows about it yet), I need 30 seconds to validate the previous transactions and reconstruct the pool, but I decide not to include any transactions, I can conveniently lie and say I found the block in 10 seconds, who is going to stop me from doing so?

JUST a fast check of three shows a big difference in time 6 to 32 seconds.

I don't think anyone knows exactly how long it takes a mining pool to fully download and validate the previous block, but I am pretty sure it's less than 32 seconds, of course, more complex blocks take slightly longer, but 32 seconds can't be it, why do I think so?

Applying cumulative distribution function, the probability of blocks being found between 1 and 32 seconds can be derived by:

exp(−1/600)−exp(−32/600) = 5.36% of blocks would be empty, in other would we would "in general" have an empty block every 18.6 blocks, that's nearly 8 blocks a day which would result in 2920 blocks per year, which never happened even when was well-intended.

so really 32 seconds is more than enough to validate the previous block, deal with the memepool and reconstruct the next block WITH transactions in it, but where did the 32 seconds come from?

1- That node's memepool was empty. > very unlikely.
2- The time reported is actually "wrong" > Very likely.


I would still do the analysis, but really the results will be meaningless

people scream empty blocks are  pools being bad actors

is it simply the pools are really big?

The fact that the time to mine those blocks is within seconds and the number of transaction is '1' (Coinbase TX) tell that those are probably mined with 'Covert ASICBoost'.
Because not including any transaction is the easiest way to generate a Merkle Root Hash (hashMerkleRoot) with fixed last 4 bytes.

But there's no evidence so I'll leave it with "probably"  

I don't think anybody uses Covert Asicboost anymore, finding blocks in the next second at any given time always has a probability of 0.166%, if everyone was mining with a pen and paper, people would probably still mine empty blocks.

To explain even further, for the past 4 months of 2020 we had exactly 14 empty blocks every month, that's a bit less than 0.5 blocks a day, this is below normal as far as statistics and probability are concerned, applying the above formula and assuming for the sake of it that 5 seconds is more than enough to validate the transactions it is still OKAY to mine an empty block once every day, I think the number of empty blocks for the past 2 years is pretty normal.

[nc50lc]

-snip-

I don't think anybody uses Covert Asicboost anymore, finding blocks in the next second at any given time always has a probability of 0.166%, if everyone was mining with a pen and paper, people would probably still mine empty blocks.
-snip-

That probability explains the seconds difference in the timestamp but those "few seconds block" that are empty can't be a coincidence.
Because if it's just luckily mined, then it shouldn't be empty unless it's purposely made empty.

But since it's usually only seconds after the previous block, there's low to zero effect on the network when it comes with transaction validation.
So I agree with the second paragraph.

[mikeywith]

That probability explains the seconds difference in the timestamp but those "few seconds block" that are empty can't be a coincidence.
Because if it's just luckily mined, then it shouldn't be empty unless it's purposely made empty.

Nop, the probability explains exactly the chances of actually finding a block the very next second, it has nothing to do with the timestamp, in other words, if you were mining your own blockchain with 0 verifications needed, the chances of hitting a block in that very next second is always 0.166% (provided the mean time is 600 seconds), empty blocks are found in a very short time anywhere from => 1 second and < the time needed to validate with the previous block.   

We could also be talking about different things here, but the use of the word "purposely" creates confusion, miners want nothing more than extra profit, they have every interest in the world to NOT mine empty blocks WHEN they can fill them with transactions, but they have no problem with mining empty blocks when they happen to find one BEFORE being able to download the previous block, validate the transactions, clear the memepool, reconstruct the block and then propagate it, so this is not really "purposely" mining empty blocks, because "purposely" means they "CAN SAFELY" include transactions but they chose not to, which is not the case at all because nobody is mining empty blocks for the sake of it.

[pooya87]

the main reason for empty blocks has always been SPV mining, that is the fact that miners didn't verify the previous block completely before starting the next so they start with an empty block until they verify the previous one and be able to update their mempool and add new transactions to their block. sometimes they get lucky and find the answer to that empty block and publish that.
since during the past couple of years there has been a lot of improvements in the speed of transaction verification process with all the optimizations done by core team and SPV mining is not that common anymore we are seeing a much reduced number of empty blocks nowadays.

as for ASIC boost, it is an optimization that could only makes sense financially. using this optimization to the algorithm with which a miner computes the block hash will only give a very small "boost" that small boost could only make sense if mempool was empty or had very low paying fees.
ignoring the 2015 in your chart, the 2017 spike doesn't make any sense to be linked with ASIC boost since during that spike on your chart we were paying miners between 3 to 5 bitcoins in fees in total per block. in other words an empty block was losing somewhere around $8000 (25% of block reward).

p.s. why does all your charts say number of "blocks" instead of "empty blocks"? i'm confused...

[mikeywith]

as for ASIC boost, it is an optimization that could only makes sense financially. using this optimization to the algorithm with which a miner computes the block hash will only give a very small "boost" that small boost could only make sense if mempool was empty or had very low paying fees.

What do you mean by a small boost? using Asicboost yields up to 2000% more profit, even now with overt Asicboost mining gears run with 20% less power, giving the fact the profitability margin is too small a 20% savings on the power bill is a dozen time more profit, miners rather mine empty blocks using Asicboost than including your transactions even if you think you were paying high, overt Asicboost, however, does not have the tendency of generating empty blocks, so miners still use the boost and include your transactions, but the former is more important to them than the latter 99% of the time.

As far as May 2017, I did point that

Aside from Covert Asicboost, there is a good possibility that some mining pools were purposely refusing to include transactions in the blocks they mined, causing a delay in transactions confirmation probably to give the impression of bitcoin "block is too small and we must increase it", this perfectly coincides with the spam attacks on the blockchain which happened in 2017, to be more accurate, May 2017 as shown in the chart below.

p.s. why does all your charts say number of "blocks" instead of "empty blocks"?

Sorry, I forget to add the word "empty", figured that out later but then I thought that shouldn't be so confusing given the blocks number is too small and the obvious topic title and content which focuses on empty blocks, thanks for pointing that out anyway.

[pooya87]

using Asicboost yields up to 2000% more profit,

that number makes no sense at all.
mining is calling the SHA256 compression function 3 times, this "boost" is changing these 3 calls by fixing the result of one for part of the computation and the result is far less than 2000% profit!!! it would at most increase it by 10%.

in any case let me ask you this, since you claim the reason for empty blocks is ASIC boost how do you explain lack of it nowadays? 2000% increased profit seems to be an excellent incentive to always use ASIC boost and mine empty blocks.

[mikeywith]

that number makes no sense at all.

Well, you can complain to "Antonopoulos" who mentioned the 2000%, or you can prove him wrong, or I can save you the trouble and explain to you why he is right.

Here is the calculation from whattomine.com for a single miner that does 10th and consumes 1000w ( pretty much similar efficiency to the most famous miner Antminer S9 taking the average rate of 6 cents per Kwh the miner earns exactly $0.02.

Now running the miner with Asicboost which can achieve up to 30% decrease in power consumption, the miner now uses only 700 wats and makes 0.46$ a day that's a 23 times more profit aka 2200% more profit, and by the way, I am not even trying to tweak any numbers to get to these results, i am using the average gear with the average power rate, results can be a lot better for many other miners.

in any case let me ask you this, since you claim the reason for empty blocks is ASIC boost how do you explain lack of it nowadays? 2000% increased profit seems to be an excellent incentive to always use ASIC boost and mine empty blocks.

Bitmain still uses Asicboost,  I personally use Asicboost, almost everyone and their grandmother uses ASICboost nowadays and get 20-30% saving on the power cost aka 2000% more profit, what you must understand is that there are TWO types of ASICboosts, the COVERT used previously by bitmain which bitmain then denied, that type of ASICboost has to do with empty blocks, the community opposed it because it's patented and it's not easy to detect and is not compatible with SegWit.

The OVERT Asicboost is a whole different story, it's the one we use now, has no effect on empty blocks, easily detectable, etc.


I hope that by now the confusion is gone.

[tranthidung]

I could do a 10 years analysis instead of just 5, the only issue is scraping the data from blockchair.com, it took me very long to get 5 years worth of data, however, if someone (maybe LoyceV or DdmrDdmr) can help me scrape the data I'll be willing to make a 10 years analysis.

I checked at https://blockchair.com/bitcoin/blocks?q=
It seems they only allow 10 blocks in a new batch of result. I don't find option to set up time window to get all time data. Or did I miss something? If there is such option, I can help you.

[LoyceV]

I could do a 10 years analysis instead of just 5, the only issue is scraping the data from blockchair.com, it took me very long to get 5 years worth of data, however, if someone (maybe LoyceV or DdmrDdmr) can help me scrape the data I'll be willing to make a 10 years analysis.

A year ago, I scraped all block headers from blockchain.com (for this topic). Around the same time someone posted a link to a site that allowed to quickly select this data, but I can't find it back.
I set a 1.8 second delay in between page loads. If you tell me exactly what you need, I can get it in about 2 weeks. Running on a VPS is not a problem, assuming Blockchain.com hasn't changed scraping restrictions.

[tranthidung]

I set a 1.8 second delay in between page loads. If you tell me exactly what you need, I can get it in about 2 weeks. Running on a VPS is not a problem, assuming Blockchain.com hasn't changed scraping restrictions.

https://blockchair.com/bitcoin/blocks?q=time(2020-05-02%2010:19:32..2020-05-03%2010:19:32)

I think these following indicators are enough (choose them from the General section):

• Height
• Mined on
• Miner
• Generation (BTC)
• Reward (BTC)

Raw data will be like that, and I can import data with tab delimiter to find which blocks are empty and related details (miners & date time)  

Code:

Height	Mined on 	Miner	Generation (BTC)	Reward (BTC)
628553	2020-05-02 10:15	OKEX	12.50000000	13.36347909
628552	2020-05-02 09:59	F2Pool	12.50000000	12.71661242

I don't know what does it mean with the part from the link above

Code:

(2020-05-02%2010:19:32..2020-05-03%2010:19:32)

Can we set up something to display all time data?

I tried but it only narrows down time window and only 10 lines of result are displayed.

[mikeywith]

If you tell me exactly what you need, I can get it in about 2 weeks. Running on a VPS is not a problem, assuming Blockchain.com hasn't changed scraping restrictions.

The problem now is that some members want to know the time difference between empty blocks and the block that came before them, to analyze this kind of data Blockchain.com is not enough as it doesn't show the full timestamp, it's missing the last two digits the represent the seconds, the only explorer I am aware of which provides the full timestamp is https://blockstream.info.

for this study, I will need the following columns.

Height
TimeStamp
Transactions (only the number)

If possible (depends on how you scrape the data, you could exclude all blocks that are not followed by a block which has 1 transaction (empty block), this will reduce the data by a tremendous amount, if you can't filter the results, it's okay, I can do it.


Now in regards to a similar study in the OP but with longer data, all I need is

Miner
Timestamp
Transactions ( number of transactions)

You still can't use blockchain.com because it doesn't show the timestamp, so really blockchain.com is no use, and you will need to use blockchair for that, here is a permalink of what I need https://blockchair.com/bitcoin/blocks?q=transaction_count(1)#f=time,guessed_miner,transaction_count

I think these following indicators are enough (choose them from the General section):

Height
Mined on
Miner
Generation (BTC)
Reward (BTC)

Three of those are not needed for the study, please refer to my explanation above

I tried but it only narrows down time window and only 10 lines of result are displayed.

Exactly, that's the problem, Imagine how time-consuming that was when I had to do that manually for 5 years of empty blocks   , but I can only think that there is a way to automate this.

[LoyceMobile]

I'll see what I can do. I kinda want to just scrape everything, and make a huge csv. That'll come in handy for other analyses too.

[philipma1957]

I'll see what I can do. I kinda want to just scrape everything, and make a huge csv. That'll come in handy for other analyses too.

It would be cool to see that a huge amount of empty blocks by antpool were 30-60 seconds

vs 1-10 seconds as it would expose a pattern of bad acting that they are accused of.

[tranthidung]

Yesterday, I saw that link https://gz.blockchair.com/bitcoin/blocks/ but I gave up when see their message that all files require over 1Tb. If it is what you will have to scrape everything, it is good to download their files to save time.  

I have not yet used or extracted any file with that format. I searched and found TSV means tab separated values. I will try to extract one file to see how it looks.

I still think include blocks that have same amount of generation and reward BTC is good because we will know there are how many percent of fake empty blocks with same generation and reward BTC.

How to include that condition from what you have us?
https://blockchair.com/bitcoin/blocks?q=transaction_count(1)#f=time,guessed_miner,transaction_count

Your current conditions result in less than 90k results!

[mikeywith]

I'll see what I can do. I kinda want to just scrape everything, and make a huge csv. That'll come in handy for other analyses too.

If that's not too much to scape I would encourage you to do that, I am also interested in block-size analysis, kind of want to see if we are really fully utilizing the block-size we have now or we aren't and all these calls for block size increment are unlogical, further analysis like how often do we really get unusual block time such as 1 or 2 hours block is also interesting, different studies require different data, so scrapping everything especially from blockchair.com will be really useful, good luck and please keep me updated.

Yesterday, I saw that link https://gz.blockchair.com/bitcoin/blocks/ but I gave up when see their message that all files require over 1Tb. If it is what you will have to scrape everything, it is good to download their files to save time. 

1TB is TOO MUCH, those files probably contain everything about the blocks and more, the current blockchain size less than 250gb, the data we need shouldn't be larger than 1mb in a text/excel format, I most certainly can't process a 1TB worth of data.

I still think include blocks that have same amount of generation and reward BTC is good because we will know there are how many percent of fake empty blocks with same generation and reward BTC.

The generation is the same for every 210,000 blocks and they have nothing to do with a block being empty or full, the generations are not needed in this study and most likely not in any other analysis, I can simply populate them manually if I had to since we know the first block had 50 btc and then 210,000 later it was 25 btc and then 210,000 later it became 12.5 btc, I don't know how to explain it better, but really we don't need them.

for the reward, it's merely generation + fees, if you include the fee(btc) column you will see that, now similar fees for more than one block proves nothing, they are pretty normal.

Your current conditions result in less than 90k results!

That simply means we had less than 90k empty blocks since Satoshi mined the first block.

It would be cool to see that a huge amount of empty blocks by antpool were 30-60 seconds

vs 1-10 seconds as it would expose a pattern of bad acting that they are accused of.

Phill, I will probably still do that analysis for you and the other person who requested it, but I can tell you beforehand that it will prove NOTHING, bitmain can find blocks in 30 seconds and fake the time in the block header to be 3 seconds unless you could hack into their database and assuming they do keep such records, the study will prove nothing, you are counting on their stupidity, integrity, and kindness, and we both know bitmain doesn't have any of those three aspects.

[pooya87]

I'll see what I can do. I kinda want to just scrape everything, and make a huge csv. That'll come in handy for other analyses too.

It would be cool to see that a huge amount of empty blocks by antpool were 30-60 seconds
vs 1-10 seconds as it would expose a pattern of bad acting that they are accused of.

it is worth noting that timestamps are only as accurate as the clock of the computer that created the block to be mined. specially when the plan is to compare the timestamps with a high accuracy of a couple of seconds you have to take the room for error in mind.

[LoyceV]

Yesterday, I saw that link https://gz.blockchair.com/bitcoin/blocks/ but I gave up when see their message that all files require over 1Tb.

Great find! But it's much, much less than 1 TB. I'm downloading this now (at 10 kB/s) to make a big csv. If it has enough data it's much faster than scraping all blocks.

it is worth noting that timestamps are only as accurate as the clock of the computer that created the block to be mined. specially when the plan is to compare the timestamps with a high accuracy of a couple of seconds you have to take the room for error in mind.

If I'm not mistaken, the time between blocks can even be negative if the miner's clock is a bit off.

[mikeywith]

If I'm not mistaken, the time between blocks can even be negative if the miner's clock is a bit off.

You are right, he only rule that stops miners from mining blocks with timestamp in the past is the MPT rule, which states that timestamp of any given block must be > than the median time of the last 11 blocks, since the median of 11 blocks is block 6, this means

Timestamp of block 12 can be

less than block 11
less than block 10
less than block 9
less than block 8
less than block 7

can NOT be less than block 6 timestamp, provided block 1 to 11 didn't have any negative timestamps, if they do, the calculation method will be different, the code simply takes the past 11 timestamps and get the median of those, which is always the 6 blocks back if they all had positive timestamp differences, I might be mistaken, would love to be corrected.

so timestamps can be negative, not only if the miner's clock is off, it could be done intentionally, but to miners best interest (assuming they are not purposely mining empty blocks and trying to hide it) is to fake the time to be LONGER and not shorter, because that gives the miners a decrease in difficulty while the latter causes an increase in difficulty and thus reducing their rewards in the future.

[pooya87]

so timestamps can be negative,

do you mean the difference between two timestamps (t2-t1<0)?
because if not, and if you are indeed talking about the 4 bytes after the merkleroot hash in a header then i would love to see how this works. is it another weird thing in bitcoin protocol that we let happen?

[mikeywith]

 (t2-t1<0)? 

Given the context i think it is pretty clear what i mean is the quoted part, however you brought up an interesting point,
 the timestamps in the header are the seconds elapsed since 1st jan 1970, can unix timestamp be negative? I don't know.

Let's assume you managed to sequeze in a negative value and kept it at 4bytes, what will actually happen? Is there any piece in the code that specifically checks that?  The only issue is that timestamps - - timestamps will result in a timestamps that way far into the future, which then will be invalidated by this rule.

Code:

MAX_FUTURE_BLOCK_TIME =
2 * 60 * 60

[pooya87]

i'm the worst at reading C++ but it seems like core is storing the blocktime (ntime) as an unsigned 32-bit integer[1] and during comparisons (eg.[2]) the GetBlockTime() method [3] is called which will cast that into a 64-bit signed integer which means it will never be negative (casted UInt32.Max = 0x00000000ffffffff => always positive)

[1] https://github.com/bitcoin/bitcoin/blob/78dae8caccd82cfbfd76557f1fb7d7557c7b5edb/src/primitives/block.h#L27
[2] https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L350
[3] https://github.com/bitcoin/bitcoin/blob/54f812d9d29893c690ae06b84aaeab128186aa36/src/chain.h#L247-L250

[mikeywith]

I am not good at C++ too, but I know it can't be 64 bit both singed and unsigned because 64 bits is 8 Bytes and thus it won't fit into the block header, so it must be 32, by quickly skimming the public class code

Code:

uint32_t nTime{0};

So no negatives here, only 0 and above, all the way to 4294967295 and that so happen to be equivalent to 02/07/2106 @ 6:28am (UTC) according to https://www.unixtimestamp.com/index.php, so in 86 years, some work and a fork will be needed to keep the blockchain going.

[LoyceV]

which means it will never be negative

I just checked (using this work in progress), and using yesterday's data I found 14,145 blocks that had a time earlier than the previous block.
Examples:
628453 - 2020-05-01 19:02:08
628454 - 2020-05-01 19:02:54
628455 - 2020-05-01 19:02:47 (-7 seconds)
628456 - 2020-05-01 19:02:34 (-13 seconds)
628457 - 2020-05-01 19:13:10

I would have expected miners to synchronize their clocks much more.

[DaCryptoRaccoon]

This is a very interesting topic I brought up something about this a long time ago back in 2018 when I spotted strange things happening in the block explorers.

https://bitcointalk.org/index.php?topic=4998410.msg45156234#msg45156234

My post was actually deleted at the time. (Screen shot 2)

I felt it was a valid question to ask as it was not something you normally see happening on the chain it looked to me like someone had worked out how to manipulate the time to ensure they could mine the next block empty before anyone else even started on the block.

So are people now thinking that antpool and bitmain are doing something sketchy to ensure they can mine those empty blocks while the rest of us are trying to play on the un-level playing field?

I was under the impression that most miners used the NTP time pool's for there clock source I know my old miners used NTP and even had the ability to run as NTP server.   

Thanks

Magic

[mikeywith]

someone had worked out how to manipulate the time to ensure they could mine the next block empty before anyone else even started on the block.
 

Nop, can not start mining block N before everybody else knows about block N-1 ( ignoring network delays for certain nodes), block timestamps mean nothing in regards to the chain order. 

So are people now thinking that antpool and bitmain are doing something sketchy to ensure they can mine those empty blocks while the rest of us are trying to play on the un-level playing field

That is not what anybody else is thinking, you see having negative times between blocks only means 1 of 3

1- The clock is off (behind)
2-The clock of the miner who mined the previous block is off (ahead)
3- The miner doing that on purpose to

 a- hide the fact that they had enough time to include transactions but refused doing so. (this is what people are suspecting)

b- The miner wants to artificially increase the difficulty by tricking the protocol as if blocks were mined faster than they actually were (no logical reason for any miner to do so)

[tranthidung]

I just checked (using this work in progress)

It has not yet included block heights. Could you include block heights, please.

[LoyceV]

I just checked (using this work in progress)

It has not yet included block heights. Could you include block heights, please.

I was still working on it, see Bitcoin block data in CSV format.

@mikeywith: is this what you were looking for?

[tranthidung]

see Bitcoin block data in CSV format.

You are actually a data-mining beast, LoyceV. Thanks for another data which is huge this time.  

[BrewMaster]

1- The clock is off (behind)
2-The clock of the miner who mined the previous block is off (ahead)
3- The miner doing that on purpose to

 a- hide the fact that they had enough time to include transactions but refused doing so. (this is what people are suspecting)

b- The miner wants to artificially increase the difficulty by tricking the protocol as if blocks were mined faster than they actually were (no logical reason for any miner to do so)

keeping in mind that a miner first sets the block time in the header and then starts mining it the reason for the differences in matter of seconds between blocks and real time could simply be because the miner took longer to update the time.

for example the miner could set the time then start going through the nonces then after failing to find a good hash they change their "extra nonce" and hash again, and so on. then right before they get around to update the time they could find a good hash and release it. so the result is a couple of seconds in the past.

[mikeywith]

is this what you were looking for?

By the look of it, it seems like that is more than I need, I have yet to download the data I need and see if it fits in perfectly in my excel sheets, you did a great job.

It has not yet included block heights. Could you include block heights, please.

It is there, he refers to it as ID > http://loyce.club/blockdata/id.txt

keeping in mind that a miner first sets the block time in the header and then starts mining it the reason for the differences in matter of seconds between blocks and real time could simply be because the miner took longer to update the time.

You are right indeed, but that difference in time is too small to be considered, updating the time in the block header probably takes a few milliseconds and since it doesn't affect the miner chances of solving the block and also keeping in mind that for miners' best interest the time is either exact or in the future (to make the best use of next difficulty adjustment) it's safe to say at least large mining pools make sure the time is rather in the future, not the past.

but really combining all these factors, small or large, makes the analysis a bit far from accurate, but I will do it either way.

[mikeywith]

As requested by a few members, and after getting the data from LoyceV, here is what I came up with.


I excluded the years before 2016 so the data is only for 2016-2019, the reason behind this is the fact that in the early days, we had a ton of empty blocks, simply because at many times there were no transactions to be added to the block anyway, also most of the blocks come from "unknown" miners.

In this chart, I show the total time for all timestamps of empty blocks - the block which preceded it for the top 5 pools.




But I realized this figure might be misleading because finding more empty blocks will give the miner a lead in this chart, and since Antpool did find a ton of empty blocks most likely do the use of covert Asicboost, the figure above might not show any evidence of delaying transactions on purpose.

The next step was getting the average timestamp for those empty blocks, I got the total time difference and divided it by the total number of empty blocks per pool per year.




The above figure is pretty fair since it takes into account that larger pools tend to find more blocks and therefore find more empty blocks.


Based on the points mentioned in the previous comments, I will not attempt to conclude anything out of this study, everyone is free to interpret
these figures the way they like.

[PrimeNumber7]

Great analysis. Could you factor in the timestamp/the timing received by blockchair into the graph? It would be a lot clearer to see the timings between the empty blocks and the block before it.

I could but there are two problems, the first one is scraping the data of blockchain,took me forever to extract the data for empty blocks which is nothing compared to the total number of blocks, but if someone has a better way of getting those data, put them in a table format like excel and send them to me, I can do it and even more perhaps.

The second problem is that time-stamping isn't exactly accurate,

If you are running a full node, you can use RPC commands to obtain timestamp information about each block, using the RPC command "getblock" using verbosity 1. This will not tell you which pool mined each block, you will need to get this from somewhere else.

The published timestamp has the potential to be off by up to 2 hours, although in most cases, I believe it is closer to accurate. To have an authoritative timestamp, you will need to have a well-connected node that you specifically program to keep track of the time each block is received.  If you only have the published timestamp, that will have to do.

I would be curious if there is a correlation between the percentage of blocks found, and the percentage of zero tx fee blocks/total pool blocks found, and if so, what this correlation is. Does the percentage of zero tx fee blocks/total pool blocks found increase as the percentage of blocks found increases? Are there any outliers in this particular slope?

I would not want to pre-judge data, but I would propose that pools that find more blocks generally can invest in better equipment/network connectivity, to process found blocks, to propagate found blocks, and to identify found blocks. I would also propose that some pools may have different groups miners try to find blocks based on different sets of transactions.

[pooya87]

This will not tell you which pool mined each block, you will need to get this from somewhere else.

if you use Verbosity 2 then each transaction in block will also be fully shown in JSON format and the first one is obviously the coinbase tx which contains the possible name of the pool or miner that found the block. all you have to do is to find result.tx[0].vin.coinbase then use UTF8 to decode the result. for example for block (currently last block) 0000000000000000000fcf675c44734ddbe2af6dddd480f7d7aba324488f138d

Code:

��	4Ÿ^vip/www.okex.com/��mm�d8OR :Y:�ٜ�U��Juf��䶎;x

then search inside that string for known names which could found online with a little search.

it could also split into two calls (reduces the size of the first response):
first with verbosity 1 as before then fetch the first transaction ID then use that in getrawtransaction with verbose true to get the coinbase JSON as a single transaction and do the same UTF8 decode again.

test here if you don't have a node close:
https://chainquery.com/bitcoin-cli/getblock
https://chainquery.com/bitcoin-cli/getrawtransaction

[PrimeNumber7]

How frequently over the past 5 years have miners put their name into the coinbase tx as you describe? Is this how most block explorers determine which pool found each block this way? Or do they look at different/additional information?

[pooya87]

How frequently over the past 5 years have miners put their name into the coinbase tx as you describe? Is this how most block explorers determine which pool found each block this way? Or do they look at different/additional information?

from genesis block (block zero) coinbase transactions were allowed to put anything they wanted in their input's signature script since coinbase transaction doesn't really have any input (empty outpoint and max index). and Satoshi is the first miner who put something there (Chancellor on brink of second bailout for banks).
but it is optional, so only big mining pools put their name mostly as advertisement. interesting enough if you look closer each pool has multiple servers and each server puts a different name in there. there may be miners who don't though.
i believe that is the only way block explorers or any other chain analyzers determine hashrate distribution. the only other way would be if the pools publicly published ALL their addresses so we could see which address is receiving which blocks' rewards. which is not possible since addresses can change constantly.

[PrimeNumber7]

How frequently over the past 5 years have miners put their name into the coinbase tx as you describe? Is this how most block explorers determine which pool found each block this way? Or do they look at different/additional information?

from genesis block (block zero) coinbase transactions were allowed to put anything they wanted in their input's signature script since coinbase transaction doesn't really have any input (empty outpoint and max index). and Satoshi is the first miner who put something there (Chancellor on brink of second bailout for banks).
but it is optional, so only big mining pools put their name mostly as advertisement. interesting enough if you look closer each pool has multiple servers and each server puts a different name in there. there may be miners who don't though.
i believe that is the only way block explorers or any other chain analyzers determine hashrate distribution. the only other way would be if the pools publicly published ALL their addresses so we could see which address is receiving which blocks' rewards. which is not possible since addresses can change constantly.

I have noticed over the years that some pools use the same address for block reward payout, while others don’t and some pools have paid out to their miners directly.

I guess my question is if you use the verbose 2 option for the getblock RPC call, how many blocks could you determine the pool that mined each block?

I would not be surprised to see major pools to have different servers putting different message variations into the input signature script of the Coinbase transaction for debugging purposes.

[kano]

the main reason for empty blocks has always been SPV mining, that is the fact that miners didn't verify the previous block completely before starting the next so they start with an empty block until they verify the previous one and be able to update their mempool and add new transactions to their block. sometimes they get lucky and find the answer to that empty block and publish that.
since during the past couple of years there has been a lot of improvements in the speed of transaction verification process with all the optimizations done by core team and SPV mining is not that common anymore we are seeing a much reduced number of empty blocks nowadays.
...

What has changed is that they simply update the work to the miners faster now than they used to do it.
Simple example:

Before
Blockchange ... send out empty work.
30s later ... send out new work with transactions.

Over time I guess they realised how stupid this is and changed it to:

Now
Blockchange ... send out empty work.
A few seconds later ... send out new work with transactions.

Magic! Now they generate 10% of the empty blocks they used to generate if they take 3s instead of 30s
If they take 0.3s, empty blocks drop to 1% ... etc.

You can see that most pools are still ignoring transactions on a block change.
If you can see the mempool after each block change ... you check that, any time, after you see an empty block on the network.
... I can coz I have extra information in the logs coded into all the bitcoinds that run on my pool so I can always see the size of all work generated.

P.S. I'm one of the VERY few pools that has NEVER mined an empty block
I can only think of one other pool - and that effectively died recently when they lost yet another block due to negligence by the guy who ran the pool.

P.P.S. the time to validate a block and generate a full block is less than 200ms

[kano]

How frequently over the past 5 years have miners put their name into the coinbase tx as you describe? Is this how most block explorers determine which pool found each block this way? Or do they look at different/additional information?

At the moment I get about 99% identification from a text search or address scan of each block's coinbase transaction,
just like any of the large explorers do.

True unknown's are rare as you'll see on any of the large explorers.

Usually when it drops to the low 90s, it means someone changed their sig text so I just look at an 'unknown' and see what's changed
- e.g. f2pool changed the text a bit, recently.