Quote from: mysidia on June 16, 2014, 06:42:57 AM

Quote from: NewLiberty on June 16, 2014, 05:16:07 AM

How, by sending a winning nonce to all the largest miners in their pool to see if one doesn't return it?

I think one of the problems is; there's no guarantee about which order the miner tries the nonce values in, and it might fail or decide not to try some subset of nonces of the winning one is one of... without being a "cheating" or withholding miner.

The other thing is sending miners some fake work units: results in hashing power being wasted, so great care must be taken for the "fix" to not have greater expected total losses on average, than the block withholding attacks that are likely.

Yes... this has been discussed a month or two ago, I think here in this thread. In any case, it is known that some hardware only checks certain nonces due to the design of the chip.... e.g. maybe it only checks even numbers and skips odds, or only factors of 4, etc. This is built into the design of the hardware. It still checks X number of hashes per second, but it just skips certain nonces.

And then you have the efficiency issue. All miners in a pool should be notified ASAP when a new block is found, and new work pushed to all of them. Otherwise, the workers pull work from the pool on an as-needed basis. If the pool found a block (i.e., a known good nonce) then it would have to have some way to push a normal-looking work payload to all miners in order to test them. This just isn't going to happen, it will be easily detectible (just set up 3 addresses to mine to, if all of them get the same work at once then it's an obvious test) and also loses efficiency. It is making miners work on an old block which has already been found, when they should be working on a new block. It just doesn't make sense to do this. Perhaps on a targeted basis, but certainly not for the whole pool, or even for all of the larger miners.

All in all, statistical analysis is the best way to discover block withholders.