[ANN] CureCoin 2.0 is live - Mandatory Update is available now - DEC 2018

[merc84]

Everything has gone very silent for the past few weeks any news on progress towards next test release for CC2.0?

In about a week and a half, I'll push out another alpha revision that fixes issues found during 2.0.0a1 (occasional desynchronization, and a cosmetic issue with the miner, which really doesn't matter) and adds the binary radix tree (or binary-radix-tree-inspired) block content (and enforces it properly), some new code to handle adding additional peers, and a lightweight GUI.

Been almost a month any update?

Yup, 2.0.0a3 now up for public testing:

http://1.curecoinmirror.com/2.0.0a3/2.0.0a3.zip

Major changes include the fledling hooks for block explorers, as well as all of the required RPC commands for a GUI to function. A 2.0.0a3 GUI is included in the download, though it has a bit of design evolution left before final release.

Forgive my ignorance but how does one run this???

[Vorksholk]

Everything has gone very silent for the past few weeks any news on progress towards next test release for CC2.0?

In about a week and a half, I'll push out another alpha revision that fixes issues found during 2.0.0a1 (occasional desynchronization, and a cosmetic issue with the miner, which really doesn't matter) and adds the binary radix tree (or binary-radix-tree-inspired) block content (and enforces it properly), some new code to handle adding additional peers, and a lightweight GUI.

Been almost a month any update?

Yup, 2.0.0a3 now up for public testing:

http://1.curecoinmirror.com/2.0.0a3/2.0.0a3.zip

Major changes include the fledling hooks for block explorers, as well as all of the required RPC commands for a GUI to function. A 2.0.0a3 GUI is included in the download, though it has a bit of design evolution left before final release.

Forgive my ignorance but how does one run this???

Ahh right, the old instructions got buried. Inside that zip file, you'll find four Jar files:
2.0.0a3.jar
2.0.0a3Miner.jar
2.0.0a3Client.jar
2.0.0a3GUI.jar

First, double-click on 2.0.0a3.jar to start the 'core' or daemon, similar to bitcoind. Then, you can start up 2.0.0a3Miner.jar to mine (simulating returning WUs for certificates with a certificate server, similar to what a research institution will eventually run). Then, you can run either 2.0.0a3Client.jar to interface with the 2.0.0a3 daemon, or you can use the 2.0.0a3GUI to do so in a similar fashion to Bitcoin-Qt. If you don't want to mine, just PM me your testnet address and I'll send you some testnet coins

[merc84]

Thanks got it running however it seems to have frozen after finding first testnet block.

Current hash rate: 52 KH/s of 12 x SHA256
     Mined 0 blocks.
SHA256(Wv80hdeEfIOI186331570, 12) = 000000DC30D7F2FB824EB87B34AC968724E535658D5C
7CFBE348F1509EE728FF
Submitting Wv80hdeEfIOI186331570 to work server...

Attempting to add block...
got data: BLOCK {1435103449008:427:959C9...E53g9n2eiKmmskCji6nSalw=},{28}
Attempting to add block...
got data: BLOCK {1435105596945:428:E2FC9...E53g9n2eiKmmskCji6nSalw=},{29}
Attempting to add block...
got data: BLOCK {1435105997250:429:0ABA0...E53g9n2eiKmmskCji6nSalw=},{30}
Attempting to add block...
got data: BLOCK {1435106133650:430:A97CC...E53g9n2eiKmmskCji6nSalw=},{31}
Attempting to add block...
got data: BLOCK {1435106606586:431:13945...E53g9n2eiKmmskCji6nSalw=},{32}
Attempting to add block...
got data: BLOCK {1435107966622:432:40CBB...E53g9n2eiKmmskCji6nSalw=},{33}
Attempting to add block...
got data: BLOCK {1435108311962:433:30000...E53g9n2eiKmmskCji6nSalw=},{34}
Attempting to add block...
got data: BLOCK {1435108534737:434:5D23C...E53g9n2eiKmmskCji6nSalw=},{35}
Attempting to add block...
got data: BLOCK {1435109154496:435:1395E...E53g9n2eiKmmskCji6nSalw=},{36}
Attempting to add block...

