Pages:
Author

Topic: Mempool/mining question - page 2. (Read 290 times)

newbie
Activity: 7
Merit: 0
July 24, 2021, 02:08:55 AM
#6
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 Smiley
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
July 24, 2021, 02:04:25 AM
#5
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?
legendary
Activity: 3472
Merit: 10611
July 24, 2021, 01:51:55 AM
#4
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.
legendary
Activity: 2982
Merit: 4193
July 24, 2021, 01:47:46 AM
#3
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  Wink
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.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
July 24, 2021, 01:39:33 AM
#2
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.
newbie
Activity: 7
Merit: 0
July 24, 2021, 01:33:21 AM
#1
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  Wink

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?
Pages:
Jump to: