The pool adds unique data into a block template (in the reserved space) and creates a hashing blob so that it sends each miner unique data (a unique hashing blob) for each miner to hash. Note here that the pool stores the block template it used to create the miners hashing blob.
The miner adds unique data (the nonce) to the supplied hashing blob and then hashes it repeatedly (changing the nonce each time), until it finds a nonce that creates a resulting hash that meets the required jobs difficulty target.
The result sent back from the miner is the result hash, not "block hex". The pool verifies the result hash by:
- Taking the block template from step 1 above, the stored template
- Adding the submitted nonce into this template (and note, this is not added to the reserved space, the block template has its own location/field for a nonce)
- Getting the hashing blob and then hashing it
- Comparing the resulting hash to the miner supplied result hash
Verification then involves the several steps:
- Do the hashes match?
- Does the hash meet the jobs difficulty target?
- Is this the first time this miner submitted this hash and nonce?
If these all pass, it's a verified job/share submission.
Lastly, if the hash meets the network difficulty target, the pool can submit the block template (from steps 3.1 & 3.2) to the network.
A new blob is constructed from the blocktemplateblob. Which uses
extraNonce and the nonce obtained from miner in place of bytes 4-8 in
the reserve location if I understand correctly.
The nonce from the miner is not placed in "bytes 4-8 in the reserve location". It's placed in the part of the block that holds the block nonce. Blocks have a specific field for the nonce.
What's the point of putting random bytes in 4-8 bytes of blocktemplate.
Can someone explain what's happening here?
This is specific to the nodejs-pool implementation. Recall, the pool can use the reserved space in any way it needs to. For nodejs-pool, which is a multi-process pool, it needs to add extra randomness into the reserved space. It calls this extra randomness variable "instanceId". When a pool instance starts, it instantiates a specific "Coin". The "Coin" constructor sets the "instanceId" to a random 4 byte number. This ensures that multiple pool processes/instances always set something unique in the reserved space. It has to do this because the other unique(ish) data it writes to the reserved space (the variable they call "extraNonce"), starts at 0 and increments for each blob created. Therefore multiple instances of the pool all start with "extraNonce" the same, 0. But you don't need to get hung up on the way that nodejs-pool uses the reserved space - all you need to know is: you have to ensure your miners aren't hashing the same hashing blob and you can use the reserved space any way that works best for your implementation.