Topic: Is it a bug in a popular miner that lowers a chance to find a nonce? [SOLVED] (Read 678 times)
November 22, 2011, 01:19:17 PM
You are right. I didn't notice "=". That explains why sometimes my miner writes that proof-of-work failed.
November 22, 2011, 01:14:45 PM
Looks like with the "less than or equal" comparison the interval (in your notation) is
[0-0x00000001FFFFFFFF]. In my notation it would be [0-0x00000001XXXXXXXX], where X stands for "don't care". Please check the data flow again.
[0-0x00000001FFFFFFFF]. In my notation it would be [0-0x00000001XXXXXXXX], where X stands for "don't care". Please check the data flow again.
November 22, 2011, 12:10:40 PM
Hello.
Few days ago i was digging through the source of ArtForz' miner (https://github.com/ArtForz/cpuminer) and had found a piece of code that looked weird. It's in the very end of "scrypt.c":
With current LTC difficulty ptarget points to "0000000000000000000000000000000000000000000000000000a78e01000000" number. Which becomes 0x000000018ea70000.......... after conversion. So Htarg contains 0x00000001 and we are trying to find a nonce comparing last 4 bytes to 0x00000001. I suspect that we should pay attention to the next 4 bytes which are 0x8ea70000 and compare 64-bit Htarg (not 32!) to 0x000000018ea70000. This will increase our chance to "win" a block, because then we need to hit [0-0x000000018ea70000] not [0-0x0000000100000000] interval.
Am I right?
PS: If you mine in a pool you get work (share) with much lower difficulty (higher target), so you don't loose 30% chance to find a solution, loss is like 0.01%. But if you prefer solo-mining then you could get +50% more coins for the same period of time. In case if I'm not mistaken, of course...
Few days ago i was digging through the source of ArtForz' miner (https://github.com/ArtForz/cpuminer) and had found a piece of code that looked weird. It's in the very end of "scrypt.c":
Code:
uint32_t Htarg = ((const uint32_t *)ptarget)[7];
...
...
...
if (tmp_hash7 <= Htarg) {
((uint32_t *)pdata)[19] = byteswap(n);
*hashes_done = n;
return true;
}
...
...
...
if (tmp_hash7 <= Htarg) {
((uint32_t *)pdata)[19] = byteswap(n);
*hashes_done = n;
return true;
}
With current LTC difficulty ptarget points to "0000000000000000000000000000000000000000000000000000a78e01000000" number. Which becomes 0x000000018ea70000.......... after conversion. So Htarg contains 0x00000001 and we are trying to find a nonce comparing last 4 bytes to 0x00000001. I suspect that we should pay attention to the next 4 bytes which are 0x8ea70000 and compare 64-bit Htarg (not 32!) to 0x000000018ea70000. This will increase our chance to "win" a block, because then we need to hit [0-0x000000018ea70000] not [0-0x0000000100000000] interval.
Am I right?
PS: If you mine in a pool you get work (share) with much lower difficulty (higher target), so you don't loose 30% chance to find a solution, loss is like 0.01%. But if you prefer solo-mining then you could get +50% more coins for the same period of time. In case if I'm not mistaken, of course...
Jump to: