Topic: [ANN][RFC][RIC] Logo contest! Riecoin, new prime numbers POW coin -CONTEST ENDED - page 2. (Read 16889 times)

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

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?

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!

you should increasee reward

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.

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.

+1

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.

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  reward=0
elif 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?

Is there a better eta already?

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.

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)

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?

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?

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

I am looking forward for the launch.

Very intrigued, will be watching closely 

general parameters are like LTC: supply is 4x BTC, targeted at 2.5mins between blocks, reward starts at 50RIC.
Diff adjusts every 1008 blocks, but taking into the equation the last 2016 blocks (similar to BTC, but intervals are shorter and overlap). However I'm not 100% sure about this, I might change it to retarget more often.

Scientific value is hard to judge a priori, we will be gethering evidence for or against the Riemann hypothesis (which has a prize of 1M USD if you can prove or disprove it!). The PoW might generate groundbreaking results, or may be as pointless as hashing, most likely something in between: we'll create a repository of numbers that some mathematicians may consult for reference. It's very unlikely that we win the million dollars because the hypothesis is considered to be true and we are not explicitly evaluating the zeta function, but we are looking for numbers that will (or won't, that's the point) follow the distribution derived from Riemann's equations.
But if someone makes FPGAs/ASICs for finding prime numbers I'm sure that would be a big help for mathematicians in general. Even if it only helps for generating interest in math, I already consider it a win: we are proving that not only it's possible to make a distributed computing network more powerful than the largest supercomputers, but we would also prove that we can use it for something other than hashes. That surely must be of some "scientific value".

Thanks for the update.

You definitely are not like all those clone maker. I'm really looking forward to the release.

Do you already know the total supply of coin? (or no supply limit like SunnyKing's coins)
Do the Difficulty retarget will be classic or custom?

And I have a last question : In comparison to Primecoin, how do you judge the scientific value of your PoW? I guess it's hard to judge but some people are saying Cunningham chain are almost pointless.
At least, you can't be worth than Bitcoin, for sure!

hi!

Of course, once everything is ready I will focus on the users.

Updates:

- I'm satisifed with the optimized version of the new cpuminer. It's a fork of pooler's cpu-miner (minerd), and it will be released with sources and windows binaries at launch time.

- Everything works on linux, but the windows -qt wallet is very unstable. Maybe because I'm compiling with mingw natively, which is not supported by bitcoin. I've given up on that and I'll try to cross-compile for win32 from linux.

- I've been writing text for the web site explaining the new proof of work. I'll follow Sunny King's example and release that data 2 days before launch in order to avoid copycats.

- Now that I'm done with the cpuminer, I'm back to the struggle of setting up dnsseed and bind

There are a lot of things involved in doing this right. Most developers don't do it, but I want to do it right. Today I generated new alert keys. Many coins out there don't care about this and just launch with other coin's alert keys and without dnsseeds...

Hi again,

How the project is going?

You're probably busy building the tech, but a coin is nothing without users. This thread need to be upped more frequently to gain awareness.  I think small frequent update, explaining your avancement, your struggle, etc..  could be interesting for people.