[XPM] [ANN] Primecoin Release - First Scientific Computing Cryptocurrency

[nmersulypnem]

I thought difficulty will rise a lot when GPU miners appear?

The prime number searching range for Primecoin is roughly 2^100 ~ 2^2000 ( 100 digits ~ 2000 digits ).  For the sake of simplicity, let's assume the primes are about 2^100.  According to the Prime number theorem, the prime number distribution of this range is about 1 prime number in 230 integers.  When difficulty grows from 7 to 8, it means the miner needs to find a prime chain of length 8 instead of 7, making the likelihood to 1/230 of before.  In other word, it takes 230 times longer to find a 8-chain than a 7-chain if we assume the mining power remain the same.  It would take  230*230*230 = 12167000 times longer to find a 10-chain, that's 10 million times more difficult.

Now let's take the GPU and other possible device into account.  The GPU is very efficient of calculating hash, but in the specific case of primecoin, it doesn't seem have the same kind of advantage.  Unless there are some specially designed hardware for prime searching, the mining speed at most will be less than 1000x faster.

So it is quite clear that even with 10000x more miners equipped with monster machines, it is still not even close to reach difficulty 10.

Where do you see that range in the code?  I don't see it...

<prime.h>

static const CBigNum bnPrimeMax = (bnOne << 2000) - 1;
static const CBigNum bnPrimeMin = (bnOne << 255);

I think an FPGA would be perfect for this...

[1713990142]

1713990142

[1713990142]

1713990142

[1713990142]

1713990142

[1713990142]

1713990142

[mustyoshi]

nMaxSieveSize = 1000000u  ~130 - 230 pps
nMaxSieveSize = 100000u    ~230 - 400 pps
nMaxSieveSize = 10000u      ~ 350 - 800 pps

Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. 

I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW...

Who knows what that actually does to the potential of finding a correct PoW though.

[oroqen]

nMaxSieveSize = 1000000u  ~130 - 230 pps
nMaxSieveSize = 100000u    ~230 - 400 pps
nMaxSieveSize = 10000u      ~ 350 - 800 pps

Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. 

I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW...

Who knows what that actually does to the potential of finding a correct PoW though.

Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M

[mustyoshi]

nMaxSieveSize = 1000000u  ~130 - 230 pps
nMaxSieveSize = 100000u    ~230 - 400 pps
nMaxSieveSize = 10000u      ~ 350 - 800 pps

Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. 

I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW...

Who knows what that actually does to the potential of finding a correct PoW though.

Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M

There's an idea. Then run that setup for a day and figure out proportionally which sieve size resulted in the most correct PoWs.

[eule]

Who knows what that actually does to the potential of finding a correct PoW though.

Indeed, might go horribly wrong. But I didn't mine anything since 1800 blocks on that machine, nothing to lose.

Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M

Hmm, is it possible to run multiple instances of primecoind? Or how to assign different sieves to different threads, VMs?

[illpoet]

WTS Primecoin asic. 20,000 primespersec for just 1 watt of electricity.  10,000 btc.  will ship sometime soon, i promise. 

wait, too soon?

[mpr20rt]

Left my somewhat optimized version running over night and came back to 3 additional blocks mined.
Getting roughly ~60 pps with 500K sieve size and basic optimization flags. Running on a single thread of a stock i3 2120.

Dude. Post it. Keeping optimized miners secret is a bad move for your rep and the coin. Don't make me get my own optimized one to post.

Other than the sieve size change. I also opted to pass the blockheader hash through the functions, instead of making calls to block->GetHeaderHash() every time. I'm not sure what kind of improvements that actually made since I also changed the sieve size when I first did it.

But it stops me from running double SHA256 like 3 times more than I used to.

could you please post the codelines you've changed?

cheers!

[E.Sam]

My first solo mined coin

Was starring at screen, wondering if anything would actually happen... and 18.77 XPM just appeared :]

Took me 6:30 hours on a iMac 3.4GH i7

Wow, that's a long time to be staring at the screen but whatever helps...    


-tb-

Was worth the excitement  :]

[bidji29]

Any hope of a gpu version?

At least with my current (still incomplete) comprehension of the algorithm, it requires a bignum library.
With this in mind, I don't plan to do a GPU port on my spare time.
Maybe later, after CPU is working, if someone is willing to sponsor the development time.

LukeJr, do you have any hints for people getting started on where to look or what to look for?  Are you running Linux?

