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

[gatra]

I believe you guys are making your estimates based on an old world record.
The 1857 difficulty corresponds to a 559 digits 6-tuplet found in 2009. The present record, according to Tony Forbes, is 593 digits or a difficulty of about 1970. The record 6-tuplet is

219946485329 * 1399# / 2 + d, d = −8, −4, −2, 2, 4, 8, found by Serge Batalov in December 2013.

Tony Forbes' k-tuplet page may be found here:

http://anthony.d.forbes.googlepages.com/ktuplets.htm

But as (1973/1441)^9 = 16.9 using gatra's estimates, we should be able to beat the record with an extra digit within an hour or so. The Primecoin lot have broken quite a few world records, it would be nice if we could get some too.

F*ck! ^$&$^%$&%$&%$^@#$%^! 


thanks vidarn for noticing
so we would have 1 hour blocks once per week.... let's wipe that list!

[Ellieo]

I believe you guys are making your estimates based on an old world record.
The 1857 difficulty corresponds to a 559 digits 6-tuplet found in 2009. The present record, according to Tony Forbes, is 593 digits or a difficulty of about 1970. The record 6-tuplet is

219946485329 * 1399# / 2 + d, d = −8, −4, −2, 2, 4, 8, found by Serge Batalov in December 2013.

Tony Forbes' k-tuplet page may be found here:

http://anthony.d.forbes.googlepages.com/ktuplets.htm

But as (1973/1441)^9 = 16.9 using gatra's estimates, we should be able to beat the record with an extra digit within an hour or so. The Primecoin lot have broken quite a few world records, it would be nice if we could get some too.

Too bad the Tony Forbes' K-tuplet page didn't indicate the amount of time required for making the world record. Having a world record in record time is totally a different league.

[bsunau7]

The Primecoin lot have broken quite a few world records, it would be nice if we could get some too.

The difficulty on the primecoin network has been stuck at 10.95-10.98 (give or take) for months.  It only seems to be increasing in response to miner efficiency.

I doubt they will be seeing any new records for a while.

Regards,

--
bsunau7

[fairglu]

If it's not poloniex nor mintpal my guess is that it's btc38, but how could we really know?

We probably need some chinese guy to confirm. The btc38 website is basically unresponsive and timing out from here, I couldn't even run automated translation on it because I could even see complete pages :/

Meanwhile, the cold wallet of btc38 riecoin is public as RUrTHyyKiPr1SkAraTHvSY9d3vsdQHBjca, which has 3487644.
Therefore, we know that more than 50% of Riecoins are sitting in btc38.

Great to know! do you have some official link/url about it?

RUrTHyyKiPr1SkAraTHvSY9d3vsdQHBjca has only 550k however, and so far isn't related by taint to the large exchange wallet (https://chainz.cryptoid.info/ric/wallet.dws?87250.htm), where does that 3487644 figure comes from?

[vidarn]

The difficulty on the primecoin network has been stuck at 10.95-10.98 (give or take) for months.  It only seems to be increasing in response to miner efficiency.

I doubt they will be seeing any new records for a while.

Unlike Riecoin, Primecoin makes it possible to submit POW well above the current difficulty. The present Primecoin record is a 2nd kind Cunningham chain of length 14 from May this year (when the difficulty was 10.96)

http://primecoin.io/index.php
http://primerecords.dk/Cunningham_Chain_records.htm

[gatra]

The difficulty on the primecoin network has been stuck at 10.95-10.98 (give or take) for months.  It only seems to be increasing in response to miner efficiency.

I doubt they will be seeing any new records for a while.

Unlike Riecoin, Primecoin makes it possible to submit POW well above the current difficulty. The present Primecoin record is a 2nd kind Cunningham chain of length 14 from May this year (when the difficulty was 10.96)

http://primecoin.io/index.php
http://primerecords.dk/Cunningham_Chain_records.htm

