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!