question on empty block mining economy

[tdk2]

Hi,

maybe someone can shed light on a question I am wondering about.

Empty blocks are usually found very quickly after a "normal" block. The explanation I have heard most is that miners will start mining an empty block while they still assemble the tx and merkle roots for the next "normal" block. Sometimes they get lucky in this short time.
The frequency of empty blocks would suggest this "short time" to be around 5 seconds, plus/minus 50% or so. This sounds like an awfully long time to get the normal block preparation done.
Is there something I am missing? Is the chance to catch the block reward with an empty block good enough to always mine on it for several seconds?

thanks for any insights

[1715093298]

1715093298

[1715093298]

1715093298

[DaveF]

It really is a calculated risk.
You CAN get the block processing work done faster, BUT if someone else gets just as lucky 1st you loose the block.
So it becomes a bit of a loop Do you wait the full second or so or do you work with what you have.
A pool solves a block, another pool comes right behind that black with an empty block. Another pool put up a block with TXs but it was 0.1 seconds behind it.
They loose the full reward because they wanted those TX fees

Some pool operators like to brag that they can figure out the block and begin working on the next one in fractions of a second.
They probably can, but a larger pool solving 40+ blocks a day. The risk of loosing some TX fees is greater then the risk of loosing the entire block to them.
To a small pool operator that does not even solve a block a month, they need to try to get every last BTC0.00000001 they can.

-Dave

[ranochigo]

Empty blocks are usually found very quickly after a "normal" block. The explanation I have heard most is that miners will start mining an empty block while they still assemble the tx and merkle roots for the next "normal" block. Sometimes they get lucky in this short time.

Yes, if the blocks are relayed at almost the same time.

The frequency of empty blocks would suggest this "short time" to be around 5 seconds, plus/minus 50% or so. This sounds like an awfully long time to get the normal block preparation done.
Is there something I am missing? Is the chance to catch the block reward with an empty block good enough to always mine on it for several seconds?

Miners usually have to download and validate the entire block before continuing to the next block. Certain pools would connect to each other with zombie users to attempt to get the block headers ASAP, without downloading and validating the blocks. This was the case back in 2015, but the efficiency of block relaying has improved so much that it really isn't that necessary.

I'd say that there's really nothing to lose for the miners. It would be worth if the relaying and validation takes a few seconds; if you were to wait and assemble a new set of merkle roots in the meantime, the time inbetween is still wasted. The only caveat being that it isn't fully validated before the pool starts on the new block; resulting in 2015 Bitcoin fork fiasco.

[DaveF]

Another thing is how the majority of miners on the pool are getting paid.
If it's PPLNS then you don't care if you miss a block, sucks to be the people mining there but they loose. The pool just looses their fee.
If it's a PPS pool then, the miners get paid no matter what, so get the block out ASAP and worry about the additional tx fees for the next block. Because you have to pay the miners.

-Dave

[DannyHamilton]

Also note, there is no universal exact time that all miners and pools are using.  Because of this, there may be some miners and/or pools that use the timestamp as an additional nonce. The timestamp in the block header can vary quite a bit. So, that 5 seconds might not actually be 5 seconds.

So, some of the "delay" that you are seeing may be attributed to:

1. Time for the first completed block to be propagated from the miner that "solved" it, to the pool that miner was participating in, to the pool that will solve the second block, to the miner that will solve that second block.
2. Differences in clock time between the two pools that build the two blocks.
3. Time for the second pool to verify the first block, and then build the second block.
4. Any alterations made to the timestamp in the process of solving the second block.

[tdk2]

Also note, there is no universal exact time that all miners and pools are using.  Because of this, there may be some miners and/or pools that use the timestamp as an additional nonce. The timestamp in the block header can vary quite a bit. So, that 5 seconds might not actually be 5 seconds.

I was not looking at the timestamps for my estimate. If average block time is 10min (600s) , then a quota of roughly 1% of empty blocks found points to an average "empty block mining time" of 6s. Rough guesstimate, of course, but still way beyond the actual "assembly time" for a full block header.

From the previous answers (thanks!) I get that many widely varying economic factors come into play for a pool's decision on how long to keep mining the empty block.

[pooya87]

I was not looking at the timestamps for my estimate. If average block time is 10min (600s) , then a quota of roughly 1% of empty blocks found points to an average "empty block mining time" of 6s. Rough guesstimate, of course, but still way beyond the actual "assembly time" for a full block header.

You can't guess these things you have to look at the actual values, and the only value we have is the timestamp inside each block header. You could also run your own node and then measure the time based on when you receive the new block but it won't be accurate either because you would be affected by delay caused by other nodes receiving, verifying then notifying you and you receiving that block.

Here are past 4 "empty" blocks and their previous block with their timestamps, the difference is 0 or 1 second:

Code:

672200	2021-02-25 23:56
672199	2021-02-25 23:55

672183	2021-02-25 21:38
672182	2021-02-25 21:38

671897	2021-02-24 01:57
671896	2021-02-24 01:57

671775	2021-02-23 02:46
671774	2021-02-23 02:45

You can find more on a block explorer and then by clicking on the "empty" block and looking for its previous block you can see both timestamps:
https://blockchair.com/bitcoin/blocks?q=transaction_count(1)#f=id,time,transaction_count

[tdk2]

DannyHamilton just explained that there is no universal timestamp.

And even if I went your way, it would only make the mystery much deeper: If really most empty blocks are found within a second, and we have about 1% empty blocks on average - that would mean the probability to find an empty block within 1 second is 1%. Not 1/600th of the roughly 50% at average block time of 600s.

Do you imply that different mathematics of difficulty apply to empty blocks?
If yes, why would any miner "waste" 99% of his computing time on finding full blocks, when mining empty is so much easier?

[ranochigo]

And even if I went your way, it would only make the mystery much deeper: If really most empty blocks are found within a second, and we have about 1% empty blocks on average - that would mean the probability to find an empty block within 1 second is 1%. Not 1/600th of the roughly 50% at average block time of 600s.

Do you imply that different mathematics of difficulty apply to empty blocks?
If yes, why would any miner "waste" 99% of his computing time on finding full blocks, when mining empty is so much easier?

The way the difficulty works should be the same as well. If it's empty, the merkle root is the TXID of coinbase so there is really no difference in the difficulty whether you are mining empty blocks or not. You could use covert ASICboost and mine empty blocks but that probably wouldn't make sense economically.

I see that you understand that the distribution of the block intervals follows an exponential function and that the probability of a block being 1 second from each other is 0.167%. The problem with this is that there is no perfect information when you're looking at block intervals. Propagation of the transaction across the network takes some time (depending on how well your node is connected). The only metric that is remotely usable is the timestamp that the block is received by the node which is subjected to the delay as above.

It would be a stretch to assume that all of the blocks are mined within 1 second of each other. It's much faster to just take just the hash of the block header on the other pool than waiting for it to be relayed through the network.

[franky1]

1. Time for the first completed block to be propagated from the miner that "solved" it, to the pool that miner was participating in, to the pool that will solve the second block, to the miner that will solve that second block.
2. Differences in clock time between the two pools that build the two blocks.
3. Time for the second pool to verify the first block, and then build the second block.
4. Any alterations made to the timestamp in the process of solving the second block.

not quite.
pools create the block and the datahash of the block. they only send the hash to the miners and miners only send a hash back that represents the solution with the correct amount of leadings zeros
ASICS do no store block data. they only receive. process and send hashes. nothing more

here is where the real efficiences are in empty blocking.. first lets show what takes the time.
1. most pools wait for opponents solved block to then confirm that block.
2. remove those confirmed tx from the mempool to know whats leftl in mempool is unconfirmed tx
3. grab transactions from mempool to ensure their new attempt only has unconfirmed transactions added.

by doing 'empty block' pools can skip all 3 steps and just make a block using just the opponents hash without even bothering to confirm the block or the tx content
this can save minutes.

opposing pools do treat blocks as valid based on fastest first to be valid gets kept. but this is based on received time into the node not timestamp time of the block.
if timestamp was even a thing. pools would just put a time stamp 20minutes earlier each time and win. even if it took them 22 minutes to complete

[pooya87]

this can save minutes.

All of that takes only seconds not minutes.
Additionally with new protocols added years ago no new node downloads "the entire" block anymore, they only have to get the transaction IDs and check them against their mempool and update the database while knowing those txs are already validated. Again reducing the time it takes to download and verify a block and update databases.

[DaveF]

Also, a lot of this discussion is using the assumption that the pools are using the "stock reference client"
We don't know what back end tinkering they have done, or if what they use is in any way similar to what we see out there.

Do they have more checks in there accepting that it might make it a bit slower but reducing the potential of orphan blocks?
Do they have less checks in there to save 1/2 a second because the math shows that an occasional orphan is worth the risk to get the block out a bit faster?
Do they have an extra security check to make sure the BTC only goes to a certain address (or addresses) to prevent an employee with access from going and sending the funds to their wallet?

etc.

Discussing it is kind of interesting but without knowing exactly what they are doing behind the scenes it puts it firmly into the speculation category.

-Dave