Mempool/mining question

[vacsim]

Hello all, sorry if this has been answered before but I can't quite find the answer I am looking for. So I am new to running a full node and lately I have been spending time looking at mempool explorer. Watching blocks fill up in real time as they are being mined made me realize that miners are hashing a block that is (potentially) changing every second. Especially when there aren't enough transactions to fill up a block. So does this mean that, say in the case when transactions in the mempool are low, each time a new transaction enters the mempool the miners will stop attempting to hash the old block and start attempting to hash the new block that includes the new transaction? It seems like trying to shoot a moving target would really slow down the process... but I am not a programmer or a developer of any sort 

Also I have noticed a handful of really small blocks that get mined especially fast. Is this just a coincidence that my lizard brain makes a connection, or is there some causality there?

[BlackHatCoiner]

So does this mean that, say in the case when transactions in the mempool are low, each time a new transaction enters the mempool the miners will stop attempting to hash the old block and start attempting to hash the new block that includes the new transaction?

Yes, they could do that. They probably do it, but I'm not sure if that answers to “miners hash a block that is changing every second”. While they mine, they may change various values (despite the nonce) like timestamp, transactions from mempool (which changes the merkle root) etc.

Also I have noticed a handful of really small blocks that get mined especially fast.

Small like... empty? Probably empty blocks could be solved more easily, due to the fact that there's less information to be hashed each time.

[ranochigo]

Watching blocks fill up in real time as they are being mined made me realize that miners are hashing a block that is (potentially) changing every second. Especially when there aren't enough transactions to fill up a block. So does this mean that, say in the case when transactions in the mempool are low, each time a new transaction enters the mempool the miners will stop attempting to hash the old block and start attempting to hash the new block that includes the new transaction? It seems like trying to shoot a moving target would really slow down the process... but I am not a programmer or a developer of any sort  

It depends. There is almost practically no penalty to change the merkle hash of the block since miners should be fast enough to include an alternative merkle root as required. The server may request for the workers to change out the merkle root periodically through mining.notify on stratum for example.

Miners can include any transactions as they wish and it is not a necessity for them to discard the current block and include new transactions whenever they see anything.

Also I have noticed a handful of really small blocks that get mined especially fast. Is this just a coincidence that my lizard brain makes a connection, or is there some causality there?

No. The chances of you getting a valid block is not affected by the number of transactions or the size of the block. It's common for blocks to be mined within a few seconds of each other as some miners either don't include transactions at all after seeing a valid block on the network (to avoid the risk of including conflicting transactions, while they are validating the blocks) or if the miners are just slow at including transactions in the block.

Small like... empty? Probably empty blocks could be solved more easily, due to the fact that there's less information to be hashed each time.

It's the same.

[pooya87]

If you put the number of hashes a miner does in a second into perspective it becomes easier to figure things out. A single S19 antminer can compute 95 TH per second. That is 95,000,000,000,000 hashes per second. A block header has a nonce that can go from 0 to 4,294,967,295 that means each time the miner goes through all those nonces it has to change something else (extra nonce in coinbase transaction to run from 0 again). S19 would change extra nonce 22,118 times per second.
So basically at least a transaction in the block is changing which requires changing the merkle root hash and witness merkle root hash. Adding or changing more transactions in that block doesn't add any extra times.

Small like... empty? Probably empty blocks could be solved more easily, due to the fact that there's less information to be hashed each time.

Technically not correct since the miner hashes the fixed length block header (80 bytes) and it won't change whether the block has 1 transaction or thousands.

[BlackHatCoiner]

Technically not correct since the miner hashes the fixed length block header (80 bytes) and it won't change whether the block has 1 transaction or thousands.

The miner, indeed, hashes a 80 bytes block header, but to reach the certain merkle root, he has to hash transactions. Hashing transactions may take some time; it may not seem slow in practice, but in theory, doesn't it take more time to hash multiple transactions over and over again, instead of just one?

[vacsim]

