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

[smarthuman]

I sell Steam/Desura keys for Curecoin: http://a-bit-help.beepworld.de/ .

[1714002712]

1714002712

[1714002712]

1714002712

[1714002712]

1714002712

[SalimNagamato]

I sell Steam/Desura keys for Curecoin: http://a-bit-help.beepworld.de/ .

good. thanks
a way to make a currency valuable, is to accept it as payment.

[Vorksholk]

Hey everyone, update within the next week or so to the 2.0 alpha testing which will include PoS.

[smarthuman]

I sell Steam/Desura keys for Curecoin: http://a-bit-help.beepworld.de/ .

good. thanks
a way to make a currency valuable, is to accept it as payment.

I find it quite sad, that so few especial charity oriented groups like: Blender, groupees and Humble Bundle. Even most hardware seller don´t accept it.

[SalimNagamato]

I sell Steam/Desura keys for Curecoin: http://a-bit-help.beepworld.de/ .

good. thanks
a way to make a currency valuable, is to accept it as payment.

I find it quite sad, that so few especial charity oriented groups like: Blender, groupees and Humble Bundle. Even most hardware seller don´t accept it.

imagine overstock
would be nice to buy a new shoes for winter using curecoin

[cryptohunter]

I sell Steam/Desura keys for Curecoin: http://a-bit-help.beepworld.de/ .

good. thanks
a way to make a currency valuable, is to accept it as payment.

I find it quite sad, that so few especial charity oriented groups like: Blender, groupees and Humble Bundle. Even most hardware seller don´t accept it.

exactly if the currency was totally transparent and had a larger following i think a lot of places would certainly consider accepting it.

[smarthuman]

I sell Steam/Desura keys for Curecoin: http://a-bit-help.beepworld.de/ .

good. thanks
a way to make a currency valuable, is to accept it as payment.

I find it quite sad, that so few especial charity oriented groups like: Blender, groupees and Humble Bundle. Even most hardware seller don´t accept it.

exactly if the currency was totally transparent and had a larger following i think a lot of places would certainly consider accepting it.

To be honest Bitcoin isn´t much more transparent and they dont use Gridcoin, Foldingcoin or Primecoine, not even Lightcoin, Dogecoin or devcoin.

[DevShuster]

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...

Perhaps there would be a way to insert a work unit (wu) into the stream of work units issued by the institutions once in a great while, perhaps 1 in every 1,000 work units, which has a measured, or known, difficulty.  If the university processes this wu and consistently and assigns too many points to them, then the devs, and the part of the public that can interpret the data, will know that something appears to amiss, and the institution will warrant investigation, with possible suspension from the Curecoin program, or perhaps just an adjustment to the number of points rewarded.

This same type of wu may be used eventually in case of selling processing time to pharma for Curecoin purchased or burned, as they could audit the data and all parties could be assured of receiving their value.  As usual, if this seems like a viable idea, I request that it be added to the list of things to do after the release of CC 2.0.

[huffnpuff]

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...

Perhaps there would be a way to insert a work unit (wu) into the stream of work units issued by the institutions once in a great while, perhaps 1 in every 1,000 work units, which has a measured, or known, difficulty.  If the university processes this wu and consistently and assigns too many points to them, then the devs, and the part of the public that can interpret the data, will know that something appears to amiss, and the institution will warrant investigation, with possible suspension from the Curecoin program, or perhaps just an adjustment to the number of points rewarded.

This same type of wu may be used eventually in case of selling processing time to pharma for Curecoin purchased or burned, as they could audit the data and all parties could be assured of receiving their value.  As usual, if this seems like a viable idea, I request that it be added to the list of things to do after the release of CC 2.0.

There will be a more official announcement on the ANN, but checkout the latest forum post:
Coinpayments to accept CureCoin with up to 18065 participating vendors
this is really good progress from both liquidity and marketability perspectives of CureCoin 1.2

[SalimNagamato]

is it possible to use coinpayments in a shop website, and accept explicitly Curecoin ?
 

[cygnusxi]

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...

Perhaps there would be a way to insert a work unit (wu) into the stream of work units issued by the institutions once in a great while, perhaps 1 in every 1,000 work units, which has a measured, or known, difficulty.  If the university processes this wu and consistently and assigns too many points to them, then the devs, and the part of the public that can interpret the data, will know that something appears to amiss, and the institution will warrant investigation, with possible suspension from the Curecoin program, or perhaps just an adjustment to the number of points rewarded.

This same type of wu may be used eventually in case of selling processing time to pharma for Curecoin purchased or burned, as they could audit the data and all parties could be assured of receiving their value.  As usual, if this seems like a viable idea, I request that it be added to the list of things to do after the release of CC 2.0.

There will be a more official announcement on the ANN, but checkout the latest forum post:
Coinpayments to accept CureCoin with up to 18065 participating vendors
this is really good progress from both liquidity and marketability perspectives of CureCoin 1.2

Hey guys, massive re-quote post we have going, I'll touch on a few items here.

First point, that last post about integration with coinpayments.net is a pretty big step forward. Curecoin is moving from its adolescent stage of a coin that can only be converted into btc to its fully grown currency where you will be able to spend curecoins directly on many different items. This alone is known to make coins worth more once they have merchants accepting them.

