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

[ChasingTheDream]

Yeah I'm actively trading now as well to try to increase the volume.

Edit:  I'm not sure how big a deal it would be to lose an exchange since we don't have much volume.  Forcing everyone onto one exchange might not be a bad thing since it would increase the volume on that exchange.  I prefer Bittrex over Poloniex though.

I'm curious why you prefer bittrex. I use bittrex a lot because it has an incredible number of coins, but it seems to me that poloniex is technically 'better'. Trade fees are 0.2% on polo and 0.25% on bit. Withdraw fees are generally lower on polo. Polo offers the ability to analyze your trades for each coin using special parameters to determine your average price. Charts are more smooth and detailed. Admins are more active in the chat, users are more active in the chat....

Higher volume on the coins I've traded which is only Curecoin and Dogecoin and I've never seen any downtime.  Never had any sort of problem what-so-ever.  At the time I'm typing this Poloniex appears to be down but I could reach it within 10 minutes.

I suspect I'll start moving over to Poloniex soon.  I have an account there.  I just prefer the GUI a bit more on Bittrex but either will work fine for my purposes.

Ironically it looks like the Dogecoin wallet is disabled on Bittrex now so I guess I can't say I've never seen an issue anymore...

[1714934741]

1714934741

[LasersHurt]

Hey everyone, just wanted to drop in here to note some fun changes. We're trying to create a bit of a better user experience by slowly bring our separate web elements into one domain and central branding.

The forum is now located on-site at CureCoin.net/forum. All existing topics and users should have been brought over without issue; that said, we converted from SMF to phpBB and rolled the login into the site's central system, so you might find you need to reset your password or something. If you have issues, visit the IRC chat for help and I'll get you squared away.

In the future, we'll bring the pool from cryptobullionpools.com to Pool.CureCoin.net as well (it forwards for now, if you happen to try the URL).

Pop on over to the forum, and breathe a little life into it - like a tender rose, it was a little shocked by the move.

[alicea]

Yeah I'm actively trading now as well to try to increase the volume.

Edit:  I'm not sure how big a deal it would be to lose an exchange since we don't have much volume.  Forcing everyone onto one exchange might not be a bad thing since it would increase the volume on that exchange.  I prefer Bittrex over Poloniex though.

I'm curious why you prefer bittrex. I use bittrex a lot because it has an incredible number of coins, but it seems to me that poloniex is technically 'better'.

Poloniex is better for sure!

[RENDERING]

Yeah I'm actively trading now as well to try to increase the volume.

Edit:  I'm not sure how big a deal it would be to lose an exchange since we don't have much volume.  Forcing everyone onto one exchange might not be a bad thing since it would increase the volume on that exchange.  I prefer Bittrex over Poloniex though.

I'm curious why you prefer bittrex. I use bittrex a lot because it has an incredible number of coins, but it seems to me that poloniex is technically 'better'.

Poloniex is better for sure!

Bittrex has a much larger audience and it is much easier on the eyes. Polo reminds me of 1998. Just cant get over it. :/

[alicea]

Yeah I'm actively trading now as well to try to increase the volume.

Edit:  I'm not sure how big a deal it would be to lose an exchange since we don't have much volume.  Forcing everyone onto one exchange might not be a bad thing since it would increase the volume on that exchange.  I prefer Bittrex over Poloniex though.

I'm curious why you prefer bittrex. I use bittrex a lot because it has an incredible number of coins, but it seems to me that poloniex is technically 'better'.

Poloniex is better for sure!

Bittrex has a much larger audience and it is much easier on the eyes. Polo reminds me of 1998. Just cant get over it. :/

Bittrex has gathered the audience by adding shitcoins as quick as possible and delisting them even faster (the thing c-cex does now). Poloniex (or Cryptsy) is more serious company.

[ryohazuki89]

Protein folding is not just about curing disease.. we should garner as much positive attention to protein folding as we possibly can. We should post this Ted Talk video on the website, or reiterate some of it... along with it are some important quotes from the video:

http://www.youtube.com/watch?v=zm-3kovWpNQ

"So obviously one thing that proteins are important for is for understanding health and curing disease. But the other thing that I want to make a case for you about is the prospect of us scaling up small world machines to the big world."

"There's huge prospects for scaling these up for solving problems having to do with water supply, health, energy, solar energy conversion, human transportation, information.. We see it on the micro scale, we should be able to make it work on the macro scale."

