Bitcoin Forum

Hi, this will expose my ignorance on how some of this works but..  What will cause a share to be rejected?

Also does each pool send out a different nonce or are they the same? Also if they are not the same, does each pool send out different nonce to a different worker?

Thanks.

share can be rejected for one of three reasons
a) it is junk.  hardware failure resulted in "wrong answer".  the hash provided isn't produced from the data
b) it is for the wrong pool.  can happen w/ errors in backup pools.  You send backup pool hash to main pool
c) it is stale.  block has changed so that data is worthless

pools don't send out nonces.  If they did they would need to send couple hundred million every single second for every single worker.

Pools compute the block header EXCEPT the nonce and provide that to the miner.  The miner then starts at nonce 0 and hashes it, then tries 1, then tries 2, then tries 3 .... up to 2^32 -1.  It returns any shares and asks for more work (new header).  It then tries annother 4 billion nonces on that header.

Yes.  Otherwise it would have two miners doing the same work (cutting effective hashrate of the pool in half).  If a pool is consistently "unlucky" over a long period of time it may be caused by a bug which is sending duplicate work to multiple miners.


Effectively no.  One element of the block header is the merkle tree root and the merkle tree cointains the coinbase which contains the pool's reward address.  Thus two different pools will always have a different merkle tree root and different headers.

I say effectively because technically two different sets of data could generate the same hash (a hash collision) but the odds are 1 in 2^256 and can be effectively considered 0.

The entire block header consists of:
Version
Previous hash
Merkle root
Timestamp
"Bits" (current target)
Nonce 32-bit number

So the pool sends all that data except nonce to the miner who increments and hashes each nonce looking for shares.  N-time-rolling allows the miner to increment the timestamp locally.  This allows multiple nonce ranges (0 to 2^32) to be attempted on each get work.  Technically the pool only needs to update the miner when one of the other elements change.

target, and version will never change intra block.
Previous hash only changes when a block is found.
The merkle root only changes when a transaction is added.

d) this share was already sent by you or another miner of same pool

Good one.  Got to keep those miners honest. :)

Or a bug in pool software which resulted in same header being sent to two workers.  Possibly a bug in a miner code which caused it to resend same work more than once.