Well, the most obvious one was hashing the block header once per nonce instead of 1-3x...
I think the rest of my optimizations required actually comprehending the code

Any idea how to "hashing the block header once per nonce instead of 1-3x..."

[paulthetafy]

Is it possible to have multiple primecoind instances on different machines use a single wallet?  I thought that this could be achieved by using connect=<ip of server> for all of the slave primecoind instances, is that right?

[ReCat]

WTS Primecoin asic. 20,000 primespersec for just 1 watt of electricity.  10,000 btc.  will ship sometime soon, i promise.  

wait, too soon?

You forgot to say that you're BFL.

[nmersulypnem]

nMaxSieveSize = 1000000u  ~130 - 230 pps
nMaxSieveSize = 100000u    ~230 - 400 pps
nMaxSieveSize = 10000u      ~ 350 - 800 pps

Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. 

I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW...

Who knows what that actually does to the potential of finding a correct PoW though.

Is there only one correct PoW?  How does the program choose where to start looking in the range?  Is it random?

[eule]

Any idea how to "hashing the block header once per nonce instead of 1-3x..."

https://bitcointalk.org/index.php?topic=251850.msg2689718#msg2689718
A bit cryptic and above my skills (yet ^^), but someone more bright than me might know what to do.

edit: Awesomeness below! 

[mustyoshi]

could you please post the codelines you've changed?

cheers!

My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh.
But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area.

Code:

main.cpp
4610:  uint256 phash = pblock->GetHeaderHash();

4611 - 4614:         while ((phash < hashBlockHeaderLimit || CBigNum(phash) % bnHashFactor != 0) && pblock->nNonce < 0xffff0000){
            pblock->nNonce++;
            phash = pblock->GetHeaderHash();
        }

4644: CBigNum bnMultiplierMin = bnPrimeMin * bnHashFactor / CBigNum(phash) + 1;
4655: if (MineProbablePrimeChain(*pblock, bnFixedMultiplier, fNewBlock, nTriedMultiplier, nProbableChainLength, nTests, nPrimesHit,phash))

prime.h
10: static const unsigned int nMaxSieveSize = 500000u;
60: bool MineProbablePrimeChain(CBlock& block, CBigNum& bnFixedMultiplier, bool& fNewBlock, unsigned int& nTriedMultiplier, unsigned int& nProbableChainLength, unsigned int& nTests, unsigned int& nPrimesHit,uint256& headerhash);

prime.cpp
342: bool MineProbablePrimeChain(CBlock& block, CBigNum& bnFixedMultiplier, bool& fNewBlock, unsigned int& nTriedMultiplier, unsigned int& nProbableChainLength, unsigned int& nTests, unsigned int& nPrimesHit,uint256& headerhash)

360: psieve.reset(new CSieveOfEratosthenes(nMaxSieveSize, block.nBits, headerhash, bnFixedMultiplier));
380: bnChainOrigin = CBigNum(headerhash) * bnFixedMultiplier * nTriedMultiplier;

[grc]

could you please post the codelines you've changed?

cheers!

My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh.
But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area.
...

If you're changing the max sieve size, I think you can also change the vector sizes on lines 102-104.

[PSL]

Do you know diff utility? Could you try to create a patch?

Code:

$ diff -u main.cpp main.cpp.new

[nmersulypnem]

could you please post the codelines you've changed?

cheers!

My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh.
But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area.
...

If you're changing the max sieve size, I think you can also change the vector sizes on lines 102-104.

....but what's the point?  You're obviously just proportionately reducing the chance of finding something...

[mustyoshi]

could you please post the codelines you've changed?

cheers!

My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh.
But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area.
...

If you're changing the max sieve size, I think you can also change the vector sizes on lines 102-104.

....but what's the point?  You're obviously just proportionately reducing the chance of finding something...

I believe people are having trouble running this on multi-core machines because of cache issues, reducing the amount of memory that goes into each thread might improve the issue? I don't have a 32 core machine to test on though.

I just linked those vectors to my nMaxSieveSize, we'll see if it offers any improvement.

[akspa]

Now we wait for an improved miner to be created. This is quite fun to watch and be a part of. My question now is how quickly the difficulty will go up, even if we're all on cpu miners for the foreseeable future?

[maka]

Maybe the improvement should be tested with shorter chains on the testnet first.  Or it takes days or probably weeks to show its effects...