Extranonce in Mining Submit

[gt.townsend]

I have a question about the last blob in my mining.submit JSON's right after the Nonce (i.e. the "09b66000")

   "1AGf9v4rYBSAnMXi8rvE6nxutC5ZoaVfNa.425" // Miner ID
   "3782626",                                // Job ID
    "ec100000000000",                         // Extranonce2
    "67c28154",                               // Time
    "16384721",                               // Nonce
    "09b66000"                                // Extra nonce (optional, rarely used)
  ],
  "id": 19,                                   // Request ID
  "method": "mining.submit"                   // Method name
}

Is there any chance the the S19 ASIC would ever involve this in the hashing process for any reason at all, and if so, how would it incorporate it? I cannot reconstruct a block header with a decent hash value no matter what I try, so now I'm grasping at straws, wondering if this extra field is somehow used. The pool was cruxpool, in case that matters.
-gt-

[nc50lc]

Is there any chance the the S19 ASIC would ever involve this in the hashing process for any reason at all, and if so, how would it incorporate it? I cannot reconstruct a block header with a decent hash value no matter what I try, so now I'm grasping at straws, wondering if this extra field is somehow used. The pool was cruxpool, in case that matters.

You'll need to directly contact the pool's developer for that because the concept of "extra nonce" is vague since it can be anything in the coinbase transaction to refresh the block header once the 32-bit nonce reached it max value.

If somehow used, it'll affect the MerkleRoot hash since its value will change if the extra nonce is changed.
Or it may be referring to the version field (32-bit) which is famously used as extra nonce. (read articles about "Overt ASICBOOST")

[gt.townsend]

Thanks for that information. I imagine an Antminer cannot just choose arbitrarily to use this "if it feels like it" because the only way the pool can reconstruct the block header is if there is agreement on how it is built. Nevertheless, there must surely be some standard that dictates such things. Neither a pool nor a miner can operate without strict agreement on what is happening. I do not see anything in the JSON exchanges to suggest there is anything in the negotiation that indicates whether or not this extra piece is going to be used/expected.

Is it perhaps the case that the miner gets to decide that, and if it includes it in the mining.submit JSON, then the pool must agree to go ahead and use it also?

Another possibility (again based on the absence of any negotiation present in the captured JSON traffic I have) is that the miner assumes the pool supports it, but if shares are rejected, then the miner stops using the extranonce on the assumption that if shares are being rejected, the pool must not support it.

Either way, it seems that:

i) I do not change my miners when I relocate to another pool
and
ii) the JSON exchange does not include anything to indicate whether or not the pool expects the extranonce

My conclusion is that the pool must either support it, in which case it uses it and accepts the shares, or rejects shares that include it. It will be clear to a pool that allows it that it is being used by its very presence in the submit. If a pool doesn't support it, then it has to ignore it and must reject the share in which case the miner would know to stop attempting to use it.

What do you think?  And surely, this MUST be documented SOMEWHERE!?

Does anyone know of a pool that does NOT use this extranonce? If so, I could attach to it and see if suddenly my miners stop using it. That would be an acid test to answer this question.
-gt-

[gt.townsend]

Okay, for anyone who has been following this, I FINALLY got it completely solved. The sixth field is indeed used in computing the block hash. It turns out this is actually a well know addition to stratum mining - but I didn't know about it and no one I asked mentioned anything about it. I looked more closely at the traffic and noted an exchange where the miner and pool negotiated something called "version rolling" where the pool responds with a "version rolling mask" which indicates how you can manipulate the version number before using in the block header to hash the block header. The advantage is that rather than mess with the extranonce2 value (which you are still allowed to to if all else fails) you can mess with the version instead. This has the advantage of not requiring recomputing the coinbase and merkleroot so it saves a bit of effort. The version rolling mask tells you which bits of the version you are allowed to mess with and which you are not. That sixth field is the version number you used in place of the orignal version number the pool issued with the job.

So the solution after about a month of investigation was to do exactly what I was already doing, but to replace the version number of the block with that sixth field (well, not quite - you need to combine the mask, original version and sixth field together in a Boolean equation to get it right).

Anyway, after a month of spinning my wheels, I finally generated a lovely hash for my accepted share with a long string of leading zeros on the front of it.

By the time I sorted things out, I became very proficient in building Merkle trees and branches and messing with the parts to make the coinbase, and even found out how something called the "midstate" can be precomputed for 64 of the 80 bytes in the header so that replacing the nonce in the reaming portion and re-hasing becomes far more efficient as nonces are tested. So I guess it was a blessing in disguise that this was not strightforward to solve. Although, in the end, it turns out to be pretty easy - once you know what to do!
-gt-

[nc50lc]

So the solution after about a month of investigation was to do exactly what I was already doing, but to replace the version number of the block with that sixth field (well, not quite - you need to combine the mask, original version and sixth field together in a Boolean equation to get it right).

Good find, so it's "Overt ASICBOOST" all along, it's just that the mentioned sixth field's value isn't exactly the version number itself.

I noticed that you only shared five fields in the OP excluding "id" and "method", others may find it confusing when reading your reply about the "sixth field".
Snipped 1st field should be the 'worker', right?

[gt.townsend]

Yes, thanks. I've edited the original for clarity.
-gt-