Including transactions in a block - rules and time / technical aspect

Question

I’ve a question regarding block and transactions included in the next block that is solved.

Let us assume theoretically that there is newly propagated solved block.

And now there are: tx0 and tx1 – not included in propagated block with time of transaction earlier that solved block.

Tx2 – which was propagated 10 second after solving previous block

Tx3 - which was propagated 60 second after solving previous block

Does the miners take only Tx0 and tx1, make hash and start to mine (already have hash of those) or (I presume this is not the case) are adding those tx2 and tx3 which was propagated in this “10 minute” window?

Presumably they would need to start all over again, but it would mean that when miner receive info about new block that was solved by another miner stops working, puts all of transaction form block which he was solving, all transaction in pool (tx0 and tx1 in my example), check what transaction is already in solved block takes all reminding tx makes hash and start solving. Is that correct?

So basically my question is, does the next block includes only those transactions that were propagated BEFORE solving of current block and AFTER miners starting to find current block (so in this “10 minute window” or there are some other rules? I tried to find solution in docs but no success. (if anyone knows some source I would be grateful)

Best regards

Answer 1

There are no real rules, per se, just various optimizations.

ASICs are fast. They can burn through the entire 2^32 possible nonces for a given block in seconds, which requires miners to use the extra nonce field in the coinbase transaction to generate a new block header (since altering the coinbase transaction changes the merkle root) and try again.

This process can be done in parallel - a miner can prepare the N+1 block header by changing the extra nonce in the coinbase transaction while they are checking the Nth block header's 2^32 nonce values.

Similarly, transaction selection can also be done in parallel - a new block template can be created while a miner is operating on the previous one, and the new template's block header can simply be used when the miner swaps out the previous one after exhausting the nonce space (unless they find a valid block, in which case the template must be updated again).

This is what most mining pools do - the block template generate is done in parallel by the mining pool, and they continuously pass updated block templates to all of their miners. This allows them to quickly include high fee transactions in potential blocks while still ensuring that they are looking for a solution at all times.

Answer 2

There really isn't any "starting over" in mining, because mining is effectively progress free, like a lottery and unlike a race. Nothing is lost when updating the transaction list, other then the negligible amount of processing needed to make the new list and bandwidth to communicate it.

The miner will include the additional transactions whenever it gets around to it, usually within a couple seconds-- with the delay simply being batching to save bandwidth and cpu in sending out updated block data to their hardware.