That's true: there is the possibility that, by chance, a primecoin POW will be a chain of greater length than what's specified by the difficulty. However this happens "by luck", and since they are limited on the size of their primes, I agree with bsunau7 that they won't be seeing much new records for a while.

On the other hand, Riecoin cannot find sextuplets above difficulty (as you said)... BUT, analogous to what you decribed with primecoin, RIC can find sextuplets that are also part of septuplets or octuplets. The records for septuplets are much lower than those of sextuplets, so we may have broken some of those already! wow, I haven't realized this before... I'll have to make a script to test it, but with 120000 sextuplets there's a chance one of those is also a septuplet (and a world record breaking one)! the numbers are so large that the chance may be too small, but we have to test it...

[dga]

The difficulty on the primecoin network has been stuck at 10.95-10.98 (give or take) for months.  It only seems to be increasing in response to miner efficiency.

I doubt they will be seeing any new records for a while.

Unlike Riecoin, Primecoin makes it possible to submit POW well above the current difficulty. The present Primecoin record is a 2nd kind Cunningham chain of length 14 from May this year (when the difficulty was 10.96)

http://primecoin.io/index.php
http://primerecords.dk/Cunningham_Chain_records.htm

That's true: there is the possibility that, by chance, a primecoin POW will be a chain of greater length than what's specified by the difficulty. However this happens "by luck", and since they are limited on the size of their primes, I agree with bsunau7 that they won't be seeing much new records for a while.

On the other hand, Riecoin cannot find sextuplets above difficulty (as you said)... BUT, analogous to what you decribed with primecoin, RIC can find sextuplets that are also part of septuplets or octuplets. The records for septuplets are much lower than those of sextuplets, so we may have broken some of those already! wow, I haven't realized this before... I'll have to make a script to test it, but with 120000 sextuplets there's a chance one of those is also a septuplet (and a world record breaking one)! the numbers are so large that the chance may be too small, but we have to test it...

Am I crazy, or should we not expect to have a few tens of septuplets already?  Perhaps I'm mis-thinking the math -- 1/ln(2^1700) ~= 1/1200 chance of a sextuplet being a septuplet?

[gatra]

Am I crazy, or should we not expect to have a few tens of septuplets already?  Perhaps I'm mis-thinking the math -- 1/ln(2^1700) ~= 1/1200 chance of a sextuplet being a septuplet?

You're right, but looking at the admissible patterns for sextuplets vs septuplets:
0  4  6  10  12  16
vs
0  2  6  8  12  18  20
0  2  8  12  14  18  20

it doesn't fit...looks like we're screwed... we won't have septuplets with minimal distance (p ... p+20)
I didn't verify this, but the source is Anthony Forbes

same thing with octuplets:
0  2  6  8  12  18  20  26
0  2  6  12  14  20  24  26
0  6  8  14  18  20  24  26

[bsunau7]

Am I crazy, or should we not expect to have a few tens of septuplets already?  Perhaps I'm mis-thinking the math -- 1/ln(2^1700) ~= 1/1200 chance of a sextuplet being a septuplet?

You're right, but looking at the admissible patterns for sextuplets vs septuplets:
0  4  6  10  12  16
vs
0  2  6  8  12  18  20
0  2  8  12  14  18  20

it doesn't fit...looks like we're screwed... we won't have septuplets with minimal distance (p ... p+20)
I didn't verify this, but the source is Anthony Forbes

same thing with octuplets:
0  2  6  8  12  18  20  26
0  2  6  12  14  20  24  26
0  6  8  14  18  20  24  26

I spotted that as well, but it might not be as bad as you think (but not as easy as testing one extra prime).

If you take the first p7 variant and subtract 2 you get the pattern:

Code:

-2 0 4 6 10 16 18

Aside from "12" is a very good match for the 6-tuplet pattern (for the second p7 variant you ignore the "4").  In both cases you just need to test p-2 and p+18 for a valid p7 chain.  In effect a valid 6-tuplet means you know you have 5 out of 7 valid primes for the 7-tuplet.