"The great thing about this field is that it's one of the rare cases in history where you can already see how a technology works in great detail before you've even developed it. We see it work on the smale scale, it's just a matter of "can we scale it up?". We just need to learn the principles, we just need to learn how to harness it, and conceivably it's a future you will see and we will all see if that happens."

[cryptoconomist]

Any news dev.

How are we getting along on the cc 2.0?

[Vorksholk]

Any news dev.

How are we getting along on the cc 2.0?

Going great! This weekend I'm finalizing the code for Merkle signatures (including the certificates used for folding mintage), and hopefully wrapping up the specs of the transaction formatting. The Curecoin 2.0 transaction system is fairly basic at this point.

On the in-progress list:
Blockchain database (need to optimize for performance and storage space)
Certificate formatting (this is more of just a final approval on the existing specifications we discussed months ago)
P2P Networking (a fair amount to do here)
GUI

Then the upcoming list (all of which are non-essential items which can be added later, but would be nice at launch):
-Light merchant 'scripting? not even.' language: Can tell daemon to perform job x upon completion of condition y
->Example 1: Send "x8cmeob" to 192.168.0.12 when <address> receives 8 CUR
->Example 2: Append "x8cmeob" to file "transactions.txt" when <address> receives 8 CUR
-Basic accounting features built-into GUI wallet (group addresses into an account, produce transaction records for a given account,  etc.)
-Some indication/measure of network health and connection quality

Curecoin 2.0 will be cross-platform at launch, with a compiled binary available for Windows, Linux, and Mac OS X.

For anyone interested in the practicality of Merkle signatures for a cryptocurrency network, an address capable of signing 8192 transactions takes around 3 seconds to generate on modern hardware using one core. People will be able to choose what capacity address they would like to use. More capacious (more possible transaction signatures) take longer to generate. Lowest possible will likely be 4096 transactions, with the highest being either 32768 or 65535. 4096 will be far more than 99.99% of use cases. Signature verification takes a trivial amount of time. Signatures are small enough in size to not produce blockchain bloat. Private keys require less than a megabyte each.

[einsteinium]

Any news dev.

How are we getting along on the cc 2.0?

Going great! This weekend I'm finalizing the code for Merkle signatures (including the certificates used for folding mintage), and hopefully wrapping up the specs of the transaction formatting. The Curecoin 2.0 transaction system is fairly basic at this point.

On the in-progress list:
Blockchain database (need to optimize for performance and storage space)
Certificate formatting (this is more of just a final approval on the existing specifications we discussed months ago)
P2P Networking (a fair amount to do here)
GUI

Then the upcoming list (all of which are non-essential items which can be added later, but would be nice at launch):
-Light merchant 'scripting? not even.' language: Can tell daemon to perform job x upon completion of condition y
->Example 1: Send "x8cmeob" to 192.168.0.12 when <address> receives 8 CUR
->Example 2: Append "x8cmeob" to file "transactions.txt" when <address> receives 8 CUR
-Basic accounting features built-into GUI wallet (group addresses into an account, produce transaction records for a given account,  etc.)
-Some indication/measure of network health and connection quality

Curecoin 2.0 will be cross-platform at launch, with a compiled binary available for Windows, Linux, and Mac OS X.

For anyone interested in the practicality of Merkle signatures for a cryptocurrency network, an address capable of signing 8192 transactions takes around 3 seconds to generate on modern hardware using one core. People will be able to choose what capacity address they would like to use. More capacious (more possible transaction signatures) take longer to generate. Lowest possible will likely be 4096 transactions, with the highest being either 32768 or 65535. 4096 will be far more than 99.99% of use cases. Signature verification takes a trivial amount of time. Signatures are small enough in size to not produce blockchain bloat. Private keys require less than a megabyte each.

You are encouraged to contribute content to the cause-coin page at The Einsteinium News, so a far there are four stories there regarding cause-coins, consider contributing your  your perspective.

www.Einsteinium.biz and
https://sites.google.com/site/einsteiniumbiz/cause-coins

[bitLeap]

interesting! I'll keep an eye on this project!

[pallas]

I have a "generate" transaction in my wallet that, after more than 700 confirmations, is not in the balance yet.
But it shows on "listaccounts". Is that normal?

[I_AM_AT_WORK_NOW_]

what's the address for the block explorer?

[pallas]

I have a "generate" transaction in my wallet that, after more than 700 confirmations, is not in the balance yet.
But it shows on "listaccounts". Is that normal?

BUMP
now more than 1000 confirmations, but still not in the balance.
lost coins?

[defaced]

Any news dev.

How are we getting along on the cc 2.0?

Going great! This weekend I'm finalizing the code for Merkle signatures (including the certificates used for folding mintage), and hopefully wrapping up the specs of the transaction formatting. The Curecoin 2.0 transaction system is fairly basic at this point.

On the in-progress list:
Blockchain database (need to optimize for performance and storage space)
Certificate formatting (this is more of just a final approval on the existing specifications we discussed months ago)
P2P Networking (a fair amount to do here)
GUI

Then the upcoming list (all of which are non-essential items which can be added later, but would be nice at launch):
-Light merchant 'scripting? not even.' language: Can tell daemon to perform job x upon completion of condition y
->Example 1: Send "x8cmeob" to 192.168.0.12 when <address> receives 8 CUR
->Example 2: Append "x8cmeob" to file "transactions.txt" when <address> receives 8 CUR
-Basic accounting features built-into GUI wallet (group addresses into an account, produce transaction records for a given account,  etc.)
-Some indication/measure of network health and connection quality

Curecoin 2.0 will be cross-platform at launch, with a compiled binary available for Windows, Linux, and Mac OS X.

For anyone interested in the practicality of Merkle signatures for a cryptocurrency network, an address capable of signing 8192 transactions takes around 3 seconds to generate on modern hardware using one core. People will be able to choose what capacity address they would like to use. More capacious (more possible transaction signatures) take longer to generate. Lowest possible will likely be 4096 transactions, with the highest being either 32768 or 65535. 4096 will be far more than 99.99% of use cases. Signature verification takes a trivial amount of time. Signatures are small enough in size to not produce blockchain bloat. Private keys require less than a megabyte each.

Sounds awesome man, anychance the source for folding pools will be released? I'd really like to get franko folders back up and going since ive got so many frk now to fund it.

[Vorksholk]

I have a "generate" transaction in my wallet that, after more than 700 confirmations, is not in the balance yet.
But it shows on "listaccounts". Is that normal?

This is really odd, does it show as confirmed in listtransactions?

[Vorksholk]

Any news dev.

How are we getting along on the cc 2.0?

Going great! This weekend I'm finalizing the code for Merkle signatures (including the certificates used for folding mintage), and hopefully wrapping up the specs of the transaction formatting. The Curecoin 2.0 transaction system is fairly basic at this point.

On the in-progress list:
Blockchain database (need to optimize for performance and storage space)
Certificate formatting (this is more of just a final approval on the existing specifications we discussed months ago)
P2P Networking (a fair amount to do here)
GUI

Then the upcoming list (all of which are non-essential items which can be added later, but would be nice at launch):
-Light merchant 'scripting? not even.' language: Can tell daemon to perform job x upon completion of condition y
->Example 1: Send "x8cmeob" to 192.168.0.12 when <address> receives 8 CUR
->Example 2: Append "x8cmeob" to file "transactions.txt" when <address> receives 8 CUR
-Basic accounting features built-into GUI wallet (group addresses into an account, produce transaction records for a given account,  etc.)
-Some indication/measure of network health and connection quality

Curecoin 2.0 will be cross-platform at launch, with a compiled binary available for Windows, Linux, and Mac OS X.

For anyone interested in the practicality of Merkle signatures for a cryptocurrency network, an address capable of signing 8192 transactions takes around 3 seconds to generate on modern hardware using one core. People will be able to choose what capacity address they would like to use. More capacious (more possible transaction signatures) take longer to generate. Lowest possible will likely be 4096 transactions, with the highest being either 32768 or 65535. 4096 will be far more than 99.99% of use cases. Signature verification takes a trivial amount of time. Signatures are small enough in size to not produce blockchain bloat. Private keys require less than a megabyte each.

Sounds awesome man, anychance the source for folding pools will be released? I'd really like to get franko folders back up and going since ive got so many frk now to fund it.

