Bitcoin Forum
August 17, 2018, 11:26:19 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 [101] 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 »
  Print  
Author Topic: [XPM] [ANN] Primecoin High Performance | HP14 released!  (Read 396495 times)
Tamis
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250



View Profile
August 25, 2013, 08:31:20 AM
 #2001

Man were they quiet about it !   Angry
1534548379
Hero Member
*
Offline Offline

Posts: 1534548379

View Profile Personal Message (Offline)

Ignore
1534548379
Reply with quote  #2

1534548379
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 08:54:42 AM
 #2002

I start primecoin and it crashes...  Huh

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
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 09:01:37 AM
 #2003

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 Smiley

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
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 09:36:08 AM
 #2004

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
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 09:45:19 AM
 #2005

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
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250



View Profile
August 25, 2013, 09:53:29 AM
 #2006

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 Smiley

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
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 10:08:54 AM
 #2007

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
Sr. Member
****
Offline Offline

Activity: 247
Merit: 251



View Profile
August 25, 2013, 10:11:48 AM
 #2008

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 Smiley

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
Legendary
*
Offline Offline

Activity: 1946
Merit: 1570


GUNBOT Licenses -15% with ref. code 'GrumpyKitty'


View Profile WWW
August 25, 2013, 10:38:27 AM
 #2009

Good work. Difficulty going up  Cool

.FORTUNE.JACK.
      ▄▄███████▄▄
   ▄████▀▀ ▄ ██████▄
  ████ ▄▄███ ████████
 █████▌▐███▌ ▀▄ ▀█████
███████▄██▀▀▀▀▄████████
█████▀▄▄▄▄█████████████
████▄▄▄▄ █████████████
 ██████▌ ███▀████████
  ███████▄▀▄████████
   ▀█████▀▀███████▀
      ▀▀██████▀▀
         
         █
...FortuneJack.com                                             
...THE BIGGEST BITCOIN GAMBLING SITE
       ▄▄█████████▄▄
    ▄█████████████████▄
  ▄█████████████████████▄
 ▄██
█████████▀███████████▄
██████████▀   ▀██████████
█████████▀       ▀█████████
████████           ████████
████████▄   ▄ ▄   ▄████████
██████████▀   ▀██████████
 ▀██
█████████████████████▀
  ▀██
███████████████████▀
    ▀█████████████████▀
       ▀▀█████████▀▀
#JACKMATE
WIN 1 BTC
▄█████████████████████████▄
███████████████████████████
███████████████████████████
██████████▀█████▀██████████
███████▀░░▀░░░░░▀░░▀███████
██████▌░░░░░░░░░░░░░▐██████
██████░░░░██░░░██░░░░██████
█████▌░░░░▀▀░░░▀▀░░░░▐█████
██████▄░░▄▄▄░░░▄▄▄░░▄██████
████████▄▄███████▄▄████████

███████████████████████████
███████████████████████████
▀█████████████████████████▀
cabin
Sr. Member
****
Offline Offline

Activity: 576
Merit: 250


Join Cashbery Coin!


View Profile
August 25, 2013, 12:21:16 PM
 #2010

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.

binaryFate
Legendary
*
Offline Offline

Activity: 1344
Merit: 1001


Still wild and free


View Profile
August 25, 2013, 12:24:36 PM
 #2011

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

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. 
This makes Monero a better candidate to deserve the term "digital cash".
mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 12:39:04 PM
 #2012

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
Sr. Member
****
Offline Offline

Activity: 576
Merit: 250


Join Cashbery Coin!


View Profile
August 25, 2013, 01:13:00 PM
 #2013

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
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile
August 25, 2013, 02:16:18 PM
 #2014

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
Sr. Member
****
Offline Offline

Activity: 576
Merit: 250


Join Cashbery Coin!


View Profile
August 25, 2013, 02:31:26 PM
 #2015

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
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
August 25, 2013, 03:08:42 PM
 #2016

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.

http://www.freebieservers.com/  100% FREE GAME SERVERS
cabin
Sr. Member
****
Offline Offline

Activity: 576
Merit: 250


Join Cashbery Coin!


View Profile
August 25, 2013, 03:39:06 PM
 #2017

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://bitcointalk.org/index.php?topic=149479.0

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 <mswsock.h> in compat.h

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 <winsock.h>
#endif
*/

Edit2: Just saw your advice mikaelh, thanks that looks like a good fix too!


mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
August 25, 2013, 04:07:29 PM
 #2018

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://bitcointalk.org/index.php?topic=149479.0

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 <mswsock.h> in compat.h

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.
elvisrene
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
August 25, 2013, 04:50:29 PM
 #2019

mikaelh i cant sync wallet it shows no connections i have tried all do i need to do a config file in appdata/primecoin
elvisrene
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250



View Profile
August 25, 2013, 04:54:24 PM
 #2020



it maintains it self in this state
Pages: « 1 ... 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 [101] 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!