[merc84]

My stats don't seem to be updating on http://stats.curecoinfolding.com/daily.html been stuck at 10027 points since yesterday. Here u can see I have submitted many more Wu's than that http://folding.extremeoverclocking.com/user_summary.php?s=&u=681038

[artoar_11]

My stats don't seem to be updating on http://stats.curecoinfolding.com/daily.html been stuck at 10027 points since yesterday. Here u can see I have submitted many more Wu's than that http://folding.extremeoverclocking.com/user_summary.php?s=&u=681038

In the pool the past three days I see the same values (do not change):

Your 24 Hour Folding Points
Valid: 372505

Current Payout Est.
59.32342845 CURE

But the transactions are updated.

[Vorksholk]

My stats don't seem to be updating on http://stats.curecoinfolding.com/daily.html been stuck at 10027 points since yesterday. Here u can see I have submitted many more Wu's than that http://folding.extremeoverclocking.com/user_summary.php?s=&u=681038

That's weird, I'll keep an eye on it today and see if it changes. Server might need a restart.

My stats don't seem to be updating on http://stats.curecoinfolding.com/daily.html been stuck at 10027 points since yesterday. Here u can see I have submitted many more Wu's than that http://folding.extremeoverclocking.com/user_summary.php?s=&u=681038

In the pool the past three days I see the same values (do not change):

Your 24 Hour Folding Points
Valid: 372505

Current Payout Est.
59.32342845 CURE

But the transactions are updated.

Are you getting the correct number of Curecoins to your wallet?

Josh is putting a ton of work into getting our new pool up and running, no ETA but we should be launching it soon The frontend might be a bit whacked, cause he's been freezing and converting some MySQL tables to the new format.

[artoar_11]

In the pool the past three days I see the same values (do not change):

Your 24 Hour Folding Points
Valid: 372505

Current Payout Est.
59.32342845 CURE

But the transactions are updated.

Are you getting the correct number of Curecoins to your wallet?

Josh is putting a ton of work into getting our new pool up and running, no ETA but we should be launching it soon The frontend might be a bit whacked, cause he's been freezing and converting some MySQL tables to the new format.

Today in the pool:

Your 24 Hour Folding Points
Valid: blank (?)

Current Payout Est.
35.53188704 CURE

in PAYOUT / TRANSACTION LOG: | 2015-09-29 00:00:41 |.....| Block # - blank | Amount - 30.662781

In Team Stats - CURECOIN REWARDS: | artoar_home | 35.53188704 | 0.35890796

In the wallet:
| 09.29.2015 07:01 |....| Amount - 30.662781
| 09.29.2015 06:09 |....| Amount - 30.662781 (?)
| 09.29.2015 04:13 |....| Amount - 60.590095 (?)

Is not problem 5-10-20 CURE (+/-), but to fix if there is a bug (or whatever it is).

[SalimNagamato]

why price so low... what is the problem with this coin ??

[merc84]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

[SalimNagamato]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

[d0om]

Has anybody else had issues with the F@Home client on windows? Namely when the computer goes to sleep.

[wilding2004]

Has anybody else had issues with the F@Home client on windows? Namely when the computer goes to sleep.

I'm guessing you're folding on a GPU? That doesnt work with sleep mode, due to the way windows backs up memory. Main Ram is cached, so CPU folding works ok - but GPU ram is is not preserved during sleep, so the client fails. It's not a problem with the client, just the way windows handles things when is goes into sleep mode.

[merc84]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

No but the new version will remove the sha256 mining component for certificates which can be issued by university etc.

[asphout]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

No but the new version will remove the sha256 mining component for certificates which can be issued by university etc.

