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.


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

cool, thanks for the updated list!

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:
but actually this:

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:
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...

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

+1
but careful, you may become wicked compost!
don't worry, I believe it's just the same as saint compost...

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...

I don't think Riecoin is mineable by GPU. I expect it to be sometime, but so far I'd say it isn't.

I think the cpu coin list here is fairly accurate: http://cpucoinlist.com/

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


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

I'm leaning towards a 30min block once a week. With current difficulty this would get us slightly above world record. If difficulty increases, the goal of the weekly superblock would increase too, going farther where no man has gone before.

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



I'd give a couple of weeks for everyone to update and use the built-in alert system to let everyone know.

I hate it that we still have one pool dominating, however it does make hard-forking easier and I'm thankful that it's ypool because it's behaving really well.

Sure! there's always math to be had when it comes to ric.
The assumption is that the difficulty raised to the ninth power is linear (6 because according to Hardy-Littlewood's k tuple conjecture the average space between 6 tuples is O(log^6 p), and 3 because testing for primality takes about O(log^3 p), so 6+3=9). This has been working nicely: the average time between blocks is about the expected 150 seconds, which means the assumption is working so far.

Current diff is 1441, but we want a block with 1857. So (1857/1441)^9 = 9.8 times harder. If we now have 2.5 minutes then 9.8 times harder would take 24.5 minutes (24.5 in average! it should be between 18.5 and 32 mins with 90% confidence, we have about 5% chance of it being more than 32 minutes and 0.2% of it taking more than an hour - this is calculated assuming we are following a Poisson process).
When difficulty was 1700, it would have been 1.7 times harder, meaning that choosing a block interval target of 5 minutes instead of 2.5 would have made us break the record a couple of months ago.

1CounterpartyXXXXXXXXXXXXXXXUWLpVr is the burn address for counterparty (it's like an altcoin on top of the btc blockchain), not a vanity address. Nobody knows it's private key, at least that's what they claim, no one is supposed to... it would be a very clever and elaborated scam if they had it.

juajua!! "Moneda anónima Basada en Firmas de timbre"
firmas de timbre!!! qué hijos de mil......
"ring signatures" pueden ser firmas en anillo..... pero "de timbre"!? seguro que no, jajaj

hi! this is just to confirm that I've been receiving my payments. Thanks!

Regarding the superblock thing, I think that the easiest would be to force one block (let's say block 122000) to have the desired difficulty and then return to normal. At current rates, I expect it would take about 30 mins (expected time) to solve the world-record block. Less if we are lucky, more if we aren't. This would require everyone to update to the new client but nothing else would need to be changed.
There will be a delay on transactions, but only for less than half an hour. Think of it as "expected downtime". We could make that block have a reward of 600 to accomodate for the extra difficulty.

What do you say?

hi!

I tryed the uninitialized variable fix and yes, it now seems to work well under windows. I also made the stratum protocol properly reconnect after losing the connection to the pool.
Source is (under the stratum branch) here: https://github.com/gatra/fastrie

dga: would you please merge this?

thanks and regards,
gatra

argentinians take one collapse every 15 years, since 100 years ago, we're used to that, that's not a weighting factor. But btc is getting trendy and lots of snobs are starting to learn about it. We love "trendy". Will it stay or will it fade away like trendy fashions? idk

thanks again dga, I'll test with the new fix

also, an idea I received by "randomaxingman" that was discussed with dga, that would help us break the world record:


I really like the idea but I see 2 issues with this:
1) timestamps are not enforced, so the protocol shouldn't rely on time frames very much. While all people are working on the superblock, a clever hacker would have free highway to mine standard blocks and force the timestamp in order to make it appear as it was mined after the time frame. If the super block is not found, then he has a lot of advantage.
2) It requires a hard fork. I don't like hard forks. However this may justify it

Let's think about how to work around issue 1....


another update: I'm not convinced by the supernetwork thing... must investigate carefully

I've found some mentions here: https://bitcointalk.org/index.php?topic=101954.msg1277594#msg1277594
and here: http://www.peercointalk.org/index.php?topic=1956.0

but they talk about reusing work on multiple chains, not about using this to intentionally create multiple chains in order to split the net

they'll implement this that may help relieve the problem: http://www.peercointalk.org/index.php?topic=2783.msg28885#msg28885
they'd reject both blocks (only latest block of a chain is rejected) if there is a duplicate...

do you think this would solve the issue? I think it might, but until then all pow/pos coins are vulnerable

Hi, there!

quoting the PPC paper:


So, if I find a stake kernel that meets the difficulty, I could use it to generate 2 different blocks with it (by including different tx), send one to half of the nodes, the other one to the other half, and split the network?
generalizing, I could generate N blocks, send each node a different block simultaneously, and partition the network in many many pieces, only with a single POS minting?
"until a successor is received"... but it could be some time... this is specially bad for POW/POS hybrids that already have a relatively low POW hashrate...

Please confirm and expand on consecuences, or explain where am I wrong.

cheers!
gatra

only profiling will tell, but I'm afraid that the "other necessary calculations to find a stake" part may be more cpu intensive than the sha256d
It has to access many blocks to get the "stake modifier" for each tx.