I tried changing the Sieveextensions.
Chainperday is lower with value lower than 6. But I get similar result with 6, 8, 10 and even 12. (highter than that and it crash in a few second)
Is there any purpose to rise this value or the chainperday is telling the truth?
Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 32. (Read 397657 times)
mikaelh i cant sync wallet it shows no connections i have tried all do i need to do a config file in appdata/primecoin
My best guess at this point is that you're behind a strict firewall/proxy. If it's your own firewall, adjust it. If not, there's not much that can be done about it.
Q: How do I solve a problem with the client not being able to synchronize or connect to any nodes?
A: Try adding this line to your primecoin.conf file:
Code:
seednode=primeseed.muuttuja.org
And it will work
What's the best sievesize for hp 10?
mikaelh i cant sync wallet it shows no connections i have tried all do i need to do a config file in appdata/primecoin
My best guess at this point is that you're behind a strict firewall/proxy. If it's your own firewall, adjust it. If not, there's not much that can be done about it.
it maintains it self in this state
mikaelh i cant sync wallet it shows no connections i have tried all do i need to do a config file in appdata/primecoin
Quote
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.
I think I'm close to being able to build it. I've gone through all the steps from here:
https://bitcointalksearch.org/topic/building-headless-bitcoin-and-bitcoin-qt-on-windows-149479
But I have a problem halfway through the compile with primecoin/src/compat.h
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ws2tcpip.h:38:2: error
: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
In file included from compat.h:18:0,
from netbase.h:11,
from net.h:19,
from rpcnet.cpp:7:
I tried commenting out:
//#include
but that didn't work.
I think I had a similar issue with mingw64. Try adding -DWIN32_LEAN_AND_MEAN to the compiler flags. I think the cause of the issue was some boost header file including windows.h. If WIN32_LEAN_AND_MEAN is not defined, then winsock.h would also be included.
Quote
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.
I think I'm close to being able to build it. I've gone through all the steps from here:
https://bitcointalksearch.org/topic/building-headless-bitcoin-and-bitcoin-qt-on-windows-149479
But I have a problem halfway through the compile with primecoin/src/compat.h
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ws2tcpip.h:38:2: error
: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
In file included from compat.h:18:0,
from netbase.h:11,
from net.h:19,
from rpcnet.cpp:7:
I tried commenting out:
//#include
but that didn't work.
But this worked:
Edit: C:\MinGW\include\windows.h and comment out this part around line 91
/* __USE_W32_SOCKETS is a __CYGWIN__ guard */
/* Ryan
#if defined(__USE_W32_SOCKETS) || !(defined(__CYGWIN__) || defined(__MSYS__))
#include
#endif
*/
Edit2: Just saw your advice mikaelh, thanks that looks like a good fix too!
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.
You see there is no increase, so i don't think 9.996 is more difficult than 10.
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 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.
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 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?
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 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.
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 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.
I would love for a -sievelength param to be added to the build that would sieve for chains of a set length.
+1 Quote
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.
Good work. Difficulty going up 
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 !
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.
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.
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 !
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 !
What do you mean out for a while ?
It was released yesterday !
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).
Jump to: