Question about how the pool servers operate..

[oatmo]

Pardon the noob question, but I searched a lot and couldn't find a technical description of how these things work. If there is a description somewhere that I didn't find, please point me to it and pardon the annoyance.

I'm curious the pseudo loop for pool mining (or I guess solo mining in general).

Is this sort of correct:

Pool server

  1. Collect transactions
  2. Make a block (which includes your address for the 25 bitcoin bonus)
  3. Start hashing
      SHA256(SHA256 (your constructed block + incrementing nonce))
  4. If you didn't find a valid hash, then go back to 1.

Couple questions:

Is the nonce a 32-bit value? If so, then it seems like any mining pool with >4GH/s is going go to go through these pretty quick..

Since you SHA the entire block, I assume that the mining clients store the SHA results for the block upto the last one where the nonce is added, then just do the final SHA repeatedly.

Thanks for the info. I'm looking at how mining hardware is designed, and what makes sense to accelerate and what doesn't.

Oatmo

[DannyHamilton]

Couple questions:

Is the nonce a 32-bit value?

Yes.

If so, then it seems like any mining pool with >4GH/s is going go to go through these pretty quick..

Yes.

Since you SHA the entire block,

No. Just the 80 bytes of the block header.

I assume that the mining clients store the SHA results for the block upto the last one where the nonce is added, then just do the final SHA repeatedly.

I'm not sure what you are assuming here.  I believe there are some SHA shortcuts that mining software takes advantage of, but I'm not certain that what you are trying to describe would be such a shortcut.

Thanks for the info. I'm looking at how mining hardware is designed, and what makes sense to accelerate and what doesn't.

Oatmo

[DannyHamilton]

On further consideration, I'm wondering if when you say "you SHA the entire block", you're perhaps referring to building the Merkle Root?

In that case, yes, you would not rebuild the merkle root every time.  You'd build it once, then use it to build the header, then begin the loop of:

• SHA(SHA(blockheader))
• Compare result to difficulty
• Increment nonce value in header
• REPEAT

If you've gotten through all the possible nonces and you haven't yet received a new transaction to add to the block, you need some other way to modify the header.

Most mining software handles this by adjusting the timestamp in the blockheader.

If your mining hardware is fast enough (and/or your pool is big enough), you can run into the situation where you haven't received any new transactions that you want to include AND you are unable to adjust the timestamp any further (the protocol has limitations on how much the next timestamp is allowed to vary).

In this case, you now have to modify your merkle root.  You can keep track of the merkle root building hash that occured prior to the one that is in the blockheader, and then all you have to do is change the arbitrary data in the input of the coinbase transaction (generally called extranonce), finish off the merkle root and return to the loop above with timestamp adjustments again as well.

[oatmo]

Ahhh, I understand..

So I assume that the block header has a hash of the rest of the stuff in the block (just like IPsec an every other secure protocol).

I was just trying to figure out how all the stuff in the block is covered. The POW covers the header, and the header covers the data in the block.

[DannyHamilton]

Ahhh, I understand..

So I assume that the block header has a hash of the rest of the stuff in the block (just like IPsec an every other secure protocol).

I was just trying to figure out how all the stuff in the block is covered. The POW covers the header, and the header covers the data in the block.

Other than the header, the only other thing in the block is the transaction list.

A Merkle Tree is built for the transaction list, and the value of the Merkle Root is placed in the header.  If any value in the transaction list changes, it changes the Merkle Root, so the contents of the transaction list can be verified by building the Merkle Tree, and comparing the resulting Merkle Root to the Merkle Root in the header.

[leijurv]

That's a good point. 2^32 is 4,294,967,296, so what happens if a pool with 4GH/s go through all possible nonces and none of the corresponding hashes are below the target?

[nimda]

That's a good point. 2^32 is 4,294,967,296, so what happens if a pool with 4GH/s go through all possible nonces and none of the corresponding hashes are below the target?

You update the timestamp

[DannyHamilton]

That's a good point. 2^32 is 4,294,967,296, so what happens if a pool with 4GH/s go through all possible nonces and none of the corresponding hashes are below the target?

It happens constantly all day long.

- snip -
Most mining software handles this by adjusting the timestamp in the blockheader.

If your mining hardware is fast enough (and/or your pool is big enough), you can run into the situation where you haven't received any new transactions that you want to include AND you are unable to adjust the timestamp any further (the protocol has limitations on how much the next timestamp is allowed to vary).

In this case, you now have to modify your merkle root.  You can keep track of the merkle root building hash that occured prior to the one that is in the blockheader, and then all you have to do is change the arbitrary data in the input of the coinbase transaction (generally called extranonce), finish off the merkle root and return to the loop above with timestamp adjustments again as well.