Smiley faces on the website or not---selling folder-donated CURE on markets and donating the USD to stanford is not helping folders.  It should go to more dev or it should be burned.  Not dumped and donated to stanford.

Reading _future_ talk in the thread, it sounds all backwards.  Entities who need collective computing power will be able to create more CURE?  Shouldn't they be buying CURE and using it to pay for computing power?  We need to rethink this, or we're going to just end up with feel-good Points Per Day and CURE Per Day.

[d0om]

Has anybody else had issues with the F@Home client on windows? Namely when the computer goes to sleep.

I'm guessing you're folding on a GPU? That doesnt work with sleep mode, due to the way windows backs up memory. Main Ram is cached, so CPU folding works ok - but GPU ram is is not preserved during sleep, so the client fails. It's not a problem with the client, just the way windows handles things when is goes into sleep mode.

Yup, you got it. Thanks for the response!

[merc84]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

No but the new version will remove the sha256 mining component for certificates which can be issued by university etc.

Smiley faces on the website or not---selling folder-donated CURE on markets and donating the USD to stanford is not helping folders.  It should go to more dev or it should be burned.  Not dumped and donated to stanford.

Reading _future_ talk in the thread, it sounds all backwards.  Entities who need collective computing power will be able to create more CURE?  Shouldn't they be buying CURE and using it to pay for computing power?  We need to rethink this, or we're going to just end up with feel-good Points Per Day and CURE Per Day.

They won't be creating additional coins but issuing certificates for already existing cure that was originally intended for the mining/folding components of cure.

[Vorksholk]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

No but the new version will remove the sha256 mining component for certificates which can be issued by university etc.

Smiley faces on the website or not---selling folder-donated CURE on markets and donating the USD to stanford is not helping folders.  It should go to more dev or it should be burned.  Not dumped and donated to stanford.

Reading _future_ talk in the thread, it sounds all backwards.  Entities who need collective computing power will be able to create more CURE?  Shouldn't they be buying CURE and using it to pay for computing power?  We need to rethink this, or we're going to just end up with feel-good Points Per Day and CURE Per Day.

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.

[asphout]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

No but the new version will remove the sha256 mining component for certificates which can be issued by university etc.

Smiley faces on the website or not---selling folder-donated CURE on markets and donating the USD to stanford is not helping folders.  It should go to more dev or it should be burned.  Not dumped and donated to stanford.

Reading _future_ talk in the thread, it sounds all backwards.  Entities who need collective computing power will be able to create more CURE?  Shouldn't they be buying CURE and using it to pay for computing power?  We need to rethink this, or we're going to just end up with feel-good Points Per Day and CURE Per Day.

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.

merc84 and Vorksholk, thank you both for your responses.  Very helpful. 

I've been folding altruistically for some time.  CURE being a way to recoup some of my electric/equipment costs has allowed me to increase my output tremendously.  For that, i sincerely thank the entire CURE community.  My criticism is only for the sake of improvement.  I believe in the cause, I believe in the currency, and I appreciate all of the hard work that has created CURE.

I still believe selling CURE for USD and donating it to stanford harms the folders/markets more than it benefits stanford.  Folders are already donating their comp/elec.  There's a finite amount of BTC being injected into the CURE market.  The more of it which goes to stanford, the less of it there is to offset folders' costs.  If anything, stanford should be receiving donations in the form of CURE, which they can redistribute to the folding pool.  Ideally, though, donations to the Curecoin project would be in the form of BTC. 

Hands down, the best way to donate to the Curecoin project and support its folders/research is to buy CURE with BTC on the exchange(s). 

I'm getting ahead of myself, though...  Consider this in support of the above:

The product already exists, the currency already exists, they're just not reciprocal at the moment. 

Allow me to present a scenario.  For simplicity, let's call universities/pharma corporations/etc. "entities" and those who are providing computational power "folders"---even though it might not be "folding;" rather something else which requires CPU/GPU distributed computing power.  Anyway, "entities" and "folders."   

