Quote from: AtomSea on June 02, 2014, 07:07:23 AM

The above needs to be placed on the appropriate reddit thread.
The accusations that the alleged "lead-developer" put on there are very inaccurate and damaging to this project.
Purple-monkey-dishwasher.

I'd like to post that on the reddit thread, but I don't want to create any form of flame war...

Quote from: kqpahv on June 02, 2014, 07:27:15 AM

Quote from: Vorksholk on June 02, 2014, 05:41:28 AM

We've been fairly quiet on the threads where jcoff talks about Curecoin. To clarify a few points though, he is not the "Lead Dev" of F@H as he claims to be, he developed the NaCL (Chrome folding) client, as well as the current desktop-version client, and likely contributes some other code elsewhere in the system. He brings up a few valid points, namely the centralization of the project. To summarize a longer explanation I went into on IRC, there are essentially four main options for integrating scientific computations into a cryptocurrency:

1.) Follow the path of Primecoin/Riecoin, where you create a proof-of-work which, while having some mathematical interest, doesn't have significant adaptability. From a decentralization standpoint, this option rocks, as it keeps the creation of work decentralized. However, the results of the PoW are not particularly helpful to science, and a new coin (or a fork of the coin) would be required to attempt proofs of another related mathematical theorem, such as the frequency with which primes are created, or the patterns? they will follow.

2.) Create a coin with a proof-of-work system based around the clients themselves collecting stats from the Stanford website, and agreeing on point payouts. This proposition, while on the surface quite decentralized, is also quite susceptible to errors. A change in the formatting of the Stanford stats, a change to the way points are assigned, etc. would cause massive client panic, and the network would be inoperable for days until the majority of users adopted a hot patch created by the developers. Not something that can occur in a legitimate currency, so this idea is, naturally, removed from consideration... Additionally, this idea would not allow easy transitions to include other distributed computing projects, such as Rosetta@Home, SETI@Home, World Community Grid. . .

3.) Create a coin which, with each block, creates a subsidy that is paid out to a pool account. The pool account would collect the subsidies created, and every day the server would look at the available coin balance, and split/payout that proportionally to all users, based on their computational resources contributed. This idea makes the folding server a large target, as the subsidy would be paid out to a hard-coded address, which, if the private key was obtained for it, would compromise the folding component of the currency.

4.) The method we chose involves the folding payout coins to be premined. This has several benefits, which was the reason we chose this path: we have a constant amount of currency, so we can stabilize folding payouts by having the same exact amount paid out (total) per day, reducing the risk of slow blocks impacting folding rewards, the premine can generate PoS to give additional rewards to folders, and those coins act as a major stake in the currency, which allows PoS blocks to be created, further increasing the difficulty of performing some form of 51% attack against the network, and the coins can, similar to the above option, be seen on the blockchain, on the public ledger. Similar to option #3, this approach allows us to add additional distributed computing projects to Curecoin in the future.

Admittedly, like all the above options, option number 4 has some shortcomings. The centralization of payouts worries some people, and the fact that a large number of coins are controlled by one party is also quite concerning to many. We saw this as the best option despite these inherent flaws, and therefore made the coin with that model in mind.

That is not to say that, in the future, the coin could not be adapted to, at some point, migrate all user balances and implement alternate network rules--once the blockchain has a significant and semi-constant hashing power, one option would be to make one such migration, in which a block subsidy is introduced, and all remaining folding premine funds would either not transfer over, or would be destroyed. Another option is to implement some form of network rule for the emission of folding funds in a more predictable manner, however it would still, at some level, be reliant on block speeds. If such a modification was to be introduced to the Curecoin network, it would require quite the organizational feat, and the transition would likely by disruptive for a short period of time.

As to complaints about the speed of payouts occurring, one of the things Josh and I have been working on "behind the scenes" (and in IRC) is tightening the screws of the system, and a few days ago we shaved off nearly 14 hours from the time it takes from the submission of a WU until it is credited in the system on our end.

We've also been extremely busy with figuring out how the BTC:Chicago conference's Curecoin booth will be done, if anyone has any ideas/experience they would like to offer, either post it here, or hop on IRC!

Thank You for the detailed answer.
Now if you added this information to the OP or Curecoin.net with links to updated information about the developer team and the LCC holding the coins it would already remove so much uncertainty and add credibility to the whole operation.

I agree that while the premine option is far from perfect it's hard to think of a better solution for now.
Jcoffland proposed a way where Stanford would issue certificates for WU's which could be used as Proof of Work. Is this something you might look into and try to work with Stanford to maybe get it implemented ? Now that they have seen the potential benefits Curecoin will bring to F@H maybe tehy will be more willing to work more closely with you guys ?

About the conference: Have you guys considered the idea of selling Curecoin gift cards which would be a mean for people to support the F@H cause as more buy support will directly bring more power to the network ? It's something that could only work and be unique for Curecoin and could attract people previously not familiar with cryptocurrencies.