If you put the number of hashes a miner does in a second into perspective it becomes easier to figure things out. A single S19 antminer can compute 95 TH per second. That is 95,000,000,000,000 hashes per second. A block header has a nonce that can go from 0 to 4,294,967,295 that means each time the miner goes through all those nonces it has to change something else (extra nonce in coinbase transaction to run from 0 again). S19 would change extra nonce 22,118 times per second.
So basically at least a transaction in the block is changing which requires changing the merkle root hash and witness merkle root hash. Adding or changing more transactions in that block doesn't add any extra times.

Oh wow, this sums it up pretty well. I didn't realize the nonce had such a (relatively) small cap. This really helps me understand the difficulty target much better, as there are immense amounts of blocks that cannot be hashed under the difficulty target by only changing the nonce. Thank you for the intuitive reply! Thanks to everyone else who chimed in as well

[ranochigo]

The miner, indeed, hashes a 80 bytes block header, but to reach the certain merkle root, he has to hash transactions. Hashing transactions may take some time; it may not seem slow in practice, but in theory, doesn't it take more time to hash multiple transactions over and over again, instead of just one?

There isn't a lot to hash. Anyways, I don't think ASICs hash merkle root. They only hash the block headers, any CPU can hash the merkle tree in milliseconds so it can be done in parallel.

[pooya87]

The miner, indeed, hashes a 80 bytes block header, but to reach the certain merkle root, he has to hash transactions. Hashing transactions may take some time; it may not seem slow in practice, but in theory, doesn't it take more time to hash multiple transactions over and over again, instead of just one?

There isn't a lot to hash. Anyways, I don't think ASICs hash merkle root. They only hash the block headers, any CPU can hash the merkle tree in milliseconds so it can be done in parallel.

A lot less than that (micro seconds). For example I was trying to benchmark the time it takes to compute merkle root hash of block 692,400 containing 1,121 Transactions using my own code that doesn't have SIMD and it takes 902.3 μs to do that. With SIMD or a stronger CPU than mine it would take a lot less.

Code:

| Method |     Mean |    Error |   StdDev |
|------- |---------:|---------:|---------:|
| Merkle | 902.3 μs | 17.29 μs | 14.44 μs |

This amount of time is negligible in comparison.

[bitmover]

Also I have noticed a handful of really small blocks that get mined especially fast. Is this just a coincidence that my lizard brain makes a connection, or is there some causality there?

I think this may be a coincidence, as the blocktime isn't necessarily after an empty block

A few months I made a dashboard with block data . If you click the button "Last Week", you will see that there were 3 empty blocks mined last week:

block id   pool      blocktime
691877   AntPool   00:01:15
692142   AntPool   00:15:49
692222   ViaBTC   00:07:40

Except for the first one, the other two had a normal blocktime. And 1 minute is more than enough to add transactions from the mempool into a block.

I think some pools might want to mine empty blocks to try to make fees goes higher, so they will make more money in medium term (this is my guess only, but I think it makes sense)

[garlonicon]

If those timestamps are based on block headers, then you should notice that timestamps are also used as nonces: they can be incremented or decremented after exhausting nonce inside block header, because in this way there is no need to recalculate merkle root.

[j2002ba2]

A few months I made a dashboard with block data . If you click the button "Last Week", you will see that there were 3 empty blocks mined last week:

block id   pool      blocktime
691877   AntPool   00:01:15
692142   AntPool   00:15:49
692222   ViaBTC   00:07:40

Except for the first one, the other two had a normal blocktime. And 1 minute is more than enough to add transactions from the mempool into a block.

UpdateTip at my node shows something different:

block   pool     blocktime  realtime
691877  AntPool   00:01:15  00:00:15
692142  AntPool   00:15:49  00:00:01
692222  ViaBTC    00:07:40  00:00:10

So, we see only few seconds difference.

[ranochigo]

block id   pool      blocktime
691877   AntPool   00:01:15
692142   AntPool   00:15:49
692222   ViaBTC   00:07:40

Except for the first one, the other two had a normal blocktime. And 1 minute is more than enough to add transactions from the mempool into a block.

I think some pools might want to mine empty blocks to try to make fees goes higher, so they will make more money in medium term (this is my guess only, but I think it makes sense)

