Quote from: grnbrg on June 16, 2014, 07:33:51 PM

Quote from: NewLiberty on June 16, 2014, 07:08:28 PM

I offered this:
When a block is found, send the winning nonce to other large miners and see if one doesn't return it.

* Apparently this can be difficult to do with Stratum.
* If you wait before broadcasting the winning block, another pool may publish first.
* If you publish the block and verify the suspected miner at the same time, the suspected miner may well see the published block and be able to falsely pass your test.

grnbrg.

The merkleroot hashed in a block header, is the root of a tree of transaction hashes.
One of those transaction hashes, is always the coinbase transaction's hash.
Any changes to the coinbase transaction will change the value of the merkleroot.

Thus ... this is used in stratum, where the coinbase transaction is modified to generate work items from a single work sent by the pool.
Thus, it is quite possible that a miner, given exactly the same work from the pool, will not find the same block since:
1) it may not generate the same work items
2) it may not generate and hash as many work items to catch up to finding the block ... especially if it is slower than the block finder.
3) getting a miner to do more than a small amount of extra work (e.g. only 5.5 seconds longer than necessary on the old block to test them) will mean that miner will find more than 1% less blocks.

Just to expand on that: a stratum 32bit nonce2 work from a pool allows for enough work for over 300,000TH/s for 30s - or 4billion possible work items.
Both miners would have to mine the same work item in those 4billion possible work items.
This is possible of course, but not guaranteed.
You could possibly force it, but that's not the only issue ...

Next problem is the fact that not all mining devices mine the same nonce range.
A full nonce range is from 0x0 to 0xffffffff per work item.
Some devices don't do the full range.
Some fail to do parts of the range due to hardware flaws.
Some fail to do parts of the range due to (bad) firmware design.
This of course doesn't make any difference to the chances of finding a block, but it does affect which devices would find the same block.

..........

And then while thinking about this ... I reread my point 3) above ... that would reduce the pool block find rate, by making big hashers find less blocks ...
You'd wanna hope no pool is doing that and causing their own bad luck ...