mjhjmtu

I have a question about getting transactions from mempool to be added to block. Imagine the situation where we have 500 transactions in mempool, when we decide that is enough to start adding them to the block? Also what if we sre in the middle of mining (so we have Merkles tree root already) and the new transaction is added to the mempool? The process of our mining in my node is starting again?

You can start to work in a block at any moment, you can even mine an empty block. If any new transaction arrives you rebuild the merkle tree and continue.

While mining is done by specialized hardware, transaction choosing and merkle root calculating is done by the node software. While the specialized hardware is mining, a node may (and will) update its mempool continuously, and will calculate a new merkle root every few seconds. The mining hardware will check for header-template updates often, (and this instantaneous process is done without needing a restart), and will continue mining. The interval of header updates is chosen by the pool, and one of the aims is not to do it too often, or it'll waste the bandwidth

Producing the optimal block-template to mine is a NP-hard problem.

The optimal block-template includes the highest sat/byte(or weight) transactions to maximise the miner reward. Assuming this computation and propagation of the perfect block-template took no time, it would make sense to update the block-template for each new transaction accepted to the memo-pool, as this new transaction could potentially increase the block reward. In this hypothetical scenario, the mining hardware is continuously working (hashing) and continuously updating the block header for a better block reward.

However, since producing the optimal block-template is NP-hard, it takes significant time/cost to compute the optimal block-template from the mempool at any point in time:

• Knapsack problem - maximise total fee value in block


• Maximum independent vertex set - ensure no two tx spend the same output.

Both problems scale exponentially and are expensive. This cost could have been invested in more hash-rate.

Therefore, there is a trade-off between block optimisation and mining utilization.

• Continuously optimising for a better block-template represents a cost in itself, which could be invested in more mining hash rate.


• There exists a financial optimum, where suboptimal blocks-templates are mined, whilst mining equipment is fully utilised.


• (One extreme could be mining empty blocks, maximising the number of hashes performed, whilst spending zero resources in block optimisation.)


• In practice, simplified heuristics are used to update new block-templates cost-effectively as mining is being performed.