[ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record

[dga]

wtf the ypool shares per second just doubled to 20 

yeah... I think many people (including me) pointed their rigs back to ypool after solomining while they had troubles...

Is it even feasible to solo mine right now?

The whales can.   Someone's mined some blocks using my solo miner, and it's pretty clear from the ypool block logs that others are solomining also.

There's an interesting exercise in looking at the offsets in the block log, btw - it can tell you a lot about the miners that are in use.

I mined 11 blocks yesterday with 10 Dell R620 servers (2 x Intel E5-2697 v2's each), can you tell which ones are mine? 

As a smaller subset to reduce copy/paste size in the message, yours are among this set for the 12800-13000 blocks:

12803     "nOffset" : "d5a1ebe253189505c4e30fa821352496ac07a2d8c390e09ec02fb4a886603ff3",
12814     "nOffset" : "af26f5e1ef40f66e4c22daf3b5401c5d3061f9644b9063f79bdd296ba1cbc771",
12894     "nOffset" : "a93eeb35b6f16230890569786c8d54d81af197f4058870ca730581ec4121ec5b",
12927     "nOffset" : "f5c103d9133388bacc0cbf0716ff22490879f1b93882dfc1c765f4da65ea723d",
12961     "nOffset" : "7bd1fef8febc067f30bb3ea09619f402f84b7cfe6d76bec97a0335bd6aacc009",
12963     "nOffset" : "5383a9ad7313f65a6981e9e80d6a874e90dad31f35044c224423e8dc77375e39",
12968     "nOffset" : "2ebe04d88d659ee0994aa61c15892e2d348d56aed43cf57d127cf5e5afb88b21",
12969     "nOffset" : "27f8f4155a2f33b82c96401330a44eb60e3ef46af5a59235d799159c87b26a33",

I haven't actually computed the likely primorial for each of these - just going by offset size, so it's possible someone else's miner is mixed in there.

These are probably Firkraag's, using a larger primorial but still in the jh framework:

12805     "nOffset" : "000001bdfbfccd8ef2d06d65b78b3073264c25ce8a7631e8288641262451924d",

and these are n*2310+97 miners - all default jh variants, including mine:

12808     "nOffset" : "000000000000000000000000000000000000000000000000000000000c934a4d",

[1714876104]

1714876104

[1714876104]

1714876104

[1714876104]

1714876104

[Supercomputing]

Here are a few:

2014-03-03 23:30:43 proof-of-work found
  hash: 7d6cd3886a084ccf59cc78a1f86cc070b02e112bb7cedeac9fb53d01191c1536
  diff compacted: 0204d000 nOffset: 00000000000000000000000000000212b178e655fbcc7bf075ccb80da83271e3

2014-03-03 23:48:03 proof-of-work found
  hash: 0bfbe3f8a2d95f362f97ca5ac6efecb3588019447397286fea8661b78803a9b5
  diff compacted: 0204d000 nOffset: 000000000000000000000000000002123c028c70c0a9519132cbea47d6bc9497

2014-03-04 00:12:37 proof-of-work found
  hash: 67f315a8a9a7f26b2c4ef80dcf870caaac1e721686c1734d54fbff476598b4c3
  diff compacted: 0204d000 nOffset: 0000000000000000000000000000006a361ddbafd6c5ef3812fc7e6508b5ea0f

[Supercomputing]

I mined 11 blocks yesterday with 10 Dell R620 servers (2 x Intel E5-2697 v2's each), can you tell which ones are mine?  

As a smaller subset to reduce copy/paste size in the message, yours are among this set for the 12800-13000 blocks:

12803     "nOffset" : "d5a1ebe253189505c4e30fa821352496ac07a2d8c390e09ec02fb4a886603ff3",
12814     "nOffset" : "af26f5e1ef40f66e4c22daf3b5401c5d3061f9644b9063f79bdd296ba1cbc771",
12894     "nOffset" : "a93eeb35b6f16230890569786c8d54d81af197f4058870ca730581ec4121ec5b",
12927     "nOffset" : "f5c103d9133388bacc0cbf0716ff22490879f1b93882dfc1c765f4da65ea723d",
12961     "nOffset" : "7bd1fef8febc067f30bb3ea09619f402f84b7cfe6d76bec97a0335bd6aacc009",
12963     "nOffset" : "5383a9ad7313f65a6981e9e80d6a874e90dad31f35044c224423e8dc77375e39",
12968     "nOffset" : "2ebe04d88d659ee0994aa61c15892e2d348d56aed43cf57d127cf5e5afb88b21",
12969     "nOffset" : "27f8f4155a2f33b82c96401330a44eb60e3ef46af5a59235d799159c87b26a33",

I haven't actually computed the likely primorial for each of these - just going by offset size, so it's possible someone else's miner is mixed in there.

These are probably Firkraag's, using a larger primorial but still in the jh framework:

12805     "nOffset" : "000001bdfbfccd8ef2d06d65b78b3073264c25ce8a7631e8288641262451924d",

and these are n*2310+97 miners - all default jh variants, including mine:

12808     "nOffset" : "000000000000000000000000000000000000000000000000000000000c934a4d",

Yup, those are mine

[dga]

Here are a few:

2014-03-03 23:30:43 proof-of-work found
  hash: 7d6cd3886a084ccf59cc78a1f86cc070b02e112bb7cedeac9fb53d01191c1536
  diff compacted: 0204d000 nOffset: 00000000000000000000000000000212b178e655fbcc7bf075ccb80da83271e3

2014-03-03 23:48:03 proof-of-work found
  hash: 0bfbe3f8a2d95f362f97ca5ac6efecb3588019447397286fea8661b78803a9b5
  diff compacted: 0204d000 nOffset: 000000000000000000000000000002123c028c70c0a9519132cbea47d6bc9497

2014-03-04 00:12:37 proof-of-work found
  hash: 67f315a8a9a7f26b2c4ef80dcf870caaac1e721686c1734d54fbff476598b4c3
  diff compacted: 0204d000 nOffset: 0000000000000000000000000000006a361ddbafd6c5ef3812fc7e6508b5ea0f

Block 13747 - I see you're working on the ypool miner version of your core, also. :-)

[steban]

Could some one please make a technical analysis of how Riecoin is an improvement over Primecoin or otherwise.

[deadthings]

Could some one please make a technical analysis of how Riecoin is an improvement over Primecoin or otherwise.

Sure, here you go:

Riecoin ≠ Primecoin

 

[steban]

Could some one please make a technical analysis of how Riecoin is an improvement over Primecoin or otherwise.

Sure, here you go:

Riecoin ≠ Primecoin

 

care to elaborate! 

[Percy520]

Could some one please make a technical analysis of how Riecoin is an improvement over Primecoin or otherwise.

Sure, here you go:

Riecoin ≠ Primecoin

 

Which one is better and reasons?? I knew Sunny Kind is an amazing talent.

[steban]

http://riecoin.org/: ..

How is Riecoin different from Primecoin?
Primecoin is good and I'm not against it, but since its PoW might at first glance look similar to Riecoin's, I feel the need to differentiate from it. Here I go:

Primecoin uses the Fermat primality test, which has some flaws. Carmichael numbers are not prime and still pass Fermat's test for all bases, however those are relatively rare. Secondly, in general, if Fermat's test says a number is prime, it has at least a 50% probability of being prime. Primecoin uses only one Fermat test with base 2. While base 2 may provide more confidence than the general bound of 50%, still many composites will pass as primes. What's worst, is that Euler-Lagrange-Lifchitz test used for the other primes in the chain assumes the previous number in the chain is prime. So if the chain starts with a number that is not prime, then the Euler-Lagrange-Lifchitz test is not guaranteed to work, and all numbers in the chain may be composite.

short version: Primecoin numbers are not guarranteed to be prime, they may be Fermat pseudoprimes to the base 2. There is an infinite list of Fermat pseudoprimes to the base 2 (oeis.org/A001567). Riecoin uses enough Rabin-Miller tests with random bases, so the probability of a number that is not prime being accepted by the majority of the Riecoin network is negligible.

We propose the n/s "range explored (numbers) per second" metric instead of pps (primes per second) or shorter-chains per second. This is the quantity of numbers tested (whether by sieve of explicit primality test) and discarded as not constituting a valid PoW per second. While it is still difficult to compare this number for different difficulties, it is a much better metric: it can be used to meaningfully compare different algorithms, hardware speed, etc as long as you have the same diff. More n/s always means more blocks. For example a mining rig would be advertised as having X n/s@minimum diff. Something similar like "multipliers per second" might be possible for Primecoin, but it wouldn't scale as well when difficulty grows. In Primecoin, PPS is "just for fun" and shorter chains per second may not be accurate to compare the performance of algorithms for full-length chains per second.
Assuming the Riemann Hypothesis and the Hardy-Littlewood k-tuple conjectures are true, by using Hardy-Littlewood constants a miner can estimate the average time before a block is found, allowing profit calculations and to estimate the computing power of the network.
In Primecoin there is no practical way of estimating the time before finding a block, moreover difficulty 10.1 is easier than 9.9 making it impossible to estimate how secure the network is.
A centralized checkpoint system is implemented inside Primecoin. While it is disabled by default, if FUD about attacks start to spread, I believe some people will panic and enable it. A centralized checkpoint allows its controllers to perform double spends without any need for any % of hash rate. Can we be sure it will not be hacked and/or abused?
Riecoin is capped to a fixed amount of coins (84M), but Primecoin has no limit. While it is arguable, we believe our deflationary model - similar to Bitcoin's - is better.
1min block speed would bloat the blockchain and create more orphans, stales. We have 2.5min which was tested for years in LTC. I don't know of any 1min coin that has years of testing. I think it's not true that 1min is fast enough for waiting in a line when you buy a coffee: with blocks targeted each minute, you have a 1 in 150 chance of having to wait more than 5 minutes for a block, this would still be unacceptable for some coffee stores. Also, with 2.5 each block requires more work, meaning we will have larger prime numbers sooner.


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.

[gatra]

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.

It looks like the flaws of Fermat's test a are more rare than I thought, but they are still there. If you wanted cryptographically secure primes, the Rabin-Miller tests done by Riecoin are overwhelmingly more than enough (according to NIST standards) while Fermat's test isn't.

Also:
- Most importantly: cunningham chains != prime constellations
- We are testing Hardy-Littlewood k-tuples conjecture for k=6. And it's not even known if prime sextuplets are infinite. I find this more interesting than Primecoin's scientific value.
- Primecoin's primes are limited to a maximum size while Riecoin's aren't. This may imply Primecoin's verification is faster but more ASIC friendly.


As for which one is better, I'll let you decide. Primecoin still has 30x Riecoin's market cap.
Of course I like mine and I'll defend it
Hopefully, open source pool software will be a great advantage that will spawn many pools. Will post news soon.

[Supercomputing]

Here are a few:

2014-03-03 23:30:43 proof-of-work found
  hash: 7d6cd3886a084ccf59cc78a1f86cc070b02e112bb7cedeac9fb53d01191c1536
  diff compacted: 0204d000 nOffset: 00000000000000000000000000000212b178e655fbcc7bf075ccb80da83271e3

2014-03-03 23:48:03 proof-of-work found
  hash: 0bfbe3f8a2d95f362f97ca5ac6efecb3588019447397286fea8661b78803a9b5
  diff compacted: 0204d000 nOffset: 000000000000000000000000000002123c028c70c0a9519132cbea47d6bc9497

2014-03-04 00:12:37 proof-of-work found
  hash: 67f315a8a9a7f26b2c4ef80dcf870caaac1e721686c1734d54fbff476598b4c3
  diff compacted: 0204d000 nOffset: 0000000000000000000000000000006a361ddbafd6c5ef3812fc7e6508b5ea0f

Block 13747 - I see you're working on the ypool miner version of your core, also. :-)

YPOOL provides a great service to the mining community and I am now using it to test the theory of sieving for 4-chain shares versus sieving for 6-chain blocks. So far, I have not seen any noticeable difference in the number of shares submitted. The overhead of sieving for valid 4-chain shares seems to eliminate its performance advantages.

The only thing that concerns me about YPOOL is that too many of my solo mined blocks are orphaned for no apparent reason. The block below was mined about two minutes in advance before YPOOL orphaned it. As much as I enjoy using YPOOL, competing pools and exchanges are a must in order for this coin to survive.

2014-03-05 04:02:48 proof-of-work found
  hash: 9f448dc2206d2caa248ecb941d407446985d2b1d9e4dffdcfdd186b8b332c1bb
  diff compacted: 0204bb00 nOffset: 000000000000000000000000000000cfff7339e156caed0932a0a9deac5ca1db

[steban]

will it be possible to have a miner that already includes the ypool function in it?

[remistevens]

- Primecoin's primes are limited to a maximum size while Riecoin's aren't.

Wow, didn't know this. Cool.

[glongsword]

http://riecoin.org/: ..

In Primecoin there is no practical way of estimating the time before finding a block, moreover difficulty 10.1 is easier than 9.9 making it impossible to estimate how secure the network is.
A centralized checkpoint system is implemented inside Primecoin. While it is disabled by default, if FUD about attacks start to spread, I believe some people will panic and enable it. A centralized checkpoint allows its controllers to perform double spends without any need for any % of hash rate. Can we be sure it will not be hacked and/or abused?
Riecoin is capped to a fixed amount of coins (84M), but Primecoin has no limit. While it is arguable, we believe our deflationary model - similar to Bitcoin's - is better.
1min block speed would bloat the blockchain and create more orphans, stales. We have 2.5min which was tested for years in LTC. I don't know of any 1min coin that has years of testing. I think it's not true that 1min is fast enough for waiting in a line when you buy a coffee: with blocks targeted each minute, you have a 1 in 150 chance of having to wait more than 5 minutes for a block, this would still be unacceptable for some coffee stores. Also, with 2.5 each block requires more work, meaning we will have larger prime numbers sooner.

A couple of questions:

Since Primecoin is able to keep the block times at ~1 minute, clearly empirical estimations work (though with a delay of a few minutes, but that doesn't matter, does it?) for determining how secure the network is, and how long the block time will be, no?

If the block time were 1 minute, wouldn't the same amount of work be done in 2.5 minutes, just with the potential of 2.5 blocks being found instead of one?  Doesn't the amount of work being done strictly depend on the hashrate, not the difficulty?  I.e., maybe the solutions accepted for 3/5 blocks are simpler than would be accepted for the 2.5min case, but shouldn't the other 2 solutions should be just as difficult as if the block time were 2.5x more (on average)?  I have no experience making a miner or looking miner code, so I am just guessing based on how I think miners work.  Anyway if this is true, Primecoin would win for this point since it's hashrate is surely higher than Riecoin's.

Thanks for your answers!

Edit:

Also, Gatra claims Riecoin can find large primes, but in the verification section of the whitepaper for Primecoin (http://primecoin.org/static/primecoin-paper.pdf), Sunny King claims Primecoin can't find large numbers because it would be hard to verify the Proof-of-work.  It doesn't go into any detail.  Is he wrong, is there a reason this won't apply to Riecoin, or will this eventually become a problem?

[Supercomputing]

I can now say with absolute certainty, that if I had my current solo miner implementation on launch day, I would have solved the first 576 blocks in under 15 minutes using only 20 Intel E5-2697 v2 CPUs 

Was the launch really all that fair? I guess we will never know.

[bsunau7]

 - Generate up to a certain size polynomial.  I use 200560490130 or the next as my base primorial and store a vector of all 48923875 entries.
 - Sieve *this* out up to the huge primorial in advance.
 - Do your operations relative to the huge primorial.

But, as warned - the simple bitvector is still working better for me.

Cool, that is what I am going but looking at your numbers I also pre sieve the possible p6 chains reducing my candidate count by ~128 times:
const uint64_t  primorial = 7420738134810;
const uint32_t  sexcount = 14 243 984;

Then I run a second scan inline to catch the next 2 dozen or so primes (lets me avoid gmp and use simple 64bit math) before I hit the expensive code.  General idea was to get a list of candidates which could be feed into something else (GPU was the thought).

It is much faster than reference but it is reaching the limit of how fast I can push it.

I have probably made a horrendous error in my algorithm... but coding again was fun...

Regards,

My implementation is a little different from both implementations mentioned above. If fact, the overhead is much less than that of jh00's implementation. My implementation is almost identical to Kim Walisch's primesieve implementation with a few minor exceptions.

Please see Kim Walisch's description of wheel factorization if you would like to know exactly what I am doing:
http://primesieve.org/

@bsunau7 - mine does the same.  I kill any location that fails to produce a six-set.  I wonder which of us has a bug?  *grin*  I'll check my sieving code again.  As one way to start comparing, the polynomials for the first few primorials are:

Generator at Pn7 (210)
97  

Generator at Pn11 (2310)
97  937  1147  1357  2197  

Generator at Pn13 (30030)
97  1357  2407  3457  4717  5557  5767  6817  7867  8077  8287  10177  10597  11647  12907  13747  13957  15007  16057  16267  17107  18367  19417  19837  21727  21937  22147  23197  24247  24457  25297  26557  27607  28657  29917  

@Supercomputing - Did you figure out a way to combine wheel factorization with storing a dense bitvector div 2310 (or div 210)?  Or do you just allow a large bitvector and handle it through segmentation?  I liked the way the jh implementation saved a lot of sieve space that way, and a straightforward prime sieve achieves a less dense packing (3-4x).

Money on me being at fault, to save memory (make it fit!) I merge two smaller sieves... I'm working on an alternate method to validate, I suspect my error only exists in numbers later than 10million.  For referecne my first few numbers:

Code:

$ od -t u8 sextuplet.bin | head
0000000                    1                    7
0000020                   97                 1357
0000040                 3457                 4717
0000060                 5767                 8077
0000100                10597                12907
0000120                19417                23197
0000140                29917                30127
0000160                32947                34417
0000200                35797                36847
0000220                37897                38107

A quick spot check picking 10177 as an example...  10177 is prime, (10177+6) is not prime (divisible by 17) so it shouldn't be a valid sextuplet.

Regards,

--
bsunau7

[GordonSSS]

Is your miner publicly available?

I can now say with absolute certainty, that if I had my current solo miner implementation on launch day, I would have solved the first 576 blocks in under 15 minutes using only 20 Intel E5-2697 v2 CPUs 

Was the launch really all that fair? I guess we will never know.

[surfer43]

I can now say with absolute certainty, that if I had my current solo miner implementation on launch day, I would have solved the first 576 blocks in under 15 minutes using only 20 Intel E5-2697 v2 CPUs 

Was the launch really all that fair? I guess we will never know.

https://bitcointalk.org/index.php?action=trust;u=151513
Ignore this FUD 

[bsunau7]

Money on me being at fault, to save memory (make it fit!) I merge two smaller sieves...
--
bsunau7

Well at least I won my money back! (my sieve was in error).

But I can't thank you all enough for the round about way this has helped me.

Thanks!

--
bsunau7

[mhps]

http://riecoin.org/: ..

In Primecoin there is no practical way of estimating the time before finding a block, moreover difficulty 10.1 is easier than 9.9 making it impossible to estimate how secure the network is.

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.