They aren't. You're looking at the timestamp only. The timestamp of a block is almost always inaccurate because the network allows it to deviate significantly. The blocks that you've highlighted are relayed only a few seconds apart.

Miners won't try to artificially inflate fees. Trying to inflate the fees at the current stage won't work, none of the pools hold a significant portion of the network. Intentionally mining empty blocks would result them in losing out more fees in the long run. Fees are fairly demand inelastic right now, so people are more likely to put off making transactions when fees are high.

[pooya87]

Keep in mind that because of the way merkle trees work the miner doesn't have to re-compute the whole thing when they are just increment their extra nonce (in coinbase transaction, shown as t1 in the tree below), instead they only compute a smaller part of the tree.
Red parts are changing and recomputed, the green parts are fixed and stored in memory for reuse, the black parts can be discarded or stored similarly in case the miner changed another tx (eg. one with higher fee).

t1    t2    t3    t4    t5    t6    t7    t8
└─────┘     └─────┘     └─────┘     └─────┘
   t1'         t2'         t3'         t4'
   └───────────┘            └───────────┘
         t1''                    t2''
         └────────────────────────┘
                   root

[PrimeNumber7]

Especially when there aren't enough transactions to fill up a block. So does this mean that, say in the case when transactions in the mempool are low, each time a new transaction enters the mempool the miners will stop attempting to hash the old block and start attempting to hash the new block that includes the new transaction?

The specific transactions that are included in a candidate block are updated far more frequently than once per second. Miners (specifically mining pools) try to maximize their transaction fee revenue, and will adjust their block candidate accordingly.

The reason why blocks are sometimes empty immediately after a block is found, is because miners are blindly accepting that a previously found block is valid, and is mining on top of said block prior to confirming which transactions have been confirmed. Once miners validate a recently found block, they will update their database so that their new block candidates will reflect only valid transactions.

[o_e_l_e_o]

The specific transactions that are included in a candidate block are updated far more frequently than once per second. Miners (specifically mining pools) try to maximize their transaction fee revenue, and will adjust their block candidate accordingly.

Please correct me if I'm wrong, but I can't believe that this is accurate. Are mining pools really sending out a fresh candidate block to all connected miners several times per second? Perhaps the pool coordinator is constantly updating their candidate block with higher paying transactions, but surely they are only broadcasting a new candidate block to miners once every few seconds, or maybe several times per minute? Ideally, they should probably only be broadcasting a new candidate block once their updated candidate block has reached some threshold of a larger fee than the old candidate block currently being worked on.

[garlonicon]

Are mining pools really sending out a fresh candidate block to all connected miners several times per second?

They are not sending the whole candidate block, only block header is needed to mine nonce, to use timestamp as a nonce, to use block version as a nonce. Later, updating at least the coinbase transaction is needed (or changing the order of transactions, replacing them with those with higher fees, things like that). From nonce you can get 32 bits. From block version you can get many bits, something around 20 I guess. From timestamp you can get around 10 bits. All of these three fields combined will give you around 64 bits that you can change. Blocks are produced every 10 minutes and they have around 80 bits. That means 64 bits is something around bare minimum you can submit on Stratum, values below that will be useless from pool's perspective.

[ranochigo]

Please correct me if I'm wrong, but I can't believe that this is accurate. Are mining pools really sending out a fresh candidate block to all connected miners several times per second? Perhaps the pool coordinator is constantly updating their candidate block with higher paying transactions, but surely they are only broadcasting a new candidate block to miners once every few seconds, or maybe several times per minute? Ideally, they should probably only be broadcasting a new candidate block once their updated candidate block has reached some threshold of a larger fee than the old candidate block currently being worked on.

I'm currently solomining for fun, with my USB ASICs, connected to ckpool. Just hooked up a packet sniffer and I observed roughly a single mining.notify packet from the server once a minute. The server has no requirement for the miner to discard their current work until the nonce is exhausted. List of merkle branches changes every time the packet is sent to my miner. Take it with a grain of salt though, it might be different for various pools. It is possible for pools to enforce a mandatory change in the merkle branch though it would entail a slightly larger bandwidth and having the miners to discard the work that they've done.

[o_e_l_e_o]

