While lurking months ago in the BitcoinTalk topic, I read some interesting ideas about improving the Riecoin network or proof of work: accepting tuples of lengths different of 6, or do something about the Superblock so the network is not stuck during a hour each week (which would be indeed problematic when Riecoin will be much more popular).

Let's discuss about such improvements in this topic.

## Riecoin improvements/forks discussion

### Riecoin improvements/forks discussion

rieMiner - Riecoin solo + pooled miner

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

### Re: Riecoin improvements/forks discussion

I don't think is possible to search for tuples bigger than 6, without to create forks. This come from the nature of 6 tuples, the seventh number in the chain can be P1 + 18 or P1 + 20 or P1 + 22 . Obviously it cant be +18 because it will be always divisible by 5 (97+18=115), it cant be +20 because will be "always" divisible by 3 (97+20 =117), it cant be and +22 because will be "always" divisible by 7(97+22 = 119) . I put "always", because I'm sure for all 6 tuples in first 64bit range there is no such number, maybe from point of infinity there could be such number, but it will be so rare that the chance to find such on properly difficult is nearly 0 :) . We have another one option: to find prime number which is P1 - 2 or P1 -4 P1 - 6, but again we exclude P1 - 2 because it will be divisible by 5 , and P1 - 4 will be "always" divisible by 3, and P1 - 6 on 7. Our option is P1 + 24 or P1 - 8, but I don't know if it could be part of any prime constellation (most likely not). We can change the checking order (from P1,P1+4,P1+6,P1+10,P1+12 P6+16 ) or add and another check, but then all old version of riecoin wallet will not agree with Proof Of Work and this will create forks (something different what riecoin is :). The only way to not create forks is all in the network to switch to newest checking algorithm in same time, and from that point of time, nobody never ever to use older wallet versions. Cant see how this can be possible.

My understanding of supper blocks (very possible to be wrong) is: network periodically switch current difficulty * 2 for 1 hour, so if difficulty is 1000 it becomes 2000. Obviously if the current difficulty is 1000 that means there are no enough computation power in the network to find blocks on difficulty 2000, and finding supper block is pure luck. If we lower the x2 ratio for superblock difficulties we will again create forks, because not all nodes in the network will agree to accept them.

My understanding of supper blocks (very possible to be wrong) is: network periodically switch current difficulty * 2 for 1 hour, so if difficulty is 1000 it becomes 2000. Obviously if the current difficulty is 1000 that means there are no enough computation power in the network to find blocks on difficulty 2000, and finding supper block is pure luck. If we lower the x2 ratio for superblock difficulties we will again create forks, because not all nodes in the network will agree to accept them.

### Re: Riecoin improvements/forks discussion

Sure, we would need forks, and this is the point of the discussion. It would be like the fork that happened years ago to include Superblocks.

I retrieved what was said about this.

I retrieved what was said about this.

clo1 wrote:Hi all. I've been mining Riecoin since January. It is good to see some interest in new exchanges and updating the wallet.

As much as I like Riecoin I have to say I'm a bit bored with finding 6-tuples at half the current record difficulty. If a major effort is going to be made to upgrade the wallet would you consider also changing the algorithm to make finding large clusters a lot easier? It is really a shame that 6-tuples were chosen. A 6-tuple cannot be part of a 7-tuple or any larger constellation. A 7-tuple on the other hand can be part of every constellation up to 15-tuple. lf we switched to looking for 7-tuple blocks then several blocks a day would also be 8-tuples. These would probably be in the range of the current 8-tuple record. Every couple weeks one of the 7-tuples would also be a 9-tuple. This would smash the current record. If the goal is to find large constellations then why stick with an algorithm that guarantees we never find one?

I think I would also add a second chain that looked for 10 or 11-tuples. This would be a GPU friendly chain that could bring in a lot of new interest in Riecoin.

There are several other things we could consider as well. If this was implemented properly we could probably break most of the records from 7 to 13 or 14. I could probably write this part of the code. I'm also willing to help out with the upgrade but I'm much less familiar with the wallet core. Let me know what you think.

dga wrote:That's a fun idea.

I think we should first complete the upgrade -- making *more* changes to the old code before we get updated will just make future integration harder.

Gatra had a related idea for seeing if we could find longer tuples, but I don't want to share his thoughts without permission, so I'll let him chime in. In any event, I think something that increases the flexibility of the tuples to enable us to break more records would be awesome.

I already started to make some (not complete for now however) changes in rieMiner to make it easy to adapt in the case if the we choose to change the constellations types. I was able to easily find some 8-tuples at difficulty 304.gatra wrote:Thank you clo1.

I agree with dga, the priority should be updating the client. After that we can do a hard fork for larger prime sets.

I do have an idea for implementing this, it's no secret. It basically works analogous to shares like in mining, allowing for larger numbers. My plan is to implement that and also rotate between different constellation sizes. So for some blocks it would be 6-tuples, then move to 7-tuples, 8, 9, and so on. It can be done in one chain.

