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

[Dumbo]

so does anyone know how to replenish the keypool for solo mining on different servers?

I tried

Help>Debug>Console ...then Keypool = 1000

it threw a error -- > "Method not found"


Next I made a primecoin.conf file and put setkeypool = 1000 in that...

How do I know if that worked?

[Trillium]

Difficulty is clearly on the rise again !

http://192.241.170.170/

Actually, the difficulty is CLEARLY stable at the moment. It has increased <5% over diff 9 in the last two weeks.

The optimizations made in HP10 may or may not increase block rate and hence the network may increase the difficulty, although HP10 has been out for a while now and the diff has barely budged, so it's not looking like we'll see an increase.

[Tamis]

What do you mean out for a while ?

It was released yesterday !

[rdebourbon]

What do you mean out for a while ?

It was released yesterday !

The major sieve updates were made about 10 days ago according to git.. So those who build from source have had the update for a while..

[Tamis]

Man were they quiet about it !  

[mikaelh]

I start primecoin and it crashes...  

Used to work fine and suddenly started acting out...replaced with the new hp10 and same thing.
Gonna have to fiddle some more with it. ARGH

I haven't seen a crash like that. Can you post your debug.log and primecoin.conf?

[mikaelh]

If you want to get an estimation of your block/day :
Take one minus the decimal part of the difficulty and multiply it with your chain/day.

block/day = (1 - dec(difficulty) ) * chainsperday

From your example :
    "chainsperday" : 0.28633614,
    "difficulty" : 9.68146938,
block/day = (1 - 0.68146938) * 0.28633614 = 0,091206828 = around one block every 11 days !

firstly, finally a forum search where i found what I was looking for

secondly..  since we dont use the whole number of the diff, can I assume that the chainsperday calculation takes into account the whole number?

The formula posted by SlyWax isn't accurate. He assumed that the decimal part would behave linearly while in reality it seems to behave logarithmically. The chains/day estimate does account for the integer part.

[mikaelh]

Difficulty is clearly on the rise again !

http://192.241.170.170/

Actually, the difficulty is CLEARLY stable at the moment. It has increased <5% over diff 9 in the last two weeks.

The optimizations made in HP10 may or may not increase block rate and hence the network may increase the difficulty, although HP10 has been out for a while now and the diff has barely budged, so it's not looking like we'll see an increase.

Well, I'm pretty impressed with the difficulty increase so far. You have to remember that it's scaling logarithmically which means that a 5% increase is pretty big at this point. HP10 is probably still being deployed so the difficulty will keep going up. Also ypool seems to be down which means the network may have lost quite a lot of power at the same time. If ypool really is down and difficulty is still going up, I'll be very impressed.

[mikaelh]

What do you mean out for a while ?

It was released yesterday !

The major sieve updates were made about 10 days ago according to git.. So those who build from source have had the update for a while..

10 days ago was when I wrote most of the code but I didn't push it. I wanted to test it first but due to my lack of time it took a few days. So in the end it was only me benefiting from the optimization unless someone else also implemented jh00's idea (which was out at least a couple of days before I wrote my version of it).

[Tamis]

Ah that's better !

Perfectly normal you use your code before anyone else, but I was surprised to hear that some others were using it and keeping it "secret".
Thanks again for your work, haven't donated yet but will

ypool is down indeed, I wanted to check their stats since i'm pretty sure hp10 is going to hit them pretty hard, site is down.
So the current difficulty increase is hp10 only !

[mikaelh]

Well, testing the code ahead of time obviously does help to pay for the development. My testing started around Aug 19th so I did probably contribute a bit to the difficulty spike there. I am a bit surprised that nobody was paying attention to jh00's idea of extending the sieve. It's the biggest optimization in weeks and I only saw a few forum posts about it. It was only included in the official jhPrimeminer and none of the popular forks had it. But then again the mining code in the forks is based on my code and the original jhPrimeminer is different.

[SlyWax]

If you want to get an estimation of your block/day :
Take one minus the decimal part of the difficulty and multiply it with your chain/day.

block/day = (1 - dec(difficulty) ) * chainsperday