A quick look at the others shows similar tricks to "re-use" valid 6-tuplets probably also exist.

Once again check my assumptions....

EDIT:  For the 7-tuplet, you can also subtract 4 and get another pretty good subset to use as the basis of a test.  Should also increase chance of finding a valid chain.

Regards,

--
bsunau7

[aamarket]

This is much nicer think to do - than the hard fork.
I had that idea before when checking Riecoin, here are the k-tuples

http://en.wikipedia.org/wiki/Prime_k-tuple

but did not have the time ...

if anybody has tips, how to parse ric blockchain for 6tuplets, it's ease to do.

Anybody ?

[zeus101]

Am I crazy, or should we not expect to have a few tens of septuplets already?  Perhaps I'm mis-thinking the math -- 1/ln(2^1700) ~= 1/1200 chance of a sextuplet being a septuplet?

You're right, but looking at the admissible patterns for sextuplets vs septuplets:
0  4  6  10  12  16
vs
0  2  6  8  12  18  20
0  2  8  12  14  18  20

it doesn't fit...looks like we're screwed... we won't have septuplets with minimal distance (p ... p+20)
I didn't verify this, but the source is Anthony Forbes

same thing with octuplets:
0  2  6  8  12  18  20  26
0  2  6  12  14  20  24  26
0  6  8  14  18  20  24  26

am in search of a hacker who can help me with malawares and viruses, willing to pay for the services rendered..thank you
my email is craigdomnic@gmail.com

I spotted that as well, but it might not be as bad as you think (but not as easy as testing one extra prime).

If you take the first p7 variant and subtract 2 you get the pattern:

Code:

-2 0 4 6 10 16 18

Aside from "12" is a very good match for the 6-tuplet pattern (for the second p7 variant you ignore the "4").  In both cases you just need to test p-2 and p+18 for a valid p7 chain.  In effect a valid 6-tuplet means you know you have 5 out of 7 valid primes for the 7-tuplet.

A quick look at the others shows similar tricks to "re-use" valid 6-tuplets probably also exist.

Once again check my assumptions....

EDIT:  For the 7-tuplet, you can also subtract 4 and get another pretty good subset to use as the basis of a test.  Should also increase chance of finding a valid chain.

Regards,

--
bsunau7

[bsunau7]

This is much nicer think to do - than the hard fork.
I had that idea before when checking Riecoin, here are the k-tuples

http://en.wikipedia.org/wiki/Prime_k-tuple

but did not have the time ...

if anybody has tips, how to parse ric blockchain for 6tuplets, it's ease to do.

Anybody ?

Quickest way is https://chainz.cryptoid.info/ric/ has the first 60k blocks p0 in a zip file.  fairglu might be willing to run this script to get a complete set...

Other wise it looks like and extract the transaction id (looks like custom code to process the block chain) and run "riecoind getprimes <txid>".  A perl DBM based script should also be able to do it, but I've not the time :-/

And yes, no hard fork would be nicer.

Regards,

--
bsunau7

[fairglu]

Quickest way is https://chainz.cryptoid.info/ric/ has the first 60k blocks p0 in a zip file.  fairglu might be willing to run this script to get a complete set...

No problem, I'll run the update and generate a complete zip (had not bothered since diff went down).

edit: updated the zip with the first 120k primes (p0), get it from https://chainz.cryptoid.info/ric/

[bsunau7]

No problem, I'll run the update and generate a complete zip (had not bothered since diff went down).

edit: updated the zip with the first 120k primes (p0), get it from https://chainz.cryptoid.info/ric/

Quick and dirty test didn't find any p0-2 primes, tested code by running the same test with p0-0 (i.e. p0) which 'found' most of them aside from some in the 60k block range...  There is an anomaly at block hight 61000-62000 where the limb size doubles, I suspect it might be the source file/gmp parsing but I've not investigated.

Code used (so people and extend/validate):

