I got a question about that last part in the mining.submit JSON right after the Nonce. What’s with that extra thing, the "09b66000"? Is it important or just like a random number?
"1AGf9v4rYBSAnMXi8rvE6nxutC5ZoaVfNa.425" // Miner ID
"3782626" // Job ID
"ec100000000000" // Extranonce2
"67c28154" // Time
"16384721" // Nonce
"09b66000" // Extra nonce (optional)
{id: 19, method: "mining.submit"}
Understanding the Extra Nonce in Mining
5 replies 496 views
You might wanna check with the pool dev for that. The term "extra nonce" can be pretty vague and it can mean anything in the coinbase transaction. Once the 32-bit nonce hits its limit, you need something to refresh the block header. Changing it will affect the MerkleRoot...
It might also link to the version field used for extra nonce, like they mention in those "Overt ASICBOOST" articles.
Yeah but isn’t it risky if the miner just decides to use it when they feel like it? The pool needs to know how to build the block header to reconstruct it. They have to agree on the structure, right? I don’t see anything in the JSON that indicates it’s a must-use or anything.
So, I finally got it all sorted out. The sixth field is actually key for computing the block hash. I found out it’s a known feature in stratum mining but no one really mentioned it before. There’s this negotiation process called "version rolling" where the pool sends a mask showing how to tweak the version number before hashing. Seriously confusing stuff...
Nice catch! So it’s all about "Overt ASICBOOST". But that sixth value isn’t really the version number itself, right? You also mentioned five fields, and I think you forgot to include the worker ID at the start. Might confuse some folks.
Yeah good point, I added that to clear it up. Thanks for the heads up!