On official cc2.0 release, we'll be helping with getting third-party pools set up, and pool mining will be built into the certificate format , and if everything goes according to plan we'll have some very rudimentary java source code for a pool backend, or at the very least a very detailed guide that a capable programmer could use to build a pool, with all the protocol information required. If you're talking about the cc1.0-style pool, I'd be more than happy to help you with setting up the payment backend to start rewarding people for folding with Frankos

[pallas]

I have a "generate" transaction in my wallet that, after more than 700 confirmations, is not in the balance yet.
But it shows on "listaccounts". Is that normal?

This is really odd, does it show as confirmed in listtransactions?

"account" : "",
"category" : "generate",
"amount" : xxx,
"confirmations" : 1435,
"generated" : true,
"blockindex" : 1,

[Vorksholk]

I have a "generate" transaction in my wallet that, after more than 700 confirmations, is not in the balance yet.
But it shows on "listaccounts". Is that normal?

This is really odd, does it show as confirmed in listtransactions?

"account" : "",
"category" : "generate",
"amount" : xxx,
"confirmations" : 1435,
"generated" : true,
"blockindex" : 1,

Wow, that's a mystery. If you do "gettransaction txid" (replacing txid with the txid of that transaction) and then dump the private key (dumpprivkey address) replacing address with the address receiving the coins in the transaction, then import that on another wallet, does the transaction appear properly?

[pallas]

I have a "generate" transaction in my wallet that, after more than 700 confirmations, is not in the balance yet.
But it shows on "listaccounts". Is that normal?

This is really odd, does it show as confirmed in listtransactions?

"account" : "",
"category" : "generate",
"amount" : xxx,
"confirmations" : 1435,
"generated" : true,
"blockindex" : 1,

Wow, that's a mystery. If you do "gettransaction txid" (replacing txid with the txid of that transaction) and then dump the private key (dumpprivkey address) replacing address with the address receiving the coins in the transaction, then import that on another wallet, does the transaction appear properly?

I'll try importing the privkey on another wallet, but for now some more info:

- the address is the same where I receive the folding payouts, i.e. the only one having transaction
- there is just another address in the wallet but with no activity
- I've tried both repairwallet and -rescan without success

[defaced]

Any news dev.

How are we getting along on the cc 2.0?

Going great! This weekend I'm finalizing the code for Merkle signatures (including the certificates used for folding mintage), and hopefully wrapping up the specs of the transaction formatting. The Curecoin 2.0 transaction system is fairly basic at this point.

On the in-progress list:
Blockchain database (need to optimize for performance and storage space)
Certificate formatting (this is more of just a final approval on the existing specifications we discussed months ago)
P2P Networking (a fair amount to do here)
GUI

Then the upcoming list (all of which are non-essential items which can be added later, but would be nice at launch):
-Light merchant 'scripting? not even.' language: Can tell daemon to perform job x upon completion of condition y
->Example 1: Send "x8cmeob" to 192.168.0.12 when <address> receives 8 CUR
->Example 2: Append "x8cmeob" to file "transactions.txt" when <address> receives 8 CUR
-Basic accounting features built-into GUI wallet (group addresses into an account, produce transaction records for a given account,  etc.)
-Some indication/measure of network health and connection quality

Curecoin 2.0 will be cross-platform at launch, with a compiled binary available for Windows, Linux, and Mac OS X.

For anyone interested in the practicality of Merkle signatures for a cryptocurrency network, an address capable of signing 8192 transactions takes around 3 seconds to generate on modern hardware using one core. People will be able to choose what capacity address they would like to use. More capacious (more possible transaction signatures) take longer to generate. Lowest possible will likely be 4096 transactions, with the highest being either 32768 or 65535. 4096 will be far more than 99.99% of use cases. Signature verification takes a trivial amount of time. Signatures are small enough in size to not produce blockchain bloat. Private keys require less than a megabyte each.

Sounds awesome man, anychance the source for folding pools will be released? I'd really like to get franko folders back up and going since ive got so many frk now to fund it.

On official cc2.0 release, we'll be helping with getting third-party pools set up, and pool mining will be built into the certificate format , and if everything goes according to plan we'll have some very rudimentary java source code for a pool backend, or at the very least a very detailed guide that a capable programmer could use to build a pool, with all the protocol information required. If you're talking about the cc1.0-style pool, I'd be more than happy to help you with setting up the payment backend to start rewarding people for folding with Frankos

yea CC1.0 is completly fine and if there is anything i can do to help with cc2 just let me know. Ive been a believer of this project since its inception.