From your example :
    "chainsperday" : 0.28633614,
    "difficulty" : 9.68146938,
block/day = (1 - 0.68146938) * 0.28633614 = 0,091206828 = around one block every 11 days !

firstly, finally a forum search where i found what I was looking for

secondly..  since we dont use the whole number of the diff, can I assume that the chainsperday calculation takes into account the whole number?

The formula posted by SlyWax isn't accurate. He assumed that the decimal part would behave linearly while in reality it seems to behave logarithmically.

Well it's not linear.
If you plot the number of days to find a block VS fractional difficulty with my formula ( with chains/day=1 ), you get :

http://fooplot.com/plot/84iljd7anq

Then you have to add the chance of next length chain to the number as stated in my previous post (chainPerDay/36)

The chains/day estimate does account for the integer part.

Do you mean that the chains/day change with the fractional difficulty ?

If it's the case, then to compare two chains/day number we would have to account for the respective difficulty.

[Lauda]

Good work. Difficulty going up 

[cabin]

The formula posted by SlyWax isn't accurate. He assumed that the decimal part would behave linearly while in reality it seems to behave logarithmically. The chains/day estimate does account for the integer part.

Looking at the code, unless there is a bug in the algorithm that is say rejecting 10.5 length chains at the moment, it *should* behave linearly. Diff 9.999 should be same as 10, but but from the charts it is obviously not.

I wonder if this is because all the current miners are optimized to sieve for 9 chains at the moment? I wonder if the the difficulty would look more linear if miners switch to sieving for 10 chains now that most 9 chains won't solve a block. I would love for a -sievelength param to be added to the build that would sieve for chains of a set length. I would do it myself and experiment but I am having some difficulty building the project on windows, and I suspect it is at least as hard as bitcoin to build.

I can build the ypool miner easily and from those experiments the sieve length is quite effective at optimizing for chains of a desired length.

[binaryFate]

I would love for a -sievelength param to be added to the build that would sieve for chains of a set length.

+1

[mikaelh]

Looking at the code, unless there is a bug in the algorithm that is say rejecting 10.5 length chains at the moment, it *should* behave linearly. Diff 9.999 should be same as 10, but but from the charts it is obviously not.

I think the distribution of the Fermat's remainder is skewed. Sunny mentioned that briefly in his paper too. The skewed distribution is probably caused by the repeated exponentiation done during the Fermat's test.

I wonder if this is because all the current miners are optimized to sieve for 9 chains at the moment? I wonder if the the difficulty would look more linear if miners switch to sieving for 10 chains now that most 9 chains won't solve a block. I would love for a -sievelength param to be added to the build that would sieve for chains of a set length. I would do it myself and experiment but I am having some difficulty building the project on windows, and I suspect it is at least as hard as bitcoin to build.

I can build the ypool miner easily and from those experiments the sieve length is quite effective at optimizing for chains of a desired length.

I'm a bit doubtful that switching the target difficulty to 10 would be beneficial at this point. It might become beneficial when difficulty is around 9.9 but I haven't really investigated that.

Also it's good to remember that optimal mining parameters are probably not the same for ypool and solo mining. Ypool miners are concerned with maximizing the value of their shares. Previously that system was exploited using shorter chains. Now that the system was changed radically it could be possible to exploit it with longer chains.

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

[cabin]

Looking at the code, unless there is a bug in the algorithm that is say rejecting 10.5 length chains at the moment, it *should* behave linearly. Diff 9.999 should be same as 10, but but from the charts it is obviously not.

I think the distribution of the Fermat's remainder is skewed. Sunny mentioned that briefly in his paper too. The skewed distribution is probably caused by the repeated exponentiation done during the Fermat's test.

I wonder if this is because all the current miners are optimized to sieve for 9 chains at the moment? I wonder if the the difficulty would look more linear if miners switch to sieving for 10 chains now that most 9 chains won't solve a block. I would love for a -sievelength param to be added to the build that would sieve for chains of a set length. I would do it myself and experiment but I am having some difficulty building the project on windows, and I suspect it is at least as hard as bitcoin to build.

