<p>When a pool gives a miner data to mine it is not data for one specific block, but a template for a block. The miner hashes many variations of this block data to try to find a block that has a hash value below the current target (which is determined by the current difficulty).</p>

<p>To calculate the hash of a block on the blockchain given only the data that the miner was given from the pool, you would have to do the same thing the miner did. You would have to hash many different blocks in search of that low hash - only then would you know the exact data the block contains - assuming you are not allowed to look at the block data on the blockchain.</p>

<p>For the old getwork protocol the pool would only allow you to set the nonce value in the block header. Everything else in the block was determined by the pool server. So you would have 4 bytes (32 bits) to search to rediscover the block someone mined with the given getwork-data. That's 2^32 (4294967296) different blocks. On average you'd have to search 50% before finding the right block. That's 2147483648 hash operations to perform on average. This is done in an instant with modern mining hardware.</p>

<p>With the Stratum protocol it gets worse. Stratum allows the miner to modify the nonce and a part of the coinbase transaction called "extra nonce 2", the size of which is determined by the pool, but usually 4 bytes. This means the miner has 8 bytes (64 bits) to fiddle with. That's a lot of blocks to search through. 2 to the power of 64. Though on average you'd only need to try 50% of those blocks.</p>

<p>It's actually a bit worse than the above because the miner may have also changed the timestamp on the block (ntime field of the block header). It would be a value close to the original timestamp though.</p>

<p>Usually pool servers push new work data to miners quite often. If you have equally fast hardware to that which found the block, then you should be able to do the above search in less than a minute. But that assumes that your miner and the one that found the block search the nonce and extranonce2 (and ntime) in the same way. For example if both miners start with a value of zero for nonce and extranonce2 and then increment from there, then it should not take long at all.</p>

CC BY-SA 4.0
2019-12-29T12:31:40.457Z
That's a great explanation, thx @Dr.Haribo. I don't have a fast hardware. I was thinking if I could reproduce the hash without having to iterate the nonce, given that the one that solved the block is already known. So instead of calculating the hash of a mined block with the known parameters "version + prevhash + merkleroot + bits + nonce + time", do it with the "version + prevhash + coinb1 + xtranonce1 + xtranonce2 + merkle + bits + nonce + time" submitted originally by the pool to the miner that mined that block. Probably I could have written the question clearer...
Charlie
CC BY-SA 4.0
2019-12-29T13:31:47.347Z
extranonce2 is not originally submitted by the pool. If you already have the block, you can just hash the header and you have the hash. If you want you can certainly recreate the merkleroot yourself if you wish. But for that you need the extranonce2 which comes from the miner, not the pool.
Dr.Haribo
CC BY-SA 4.0
2019-12-29T13:33:29.820Z
If you want to simulate what happened when the miner found the block, but without doing so many hashes, then you could use the stratum data and add in the nonce, ntime and extranonce2 values you know to be correct (taken from the block on the blockchain).
Dr.Haribo
CC BY-SA 4.0
2019-12-29T18:06:49.547Z
Right, this last comment helped me to put my mind in order. Thx again. PD: I would up vote the answer but don't have enough rep yet.
Charlie
CC BY-SA 4.0
2019-12-29T12:00:38.603Z
2019-12-29T12:00:38.603Z
Dr.Haribo
<p>Miners get several parameters from the stratum pool: coinb1, coinb2, xtranonce1, xtranonce2... according to <a href="https://slushpool.com/help/stratum-protocol/#stratum" rel="nofollow noreferrer">here</a>.</p>

<p>I wonder if it is possible to reproduce the hash of one already mined block, but using that info and going all the way trough, and not just the merkle root from the block.</p>

<p>The only way I could think of is if, somehow, those parameters could be retrieved from the block. Since there are hashes involved to calculate the merkle root, I would say no... but I'm not sure, or maybe there is another way. </p>

<p>Thx!</p>

<mining-pools><mining-theory>
Calculate the hash of mined block using stratum parameters (coinb1, coinb2, xtranonce1...)?
Charlie
# Calculate the hash of mined block using stratum parameters (coinb1, coinb2, xtranonce1...)?

(Asked by: username_0 on 2019-12-28)

Miners get several parameters from the stratum pool: coinb1, coinb2, xtranonce1, xtranonce2... according to [here](https://slushpool.com/help/stratum-protocol/#stratum).

I wonder if it is possible to reproduce the hash of one already mined block, but using that info and going all the way trough, and not just the merkle root from the block.

The only way I could think of is if, somehow, those parameters could be retrieved from the block. Since there are hashes involved to calculate the merkle root, I would say no... but I'm not sure, or maybe there is another way.

Thx!

**Tags:** mining-pools, mining-theory


---

## 1 answers

### Answer by username_1 on 2019-12-29. Score: 1

When a pool gives a miner data to mine it is not data for one specific block, but a template for a block. The miner hashes many variations of this block data to try to find a block that has a hash value below the current target (which is determined by the current difficulty).

To calculate the hash of a block on the blockchain given only the data that the miner was given from the pool, you would have to do the same thing the miner did. You would have to hash many different blocks in search of that low hash - only then would you know the exact data the block contains - assuming you are not allowed to look at the block data on the blockchain.

For the old getwork protocol the pool would only allow you to set the nonce value in the block header. Everything else in the block was determined by the pool server. So you would have 4 bytes (32 bits) to search to rediscover the block someone mined with the given getwork-data. That's 2^32 (4294967296) different blocks. On average you'd have to search 50% before finding the right block. That's 2147483648 hash operations to perform on average. This is done in an instant with modern mining hardware.

With the Stratum protocol it gets worse. Stratum allows the miner to modify the nonce and a part of the coinbase transaction called "extra nonce 2", the size of which is determined by the pool, but usually 4 bytes. This means the miner has 8 bytes (64 bits) to fiddle with. That's a lot of blocks to search through. 2 to the power of 64. Though on average you'd only need to try 50% of those blocks.

It's actually a bit worse than the above because the miner may have also changed the timestamp on the block (ntime field of the block header). It would be a value close to the original timestamp though.

Usually pool servers push new work data to miners quite often. If you have equally fast hardware to that which found the block, then you should be able to do the above search in less than a minute. But that assumes that your miner and the one that found the block search the nonce and extranonce2 (and ntime) in the same way. For example if both miners start with a value of zero for nonce and extranonce2 and then increment from there, then it should not take long at all.

> **Comments:**
> **username_0**: That's a great explanation, thx @username_1. I don't have a fast hardware. I was thinking if I could reproduce the hash without having to iterate the nonce, given that the one that solved the block is already known. So instead of calculating the hash of a mined block with the known parameters "version + prevhash + merkleroot + bits + nonce + time", do it with the "version + prevhash + coinb1 + xtranonce1 + xtranonce2 + merkle + bits + nonce + time" submitted originally by the pool to the miner that mined that block. Probably I could have written the question clearer...  
> **username_1**: extranonce2 is not originally submitted by the pool. If you already have the block, you can just hash the header and you have the hash. If you want you can certainly recreate the merkleroot yourself if you wish. But for that you need the extranonce2 which comes from the miner, not the pool.  
> **username_1**: If you want to simulate what happened when the miner found the block, but without doing so many hashes, then you could use the stratum data and add in the nonce, ntime and extranonce2 values you know to be correct (taken from the block on the blockchain).  
> **username_0**: Right, this last comment helped me to put my mind in order. Thx again. PD: I would up vote the answer but don't have enough rep yet.  

---

