From c5f6509a4c1eed3d6ebb43a000f20b8b38e51045 Mon Sep 17 00:00:00 2001 From: Matt Corallo <649246+TheBlueMatt@users.noreply.github.com> Date: Mon, 20 May 2024 00:39:13 +0000 Subject: [PATCH] Update empty block explainer to remove nonsense information In #5061 it was suggested that the primary cause of empty blocks was due to ASICs taking some time to switch to new work, but this is not a possible reason for empty blocks - pools can mine empty or full blocks no matter how long ASICs do (or do not) take to switch to new work. At some time T a new block is found, at some time T+1 a pool hears about this new block and desires to switch their miners to the new block. If the pool does a full block validation of the new block prior to sending new work (and updates their mempool), they can switch miners to the new work with transactions immediately. If, then, at time T+2 the ASIC finds a block based on the prior work it doesn't matter whether they were given transactions or not - the block is based on the previous tip and is just a fork. Instead, the relevant question for empty blocks is whether the pool delays until they can fully validate the block and update their mempool (or in fact even *have* the block), selecting a first block template which contains transactions or not. #5061 tried to explain this away with an incredibly weak reference to bandwidth, but the cost of a merkle branch for a block with 4k transactions is only ~800 bytes of JSON'd hex, which shouldn't even push you into a second IP packet, let alone make for substantial bandwidth. Its worth noting that it can take many seconds for block to make it from one pool to others, and can further take a second or two to validate a block even on fast hardware (in cases where Bitcoin Core decides to flush to disk due to cache fill), so it makes sense that you'll see empty blocks for some seconds after the previous block. @mononaut posted a chart convincingly demonstrating this - for the first few seconds after a previous block ~all blocks are empty blocks (strong evidence for spy mining or otherwise sending new work prior to updating the local mempool) and we see some dropoff of empty blocks therafter on a relatively expected distribution. There are likely some empty blocks which are mined further past the previous block due to ASICs holding onto previous work, however the only reason those ASICs *have* previous work that is an empty block is because of spy mining or otherwise not tuning Bitcoin Core on the side of the pool to ensure they can update their mempool fast enough and get blocks fast enough to not need to send empty work at all. --- frontend/src/app/docs/api-docs/api-docs.component.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/frontend/src/app/docs/api-docs/api-docs.component.html b/frontend/src/app/docs/api-docs/api-docs.component.html index 63960a910..ffe6d0f85 100644 --- a/frontend/src/app/docs/api-docs/api-docs.component.html +++ b/frontend/src/app/docs/api-docs/api-docs.component.html @@ -238,7 +238,7 @@ -

When a new block is found, mining pools send miners a block template with no transactions so they can begin doing useful work as soon as possible. The pool will then send a block template full of transactions right afterward, and the miners will usually have it in under a second.

Miners sometimes get lucky and find the empty block in the interim period before having the full template however the reason is often that some hardware continues working on older templates after receiving updates.

Contrary to common belief, sending clean=true to the miner does not necessarily mean that they stop doing old jobs, just that they discard the work once completed. In the case of empty blocks this would just result in the miner throwing away a valid block that not only would have rewarded the miner, but added PoW to the Bitcoin's blockchain.

+

When a new block is found, mining pools often send miners new block templates prior to fully validating the new block, often before they've even received the new block. During this time, it is not possible to select transactions for the next block as a pool isn't sure which transactions conflict with transactions already mined.

While empty blocks do not add additional transactions to the blockchain, they do contribute to the overall security of transactions already in the chain.