What makes the creation of new coins tempting is simply what makes it tempting to start any other pyramid/ponzi scheme: the desire to be at the top of the scam/scheme.
The very fact that it is so tempting makes it abundantly clear the objective is the scam/pyramid.
Obligatory Simpsons quote: "Let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No sir. Our model is the trapezoid!"  |
|
|
|
VGER..
A lot of people are working on new coins..
I would like to say that a MASSIVE PRE-MINE or an unfair/bias coin distribution (say 10x in the first few weeks) - unless for very VERY GOOD/explained reason, seems only to inspire despair in us users..
Also - For the creators of coins, there is this looming dread, that if they take ANY, they will be flamed to a cinder in the forums. And all the hard work they put into it, will be ignored.
I certainly feel that the creator of a coin should be allowed to keep some of the coin stock back. For a very good and simple reason.
Incentive.
Knowing that your initially WORTHLESS stake MAY some day be worth something, gives the creators of a coin an incentive to stick with it. To work out the issues that will definitely arise in the early stages of a new-coins infant life.
I would suggest 1%.
Too small to be considered a massive pre-mine, and really only of any value if your coin should become valuable someday.
When Bitcoin kicked off, 1% was 210,000 coins, which at $0.01, would be $2100. Hardly a fortune. But now, with effort, sweat and time.. it certainly is a king's ransom.
You could also pledge to not dump the lot, or keep them for the first year of a coin's existence.. So as to show you're not a 'Pump and Dump Scheme'.
I wish all the new Coin Creator's Success!
(But if you have any desire to keep us Users sweet, don't be 'too' greedy, initially.. ;-p)
wtf? 1%? that's a lot! they should ask for donations and not have any premine at all |
|
|
|
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. |
|
|
|
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. |
|
|
|
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... |
|
|
|
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? |
|
|
|
|
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!
|
|
|
|
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? |
|
|
|
This is interesting. Is it enough if I watch only this thread, to catch the release announcement? Or do I need to watch somewhere else too?
Hi! thank you all for your interest. This is what I was planning to do: 1) Create an announcement thread with the release date. 2) Post a link to the announcement thread in the logo contest thread (this one: https://bitcointalk.org/index.php?topic=288065.0) 3) tweet (@riecoin) a link to the announcement thread 4) put it in the website: riecoin.org 5) Announce in other forums too! I don't want anyone to miss it, and since this thread is getting attention I'll post here too, but progress updates will be posted on the logo contest thread so may want to watch that one. ETA: Still at least 2 weeks to go... sorry |
|
|
|
short version: he wants to make a dynamic algorithm for the PoW so ASICs are infeasible to make. He proposes having some predefined functions, and at retarget time deciding which and/or in what order to apply them, thus generating a new PoW algorithm that will be used until next retarget.
Is that it?
I say it wouldn't work, because you can have an ASIC that has one circuit for each of the predefined functions and then link them together as needed. You don't need to hardwire each possible combination, ASICs can implement conditionals!
Digression on ASIC design: if you have a hardwired circuit for each of the predefined functions (each of the modules that you combine), the naive way is to simply run only one at a time or to have them run in parallel and then only keep the result of the one you want, and repeat to do the next step. This would work very well, but you would be wasting resources: it's possible to do a smarter design where you have a sort of superscalar pipelined architecture where you have all of the involved circuits running at the same time in parallel at different steps of the calculation. This would kick the CPU's and GPU's asses because -once the pipeline is full- all the big parts of the circuit are doing useful work at the same time: no waste!
The only path I see to "ASIC-hostility" is having a memory intensive algorithm... one could make trade-offs for calculations vs memory use, but either way it costs you transistors.
Interesting point, ASICs certainly can handle conditionals. I think this design would still make ASICs significantly more expensive and less efficient per area of board space, as, say, for example, that one of the algorithms needed step 18 done 6 times and step 4 done once, assuming each step was the same size, then the circuitry that does step 4 would be idle waiting for step 18 to go 6 rounds. Perhaps a better idea would be to have the very circuit logic of each step change? So some times it would be something like (assuming given 8 16-bit chunks): a = first 16, b = second 16, ... h = last 16 Then do circuit logic, such as A (a different, memory place-holder) = XOR(A,B) Then do circuit logic, such as B (a different, memory place-holder) = XOR(B,C) Then do circuit logic, such as C (a different, memory place-holder) = XOR(C,D) Then do circuit logic, such as D (a different, memory place-holder) = XOR(D,E) Then do circuit logic, such as E (a different, memory place-holder) = XOR(E,F) Then do circuit logic, such as F (a different, memory place-holder) = XOR(F,G) Then do circuit logic, such as G (a different, memory place-holder) = XOR(G,H) Then do circuit logic, such as H (a different, memory place-holder) = XOR(H,A) And then do some additional steps, don't feel like writing out an entire modular piece. Then the next retarget, that step could be different, perhaps switching some of the XORs out for AND or ORs (trying to maintain balance...), switching out some of the digits, etc. We would need more data to draw from than the last block hash for the retarget, so perhaps the system could rely on a combination of the hashes of multiple of the past blocks in such a way that there would be enough granularity to allow all circuit-logic to be changed. So psuedo-code for the above would be something like: a = first 16, b = second 16, ... h = last 16 Then do circuit logic, such as A (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as B (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as C (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as D (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as E (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as F (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as G (a different, memory place-holder) = Logic(something, somethingElse) Then do circuit logic, such as H (a different, memory place-holder) = Logic(something, somethingElse) And when retargeted, it would put something into each of Logic (AND, XOR, OR), and choose things for something, somethingElse based on block data. You brought up a very good point, think an ASIC could handle the above efficiently? At this point, it'd almost have to have just chips dedicated to XOR, OR, and AND, which is pretty close to a specialized CPU. I'm not sure I understand this last part, but I think that you are just complicating the "glue" logic that links all the modules together. That makes it harder for both the CPU and the ASIC, but the latter would still be efficient. Also, I didn't care about entropy because it's not a problem if each of your basic modules is a well studied algo like SHA-x. But if you want to randomize the logic (using and/xor/or at random) them you have to start being careful about it. |
|
|
|
|
short version: he wants to make a dynamic algorithm for the PoW so ASICs are infeasible to make. He proposes having some predefined functions, and at retarget time deciding which and/or in what order to apply them, thus generating a new PoW algorithm that will be used until next retarget.
Is that it?
I say it wouldn't work, because you can have an ASIC that has one circuit for each of the predefined functions and then link them together as needed. You don't need to hardwire each possible combination, ASICs can implement conditionals!
Digression on ASIC design: if you have a hardwired circuit for each of the predefined functions (each of the modules that you combine), the naive way is to simply run only one at a time or to have them run in parallel and then only keep the result of the one you want, and repeat to do the next step. This would work very well, but you would be wasting resources: it's possible to do a smarter design where you have a sort of superscalar pipelined architecture where you have all of the involved circuits running at the same time in parallel at different steps of the calculation. This would kick the CPU's and GPU's asses because -once the pipeline is full- all the big parts of the circuit are doing useful work at the same time: no waste!
The only path I see to "ASIC-hostility" is having a memory intensive algorithm... one could make trade-offs for calculations vs memory use, but either way it costs you transistors.
|
|
|
|
|
oh, I get it, you're right
It's interesting, but I still don't completely understand how everything fits together, I need to read the pdf a couple of times...
|
|
|
|
What is the "diff"? What do you mean "old chain"?
By diff I mean the difficulty. Imagine this scenario: Let's the minichain has 1 week worth of blocks. In week 1, network difficulty was set to a number which we'll call d1. And nodes A and B are connected during week 1 and then disconnect. During week 2, nodes A and B are not connected. Also, for some reason some nodes disconnect too (let's say week 2 is vacations in Silicon Valley, this is not crazy, bitcoin difficulty has a trend of going up but sometimes it oscilates a bit), making the difficulty of week 2 go down. So d2 < d1. Now, when nodes A and B connect to the network on week 3, they have a minichain of week 1 (the "old chain") which has more work, more difficulty, than the rest of the network which has ONLY the blocks of week 2. If nodes A and B see each other they will fork, not accepting the good minichain. So you can't choose based on difficulty. But you can't choose based on timestamp, because those are easy to forge. You must do some combination when deciding which is the valid minichain. Also, and worst, if I want to create a fake minichain for attacking, I could spend months or even a couple of years creating the minichain of one week. A hardcoded genesis block prevents this, and forces me to start from a fixed point, but new blocks are added to the end of the valid chain all the time. If you don't have this, a 50% attack can create a minichain in 1 week, but a 25% attack could create one in 2 weeks, and so on, a 6.25% attack could create a whole fake minichain in 2 months. I like the idea, I'm just pointing out that there are many things to have in mind and it may be tricky to make it work. |
|
|
|
|
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".
|
|
|
|
|
I believe it's ok that the keys are kept secret, it would be a mess otherwise.
If you need to test, I can think of two options: comment out the validation (make CAlert::CheckSignature return always true) or use your own keys.
If you create new keys using CKey::MakeNewKey and then IsValid() there should be no such thing as "fluky keys"
But I guess that either way you'll have to code you own alert sending functions.
Asking a dev to generate an alert for you is a good idea but you can do it only once or twice, you can't rely on that for testing/debugging.
I'm working on an alt-coin so I generated new keys but I haven't written the code to actually test them yet... it shouldn't be hard: just create a CAlert manually and then make the client relay it to the other nodes (adding it to mapAlerts).
|
|
|
|
|
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...
|
|
|
|
|
if I disconnected for a week (or whatever the length of the minichain), then when I connect i have to download a full new chain. If I'm shown more than one by different nodes, which one do I choose? the one with more work? what if the diff went down? I could end up downloading an old chain...
|
|
|
|
|
I found no code for generating alerts. In alert_tests.cpp, I found this:
// (SignAndSave code not shown, alert signing key is secret)
but I think that code for SignAndSave should be shown: they could share the code without sharing the private key, otherwise it feels like security by obscurity.
Currently we have to make our own code to generate alerts and test them. If we change the keys then the tests no longer work and can't be made to work without extra coding.
|
|
|
|
|
it depends...
would it include how to set up dnsseed (including bind configuration)?
would it describe how does localization work in QT and explain how to update the messages?
if not, then 0
|
|
|
|
it's not clear why...
if 2 * 1/10th are deducted then he violated the 1/10th per day rule... so one of the tx should have been ignored
also, if instead of buying one thing, he buys 19 things, and the merchants are not connected between them, 20 * 1/10th would be deducted. Except he only has 10/10ths. That's a double spend.
Nothing bad will happen if someone spends more than 1/10th of the balance. The rule is set to avoid risk of spending more than 100% of coins. Merchants don't need to be connected each other. They need to be connected to the network. please notice that 20 * 1/10th is 20/10th, which is twice the original balance, hence a double spend, so it looks like it's bad... what is the point of the 1/10th per day rule if it can be violated? I still don't understand how your proposition works... |
|
|
|
|
Show Posts