Let's say there are 3 entities interested in distributing CURE in exchange for computing power.  entity 1, stanford (cancer, etc.); entity 2, pharmacorp xyz (antibiotic-resistant bacterial evolution); entity 3, university of nebraska (agricultural diseases, weather patterns).  Let's say that each entity is authorized to sign certificates to distribute <base> CURE/day to their folders.  At <base> CURE/entitiy/day; what drives folders to choose entities?  Most likely the reason we all began folding in the first place---to donate time/money to help a field of research.  For reciprocity, I contend the following:

1.  Folder donations should be sent to entities in the form of CURE. 
2.  Entities should be allowed/encouraged to use BTC to purchase CURE from exchanges.

The above would allow entities to obtain CURE to use as they see fit.  Sell it, burn it, or (most likely) (re)distribute it to their folding pool. 

An entity's <distribution> = (<base> + <donations> + <purchases>) 

<donations> would allow folders/others to encourage additional allocation of folding resources to the research entitie(s) of their choice. 

<purchases> from exchanges would allow entities to add to their pool, enticing a higher allocation of resources to their pool.

Additionally, the above (especially <purchases>) would tie together the currency with the product.  The price would become tied less to speculation; more to cost of production and value of product.

Of course, one might argue that pharmacorp xyz would buy its own rigs for privacy, but let's say they found it to be cost-effective to use folders for the sake of this scenario/discussion---that way, I can present the following question:  Will this scenario allow entity 2 (phramacorp xyz) to out purchase the other entities and hog the folding resources?  No.  For a few reasons:  <base> will still be distributed by all entities.  It's safe to assume that increases to entity 2's <purchases> would increase their share of folding allocation, but entity 1 and entity 3 would still attract folders from <base> and keep their altruistic/loyal folders.  By loyal, i mean the folders have ties to the entity (e.g., graduated from the university of nebraska).  Buying a reasonable amount of CURE would help pharmacorp xyz keep its production above that of the others, but even if they bought an obscene amount of CURE, the others would still have folders because of <base>, altruism, loyalty, and <donations> (most likely primarily from people getting CURE from pharmacorp xyz's pool).  They would find a balance which works best for them, but ultimately, the more BTC being spent on CURE, the more folders the CURE market can support.  Also, the minting process stemming from <base> will help keep this in balance.

To paraphrase Vorsholk:  Curecoin isn't so much about turning profits as it is about offsetting costs.

I agree.  Very simply, an increase in the flow of BTC to CURE will increase CURE's overall cost-offsetting potential.  Let's call these folders "sustainable folders."

If the only BTC being injected into CURE is from donors and speculators/investors, then the number of sustainable folders recouping their costs will be less than if BTC is being injected by a reciprocation of CURE between entities and folders, coupled with BTC being injected into CURE from entities, donors, and speculators/investors.

The majority of folders are already folding altruistically (to stanford) and loyally (to their Team).  If the goal is to increase the overall folding power available for entities by increasing the capacity for sustainable folders, then I believe some of these ideas will aid in tapping into an additional demographic, without reducing the number altruistic folders (by definition).  Perhaps most importantly, it will allow existing folders to increase their output without sacrificing sustainability.

Team Curecoin has climbed the team ladder quickly on only a trickle of BTC.  Ballpark'ing recent Curecoin Team production (24hr Avg ~46m PPD):  If 1 PPD results in ~.0001700 CURE/day; then for a folder to offset elec costs (GPU, Air Conditioner), depreciation of equipment, etc., he/she might need CURE prices ~.00007500 BTC for an efficient rig.  For an inefficient rig, maybe ~.00015000 BTC.

Can an intermittent trickle of BTC support ~46m PPD?  If not, how much?  more?  less?  Looking at recent CURE prices, i'd say less.

Now, imagine a steady stream of BTC...

[Vorksholk]

why price so low... what is the problem with this coin ??

