Bitcoin Forum
March 19, 2024, 07:32:21 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 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 ... 131 »
  Print  
Author Topic: [XPM] [ANN] Primecoin High Performance | HP14 released!  (Read 397576 times)
8bitPunk
Member
**
Offline Offline

Activity: 70
Merit: 10



View Profile
July 25, 2013, 01:07:36 AM
 #1221

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.

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

BTC 18bPunkuginRBm1Xz9mcgj8mWJnHDAW5Th | Ł LTCgXEdyBdoQ9WdF6JHi7Pa2EWtzbDjG76 | Ψ ATEBiTLkLpAYeW5hQknUfSvnb7Abbgegku
1710833541
Hero Member
*
Offline Offline

Posts: 1710833541

View Profile Personal Message (Offline)

Ignore
1710833541
Reply with quote  #2

1710833541
Report to moderator
1710833541
Hero Member
*
Offline Offline

Posts: 1710833541

View Profile Personal Message (Offline)

Ignore
1710833541
Reply with quote  #2

1710833541
Report to moderator
1710833541
Hero Member
*
Offline Offline

Posts: 1710833541

View Profile Personal Message (Offline)

Ignore
1710833541
Reply with quote  #2

1710833541
Report to moderator
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
mtrlt
Member
**
Offline Offline

Activity: 104
Merit: 10


View Profile
July 25, 2013, 01:33:04 AM
 #1222

Only up to the tag. But it seems the recent commits haven't had the bug fixed.
nmersulypnem
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
July 25, 2013, 02:29:29 AM
 #1223

Any chance we can get some x64 windows binaries with the latest changes (those after hp7)?  I haven't been able to build on windows (something with my MingW build is not binding the static libraries).
maco
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 25, 2013, 02:45:42 AM
 #1224

So do we have to wait for the next update to get this problem solved?

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.

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

Activity: 266
Merit: 250



View Profile
July 25, 2013, 02:46:54 AM
 #1225

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

BTC: 17sz6AoYVpwXjaStmnVCsGTufUhvrAMhTw
Pt0x
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
July 25, 2013, 02:53:16 AM
 #1226

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.

So do we have to wait for the next update to get this problem solved?

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.

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

BTC: 17sz6AoYVpwXjaStmnVCsGTufUhvrAMhTw
maco
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 25, 2013, 02:54:09 AM
 #1227

It does up to 100 blocks. There was a detailed post at the beginning of this thread regarding that very subject.

you talking about this: https://bitcointalk.org/index.php?topic=255782.msg2725864#msg2725864 ??
Dsfyu
Member
**
Offline Offline

Activity: 75
Merit: 10



View Profile
July 25, 2013, 03:12:05 AM
 #1228

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?

Don't just trade, get paid to Atomic⚛Trade !!!
Disclaimer: I am a noob. Assume I know nothing until proven otherwise.
Pt0x
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
July 25, 2013, 03:24:52 AM
 #1229

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?

I followed this guide to the end: http://ecoinomist.com/xpm-primecoin-mining-guide-on-linux
And there is a simple script + cronjob combo that takes care of the crash, if it happened to me I didn't notice. By using hp5 I found my first block in 4 hours.

BTC: 17sz6AoYVpwXjaStmnVCsGTufUhvrAMhTw
Dsfyu
Member
**
Offline Offline

Activity: 75
Merit: 10



View Profile
July 25, 2013, 03:28:08 AM
 #1230

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.

I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.

But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?

I followed this guide to the end: http://ecoinomist.com/xpm-primecoin-mining-guide-on-linux
And there is a simple script + cronjob combo that takes care of the crash, if it happened to me I didn't notice. By using hp5 I found my first block in 4 hours.


When I was using hp5 and hp6 I didn't get anything for two days and when I installed hp7 yesterday I got a block within a half hour - It seems to come down to luck in the end - My first two days had nothing and then I got a block yesterday and today on hp7. I would really like to know how much of a difference it makes for you reverting back to hp5.

Don't just trade, get paid to Atomic⚛Trade !!!
Disclaimer: I am a noob. Assume I know nothing until proven otherwise.
Pt0x
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
July 25, 2013, 03:40:28 AM
 #1231

I don't know how that can affect your wallet  Sad . 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.

So do we have to wait for the next update to get this problem solved?

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.

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

