[XPM] [ANN] Primecoin High Performance | HP14 released!

[8bitPunk]

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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

[mtrlt]

Only up to the tag. But it seems the recent commits haven't had the bug fixed.

[nmersulypnem]

Any chance we can get some x64 windows binaries with the latest changes (those after hp7)?  I haven't been able to build on windows (something with my MingW build is not binding the static libraries).

[maco]

So do we have to wait for the next update to get this problem solved?

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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

[Pt0x]

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

[Pt0x]

According to the first post:

 Changes in -hp6:
 * Added fast divisibility tests before doing the expensive Fermat's test

I guess by just reverting to hp5 we can get around the bug while hp8 appears online.

So do we have to wait for the next update to get this problem solved?

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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

[maco]

It does up to 100 blocks. There was a detailed post at the beginning of this thread regarding that very subject.

you talking about this: https://bitcointalk.org/index.php?topic=255782.msg2725864#msg2725864 ??

[Dsfyu]

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?

[Pt0x]

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?

I followed this guide to the end: http://ecoinomist.com/xpm-primecoin-mining-guide-on-linux
And there is a simple script + cronjob combo that takes care of the crash, if it happened to me I didn't notice. By using hp5 I found my first block in 4 hours.

[Dsfyu]

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?

I followed this guide to the end: http://ecoinomist.com/xpm-primecoin-mining-guide-on-linux
And there is a simple script + cronjob combo that takes care of the crash, if it happened to me I didn't notice. By using hp5 I found my first block in 4 hours.

When I was using hp5 and hp6 I didn't get anything for two days and when I installed hp7 yesterday I got a block within a half hour - It seems to come down to luck in the end - My first two days had nothing and then I got a block yesterday and today on hp7. I would really like to know how much of a difference it makes for you reverting back to hp5.

[Pt0x]

I don't know how that can affect your wallet  . I'm using different wallets in each miner and dump the private keys every time a block it's found, then I restore the keys on my "money PC" where I only run the official client. After that I stop primecoind on the miner, delete the wallet and restart the client.

I know this is a odd question ptox, but did that affect my wallet? I was using the same wallet for a couple of my servers. I used the keypool=10000 command. Because before HP6/7 I mined 2 blocks in 1 hour then upgraded to 6/7 and nothing so far. (the blocks occurred 2 days ago) and do you know if its okay to use keypool? or should I generate a new address? I was happy with HP5, and never had a single thing wrong with it.

According to the first post:

 Changes in -hp6:
 * Added fast divisibility tests before doing the expensive Fermat's test

I guess by just reverting to hp5 we can get around the bug while hp8 appears online.

So do we have to wait for the next update to get this problem solved?

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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

[#Darren]

Is anyone just running hp7 at default?

What, if any, are the preferred changes for i72600 and AMD FX830?

[testz]

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Only one pool exists for now: http://ypool.net/

[glongsword]

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?

[Pt0x]

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Only one pool exists for now: http://ypool.net/

Looks odd to me

[8bitPunk]

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.

[maco]

+1 8bitPunk

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.

[Foamy]

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Only one pool exists for now: http://ypool.net/

Looks odd to me

I'm sure it took some hard work to be the first pool.

[mikaelh]

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.

Good catch! Letting that one slip was definitely a big oversight on my part. I pushed my own fix to bitbucket just now. I don't have time to do a release right now so it'll have to wait for a bit. In the meantime the fix is up there for testing.

[Vannicke]

Does this mean that people with hp7 that find blocks are effectively at difficulty 10?

That would certainly explain my long dryspell...