Nothing.
I think the real question is what is wrong with the crypto community, here we have a viable alt that replaces the waste of computing resources for pointless pow clones yet we have very little market interest. Probably the bottom line is alot of the big players in crypto are just in it to line their fiat wallets and not for the ideals of crypto itself.

hopefully there will be better future for Curecoin
will the new version be POS only ?

No but the new version will remove the sha256 mining component for certificates which can be issued by university etc.

Smiley faces on the website or not---selling folder-donated CURE on markets and donating the USD to stanford is not helping folders.  It should go to more dev or it should be burned.  Not dumped and donated to stanford.

Reading _future_ talk in the thread, it sounds all backwards.  Entities who need collective computing power will be able to create more CURE?  Shouldn't they be buying CURE and using it to pay for computing power?  We need to rethink this, or we're going to just end up with feel-good Points Per Day and CURE Per Day.

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.

merc84 and Vorksholk, thank you both for your responses.  Very helpful. 

I've been folding altruistically for some time.  CURE being a way to recoup some of my electric/equipment costs has allowed me to increase my output tremendously.  For that, i sincerely thank the entire CURE community.  My criticism is only for the sake of improvement.  I believe in the cause, I believe in the currency, and I appreciate all of the hard work that has created CURE.

I still believe selling CURE for USD and donating it to stanford harms the folders/markets more than it benefits stanford.  Folders are already donating their comp/elec.  There's a finite amount of BTC being injected into the CURE market.  The more of it which goes to stanford, the less of it there is to offset folders' costs.  If anything, stanford should be receiving donations in the form of CURE, which they can redistribute to the folding pool.  Ideally, though, donations to the Curecoin project would be in the form of BTC. 

Hands down, the best way to donate to the Curecoin project and support its folders/research is to buy CURE with BTC on the exchange(s). 

I'm getting ahead of myself, though...  Consider this in support of the above:

The product already exists, the currency already exists, they're just not reciprocal at the moment. 

Allow me to present a scenario.  For simplicity, let's call universities/pharma corporations/etc. "entities" and those who are providing computational power "folders"---even though it might not be "folding;" rather something else which requires CPU/GPU distributed computing power.  Anyway, "entities" and "folders."   

Let's say there are 3 entities interested in distributing CURE in exchange for computing power.  entity 1, stanford (cancer, etc.); entity 2, pharmacorp xyz (antibiotic-resistant bacterial evolution); entity 3, university of nebraska (agricultural diseases, weather patterns).  Let's say that each entity is authorized to sign certificates to distribute <base> CURE/day to their folders.  At <base> CURE/entitiy/day; what drives folders to choose entities?  Most likely the reason we all began folding in the first place---to donate time/money to help a field of research.  For reciprocity, I contend the following:

1.  Folder donations should be sent to entities in the form of CURE. 
2.  Entities should be allowed/encouraged to use BTC to purchase CURE from exchanges.

The above would allow entities to obtain CURE to use as they see fit.  Sell it, burn it, or (most likely) (re)distribute it to their folding pool. 

An entity's <distribution> = (<base> + <donations> + <purchases>) 

<donations> would allow folders/others to encourage additional allocation of folding resources to the research entitie(s) of their choice. 

<purchases> from exchanges would allow entities to add to their pool, enticing a higher allocation of resources to their pool.

Additionally, the above (especially <purchases>) would tie together the currency with the product.  The price would become tied less to speculation; more to cost of production and value of product.

Of course, one might argue that pharmacorp xyz would buy its own rigs for privacy, but let's say they found it to be cost-effective to use folders for the sake of this scenario/discussion---that way, I can present the following question:  Will this scenario allow entity 2 (phramacorp xyz) to out purchase the other entities and hog the folding resources?  No.  For a few reasons:  <base> will still be distributed by all entities.  It's safe to assume that increases to entity 2's <purchases> would increase their share of folding allocation, but entity 1 and entity 3 would still attract folders from <base> and keep their altruistic/loyal folders.  By loyal, i mean the folders have ties to the entity (e.g., graduated from the university of nebraska).  Buying a reasonable amount of CURE would help pharmacorp xyz keep its production above that of the others, but even if they bought an obscene amount of CURE, the others would still have folders because of <base>, altruism, loyalty, and <donations> (most likely primarily from people getting CURE from pharmacorp xyz's pool).  They would find a balance which works best for them, but ultimately, the more BTC being spent on CURE, the more folders the CURE market can support.  Also, the minting process stemming from <base> will help keep this in balance.

