Try the latest client if you are not already using it, I think is version 0.8.7.

We will be looking forward to using your pool server. Hopefully it is open source so that we can easily add jh00's implementation of XPT (x.pushthrough) protocol and a tamper resistant developer's fee feature to it.

Wow, RIC mining would have paid off two of my research servers trading @ 0.002 BTC/RIC. I do not pay attention to the market but perhaps it is time to.

@gatra: Any estimate on when your pool server code will be ready for testing? Also, for your GPU implementation, will you be targeting AMD or Nvidia GPUs?

Apparently setting up a pool for Rie is extremely difficult.

Also I wish the developer was more active here

so that is why I decided to just sell and move on.

Right on excellent. I'm going to add you and surfer43 to the list then. The bracketed area is more about who we have that is capable of doing certain tasks and is willing. So if someone else comes along and wants to help or ask questions they know who to talk to. Even if you can't do everything needed, you're available to let people know what you can contribute and what is still needed.

def isPrime( n ):
    if pow( 2, n-1, n ) == 1:
        return True
    return False

def riecoinPoW( hash_bin, diff, nNonce ):
    base = 1 << 8
    for i in range(256):
        base = base << 1
        base = base | (hash_bin & 1)
        hash_bin = hash_bin >> 1
    trailingZeros = diff - 1 - 8 - 256
    if trailingZeros < 16 or trailingZeros > 20000:
        return 0
    base = base << trailingZeros
    
    base += nNonce
    primes = 0
    
    if (base % 210) != 97:
        return 0
    
    if not isPrime( base ):
        return primes
    primes = 1
    
    base += 4
    if isPrime( base ):
        primes+=1
    
    base += 2
    if isPrime( base ):
        primes+=1
    
    base += 4
    if isPrime( base ):
        primes+=1
    
    base += 2
    if isPrime( base ):
        primes+=1
    
    base += 4
    if isPrime( base ):
        primes+=1
      
    return primes

This is not correct. At diff=9.9, all 10-chains found are counted as blocks. So a 10.x is always more difficult than a 9.x diff.

By the way diff a.x is more difficult than a.y f x>y, for any a as expected.

Summary:

- Primecoin uses the Fermat primality test, which has some flaws.
-  Primecoin numbers are not guarranteed to be prime
- A centralized checkpoint system is implemented inside Primecoin.
- Riecoin is capped to a fixed amount of coins (84M), but Primecoin has no limit.
- With Primecoin it impossible to estimate how secure the network is.

I see 0.8.7 on sourceforge but not on github?

Gatra, can you confirm that you are the same gatra that is authoring at https://github.com/riecoin/riecoin.git

Please update github if possible. Thanks.

What is the URL for the site that displays the supply?

Riecoin needs a static site that displays total supply first. This will come when a block explorer comes on, which I and another user are still working on

But you will then pay a hefty penalty in mining performance for checking all six candidates instead of an early abort strategy when checking a chain of four candidates. Modular exponentiation is a very expensive operation for the size of numbers that we are dealing with.

BTER

Please add Riecoin.
Probably the most exciting coin we've seen. I believe this coin will be the underdog of the year. It was lost in the Maxcoin hype as it launched a few days after. Very unique coin!
Riecoin.org

Much thanks!

Thinking about the pooling issue a bit more, I have a suggestion for how to refine it:

A key danger already identified by the Riecoin creators in using 4-chains as the PoW for pooled mining is the possibility of creating a miner tailored to finding 4 chains.

This isn't theoretical - I've played with a proof-of-concept, and it's both easy and gives a share advantage over a "correct" miner.  I've also run into it on the other side, where by too-aggressively screening out all six candidates, I created mining code that almost never generated a pool share unless it also found a block.  

I don't think it's possible to avoid all bias in this, but a few possibilities make it easier to make a more-correct pooled miner.  The first suggestion also has the advantage of providing a form of variable-difficulty pooled mining that is independently controllable from the Riecoin difficulty itself:

(a)  Minimum divisor requirement for *all* numbers:

   Accept PoW only if:
    (a)  The first four numbers are (MR) prime; and
    (b)  None of the six numbers has a divisor <= N for N=some reasonable size prime.

As an example, the optimized miner jh00 released sieves all six possibilities up to 50,000  (https://github.com/jh000/xptMiner/blob/master/xptMiner/riecoinMiner.cpp ).  A minimum PoW of 50,000 would then exclude any share that has more of a bias towards four-chains than the default ypool miner.

(b)  Generator polynomial matches only

The pattern of primes chosen for Riecoin (p, p+4, p+6, p+10, p+12, p+16) can only occur at certain values.  The simplest polynomial for these is n*210 + 7 and n*210 + 97.  Any miner searching at locations *other* than these is clearly doing something weird, because no valid 6-chain can occur at other locations.  Any non-matching share should be rejected.

  -Dave

Thinking about the pooling issue a bit more, I have a suggestion for how to refine it:

A key danger already identified by the Riecoin creators in using 4-chains as the PoW for pooled mining is the possibility of creating a miner tailored to finding 4 chains.

This isn't theoretical - I've played with a proof-of-concept, and it's both easy and gives a share advantage over a "correct" miner.  I've also run into it on the other side, where by too-aggressively screening out all six candidates, I created mining code that almost never generated a pool share unless it also found a block.  

I don't think it's possible to avoid all bias in this, but a few possibilities make it easier to make a more-correct pooled miner.  The first suggestion also has the advantage of providing a form of variable-difficulty pooled mining that is independently controllable from the Riecoin difficulty itself:

(a)  Minimum divisor requirement for *all* numbers:

   Accept PoW only if:
    (a)  The first four numbers are (MR) prime; and
    (b)  None of the six numbers has a divisor <= N for N=some reasonable size prime.

As an example, the optimized miner jh00 released sieves all six possibilities up to 50,000  (https://github.com/jh000/xptMiner/blob/master/xptMiner/riecoinMiner.cpp ).  A minimum PoW of 50,000 would then exclude any share that has more of a bias towards four-chains than the default ypool miner.

(b)  Generator polynomial matches only

The pattern of primes chosen for Riecoin (p, p+4, p+6, p+10, p+12, p+16) can only occur at certain values.  The simplest polynomial for these is n*210 + 7 and n*210 + 97.  Any miner searching at locations *other* than these is clearly doing something weird, because no valid 6-chain can occur at other locations.  Any non-matching share should be rejected.

  -Dave

If you're going that route also - have you modified the rminerd in a clean way to handle 256 bit nonce results coming from the scan function?

This would be a great patch to get gatra to accept for the reference implementation.  My own hack is just a silly quick fix, or I'd submit it.  It's a core function needed for a lot of the ways to build a very fast scanner.  I'd be delighted to share some of the work of improving the infrastructure for all of us poking at faster miners.

  -Dave