[ANN][RFC][RIC] Logo contest! Riecoin, new prime numbers POW coin -CONTEST ENDED

[int3ractivodular]

Very intrigued, will be watching closely 

[MarpleTrading]

Interesting and nice that this coin is at least trying to do something useful.

I am looking forward for the launch.

[cosurgi]

is it scrypt?

its searching prime numbers. It can't be scrypt.

@gatra please wait with release. When you are all ready, then make an announcement two weeks ahead (even better three weeks). Two weeks is minimum I think to avoid any kind of premine (not by you, but by coin stalkers), or some other kind of stupid race between people, which usually occurs when a  new coin is released.

Ideally you should release the software and sources some time ahead of launch, so that everyone will have time to download it and read.

Then people will have time to configure the software so that all are up & waiting(idle) & connected to the p2p network. When a specified number of seconds since 1970 passes (cool if you pick some prime number for that) then the p2p network will receive the first block from you and will start mining.

I think that a week of waiting idle is a minimum. So that everyone will have time to properly join and configure the software.

Also during the first days (until block 2016 is generated) you should have dynamic difficulty adjustment based on all blocks generated since genesis block. This way we will not have blocks flying every 10 seconds, and lots of orphans. Then after block 2016 it should be safe to go back to the original difficulty adjustment algorithm.

This way everything will be prepared and no surprises.

Do you like this approach?

[gatra]

is it scrypt?

its searching prime numbers. It can't be scrypt.

@gatra please wait with release. When you are all ready, then make an announcement two weeks ahead (even better three weeks). Two weeks is minimum I think to avoid any kind of premine (not by you, but by coin stalkers), or some other kind of stupid race between people, which usually occurs when a  new coin is released.

Ideally you should release the software and sources some time ahead of launch, so that everyone will have time to download it and read.

Then people will have time to configure the software so that all are up & waiting(idle) & connected to the p2p network. When a specified number of seconds since 1970 passes (cool if you pick some prime number for that) then the p2p network will receive the first block from you and will start mining.

I think that a week of waiting idle is a minimum. So that everyone will have time to properly join and configure the software.

Also during the first days (until block 2016 is generated) you should have dynamic difficulty adjustment based on all blocks generated since genesis block. This way we will not have blocks flying every 10 seconds, and lots of orphans. Then after block 2016 it should be safe to go back to the original difficulty adjustment algorithm.

This way everything will be prepared and no surprises.

Do you like this approach?