Code:

//bsunau7

#include <stdio.h>
#include <stdlib.h>
#include "gmp.h"

int     count,m2 = 0;
mpz_t   tmp,p0;

int test_minus2(mpz_t p) {
        mpz_sub_ui(tmp,p,2);

        if(mpz_millerrabin(tmp, 12)) {
                m2++;
                gmp_printf("p0 %#Zd\n",p);
        }
}

int main(int argc, char *argv[]) {
        FILE    *f;

        mpz_init(p0); mpz_init(tmp);

        f = fopen("Riecoin_Primes.txt","r");

        //while(EOF != gmp_fscanf(f,"%Zd\n",p0)) {
        while(mpz_inp_str(p0,f,10)) {
                test_minus2(p0);
                count++;

                if(count%1000 == 0) {
                        printf("count = %u minus-2's = %u limbs = %u\n",count,m2,p0->_mp_size);
                }
        }

        fclose(f);

        printf("count = %u minus-2's = %u\n",count,m2);
}

To compile & run:

Code:

pukcab% gcc -L /usr/local/lib -I /usr/local/include -O3 -o p7 p7.c -lgmp
pukcab% ./p7

No error checking (but a progress counter!!!!) just make sure that the file "Riecoin_Primes.txt" is in the same directory as you run it from.

Regards,

--
bsunau7

[bsunau7]

There is an anomaly at block hight 61000-62000 where the limb size doubles, I suspect it might be the source file/gmp parsing but I've not investigated.

fairglu, can you check the file?  The problem primes are twice as long as they should:

Code:

pukcab% head -60010 Riecoin_Primes.txt| tail -10 | wc
      10      10   10060
pukcab% head -70010 Riecoin_Primes.txt| tail -10 | wc
      10      10    4820
pukcab% head -50010 Riecoin_Primes.txt| tail -10 | wc
      10      10    5180
pukcab% 

The difficulty and the size of the prime for block 60010 don't match (https://chainz.cryptoid.info/ric/block.dws?60010.htm).  Also the p0 for block height 60010 does not match what the block chain says:

Code:

