Quote from: glongsword on July 25, 2013, 04:34:55 AM

Quote from: mtrlt on July 25, 2013, 12:28:57 AM

I might have found a bug in hp7. I copied the hp7 code over to Reaper, and found some weird behavior. I noticed that many shares/blocks it found, had a difficulty with a fractional part of 0.

Function: FermatProbablePrimalityTestFast. It does a Fermat test, and if it fails, it calculates the fractional part. However, there's a fast division test before the Fermat test. If the fast division test is succesful, the function is returned from and the fractional part isn't calculated. If it just happened to be the last number in a chain, the fractional part isn't calculated and is left at 0. This means if the difficulty is for example 6.2, and the miner found a block of difficulty 6.3, it's possible that the fractional part was left uncalculated, and the miner thinks it's difficulty 6.0. The block doesn't get submitted and lots of profit has been lost.

The same applies to EulerLagrangeLifchitzPrimalityTestFast.

Right now I don't have git set up, I can't submit a patch.

Is this the specific change that causes the bug you are referring to: https://bitbucket.org/mikaelh/primecoin-hp/commits/64528eba386c948e4e63d50b9eb6c1a500bac4ca ?

Here's the original comment explaining why it should work: https://bitcointalk.org/index.php?topic=255782.msg2787426#msg2787426

What are your thoughts?

mtrlt replied that this commit is not what he was referring to, and the commit is after the hp7 tag which mtrlt pulled into his project.

I believe he is referring to the code below - which appears around lines 556 & 606:

Code:

if (lRemainder % vPrimes[nPrimeSeq] == 0)
return false;

This code returns false without first calculating the fractional part, exactly as mtrlt explained. I'm testing a fix and will let mikaelh know if it works.