2nd point, its true that curecoin had been an excellent offset to allow folders to fold more, but that is not necessarily the end game. Curecoin price has recently spiked to 2.1 cents per coin. If you have updated hardware like a gtx 980 (or a few of them ) the point of hitting profit is getting really close. This is even with my higher than many states kwh prices @ 25 cents per kwh.

Now I know a computer science professor down in texas that just got serious with folding on a 3 gpu r9 series rig. He pays only 10 cents per kwh and has free electric on weekends. I have not yet done the math on his rig but he just might be pulling a profit from folding! He also intends to write another book on computer science and is going to include curecoin in it. He is even planning on doing a few short lessons in his class about curecoin. All good stuff there.

3rd point. There is indeed a burn address for curecoin. Here is the burn address BCurecoinEater1111111111111XavDMqR . It has not had a lot of use because I was building a certificate (printable, not encrypted   ) that will be rewarded to people who burn a certain amount of curecoins. Something you can print and hang behind your office desk next to your folding score certificate. Now what will make this unique, is that these will be like carbon offsets, but they are scientific research offsets, and unlike carbon that can be constantly pumped into the air you can not undo science. So in effect its more solid of an offset than the said carbon offset. That being said, those certificates of scientific offset could hold value in themselves. Each one will have the the TXid on it, and optionally your folding@home user name. These unique research offsets will be privately emailed to anyone looking to get one. All the while increasing scarcity of the coin. Contact me on the curecoin.net/forum if you want to get one of these.

Last point. Just a sweet and simple one. When it comes to difficulty of a work unit for a single DCN system like is currently in place, it is very much like the randomness of how long it takes to crack a block of btc. In the long run it evens out. For integration with other DCNs we have already done some pretty extensive benchmarking to get accurate calcuations of what is fair comparing one DCN to another. This will all be fine tunable also as DCNs evolve over time.

Hope that clears up a few questions, and dont forget, the more people that fold, the higher the scarcity, just like with btc, more miners = more scarcity = more value. With the proper mix of community and services, investors, and folders, Curecoin is on track to make folding a profitable event, possibly even create jobs for folding farms just like btc did. Please sign up for the curecoin forum and become a part of the community there to help us see citizen science become synergistic.

Cheers and happy folding, and many thanks to all the supporters out there, your support is very much appreciated!  

-Josh AKA CygnusXI

 

[cygnusxi]

is it possible to use coinpayments in a shop website, and accept explicitly Curecoin ?
 

Yes indeed it is 

[cygnusxi]

Integration with Coinpayments.net is complete, you can now set up a store that accepts curecoins through a long standing payment processor that includes tools for many common packages like wordpress, oscommerce, drupal, etc.

Its as easy as a simple plugin install, or you can make single use buttons.

If you would like to try it out, try making a small purchase at cloudfolding.curecoin.net . Min purchase there is ~1.40 usd.

If you are already a website vendor using coinpayments.net , please consider adding curecoin to your accepted list of coins  

Cheers
Josh AKA CygnusXI

[BTCTT]

Integration with Coinpayments.net is complete, you can now set up a store that accepts curecoins through a long standing payment processor that includes tools for many common packages like wordpress, oscommerce, drupal, etc.

Its as easy as a simple plugin install, or you can make single use buttons.

If you would like to try it out, try making a small purchase at cloudfolding.curecoin.net . Min purchase there is ~1.40 usd.

If you are already a website vendor using coinpayments.net , please consider adding curecoin to your accepted list of coins  

Cheers
Josh AKA CygnusXI

That's good news, is there a list of Curecoin shops?

thanks

[huffnpuff]

That's good news, is there a list of Curecoin shops?

thanks
[/quote]

I'll try to answer this one. Since CureCoin was listed over the weekend; retail vendors, service providers and charities on Coinpayments will be notified of the addition of CureCoin on Monday November 9th. Then it's up to them individually to decide if they will accept CureCoin payments.

Since CureCoin has been running stable for over 18 months, and it's underlying cause of medical research is so vital and unique - adoption by vendors should be "expeditious". But there's no guarantee all 18000 vendors will accept CURE at once.

[BTCTT]

That's good news, is there a list of Curecoin shops?

thanks

I'll try to answer this one. Since CureCoin was listed over the weekend; retail vendors, service providers and charities on Coinpayments will be notified of the addition of CureCoin on Monday November 9th. Then it's up to them individually to decide if they will accept CureCoin payments.

Since CureCoin has been running stable for over 18 months, and it's underlying cause of medical research is so vital and unique - adoption by vendors should be "expeditious". But there's no guarantee all 18000 vendors will accept CURE at once.
[/quote]

It might be an idea to add all the shops who already do in the OP and update frequently.

[Vorksholk]

If anyone's interested, I pushed the first wave of PoS updates to github, which are in private testing. More updates to come soon.

[ie007cheung]

Why the site curecoin.us is not accessible?

If anyone's interested, I pushed the first wave of PoS updates to github, which are in private testing. More updates to come soon.

Thanks for the good work.

[merc84]

http://stats.curecoinfolding.com/daily.html is not showing any stats.

[altseeker]

If anyone's interested, I pushed the first wave of PoS updates to github, which are in private testing. More updates to come soon.

Great! looking forward for more updates.