Other answers related to reserve_size seem to imply they are related to the real block nonce. However, there is already a portion of the hashing blob reserved for a nonce, and the reserved bytes aren't included in the hashing blob, so they don't affect the mining of the block, right?
These are simply extra bytes and are not at all related to mining or calculation of the final nonce?
The extra reserved bytes are taken into consideration to compute the block hash.
There are 4 bytes reserved for a nonce in the block header (the nonce that appears in the hashing blob).
In addition, you can reserve extra bytes (reserve_size) for a second nonce in the extra field of the block reward transaction. It allows searching for a nonce giving a valid block in a space bigger than the default 32 bit space available with the block header. When you change these bytes, the hash of the block reward transaction changes, therefore the root hash of the transaction merkle tree changes, therefore the block hash changes.
The hashing blob is a piece of data where the transaction merkle tree has already been computed, this is why the second nonce doesn't appear in it. When you change the second nonce, you have to compute the new hashing blob before continuing the mining process.
So If I understand correctly - if you're using the hashing blob "as-is" then you essentially cant throw anything into the extra field, because If you put anything in that field, then you alter the tree root, and the hashing blob would change. If you want to use the "extra" field then you need to be prepared to re-calculate the tree root and substitute it into your hashing blob.
correct?
– The Shoe Shiner Oct 16 '17 at 15:46