Almost every FLOSS software project in the world is underfunded.

Wikipedia (not quite FLOSS but similar) have to mislead users to get the amount of donations they get.

I recommend the devs hardfork to increase the development fund, be this by simply awarding themselves coins, or by increasing the % of new coins they get.

If that is so.. then why did you remove the link I had posted ?

Are you afraid of the information provided there ?

Do you mind if I call you Mr. Quack ?

The eventual goal of Curecoin isn't to create an environment where people generate a living from folding, but rather are able to offset their costs while improving the state of computational science. It's a different paradigm entirely: most altcoin mining aims to turn profits, Curecoin mining aims to offset costs. Neither is necessarily bad or good, simply different. It could certainly be argued that converting CURE to USD to donate to Stanford and other DCNs does less good than bad (as in, the price decrease in CureCoin turns more folders off from folding than the money helps to advance science by improving DCN internal architectures). As a team, we believe that the money donated to Stanford and other DCNs from donated Curecoin does far more to advance the state of computational science than a mild, temporary drop in price does to deter folders. It's a judgement call, and one that can't be simplified to a set of equations to solve for a net benefit or loss, unfortunately.

That being said, we are doing everything we can while converting the Curecoin to USD to donate to Stanford to not influence the market price--selling small quantities, selling at reasonable prices, etc.

As for future plans for 2.0, the same logic applies in a different manner: prioritizing net gains to computational science in that coin rewards are distributed from the institutes directly. Theoretically, this doesn't change the actual markets/equilibrium for Curecoin terribly much, it simply removes our position as "keepers" of the folding funds, further securing the network against any kind of compromise of our servers, and to alleviate people's concerns about us suddenly dumping a bunch of the folding-reserved Curecoin on the markets for self-benefit or whatever.

It does change the balance of power in the network, removing power from us the devs, and placing the ability to award coins in the hands of universities. There's still the potential for network abuse (as has been brought up and discussed before), but any system which awards coins based on some non-autonomously-verifiable PoW (like hashing, or finding primes). Ensuring work units were completed correctly isn't something the Curecoin network could feasibly do. In Bitcoin, peers who are verifying the block was solved correctly simply recompute the one winning hash with the provided golden nonce and additional state information to ensure the result falls under the target. If Curecoin were to behave in this way, the network would need every verifying peer to recompute the entire work unit. This means that, if one block on the network was released per minute (one of the considered speeds for 2.0), peers would have to verify 60 blocks per hour, or 60 WUs per hour. The (often MB-range, especially for something like GPUGrid) WUs would have to be stored on the network, broadcast to all (or many) peers, and the computation would have to finish in under a minute. Nodes could be specifically set to verify different WUs, but then the network has to trust anonymous peers. If we have some kind of Curecoin-controlled nodes which do the verification and are built to be beefy and capable of, between all of them, verifying WUs, then we're back to where we started, with trusting a third party (us). In the end, no individual could reasonably re-verify the whole blockchain (like they can with Bitcoin and derivatives) themselves, nor could they store the entire blockchain, even if they were able to download it.

And that doesn't even account for the non-deterministic nature of some WUs. Some WUs will yield marginally different results depending on the precision of the hardware they're running on, PRNGs seeded with system time, hell knows what else. This issue could, foreseeably, be fixed, but it still wouldn't fix the above computational mess.

If WUs were to be made shorter, it would reduce the size of the blockchain and time time it took to compute the WU, but there is a lower limit of reasonable WU size and execution time, considering the nature of the problems being approached. If WUs were made to take 10 seconds, it would be impossible to run any meaningful simulation--sometimes one single frame of simulation can take a considerably substantial period of time. And as models grow more advanced and account for more variables, this becomes even more difficult.

In the event that, instead of recomputing the WU to verify it, there was an algorithm (much like Stanford uses for determining WU validity) that could be run on peers, it would have to be included in the source code. This would reveal exactly how WUs are validated, and would open the algorithm up to people attempting to game it by submitting bogus WUs that still validate with the validation algorithm.

So the solution is to allow the DCNs to determine which WUs are valid, and then award Curecoins. However, to avoid just giving them a stack of Curecoins and hoping they treat them correctly, we instead give them the ability to sign certificates. This allows the network to see all of the coins "payed out" by a DCN, when they were created, etc. It also allows the network to impose rules on block generation, and allows us to make a near-bulletproof algorithm to prevent forking (requiring blocks to stack DCNs, so one DCN couldn't produce more than n (determined by an algorithm that adjusts to represent network state) blocks in a row, requiring a potential attacker to compromise multiple DCNs simultaneously to even *try* to fork the network). Finally, it gives a digital trail of assignment activity, which could be used if a DCN were to be investigated for unfairly assigning coins. Finally, network rules can dictate the balance of DCN mintage, and can be refined over time in response to community input (either to devs, or by a network voting system).

In 2.0, we the Devs would also have the ability to sign blocks, but these blocks would not contain any coinbase transaction--no way for us (or someone who forges our blocks, somehow) to make money--no coins would be mined with the blocks we make. They would just be there to help regulate the choppy seas of the network's block time erratic nature due to hashing functions determining winning 'tickets,' and add a further point of protection against network forks (like, a dev block could be required between every actual DCN block, so if someone were to fork the network more than one block, they would need to compromise our signature servers in addition to multiple DCNs simultaneously. That's tough.

Anyhow, a slight deviation from your initial question/remark, but I hope this helped clear up the decision to allow DCNs to sign blocks/initiate coin mintage.

As to your question as to why they don't buy Curecoins and use those to buy computational power--that system already exists. Any university could gather money and pay for supercomputing time, and run their workloads. The problem is they don't have a budget for doing this--and requiring them to pay for the Curecoin network's computation power would just add another avenue through which to purchase computational power. A network which allowed renting time on supercomputer-like resources is an awesome idea that's been attempted/discussed several times in other projects, but it's against the grain of what Curecoin's already trying to do.