$ riecoind getprimes c128a2f6a3ebb5afa55cd3896959697059b8bd36a16b1e50e56b5fb1349230f7
{
    "p0" : "6583993995561192360346046251200206127224654587084325937668318951846051159452993920231623250817659319742419550076619488702317466896549240871168724940491399822598666002168585392207972987955918925506288180520886691254442379378219899029781268734901605154351243323483934758451516491217058653000969212415484447222824114991142710278105797334598372470805981538498172580073950216353959647551925237059810296823999141391673270944333694570238718103456560515918954735187487480245413428471638426754875981718775052397",

Regards,

--
bsunau7

[fairglu]

Quick and dirty test didn't find any p0-2 primes, tested code by running the same test with p0-0 (i.e. p0) which 'found' most of them aside from some in the 60k block range...  There is an anomaly at block hight 61000-62000 where the limb size doubles, I suspect it might be the source file/gmp parsing but I've not investigated.

It's probably a bug on my side, I changed the storage format around that, a range might have gotten corrupted. Let me check.

edit: yes, encoding bug, the values in that range are actually the hexadecimal ASCII values, f.i. 60001 says "36353836..." is actually "6586..."

edit2: fixed & updated zip, now with 122000 primes.

[gatra]

If you take the first p7 variant and subtract 2 you get the pattern:

Code:

-2 0 4 6 10 16 18

Aside from "12" is a very good match for the 6-tuplet pattern (for the second p7 variant you ignore the "4").  In both cases you just need to test p-2 and p+18 for a valid p7 chain.  In effect a valid 6-tuplet means you know you have 5 out of 7 valid primes for the 7-tuplet.

A quick look at the others shows similar tricks to "re-use" valid 6-tuplets probably also exist.

Once again check my assumptions....

I'm afraid that doesn't work. Imagine that you did find p-2 and p+18 prime. So you have a septuplet. But, you started from a sextuple so p+12 is also prime. This means that your septuple is also an octuple: it has 8 primes in the range p-2 to p+18. A difference of 20. But Athony Forbes tells us that the minimum distance possible for 8-tuples is 26, so the 8-tuple with distance 20 cannot exist. But we said it did... this absurd comes from assuming you could find p-2 and p+18 both prime.

The thing is that ignoring the 12 is cheating, you won't have this:

Code:

-2 0 4 6 10 16 18

but actually this:

Code:

-2 0 4 6 10 12 16 18

and that is not possible because there is a prime q, with q<20 where any of the p(i) will be a multiple of q.
edit: let me see which one it is.....
ok, it's 5. Let's add 2 again for simplicity, so we have:

Code:

0 2 6 8 12 14 18 20

now:
if p+0 has the form 5x then it's not prime
if p+0 has the form 5x+1 then p+14 is actually 5x+1+14 = 5x+15 = 5(x+3) then it's not prime
if p+0 has the form 5x+2 then p+8 is actually 5x+2+8= 5x+10 = 5(x+2) then it's not prime
if p+0 has the form 5x+3 then p+2 is actually 5x+5 = 5(x+1) then it's not prime
if p+0 has the form 5x+4 then p+6 is actually 5x+10 = 5(x+2) then it's not prime

so it's not possible to find primes with that pattern...

[gatra]

edit: yes, encoding bug, the values in that range are actually the hexadecimal ASCII values, f.i. 60001 says "36353836..." is actually "6586..."

edit2: fixed & updated zip, now with 122000 primes.

cool, thanks for the updated list!

[fairglu]

The thing is that ignoring the 12 is cheating, you won't have this:

Code:

-2 0 4 6 10 16 18

but actually this:

Code:

-2 0 4 6 10 12 16 18

Drats!

According to https://en.wikipedia.org/wiki/Prime_k-tuple the septuplet constellations

0, 2, 6, 8, 12, 18, 20

might sometimes be octuplet and nonuplets.

Would it be worth changing the PoW from sextuplets to "septuplets with a chance of meatballs octuplets and nonuplets" ?
Would the current computing power in Riecoin mining be enough for world records then ?

[gatra]

Would it be worth changing the PoW from sextuplets to "septuplets with a chance of meatballs octuplets and nonuplets" ?

might be, but this would not only be a hard fork: all the miners would have to be updated too.
if we only added the superblocks, those mining in a pool wouldn't be affected - only the pool server would have to update the riecoin client.
You are proposing a more aggresive move.

Would the current computing power in Riecoin mining be enough for world records then ?

We would need a difficulty of 1060 (in 7-tuples). Current computing power (1462 in 6-tuples) would translate to a difficulty of approx 705 for 7-tuples. So changing block time to 4 minutes (or having 4 mins superblocks) would do the trick. If we had 4 min blocks we would find a world record size 7-tuple every block and a record octuple once or twice a week. Some years for a nonuplet, but it would be one hell of a nonuplet, exceeding current record by orders of orders of magnitude.
edit: I'm tired, my math is shaky... it's not 4 minutes, it's 2 hours. Still doable with superblocks, but forget about finding nonuplets - or octuplets - this way.

If we were going to change the PoW in such way, we'd better make it accept alternatively 7-tuples, 8-tuples and 9-tuples each with different difficulties, so we could easily break all records every day.

I made a lame attempt at giving room for this kind of change in the future by adding a "primes" value hardcoded to 6 in the "getwork" and "getblocktemplate" calls, thinking that maybe in the future this could be variable. But the thing is that we would have to update all the mining software, and see which patterns we would look for, not only the number of primes. So we would have one block be 6, the next 7a, then 7b, 8a, 8b, 8c, whatever, then repeat.

edit: looks like for 25-tuples, there are 18 possible patterns all with diameter 110... I guess we wouldn't go that far