I can build the ypool miner easily and from those experiments the sieve length is quite effective at optimizing for chains of a desired length.

I'm a bit doubtful that switching the target difficulty to 10 would be beneficial at this point. It might become beneficial when difficulty is around 9.9 but I haven't really investigated that.

Also it's good to remember that optimal mining parameters are probably not the same for ypool and solo mining. Ypool miners are concerned with maximizing the value of their shares. Previously that system was exploited using shorter chains. Now that the system was changed radically it could be possible to exploit it with longer chains.

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

Ah ok, if the distribution is heavily skewed, and the number of miners was increasing rapidly, that could explain some of it. Well, if the parameter is added I would try it out now even if it is too early and see what happens.

[hasle2]

Looking at the code, unless there is a bug in the algorithm that is say rejecting 10.5 length chains at the moment, it *should* behave linearly. Diff 9.999 should be same as 10, but but from the charts it is obviously not.

I think the distribution of the Fermat's remainder is skewed. Sunny mentioned that briefly in his paper too. The skewed distribution is probably caused by the repeated exponentiation done during the Fermat's test.

I wonder if this is because all the current miners are optimized to sieve for 9 chains at the moment? I wonder if the the difficulty would look more linear if miners switch to sieving for 10 chains now that most 9 chains won't solve a block. I would love for a -sievelength param to be added to the build that would sieve for chains of a set length. I would do it myself and experiment but I am having some difficulty building the project on windows, and I suspect it is at least as hard as bitcoin to build.

I can build the ypool miner easily and from those experiments the sieve length is quite effective at optimizing for chains of a desired length.

I'm a bit doubtful that switching the target difficulty to 10 would be beneficial at this point. It might become beneficial when difficulty is around 9.9 but I haven't really investigated that.

Also it's good to remember that optimal mining parameters are probably not the same for ypool and solo mining. Ypool miners are concerned with maximizing the value of their shares. Previously that system was exploited using shorter chains. Now that the system was changed radically it could be possible to exploit it with longer chains.

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

Would a sieve for 10 chain work just as well for 9 chains? Or would it be less efficient for 9 chains than a 9 chain sieve? Or does constructing a sieve for 10 chains take that much longer that it would not be worth it?

[cabin]

Looking at the code, unless there is a bug in the algorithm that is say rejecting 10.5 length chains at the moment, it *should* behave linearly. Diff 9.999 should be same as 10, but but from the charts it is obviously not.

I think the distribution of the Fermat's remainder is skewed. Sunny mentioned that briefly in his paper too. The skewed distribution is probably caused by the repeated exponentiation done during the Fermat's test.

I wonder if this is because all the current miners are optimized to sieve for 9 chains at the moment? I wonder if the the difficulty would look more linear if miners switch to sieving for 10 chains now that most 9 chains won't solve a block. I would love for a -sievelength param to be added to the build that would sieve for chains of a set length. I would do it myself and experiment but I am having some difficulty building the project on windows, and I suspect it is at least as hard as bitcoin to build.

I can build the ypool miner easily and from those experiments the sieve length is quite effective at optimizing for chains of a desired length.

I'm a bit doubtful that switching the target difficulty to 10 would be beneficial at this point. It might become beneficial when difficulty is around 9.9 but I haven't really investigated that.

Also it's good to remember that optimal mining parameters are probably not the same for ypool and solo mining. Ypool miners are concerned with maximizing the value of their shares. Previously that system was exploited using shorter chains. Now that the system was changed radically it could be possible to exploit it with longer chains.

The building procedure for the stock Primecoin client should be the same as for Bitcoin. For my version you also need libgmp on top of that.

Would a sieve for 10 chain work just as well for 9 chains? Or would it be less efficient for 9 chains than a 9 chain sieve? Or does constructing a sieve for 10 chains take that much longer that it would not be worth it?

It is less efficient for 9 and all lower chains, so it is certainly a bad idea unless the diff has a high fraction.

[bidji29]

If you look at the blockrate when the diff pass a new integer. (only happenend 2 times)
You see there is no increase, so i don't think 9.996 is more difficult than 10.