BTC: 17sz6AoYVpwXjaStmnVCsGTufUhvrAMhTw
#Darren
Sr. Member
****
Offline Offline

Activity: 784
Merit: 250


DIA | Data infrastructure for DeFi


View Profile
July 25, 2013, 04:15:37 AM
 #1232

Is anyone just running hp7 at default?

What, if any, are the preferred changes for i72600 and AMD FX830?


      ████████████████
   ████████████████████████
██████████████████████████████
█████████████████████████████████
███████████████████████████████████
█████████████████████████████████████
██████████████████████████████████████
███████████████████████████████████████
█████████████████   ███████████████████
█████████████████        ███████████████
█████████████████          █████████████
█████████████████            ████████████
█████████████████             ███████████
█████████████████             ███████████
█████████████████              ██████████
█████████████████              ██████████
█████████████████             ███████████
█████████████████            ███████████
█████████████████          █████████████
█████████████████      ███████████████
█████████████████ ████████████████████
█████████████████████████████████████
███████████████████████████████████
█████████████████████████████████
██████████████████████████████
██████████████████████████
     █████████████████
          ████
DIA | OPEN ACCESS FINANCIAL DATA
testz
Legendary
*
Offline Offline

Activity: 1764
Merit: 1018


View Profile
July 25, 2013, 04:17:14 AM
 #1233

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Only one pool exists for now: http://ypool.net/

            ▄▄████▄▄
        ▄▄██████████████▄▄
      ███████████████████████▄▄
      ▀▀█████████████████████████
██▄▄       ▀▀█████████████████████
██████▄▄        ▀█████████████████
███████████▄▄       ▀▀████████████
███████████████▄▄        ▀████████
████████████████████▄▄       ▀▀███
 ▀▀██████████████████████▄▄
     ▀▀██████████████████████▄▄
▄▄        ▀██████████████████████▄
████▄▄        ▀▀██████████████████
█████████▄▄        ▀▀█████████████
█████████████▄▄        ▀▀█████████
██████████████████▄▄        ▀▀████
▀██████████████████████▄▄
  ▀▀████████████████████████
      ▀▀█████████████████▀▀
           ▀▀███████▀▀



.SEMUX
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
  Semux uses .100% original codebase.
  Superfast with .30 seconds instant finality.
  Tested .5000 tx per block. on open network
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
glongsword
Full Member
***
Offline Offline

Activity: 314
Merit: 100



View Profile
July 25, 2013, 04:34:55 AM
 #1234

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.

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

Activity: 266
Merit: 250



View Profile
July 25, 2013, 04:53:24 AM
 #1235

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Only one pool exists for now: http://ypool.net/

Looks odd to me

BTC: 17sz6AoYVpwXjaStmnVCsGTufUhvrAMhTw
8bitPunk
Member
**
Offline Offline

Activity: 70
Merit: 10



View Profile
July 25, 2013, 05:49:24 AM
 #1236

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.

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;

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.

BTC 18bPunkuginRBm1Xz9mcgj8mWJnHDAW5Th | Ł LTCgXEdyBdoQ9WdF6JHi7Pa2EWtzbDjG76 | Ψ ATEBiTLkLpAYeW5hQknUfSvnb7Abbgegku
maco
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 25, 2013, 05:50:36 AM
 #1237

+1 8bitPunk

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.

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;

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

Activity: 96
Merit: 10


View Profile
July 25, 2013, 07:40:35 AM
 #1238

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Only one pool exists for now: http://ypool.net/

Looks odd to me

I'm sure it took some hard work to be the first pool.
mikaelh (OP)
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
July 25, 2013, 07:51:51 AM
 #1239

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.

Good catch! Letting that one slip was definitely a big oversight on my part. I pushed my own fix to bitbucket just now. I don't have time to do a release right now so it'll have to wait for a bit. In the meantime the fix is up there for testing.
Vannicke
Member
**
Offline Offline

Activity: 95
Merit: 10


That guy, you know, with the face


View Profile
July 25, 2013, 09:05:21 AM
 #1240

Does this mean that people with hp7 that find blocks are effectively at difficulty 10?

That would certainly explain my long dryspell...

The Satoshi Jar: 16t2BLGZyaMpGm3vzYWxucGz8g4bVotr1h
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 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 ... 131 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!