That's pretty close to what I was planning, this is what I was thinking:
I would release the sources of the coin and the stand-alone miner a few days ahead, a week if you wish, except for the PoW functions which would be replaced by stubs. The final code would be released at launch time. The idea is that everyone would be able to examine the code and confirm that there's nothing strange and it is indeed pretty similar to bitcoin's. Everyone would be able to compile it, see if they have the correct dependencies, etc, but it won't run. This way I don't have to publish the PoW so no one can steal it and launch before riecoin does. At launch time, when the final code is released, everyone could easily check that the only thing that changed is the PoW code, so you'd only have to check the diff of a few lines of code and recompile.
To avoid having a different difficulty adjustment algorithm for the first blocks, my idea is that for the first N blocks (haven't decided the value of N yet) the reward will be 0. So if there are a lot of orphans or instamining at the beginning, it wouldn't matter. I will be mining from the first moment, and encourage everyone to start mining as soon as they can. This should give everyone time to review the code and compile, but you should hurry because it will be hard to predict how long will it take to get to block N.
Maybe it can be done gradually, to avoid everyone jumping on board at block N, let's say at block N/2 reward starts to increase with each block until it reaches the full value at block N, or something like that.

Would this approach be ok?

[bidji29]

You already have the advantage to have block every 2.5 minute instead of 1 with primecoin. It should reduce the orphan and instamine.
But yeah, some block without reward at the beginning should let people have the time to jump in.

Do you consider your miner very optimised? The primecoin one was very bad at the beginning, and few poeple have privately benefited from more powerful miner earlier (thanks to Mikhael who share his version)

[cryptrol]

That's pretty close to what I was planning, this is what I was thinking:
I would release the sources of the coin and the stand-alone miner a few days ahead, a week if you wish, except for the PoW functions which would be replaced by stubs. The final code would be released at launch time. The idea is that everyone would be able to examine the code and confirm that there's nothing strange and it is indeed pretty similar to bitcoin's. Everyone would be able to compile it, see if they have the correct dependencies, etc, but it won't run. This way I don't have to publish the PoW so no one can steal it and launch before riecoin does. At launch time, when the final code is released, everyone could easily check that the only thing that changed is the PoW code, so you'd only have to check the diff of a few lines of code and recompile.
To avoid having a different difficulty adjustment algorithm for the first blocks, my idea is that for the first N blocks (haven't decided the value of N yet) the reward will be 0. So if there are a lot of orphans or instamining at the beginning, it wouldn't matter. I will be mining from the first moment, and encourage everyone to start mining as soon as they can. This should give everyone time to review the code and compile, but you should hurry because it will be hard to predict how long will it take to get to block N.
Maybe it can be done gradually, to avoid everyone jumping on board at block N, let's say at block N/2 reward starts to increase with each block until it reaches the full value at block N, or something like that.

Would this approach be ok?

This is a nice compromise between openness and protection of your work unitl launch, as fair as you can get in my opinion.
The measures against instamining and difficulty adjusting are a must also for a fair launch, but instead of a 0 reward you can put a small one and increase the initial period for low rewards, this way you will attract more people from launch.
Good luck with this new PoW, seems interesting.

[MarpleTrading]

Is there a better eta already?

[cosurgi]

That's pretty close to what I was planning, this is what I was thinking:
I would release the sources of the coin and the stand-alone miner a few days ahead, a week if you wish, except for the PoW functions which would be replaced by stubs. The final code would be released at launch time. The idea is that everyone would be able to examine the code and confirm that there's nothing strange and it is indeed pretty similar to bitcoin's. Everyone would be able to compile it, see if they have the correct dependencies, etc, but it won't run. This way I don't have to publish the PoW so no one can steal it and launch before riecoin does. At launch time, when the final code is released, everyone could easily check that the only thing that changed is the PoW code, so you'd only have to check the diff of a few lines of code and recompile.
To avoid having a different difficulty adjustment algorithm for the first blocks, my idea is that for the first N blocks (haven't decided the value of N yet) the reward will be 0. So if there are a lot of orphans or instamining at the beginning, it wouldn't matter. I will be mining from the first moment, and encourage everyone to start mining as soon as they can. This should give everyone time to review the code and compile, but you should hurry because it will be hard to predict how long will it take to get to block N.
Maybe it can be done gradually, to avoid everyone jumping on board at block N, let's say at block N/2 reward starts to increase with each block until it reaches the full value at block N, or something like that.

Would this approach be ok?

Hi,

yes, this approach is even better than what I proposed. You could increase the reward linearly starting from block N/2, so that at block N it will be a full 50 coin reward, I think that setting N at around one month should give people enough time to get everything up and running. Nobody cares about flying orphans, no premine. A very clean start. The formula would look something like that:

N - block when reward is full
n - current block

if n<N/2:
  reward=0
elif n<N:
  reward = (50*(1+(n-N)*2/N))
else
  reward=normal_reward # first  50, after four years 25, etc..

it is an integer division internally (but outside it appears as having 8 decimal places precision), so there's no danger that different architectures will grant themselves a little different reward. Unless on some architectures integer division 3/2 gives 1 while on other architectures it gives 2. So just to be safe you could ignore the eighth decimal place when determining whether to accept the block in the blockchain. In fact people could modify their code to always put "9" there, and it will get accepted, but I think that instead of treating it as a problem we can later make some statistics to determine how much hashing power belonged to people who took the effort to modify the code in such a way (and "stole" few satoshis/riemanns) .


Care to tell us what you are struggling with right now?

[bidji29]

That's pretty close to what I was planning, this is what I was thinking:
I would release the sources of the coin and the stand-alone miner a few days ahead, a week if you wish, except for the PoW functions which would be replaced by stubs. The final code would be released at launch time. The idea is that everyone would be able to examine the code and confirm that there's nothing strange and it is indeed pretty similar to bitcoin's. Everyone would be able to compile it, see if they have the correct dependencies, etc, but it won't run. This way I don't have to publish the PoW so no one can steal it and launch before riecoin does. At launch time, when the final code is released, everyone could easily check that the only thing that changed is the PoW code, so you'd only have to check the diff of a few lines of code and recompile.
To avoid having a different difficulty adjustment algorithm for the first blocks, my idea is that for the first N blocks (haven't decided the value of N yet) the reward will be 0. So if there are a lot of orphans or instamining at the beginning, it wouldn't matter. I will be mining from the first moment, and encourage everyone to start mining as soon as they can. This should give everyone time to review the code and compile, but you should hurry because it will be hard to predict how long will it take to get to block N.
Maybe it can be done gradually, to avoid everyone jumping on board at block N, let's say at block N/2 reward starts to increase with each block until it reaches the full value at block N, or something like that.

Would this approach be ok?

Hi,

yes, this approach is even better than what I proposed. You could increase the reward linearly starting from block N/2, so that at block N it will be a full 50 coin reward, I think that setting N at around one month should give people enough time to get everything up and running. Nobody cares about flying orphans, no premine. A very clean start. The formula would look something like that:

N - block when reward is full
n - current block

if n<N/2:
  reward=0
elif n<N:
  reward = (50*(1+(n-N)*2/N))
else
  reward=normal_reward # first  50, after four years 25, etc..

it is an integer division internally (but outside it appears as having 8 decimal places precision), so there's no danger that different architectures will grant themselves a little different reward. Unless on some architectures integer division 3/2 gives 1 while on other architectures it gives 2. So just to be safe you could ignore the eighth decimal place when determining whether to accept the block in the blockchain. In fact people could modify their code to always put "9" there, and it will get accepted, but I think that instead of treating it as a problem we can later make some statistics to determine how much hashing power belonged to people who took the effort to modify the code in such a way (and "stole" few satoshis/riemanns) .


Care to tell us what you are struggling with right now?

This make 2 weeks without reward at all.
By the time there is a reward, the launch period interest will have dissapear long time ago.
For a coin to be successfull, it need some interest+competition. By pool for exemple, who try to do the best miner, the best fee to attract people.

The point is to avoid instamine, not to handicap the coin at launch.

[MarpleTrading]

+1

[cosurgi]

the point is to avoid great loss on orphans and lots of people disappointed by losing their generated block.
Maybe two weeks without reward is too long. But slow increasing of reward to 50 coins is definitely a good approach.

[int3ractivodular]

the point is to avoid great loss on orphans and lots of people disappointed by losing their generated block.
Maybe two weeks without reward is too long. But slow increasing of reward to 50 coins is definitely a good approach.

Slowly increasing rewards is a good idea but 2 weeks is DEFINITELY far too long of a period, the crypto world moves way too fast for people to mine something with 0 reward for 2 weeks.

[rampalija]

you should increasee reward

[gatra]

2 weeks? I was thinking more like 3.5 days... or hours ... or 2016 blocks... explanation follows:

Keep in mind that even while I "target" for 3.5 days, I've seen that at some launches you can have a block every 4 seconds or even less. So while 3.5 days are normally 2016 blocks @ 2.5min/block, the first 2016 blocks since launch could be generated in as little as 2 hours.
When the difficulty is too low there are many "orphan" blocks, all this orphans are blocks that were valid but are not factored into the equation for difficulty adjustments (only accepted block are), this means that each orphan introduces a small error in the difficulty calculation, so it takes some time to adjust at the beginning. And in the first moments after launch, sometimes blocks go to those with better bandwidth and latency instead of processing power.
Since this is a new PoW (and my first launch) it is impossible for me to guess the right starting difficulty, so I think a small period without reward is needed to compensate for that.

As someone mentioned, the point is not to handicap the coin at launch, the points are:
- To avoid a few people concentrating an unfair amount of RICs in the first moments (if blocks are intended each 2.5mins but a few people with lots of bandwidth get 30 blocks in that time, I consider it unfair)
- To give some time for those who want to examine the code and compile themselves
- To give some time to join to those who have other obligations and cannot be there at the exact launch time and cannot set a script to do it for themselves ("more fairness, yay!")
- To ease the pain for those frustrated by orphan blocks

So I'll try to have a few hours before full reward.

Not everyone will be pleased, but please share your thoughts!

[gatra]

Unless on some architectures integer division 3/2 gives 1 while on other architectures it gives 2. So just to be safe you could ignore the eighth decimal place when determining whether to accept the block in the blockchain. In fact people could modify their code to always put "9" there, and it will get accepted, but I think that instead of treating it as a problem we can later make some statistics to determine how much hashing power belonged to people who took the effort to modify the code in such a way (and "stole" few satoshis/riemanns) .

that's nonsense: C, C++ and the Riecoin protocol define integer division as rounding towards zero (ie truncating)
If someone did it differently, it shouldn't be called Riecoin, and their language shouldn't be called C++
If they insisted in creating such a thing and compilng C++ programs with it, postconditions would be broken, invariants wouldn't hold, programs would fail, lives could be lost, would you think of the children?

[gatra]

Care to tell us what you are struggling with right now?

mostly my daily job and my kids

dnsseed is still not working. I might release with seed nodes instead of dnsseeds if I don't get it to work, but this would mean I'd have to pay more for servers...

[gatra]

Do you consider your miner very optimised? The primecoin one was very bad at the beginning, and few poeple have privately benefited from more powerful miner earlier (thanks to Mikhael who share his version)

It uses GMP which is supposed to be highly optimized for many architectures, and I spent some time optimizing the rest of the code. However I'm sure once it's out for the community to examine there will be optimizations that I missed.
If I find more optimizations, I will share them.

[cosurgi]

dnsseed is still not working. I might release with seed nodes instead of dnsseeds if I don't get it to work, but this would mean I'd have to pay more for servers...

Does it mean that you need some reliable seed nodes - from the community?

Or the problems are more technically related?

[crendore]

Is the final logo set it stone? I had just finally convinced a really talented designer to take a crack at it.  This is her work.

[gatra]

Is the final logo set it stone? I had just finally convinced a really talented designer to take a crack at it.  This is her work.

sorry, but yes, the contest ended weeks ago and the logo is in the client, twitter, web site, etc. I can't change it now.