The OpenCL part is supposed to calculate the 8 first bytes of the hash. The 4 first bytes are calculated fine, but the next ones are not, so they end up being essentially random numbers. In specific situations, it could lead to the miner ignoring a valid block.
In the python code:
BitcoinMiner.py:161
Code:
if h[7] != 0:
self.failure('Verification failed, check hardware!')
else:
Like this:
Code:
if h[7] != 0:
self.failure('Verification failed, check hardware!')
elif h[6] > 0x80000000:
self.failure('Verification 2 failed, check hardware or the algorithm! :-P')
else:
Then I made another change.
BitcoinMiner.py:273
Code:
self.miner.search( queue, (globalThreads, ), (self.worksize, ),
state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7],
state2[1], state2[2], state2[3], state2[5], state2[6], state2[7],
pack('I', uint32(0xFFFF0000)), pack('I', 0), #<-- here's the target
pack('I', base),
f[0], f[1], f[2], f[3], f[4], f[5], f[6], f[7],
output_buf)
Turns out it doesn't. When I ran poclbm, I got the "Verification 2 failed" message in a few minutes.
For some reason, there is commented-out code in BitcoinMiner.cl that modifies G, which should be the bytes 4-7 of the resulting hash in the end.
BitcoinMiner.cl:299
Code:
//W13 = W13 + (rotr(W14, 7) ^ rotr(W14, 18) ^ (W14 >> 3U)) + W6 + (rotr(W11, 17) ^ rotr(W11, 19) ^ (W11 >> 10U));
//C = C + (rotr(H, 6) ^ rotr(H, 11) ^ rotr(H, 25)) + (B ^ (H & (A ^ B))) + K[61] + W13; G = G + C;
//G+=0x1f83d9abU;
Uncommenting them didn't fix the problem, though.
Why is this a problem, then? If the bytes 4-7 of the real hash are below the current target, but the OpenCL program calculates that they're over the hard-coded value of 0xFFFF0000, it would lead to a valid block being ignored, and no BTC for you.
Proposed fix: As the bytes 0-3 are calculated correctly and the target given to OpenCL is hardcoded anyway, I'd drop the target being sent to OpenCL altogether and have it just report nonces that lead to hashes for which the first 4 bytes are zero.
