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'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.
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?
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
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.
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