Empty blocks and improvement ideas \ stacker news ~bitcoin

pull down to refresh

3507 sats \ 8 comments \ @C_Otto 13 Dec 2023 bitcoin

Sometimes miners produce empty, or rather "empty", blocks which only contain the coinbase transaction (paying new BTC to the miner) and the necessary headers. Example: https://mempool.space/block/0000000000000000000421b68859badd381d14c37e8b8fe938748db175f3ca5c

Here's mempool's description of the issue: https://mempool.space/docs/faq#why-empty-blocks

It seems creating the new block template (for which transactions need to be validated) takes some time, and then after creation this template needs to be made available to the miners. If miners don't have a "proper" template, they might mine an "empty" block instead.

Wouldn't it be possible to always have another block template available, one that does not depend on the transactions confirmed (or not!) in the previous block?

I imagine mining pools to have access to lots of transactions they create themselves, for example to pay the individual miners. For these transactions they already know that they cannot conflict with whatever happened in the previous block, as they never made those transactions available to the rest of the network (and didn't mine these themselves).

Then there are transactions that, for technical reasons, are known to be "unmined", for example those spending from some coinbase output, or transactions using block height time locks. I believe miners could just add transactions spending (only!) from such outputs.

Incentives aside, would this work? Would this be (much) faster than waiting for the "proper" block template?

view all related items

1 sat \ 1 reply \ @bitentrepreneur 18 Dec 2023

Future Jobs An empty future block job or speculated non-empty job can be sent in advance to speedup new mining job distribution. The point is that the mining server MAY have precomputed such a job and is able to pre-distribute it for all active channels. The only missing information to start to mine on the new block is the new prevhash. This information can be provided independently.

Such an approach improves the efficiency of the protocol where the upstream node does not waste precious time immediately after a new block is found in the network.

source: https://github.com/stratum-mining/sv2-spec/blob/main/05-Mining-Protocol.md#514-future-jobs

1 sat \ 0 replies \ @bitentrepreneur 18 Dec 2023

so to answer your question, yes it is possible to always have another block template available, one that does not depend on the transactions confirmed (or not!) in the previous block.

available in stratumv2 pools that allow for block template creation + tx sets

1 sat \ 1 reply \ @bitentrepreneur 18 Dec 2023

Sv2 separates mining prevhash and future job, vs the combined message in Sv1 which forces pools to send empty blocks to communicate a prevhash. Sv2 pools can send jobs to workers ahead of time for future blocks, even before the prior block has been found. Pools send the latest prevhash in a space opitimized message, starting the end-device mining on the next block in a single 32-byte message.

0 sats \ 0 replies \ @C_Otto OP 18 Dec 2023

I got that. How do miners create the actual template, though, if a new block has just been found? I think it's risky to continue working on the previous template.

1 sat \ 0 replies \ @DarthCoin 13 Dec 2023

@Murch @petertodd I would like to hear you on this matter.

0 sats \ 0 replies \ @elysia 13 Dec 2023

It is possible to always have another block template available that does not depend on the transactions confirmed in the previous block. However, there are a few reasons why this is not done by default.

First, it would require miners to maintain a larger memory pool of unconfirmed transactions. This could be a significant overhead for miners with limited resources.

Second, it would increase the likelihood of creating blocks that are orphaned. An orphaned block is a block that is not connected to the longest chain of blocks and is therefore not valid. This can happen if two miners find blocks at roughly the same time and propagate them to the network. The second block to be found will be orphaned if the first block is accepted by the network first.

Third, it would make it more difficult for miners to coordinate their efforts. Miners typically work together in pools to share resources and increase their chances of finding blocks. If each miner is using a different block template, it can be difficult to ensure that they are all mining on the same block.

Despite these drawbacks, there are some cases where it may be beneficial to use a block template that does not depend on the transactions confirmed in the previous block. For example, if a miner is confident that they have a large number of unconfirmed transactions that will be included in the next block, they may choose to use a block template that includes these transactions. This could give them an advantage over other miners who are using a block template that does not include these transactions.

The decision of whether or not to use a block template that does not depend on the transactions confirmed in the previous block is a trade-off that each miner must make for themselves. There are both advantages and disadvantages to using such a block template, and the best choice will depend on the individual miner's circumstances.

In the specific case of mining pools, it is possible for them to create a block template that includes transactions that they have created themselves. This could give them an advantage over other miners who are not using such a block template. However, mining pools typically have access to a large number of unconfirmed transactions, and it would be difficult for them to ensure that all of these transactions are included in every block. Additionally, mining pools typically charge a fee for their services, and this fee would likely be higher if they were to use a block template that does not depend on the transactions confirmed in the previous block.

It is possible to always have another block template available that does not depend on the transactions confirmed in the previous block. However, there are a number of drawbacks to using such a block template, and it is not clear that it would be beneficial for most miners.

0 sats \ 0 replies \ @C_Otto OP 13 Dec 2023

I also created a question on StackExchange: https://bitcoin.stackexchange.com/questions/120933/constructing-a-block-template-to-avoid-mining-empty-blocks

0 sats \ 0 replies \ @C_Otto OP 13 Dec 2023

I think Stratum V2 is necessary, as this allows for the separation of "transaction data" and "header information". However, I haven't found a description of how miners identify transactions that are suitable for the otherwise empty block. Do miners only do this for their own "grandchild" blocks, i.e. two consecuitive blocks mined by the same pool?

https://braiins.com/stratum-v2#empty