Could be something in the lines of " 100Cur will help solves 10 WU's". I guess technically it would have to be in the form of pre printed paper wallets where the private key is scratchable like a lottery ticket or smth and the amount of Cures and WU's could be printed on at the point of the sale. You could create a fund where these would be financed from initially and buy back what ever was sold during the day from the markets at every evening. Obviously a public ledger with addresses and balances would have to be kept. Would be great if the gift card could be digital also but I dont have an idea how to deal with the private keys then.

Some sort of effort clearly has to be made to market the coin as these days it's unfortunately not working on the principle "If you build it, they will come".

I'll chat with LasersHurt today about getting some more clarity on curecoin.net for the premine holdings.

Here's what jcoffland said about certificates:

"The first thing I would ask of the CureCoin project, is to make it 100% clear to those in the folding team that they should not get angry with Folding@home if there is a problem with their points. Naturally we are happy to help and do our best to resolve problems with points but we have limited resources. We already deal regularly with people angry about points. Now that they might be worth real money there's a real possibility of people freaking out and giving us hell over the mistakes that can and do happen. This should be one of the first items on your knowledge base page.

Secondly, CureCoin should work with us to create a CureCoin 2.0 where signed certificates issued by Stanford which represent points are accepted directly into the CureCoin blockchain. This would eliminate the possibility of incorrectly allocating CureCoins on the CureCoin side. Securing the work servers could be handled by Stanford issuing an allocation of CureCoin points to work servers which they could grant to users for folding power. All secured with public-key crypto. After these changes the only point of failure would be at Stanford and could be kept under close guard. However, I must point out that I cannot guarantee that the Pande Lab will choose to allocate resources to this. That's not up to me.

If CureCoin can address the first issue ASAP and start working towards the second issue I would be greatly appeased."

As for his first point about the separation between F@H and Curecoin, I feel we have fairly well shown the distinction between the two projects, however it couldn't hurt to add some sort of thing on the pool, like a banner.

For his signed certificate idea, it appears to be quite interesting on the surface, and is actually similar to another idea I had proposed a while ago which Josh and I decided wasn't likely feasible. If the certificates representing some value of points were assigned Stanford-side, maybe introduced to the network by a trusted node setup or private/public key confirmation, they could be accepted into the blockchain. However, depending on the implementation of this idea, it could cause significant blockchain bloat. I can think of three ways this would work (though I'm sure I'm missing some awesome ideas here):

1.) Stanford signs a certificate for each submitted WU, credits the points to the username, which could be recorded in the blockchain as an alias. Obvious blockchain bloat, as blockchain size scales linearly with increases in folding power.

2.) Stanford signs a certificate daily for each user, credits the points to the username, blockchain alias, etc. Much smaller blockchain bloat, scales in a linear fashion with increase in users rather than in folding power.

3.) Stanford signs a certificate daily for total coins minted, signing those coins over to a public address. Payouts then occur from there. No benefit derived over a simple block subsidy, except keeping a consistent flow of coins.

If we were to go this route, my personal choice would be #2. A few things would need to be in place for such a system to work:
--> Central trusted method of introducing certificates to network. I'd opt for a commonly-known public key, and then certificates signed by a private key. Each certificate would be trivial to confirm authenticity of, and then a transaction could be deterministically produced and confirmed by any node on the network. An alternate method which I would suggest against would involve a centralized node structure.
--> A rewrite of various components of the coin to shift mintage over to a certificate-based and PoW hybrid system.
--> A method of migrating current balances to the new system.

There are several different options for migrating balances to the new network system. A change could be implemented which, at a certain block, hard-forked and began creating block subsidies or something of the like based off of certificates. Alternately, it may make more sense to build a brand new network, and migrate existing balances over. This could occur in a centralized manner where a premine is created on the new chain and user balances are manually converted, or the new network could use the same addressing method where private keys are valid on both networks, and as a result an automated system could crawl the curecoin blockchain at a certain, planned block for *all* balances, and send out new coins proportionally.

One other obstacle which jcoff alluded to in his post dealt with the willingness of Stanford to integrate with Curecoin. Currently, Stanford (specifically Pande Labs) views the Curecoin project in a positive light, but is, as would be expected, distancing themselves from it for the time being, and giving no official endorsement. We of course contacted Pande labs months prior to the launch of Curecoin, and at the time any integration beyond our access to public statistics was mostly ruled out. As the Curecoin project evolves, there is of course the possibility of Pande Labs being open to higher levels of integration, at which point this certificate idea would become much more feasible.

Another point to note is that such an integration would likely remove the coin's ability to add additional distributed computing projects in the future. Not a deal breaker, but something to consider.

If this certificate idea becomes integrated, it might make more sense to create an entirely new coin without basing it on existing source code, so that "Curecoin 2.0" would be built from the ground up around certificate-based coin mintage, and also to provide a simpler platform for forks of that new source to merge-fold with us. Food for thought.

We have considered the idea of selling Curecoins at the booth, but unfortunately we don't believe the sale of a digital currency like Curecoin from a central source like a booth is legal (in the USA, at least) without appropriate licensing, which we don't have. We will be giving out Curecoins at the booth though!