Bitcoin Forum
May 09, 2024, 07:10:40 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Is it a bug in a popular miner that lowers a chance to find a nonce? [SOLVED]  (Read 663 times)
Come-from-Beyond (OP)
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
November 22, 2011, 05:10:40 PM
Last edit: November 22, 2011, 06:36:57 PM by Come-from-Beyond
 #1

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];
...
...
...
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...
1715281840
Hero Member
*
Offline Offline

Posts: 1715281840

View Profile Personal Message (Offline)

Ignore
1715281840
Reply with quote  #2

1715281840
Report to moderator
1715281840
Hero Member
*
Offline Offline

Posts: 1715281840

View Profile Personal Message (Offline)

Ignore
1715281840
Reply with quote  #2

1715281840
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715281840
Hero Member
*
Offline Offline

Posts: 1715281840

View Profile Personal Message (Offline)

Ignore
1715281840
Reply with quote  #2

1715281840
Report to moderator
1715281840
Hero Member
*
Offline Offline

Posts: 1715281840

View Profile Personal Message (Offline)

Ignore
1715281840
Reply with quote  #2

1715281840
Report to moderator
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1068



View Profile
November 22, 2011, 06:14:45 PM
 #2

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Come-from-Beyond (OP)
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
November 22, 2011, 06:19:17 PM
 #3

You are right. I didn't notice "=". That explains why sometimes my miner writes that proof-of-work failed.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!