Search content
Sort by
Showing 20 of 78 results by 8bitPunk
-hp8 is finally out!
Changes in -hp8:
* IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)
* Skip fractional length calculation for the first number in a chain (as suggested by gatra).
* Added a new configurable round primorial adjustment system.
* Round primorial can be adjusted through the -roundsievepercentage parameter (default value is 30, minimum is 1, maximum is 100). The parameter depends how much time is spent running the sieve. By default 30% of time is spent in the sieve and 70% is spent on checking the candidates produced by the sieve.
* Lots of other performance improvements.
* Bigger sieve sizes should no longer crash on Windows.
* Added new RPC commands setsievepercentage and setroundsievepercentage for changing parameters on the fly.
* GMP is now included as a separate library in the binary releases.
Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.
There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.
Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.
Changes in -hp8:
* IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)
* Skip fractional length calculation for the first number in a chain (as suggested by gatra).
* Added a new configurable round primorial adjustment system.
* Round primorial can be adjusted through the -roundsievepercentage parameter (default value is 30, minimum is 1, maximum is 100). The parameter depends how much time is spent running the sieve. By default 30% of time is spent in the sieve and 70% is spent on checking the candidates produced by the sieve.
* Lots of other performance improvements.
* Bigger sieve sizes should no longer crash on Windows.
* Added new RPC commands setsievepercentage and setroundsievepercentage for changing parameters on the fly.
* GMP is now included as a separate library in the binary releases.
Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.
There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.
Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.
Thanks mikaelh... Is there anything similar to Sunny's original gensieveroundlimitms as a fallback to limit the total time spent on a round?
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.
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;
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.
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
I found a 2CC0a block!
79590 AezMwyLP2hpT3yh3LDZkydqkpsrTg7Eyfk
How do I prove it?
79590 AezMwyLP2hpT3yh3LDZkydqkpsrTg7Eyfk
How do I prove it?
Congrats glongsword, your block is 1st-equal with block 78915...
You can verify you own an address with the signmessage command:
Code:
primecoind signmessage AezMwyLP2hpT3yh3LDZkydqkpsrTg7Eyfk "glongsword owns this address - or whatever message you want"
If you're using primecoin-qt then go to Help > Debug window > Console and run:
Code:
signmessage AezMwyLP2hpT3yh3LDZkydqkpsrTg7Eyfk "glongsword owns this address - or whatever message you want"
Post the address, message, and resulting signature here and it's sufficient proof that you can claim discovery of the 2CC0a prime of 123 digits.
No block for 2 days on Xeon e5 3,7 Ghz, decided to go ypool...
Btw while hp7 shows around 3800 primes/s, the ypool miner shows 8000 primes/s. Maybe I should not compare, dunno.
Btw while hp7 shows around 3800 primes/s, the ypool miner shows 8000 primes/s. Maybe I should not compare, dunno.
YPool is interesting in that they are finding 5% of the blocks which appears consistent with their stats page ~3/hour
If we could estimate the total number of miner nodes in the primecoin network then we could establish whether the 3000 workers are more or less 5% of the total network.
I suspect that the ypool miner performance is worse, but the aggregated effect of the pool is helping to avoid orphan blocks.
mikaelh has been hard at work optimizing the code (10 new commits on bitbucket)
After an hour running this on mainnet I'm seeing consistently higher pps and chainspermin than with hp7 on an identical box
I think it's time for another round of donations to keep mikaelh going
After an hour running this on mainnet I'm seeing consistently higher pps and chainspermin than with hp7 on an identical box
I think it's time for another round of donations to keep mikaelh going
How much higher are you seeing? I would donate in primecoin now but I only mined my first block yesterday and it still is immature - it's going to be at least another day before I am able to use the coins.
Current mining info from the box compiled from the latest code:
Code:
{
"blocks" : 81661,
"chainspermin" : 10,
"currentblocksize" : 10284,
"currentblocktx" : 1,
"difficulty" : 9.26995111,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 2995,
"pooledtx" : 1,
"sievepercentage" : 11,
"sievesize" : 4400000,
"testnet" : false
}
"blocks" : 81661,
"chainspermin" : 10,
"currentblocksize" : 10284,
"currentblocktx" : 1,
"difficulty" : 9.26995111,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 2995,
"pooledtx" : 1,
"sievepercentage" : 11,
"sievesize" : 4400000,
"testnet" : false
}
and mining info from the box running hp7:
Code:
{
"blocks" : 81663,
"chainspermin" : 7,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26969045,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 2010,
"pooledtx" : 0,
"sievepercentage" : 11,
"sievesize" : 4400000,
"testnet" : false
}
"blocks" : 81663,
"chainspermin" : 7,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26969045,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 2010,
"pooledtx" : 0,
"sievepercentage" : 11,
"sievesize" : 4400000,
"testnet" : false
}
PPS and CPM fluctuate on both boxes, but the newest code is performing ~30% better based on the stats. It's hard to tell what improvement this would translate to in finding blocks.
I'm wary of comparisons between testnet and mainnet - due to the difference in difficulty, some optimizations might never get used on testnet while they are in constant use in mainnet because of the higher difficulty.
mikaelh has been hard at work optimizing the code (10 new commits on bitbucket)
After an hour running this on mainnet I'm seeing consistently higher pps and chainspermin than with hp7 on an identical box
I think it's time for another round of donations to keep mikaelh going
After an hour running this on mainnet I'm seeing consistently higher pps and chainspermin than with hp7 on an identical box
I think it's time for another round of donations to keep mikaelh going
Re: [XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency
I don't believe so. Primecoin is specifically looking for Cunningham Chains (of the first and second kind and bitwin). Mills' constant could be used to find primes, but it won't help to find primes that form Cunningham Chains of sufficient length to satisfy the proof of work for Primecoin blocks.
In the mean time what do we use?
Mikaelh is sleeping. However, it is unlikely this network issue will reoccur in the next 8 hours.
Keep running hp6 for now...
where do you get the realtime current hash from???
getblockcount will tell you the current block indexthen getblockhash will output the hash
Re: [XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency
Fix ready for testing @
https://github.com/primecoin/primecoin/commit/efd6700bc440e1ff42623c6abf9dd6eca127a424
https://github.com/primecoin/primecoin/commit/efd6700bc440e1ff42623c6abf9dd6eca127a424
Thanks Sunny - that's quite a significant change so I appreciate your ability to turn it around this quickly.
Has anybody else noticed the rate slowing down DRAMATICALLY? In the past two hours, only 31 blocks have been found! That's one block every FOUR minutes!!! Also, my CPU is no longer showing 100% utilization. Only 50%, despite having the same mining settings as always. Anybody else notice this behavior?
Me and Jig shut down our servers, and many other botnets have as well. So from us alone, that's -20% network power.Waiting on a fix for the large blocksize flaw.
Looks like the transactions with large numbers of inputs have gone through and everyone's mempool is cleared out...
Block spacing is back under 1 min - @n4ru You've switched back on eh
Network stuck on block 78414!
+1There is nothing unusual about the block hash...
Code:
primecoind getblockhash 78414
1b32bcf8cb4ff1fc58719872bebad1f2f9d8eaa9e65e948b6eb2f8a6fda37c96
1b32bcf8cb4ff1fc58719872bebad1f2f9d8eaa9e65e948b6eb2f8a6fda37c96
I guess there is something bad about this block !! :
1b32bcf8cb4ff1fc58719872bebad1f2f9d8eaa9e65e948b6eb2f8a6fda37c96
Lol !
Good spotting guys! Someone is broadcasting malformed transactions on the network just to get evil messages into the block hash
currentblocksize is 200k + abit..
guess thats the stuff
prime chains from 17 to 0
primepersecs from 6.5k to 150
thats dual processor 6core each xeon reporting right there.
yay for the tough one!
guess thats the stuff
prime chains from 17 to 0
primepersecs from 6.5k to 150
thats dual processor 6core each xeon reporting right there.
yay for the tough one!
There have been other blocks this size and with 5 transactions...
I'm sure a miner somewhere will solve it
EDIT: Uh oh, transactions are backing up now > 140K with 12 tx
Network stuck on block 78414!
+1There is nothing unusual about the block hash...
Code:
primecoind getblockhash 78414
1b32bcf8cb4ff1fc58719872bebad1f2f9d8eaa9e65e948b6eb2f8a6fda37c96
1b32bcf8cb4ff1fc58719872bebad1f2f9d8eaa9e65e948b6eb2f8a6fda37c96
Re: [XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency
Just posting in this thread as it would be great to see more miners stepping up and claiming the world record prime chains in the blocks they've mined.
Could you use the same format Sunny uses on the first page, e.g. include the generating address.
Good suggestion thanks Rethaw - I've been using the python script provided by Clark as it produces the nice summary table. I'll change it to include the address in the output.
Thanks for the chart, it's looking likely that block spacing will trend above 30 seconds for a while now unless an influx of miners join the network or mining client performance is improved by 10x or more
Re: [XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency
Just posting in this thread as it would be great to see more miners stepping up and claiming the world record prime chains in the blocks they've mined. Relevant information on checking and claiming records is in the [XPM] Primecoin Record Books thread.
Records for Cunningham Chains of length 10 & 11 are now all attributed to Primecoin blocks, and block 74722 has beaten the previous record for a Cunningham Chain length 12.
These records are only the beginning
And it is all thanks to Sunny - I would propose that any records not claimed by a miner should be attributed to Sunny.
Records for Cunningham Chains of length 10 & 11 are now all attributed to Primecoin blocks, and block 74722 has beaten the previous record for a Cunningham Chain length 12.
Code:
New World Record!
Block 74722, Chain 2CC0c (12 primes), 97 digits
Previous record: 62 digits
Block 74722, Chain 2CC0c (12 primes), 97 digits
Previous record: 62 digits
Code:
=== Current Records ===
1CC 2CC TWN
06 633 475 399
07 356 251 *268
08 186 224 177
09 185 *158 *163
10 *123 *115 *119
11 *102 *108 *106
12 42 *97 47
13 39 33 --
14 25 33 29
15 24 32 --
16 23 28 24
17 22 25 --
18 -- -- 24
19 -- -- --
*Found by Primecoin network
1CC 2CC TWN
06 633 475 399
07 356 251 *268
08 186 224 177
09 185 *158 *163
10 *123 *115 *119
11 *102 *108 *106
12 42 *97 47
13 39 33 --
14 25 33 29
15 24 32 --
16 23 28 24
17 22 25 --
18 -- -- 24
19 -- -- --
*Found by Primecoin network
These records are only the beginning
And it is all thanks to Sunny - I would propose that any records not claimed by a miner should be attributed to Sunny.