Title: Is it a bug in a popular miner that lowers a chance to find a nonce? [SOLVED] Post by: Come-from-Beyond on November 22, 2011, 05: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": Code: uint32_t Htarg = ((const uint32_t *)ptarget)[7]; 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... Title: Re: Is it a bug in a popular miner that lowers a chance to find a nonce? Post by: 2112 on November 22, 2011, 06: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. Title: Re: Is it a bug in a popular miner that lowers a chance to find a nonce? Post by: Come-from-Beyond on November 22, 2011, 06:19:17 PM You are right. I didn't notice "=". That explains why sometimes my miner writes that proof-of-work failed.
|