If you can't help with the update, maybe you can work with me on the mining algo update, but I don't want to start coding it until we have an updated version.

rieMiner - Riecoin solo + pooled miner

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

### Re: Riecoin improvements/forks discussion

One change that would be nice and would make a small boost to the number size that could be found would be to change the way that the prime is encoded to allow a larger primorial number to be used.

To explain, Riecoin primes must be of the form where X < 2^(D-265). Additionally, X must be < 2^256 as only 256 bits may be submitted for the proof of work.

In practice, the best way to choose X is to have it of the form where # denotes the primorial operator (n# is the product of all primes <= n), x = q + (0, 4, 6, 10, 12, 16), with q normally = 16057 though the smallest prime in any small sextuplet will do.

The advantage of this form is that it guarantees that no primes <= n can be factors of P for any k. Sieving is then used to eliminate k with factors up to some limit and finally primality tests are used for candidates.

Choosing a larger n allows for faster sieving and a higher density of candidates across a given range of k, so allowing a larger n could provide a modest boost to the size of primes the network finds.

My suggestion would be to change the proof of work to consist of just k, n and q instead of the full representation of X, as it is easy to calculate X given k, n and q. This would allow X larger than 2^256, and hence larger n values to be used.

Suitable ranges for the values to give plenty of flexibility to the mining implementation would be k < 2^128, n < 2^16, q < 2^96, which would give 16 bits spare in a 256-bit submission, maybe to encode the tuple constellation.

Maybe a bit could be used to indicate whether the client was using this form or not, in case someone wants to continue using an older mining implementation. The bottom bit of the 256-bit submission would do for this, as it must always be 1 in the current implementation (if it is zero then P would be even). I'd suggest reserving another bit to indicate use of a different form in future too.

Thoughts?

To explain, Riecoin primes must be of the form

Code: Select all

`P = 2^D + S.2^(D-265) + X`

In practice, the best way to choose X is to have it of the form

Code: Select all

`X = n# - (2^D + S*2^(D-9)) % n# + k.n# + x`

The advantage of this form is that it guarantees that no primes <= n can be factors of P for any k. Sieving is then used to eliminate k with factors up to some limit and finally primality tests are used for candidates.

Choosing a larger n allows for faster sieving and a higher density of candidates across a given range of k, so allowing a larger n could provide a modest boost to the size of primes the network finds.

My suggestion would be to change the proof of work to consist of just k, n and q instead of the full representation of X, as it is easy to calculate X given k, n and q. This would allow X larger than 2^256, and hence larger n values to be used.

Suitable ranges for the values to give plenty of flexibility to the mining implementation would be k < 2^128, n < 2^16, q < 2^96, which would give 16 bits spare in a 256-bit submission, maybe to encode the tuple constellation.

Maybe a bit could be used to indicate whether the client was using this form or not, in case someone wants to continue using an older mining implementation. The bottom bit of the 256-bit submission would do for this, as it must always be 1 in the current implementation (if it is zero then P would be even). I'd suggest reserving another bit to indicate use of a different form in future too.

Thoughts?

### Re: Riecoin improvements/forks discussion

Sounds good as I remember that I indeed seemed to get better results once by increasing the Primorial Number (setting PN > 40 currently produces invalid work), and as we are not longer limited to X < 2^256. Now, we should test if we can get a big (> 30%) performance benefit with this encoding to justify such hard fork. If the gain is a few %, it is not worth forking (or maybe we could still consider this if we gain 10-20%).

rieMiner - Riecoin solo + pooled miner

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

### Re: Riecoin improvements/forks discussion

From the topic Ideas to make RIC coins useful and Riecoin more known:

The only drawback is that miners would earn 2 times less, but personally as one of them, I do not really mind. When we will reach high Difficulties again, I would earn more by holding a lot of coins, and mining should remain very profitable for people with a lot of mining power...

Anyone else favorable to this idea? Or do others see cons?

This sounds like a great idea! This would reward Riecoin supporters that buy and hold, and help a lot to maintain stability as people will be more reluctant to sell. There has to be a way to implement this in a hard fork. We could set parameters like the minimum daily interest or how old the coins have to be to start earning.rcman wrote: ↑01 Dec 2018, 19:34Can't we make a sort of interest system where half of blocks rewards will automatically and proportionally go to holders? This will make RIC neat to hold and people not wanting to sell!

The current daily interest will be 1*576*12.5/45881010 = 0.0157%, yearly compounded interest will be 5.89%, better than banks, without risk!

The only drawback is that miners would earn 2 times less, but personally as one of them, I do not really mind. When we will reach high Difficulties again, I would earn more by holding a lot of coins, and mining should remain very profitable for people with a lot of mining power...

Anyone else favorable to this idea? Or do others see cons?

Personal Riecoin page (links, download,...)

freebitco.in - earn up to $200 in BTC each hour!

### Re: Riecoin improvements/forks discussion

MIners also should be happy with higher price caused by this improvement. With both good/stable wallet and profits, even global price like 1RIC for 0,007BTC is possible very quickly.