To paraphrase Vorsholk:  Curecoin isn't so much about turning profits as it is about offsetting costs.

I agree.  Very simply, an increase in the flow of BTC to CURE will increase CURE's overall cost-offsetting potential.  Let's call these folders "sustainable folders."

If the only BTC being injected into CURE is from donors and speculators/investors, then the number of sustainable folders recouping their costs will be less than if BTC is being injected by a reciprocation of CURE between entities and folders, coupled with BTC being injected into CURE from entities, donors, and speculators/investors.

The majority of folders are already folding altruistically (to stanford) and loyally (to their Team).  If the goal is to increase the overall folding power available for entities by increasing the capacity for sustainable folders, then I believe some of these ideas will aid in tapping into an additional demographic, without reducing the number altruistic folders (by definition).  Perhaps most importantly, it will allow existing folders to increase their output without sacrificing sustainability.

Team Curecoin has climbed the team ladder quickly on only a trickle of BTC.  Ballpark'ing recent Curecoin Team production (24hr Avg ~46m PPD):  If 1 PPD results in ~.0001700 CURE/day; then for a folder to offset elec costs (GPU, Air Conditioner), depreciation of equipment, etc., he/she might need CURE prices ~.00007500 BTC for an efficient rig.  For an inefficient rig, maybe ~.00015000 BTC.

Can an intermittent trickle of BTC support ~46m PPD?  If not, how much?  more?  less?  Looking at recent CURE prices, i'd say less.

Now, imagine a steady stream of BTC...

Thank you for explaining this model in detail--allocating donations to augment DCN payouts makes a lot of sense, in effect taking advantage of some sort of money-multiplier-like behavior, given that folding doesn't have to offset ALL of the costs of folding, as people will still fold at slight losses for altruistic purposes.

As for your point on pharma companies purchasing Curecoins to crowdsource computational power, this is an idea that has been discussed a bit before internally, and the conclusion boiled down to we'll only provide signature authority to DCNs that meet certain criteria: not-for-profit, public results, and science that we (and the community) deem as valuable for improving society (biomedicine topping that list). However, nothing would prevent pharma from directly purchasing Curecoin, and distributing it in a centralized manner, it just wouldn't be generated as coinbase. Not that the discussion on this topic is at all closed, but those are the conclusions we reached in a discussion months ago. It might make sense to allow pharma companies to create blocks, but have these blocks have coinbases that have to be funded from pre-existing coins, such that the network is further decentralized, but for-profit institutes need to buy the Curecoins from the community, which in turn further promotes non-profit research. Such a choice wouldn't change the coin supply, so it wouldn't "steal" computational power from non-profits (in the long run, there's always friction to consider), and would likely encourage additional hardware investment given the sounder footing of the Curecoin ecosystem. Just my ฿0.02, I'm not an economist by any means.

Your argument makes a lot of sense, I forwarded it to the rest of the team members to get their input, perhaps future fundraisers will be worked a bit differently
At the least, I think it'd be nice if we were to provide the option directly to donors--choosing either to allocate their donation towards DCN infrastructure (like it works now), or to allocate it towards adding to the rewards offered directly to folders (or whatever other activity the DCN does, like molecular modeling, genetic algorithms for drug candidates, etc.) in exchange for their work.

It's a very interesting way to

[ryohazuki89]

We need to rethink this, or we're going to just end up with feel-good Points Per Day and CURE Per Day.

I have so much feel good points, YES! I am never selling them.