They are not sending the whole candidate block, only block header is needed to mine nonce, to use timestamp as a nonce, to use block version as a nonce.

Sure, but still? Multiple times per second? Seems a long way off from the once a minute ranochigo is experiencing.

I suppose such a question becomes less relevant with Stratum v2, as individual miners will have the ability to select which transactions to include and create their own candidate blocks.

[PrimeNumber7]

The specific transactions that are included in a candidate block are updated far more frequently than once per second. Miners (specifically mining pools) try to maximize their transaction fee revenue, and will adjust their block candidate accordingly.

Please correct me if I'm wrong, but I can't believe that this is accurate. Are mining pools really sending out a fresh candidate block to all connected miners several times per second? Perhaps the pool coordinator is constantly updating their candidate block with higher paying transactions, but surely they are only broadcasting a new candidate block to miners once every few seconds, or maybe several times per minute? Ideally, they should probably only be broadcasting a new candidate block once their updated candidate block has reached some threshold of a larger fee than the old candidate block currently being worked on.

I would doubt that pools are sending the candidate block header this frequently, however, I don't doubt that pools are updating their candidate block very frequently that they will send out to miners as they are sent new work.

Based on my reading about the stratum protocol, it does appear that miners are sent new work once per minute, or when a new block is found, whichever comes first. This does not mean that all miners mining on the same pool receives new work at the same time. Assuming a one-minute interval of receiving work, one miner may receive work at 12.1 seconds past each minute, another miner may receive work at 33.2 seconds past the minute, etc. When new work is sent, the miner will send the most recent block candidate header.

I suppose such a question becomes less relevant with Stratum v2, as individual miners will have the ability to select which transactions to include and create their own candidate blocks.

I can see this particular feature preventing pools from adopting v2. Transaction fees make up an increasingly large share of the total mining reward, and the amount that pools payout ultimately depends on how much pools receive in transaction fees. This is even true for pools that payout via PPS, as the PPS rate will depend on the expected amount of transaction fees each block will include. If individual miners can select transactions in blocks they mine, a miner may not select the transactions with the highest fees, or an individual miner may have users pay transaction fees via some method that is not sum(inputs) - sum(outputs).

For example, a large miner might expect to mine 4 blocks per day (1 every 6 hours), and the fee market might require transactions to include a fee rate of 20 sat/vByte. This large miner might have an agreement with a business that needs to send hundreds of not-time-sensitive transactions per day, and the miner might agree to confirm this business' transactions for 15 sat/vByte if paid in advance directly to the miner. The business would provide what appears to be zero-fee transactions to the miner directly, and the miner would include these transactions in blocks they find. This results in the miner receiving a higher payment than he is entitled to, and either the pool or other pool users end up losing out on these transaction fees.

There is also the issue that each individual miner's software will need to be properly configured. If one miner submits an invalid block due to a misconfiguration (intentional or otherwise), the pool will lose out on that mining revenue, but the miner will have received payment for the work that contributed to finding that block. Under the status quo, there is very little that a miner can mess up when submitting work to the pool.

[o_e_l_e_o]

Based on my reading about the stratum protocol, it does appear that miners are sent new work once per minute, or when a new block is found, whichever comes first.

That seems far more reasonable.

I can see this particular feature preventing pools from adopting v2.

I'm not so sure. Taking the example you gave - there is a large miner who has reached a private agreement with a third party to include their transactions for a fee paid directly to the miner. This miner is mining for Pool X, and is still sharing their block reward and other fees with Pool X, but is depriving Pool X of the additional private fee they have negotiated with the third party. If Pool X decide this isn't good enough, and stop using Stratum v2, then the miner in question can simply switch to Pool Y which is still using Stratum v2. Pool X have now lost the entirety of that miner's hash power, and with it, all the block rewards and other fees for the blocks they were mining. They will end up in a worse position than if they had just continued to allow Pool X to continue to mine with their private arrangement in place.

Any miner who has such an arrangement and wants to be able to select which transactions they include will just move to a pool which is willing to let them do that, and there will always be some pools which are willing to do that. Any pools which don't upgrade will be left behind by these miners.