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

[mufro]

Quite often (like this weekend), F@H servers have problems resulting in points not being rewarded on time and curecoins being paid a posteriori.
Will this fact be acceptable when CC 2.0 blockchain will totally be based on WU generation? Won't all transactions be blocked during 2,3,4 days?

Also, if CC 2.0 will rely on certificates delivered by "scientific authorities" (like universities) who's responsibility will be to secure that process against piracy from outside?

I have the feeling that CC 2.0 will be super robust against quantum computing but will rely on weak authorities. Like putting a huge armored door to a house with paper walls...

I think that if you want credibility and trust (thus investors) in a cryptocurrency you need to have it robust by itself and not needing to rely on any third party.

[1714915801]

1714915801

[1714915801]

1714915801

[ChiefCoin]

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

if accepted by sb ,it can be possible

[meganite]

What is going on with the pool? Looks like I stopped receiving distributions 2 months ago, but nothing has changed on my end. No one is home in IRC....

[CartGeezer]

Have you been folding for the last two months?

[meganite]

Have you been folding for the last two months?

Of course; literally nothing has changed on my end. I simply abruptly stopped receiving distributions on 9/25.

[wilding2004]

What's you folding name?

[meganite]

What's you folding name?

Please PM me why you need this, and how you have the ability to help.

Thanks

[wilding2004]

What's you folding name?

Please PM me why you need this, and how you have the ability to help.

Thanks

I was just going to compare your stats on Extremeoverclocking and the official Stanford stats. There isn't anybody folding with the name "meganite"

[meganite]

What's you folding name?

Please PM me why you need this, and how you have the ability to help.

Thanks

I was just going to compare your stats on Extremeoverclocking and the official Stanford stats. There isn't anybody folding with the name "meganite"

I appreciate your help, but I'm not new at this. Been folding since PS3 days. Need one of the pool admins to chime in; Cygnus, anyone?

[wonko86]

New Exchanges
LiveCoin.net CURE/BTC,

[Vorksholk]

What's you folding name?

Please PM me why you need this, and how you have the ability to help.

Thanks

I was just going to compare your stats on Extremeoverclocking and the official Stanford stats. There isn't anybody folding with the name "meganite"

I appreciate your help, but I'm not new at this. Been folding since PS3 days. Need one of the pool admins to chime in; Cygnus, anyone?

Hey meganite! PM me your folding@home username and I'll look into the stats. Stanford's end did have a hiccup a few days ago (visible on EoC stats graphs as a zero-sum day for every team), but you should be receiving payments if you're set up correctly.

Here's how to set up your folding:
-> Create an account with a passkey from Stanford's Folding@Home website
-> Create an account with the exact same as your folding name on cryptobullionpools.com
-> Make sure you fold for team 224497 (Team Curecoin)

If you've done the above correctly, I can help you troubleshoot further.

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

Great! looking forward for more updates.

Thanks! Fingers crossed that I can push a PoS update to the 2.0 testnet sometime over Thanksgiving weekend. It will be a forking change to the 2.0 testnet, ofc.

[Vorksholk]

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

Thanks for the heads up, sometimes Stanford's server doesn't respond to the hourly stats request, which can cause the blank screen.

[SalimNagamato]

New Exchanges
LiveCoin.net CURE/BTC,

looks very fancy exchange
thank you for adding CURE for the folders
will it be in fiat markets too ?

[BTCTT]

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.

Thanks! Fingers crossed that I can push a PoS update to the 2.0 testnet sometime over Thanksgiving weekend. It will be a forking change to the 2.0 testnet, ofc.

Great to hear we are making progress. Do you have a target date for CC.20 launch?

thanks

[Vorksholk]

Quite often (like this weekend), F@H servers have problems resulting in points not being rewarded on time and curecoins being paid a posteriori.
Will this fact be acceptable when CC 2.0 blockchain will totally be based on WU generation? Won't all transactions be blocked during 2,3,4 days?

Also, if CC 2.0 will rely on certificates delivered by "scientific authorities" (like universities) who's responsibility will be to secure that process against piracy from outside?

I have the feeling that CC 2.0 will be super robust against quantum computing but will rely on weak authorities. Like putting a huge armored door to a house with paper walls...

I think that if you want credibility and trust (thus investors) in a cryptocurrency you need to have it robust by itself and not needing to rely on any third party.

Relying on only one certificate authority is certainly a recipe for disaster. With the launch of 2.0, the Curecoin developers will still be signing certificates until Folding@Home decides they want to be in charge of the certificates. As such, we'll be signing certificates publicly (aka all certificates can be viewed on our website) based on Stanford stats. The server will automatically "spread out" the hourly bursts of points by signing certificates throughout the hour randomly.

Additionally, we'll have entirely separate, secure servers who can sign certificates that are worthless (as in, no coinbase transaction, no money from mining) to keep the network running smoothly, and to make sure the network never slows down simply because a certificate authority dropped out due to technical issues.

For your question on piracy, I assume you're talking about the party itself signing certificates incorrectly? Correct me if I'm wrong. There's nothing that can directly stop a university from doing this--however we will require the universities to have a public webpage of certificates. Anyone can check that the certificates are valid, and unless they are doing something like signing one rogue certificate every few days (which, in the scheme of things, probably isn't earth shattering) it should be fairly obvious that the distribution of certificates is off. It will require community vetting, and we'll also have web scraper tools to try to detect abnormalities in the certificate pages. This does require some level of trust, though. It's not something we've found a perfect solution for.

Yeah, 2.0 will be robust against quantum computers, and the CAs are likely the weak spot. There will be features in the network to allow CAs to recover stolen identities (namely, keeping several "master identities" safe and offline, and then signing a change of CA issuing address using multisig from these master identities.

You also PM'd a few questions, so I'll quote those here super quick:

Hi,

Thanks for all your work on CC.

I was hopping you'll publicly answer my post from 23 Nov...

I'm not a specialist so I'm aware some of my insights are probably not right but I have the feeling that we should not only aim for CC to just recover the folding costs (electricity) but it should become the second most valuable crypto after Bitcoin. Then we'll have ALL the GPU miners that will switch to folding. They want profit, we get science.

And if there isn't trust in the crypto people will not invest (buy) CC and it's value will not raise.

So my question is, wouldn't it be more effective to focus on the main CC 1.0 issues (e.g. the fact that it was pre-mined, that transactions are not anonymous etc) and what else could increase trust instead of searching for solutions that are intellectually satisfactory (like merkle trees) but are not such a big concern today?

Moreover, unless I'm wrong, frequent F@H server problems for rewarding points prove that they are not able to provide QoS (as they don't care about it). What will be the impact on CC 2.0 blockchain? We'll have all transactions blocked 2,3,4 days??

And what if a certificate authority will get attacked by pirates? We'll vote them out of CC? And if it is Stanford University? We won't fold anymore?

Moreover, universities are public entities so Govs can make pressure on them and this investors don't like very much...

Cheers,
M

I feel the main point here that I didn't answer above was the CC 1.0 issues. 2.0 will remove the premine (all 1.0 premine coins won't transfer to the 2.0 network).

For anonymous transactions, that isn't the goal of Curecoin--while I respect the anonymity offered by other cryptocurrencies, I feel it lends the currency to a lot of unethical use, and I personally believe that the advantages of positive public images and whatnot will outweigh the advantages of having truly anonymous transactions, though I could be wrong. On principle, I don't want to develop a cryptocurrency that can be easily used for immoral activities and to break laws. That being said, I appreciate the purpose of anonymity, and I believe the pseudo-anonymity offered by Bitcoin and Bitcoin-derivatives should be sufficient for most legitimate needs for anonymity. Naturally, the anonymity of Curecoin is the same as Bitcoin--addresses themselves don't have personally-identifiable information, but any transaction can be resolved to a sending and receiving set of addresses.

Governments can certainly pressure universities--public proof of something of this nature would be grounds for a network voting consensus to remove the CA from the network. In reality, a government could likely do two things:
1) Force a university to stop signing certificates (Network wouldn't suffer)
2) Force a university to sign rogue certificates (Any harmful amount should be possible to catch)

A certificate authority can't determine whether a given certificate will solve a block or not, no there can't be any foul play with universities signing some certificates they know will create blocks and others they know won't.

Thanks for the questions, it's always great to get these thoughts in a visible place. As covered above, 2.0 isn't perfect--any system that requires *some* trust will have *some* possibility of abuse. The diversity of research, the size of WUs, and the time they take to complete make any kind of distributed WU checking impossible, and open-sourcing tools for WU verification could potentially allow people to game WU submissions to appear correct despite being wrong. Many WUs also aren't strictly deterministic--some may come up with ever-so-slight differences depending on the capabilities of the underlying hardware. Not enough to jeopardize the science, but enough to make distributed verification even harrier.

Let me know if you have any other questions or concerns, or I missed something.

Oh, and to add on to the above about investor confidence: compromised certificate authorities wouldn't jeopardize the ability of the network to function. Although blocks could potentially be minted unfairly, the way the network is designed (stacking blocks must be from different CAs, etc.) one or two simultaneously compromised CAs couldn't rewrite blocks, reverse transactions, or stop the network from running. The more CAs in existence, the more that could be simultaneously compromised without affecting any network security. We'll be running tons of CAs putting out regulation blocks (with no block reward, mined by dedicated addresses) which will keep the network on-time and in-step.

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

Great! looking forward for more updates.

Thanks! Fingers crossed that I can push a PoS update to the 2.0 testnet sometime over Thanksgiving weekend. It will be a forking change to the 2.0 testnet, ofc.

Great to hear we are making progress. Do you have a target date for CC.20 launch?

thanks

Programming projects always seem to take orders of magnitude longer than it seems they should... but here's my optimistic timeline:
2.0.0a5 (PoS testnet update) will hopefully be in private team testing today, and public testnet release tomorrow, on Github and with compiled binaries here.
2.0.0a7 (Code cleanup) will hopefully see public release December 17th. No new (major) features, but the code will be far easier to read and work with. Bug fixes, etc.
2.0.0a9 (Variable difficulty, network timing, more advanced peer seeking mechanisms) will hopefully be public by Jan 3rd.

The version numbers skip, because 2.0.0a4 is the internal test, 2.0.0a5 is the public release, 2.0.0a6 is the internal test, 2.0.0a7 is the public release, etc. If no bugs are found in the internal test, the public release code is identical.

After that, it's mainly just fixing bugs the community finds, offering some bounties for any security issues, publishing a whitepaper on 2.0, and adding multisig. Things like code cleanup and refactoring will be ongoing tasks, with probably weekly? github pushes after 2.0.0a9's release. Given no drastic holes found in the 2.0.0a9 code, 2.0.0b1 should be out about a week after 2.0.0a9, which will just be the aforementioned code cleanup and whatnot.

The beta blockchain will start with the release of 2.0.0b1 with a new genesis block, and then subsequent beta releases will be more cleanup, bug fixes, and minor features, like RPC calls and whatnot. The beta blockchain will run for a few months, until we the developers and the community both feel it's solid, at which point we'll do a soft-launch.

[Vorksholk]

2.0.0a5 code is now on Github--will post binaries tomorrow. Occasional sync bug requires the client to be restarted, such as if it gets stuck in a loop.

Next update for the GUI will use a custom graphics engine I've been working on.

[Vorksholk]

2.0.0a5 binaries are available here: http://1.curecoinmirror.com/2.0.0a5/2.0.0a5.zip.

As stated earlier, this release adds Proof-of-Stake to the 2.0.0a testnet. Also, the code has been cleaned up, so a compile, in Eclipse, straight from github with java 7 (1.7) should generate absolutely no warnings. The debug output from this new release has been modified to avoid "spamming" the terminal with as much unintelligible gibberish. In order to run, simply download and extract the zip file, and then double-click (on Windows) or run from the command line with java -jar Curecoin\ 2.0.0a5.jar (Linux/Mac) in order to start the daemon.

Then, use either the GUI, or the command-line Curecoin client to connect and interact with the testnet. Note that, in order to test PoS, you need to have an address WITH coins in it. Also, it can't have sent any coins or mined any PoS blocks in the last 50 network testnet blocks. This testnet purposefully has 50-block-ago coin calculation disabled, so that you can mine a block on a new address, and immediately mine a PoS block, as the network won't make sure that you didn't receive those coins more than 50 blocks ago. Obviously, final releases will be different, this is only so that people can effectively test it without having to mine 50 blocks on a generally-quiet testnet. If people want to schedule something, we could all plan a certain time to all mine on the network and submit PoS blocks, to test the network under more load. Internal simulations of network load have been successful, but a lab can never mimic real life.

In this version, PoS doesn't validate the balance you use for nonces, also for testing purposes. That way, pretty much any attempt at a PoS block will succeed, rather than failing due to missing a target with a low address balance. As such, you can send large amounts of coins to an address, stake, and then immediately move them to a new address and stake again. If anyone notices any bugs BESIDES THESE I would love to hear about them The ones I mentioned will be, of course, addressed in future versions where other components of PoS testing (for which these hacks are useful) have completed. It's a simple algorithm--client just "rewinds" the blockchain 50 blocks, checks the address's balance at that time, checks that balance against the claimed certificate balance, and validates/invalidates based on comparison. That way, coins sent to an address less than 50 blocks ago would not be included in the staking.

The PoS difficulty is set at 100000, as opposed to the PoS difficulty of 150000. Each coin in an address is worth 100 nonces, so an address with one PoW block (100 coins) would be as likely to mine a PoS block as a certificate signed for 10,000 nonces. This means that, on average, an address with 100 coins will be able to mine a PoS block every ~15 blocks. So mine a few blocks, get a good balance (300-500 coins) and try mining a PoS block on a few different blocks until it succeeds.

In Order To mine a PoS block you must use the command-line client, and type the undocumented command "trypos" without quotes. This will attempt to mine a PoS block. If you have a few hundred coins in an address, chances are a PoS block can be mined within a few network blocks.

Attempts to mine a PoS block can look like this (when unsuccessful):

Code:

Pos mining failed with target score 439887573721212
Which is above target 184467440737095

And like this (when successful, example shown is the address C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7 mining block 1215):

Code:

Successfully submitted block!
Certificate earned score 126737679078394
Which is below target 184467440737095 so earned PoS!

They can also reflect failures to mine a PoS block because of outgoing transactions occurring too recently from the main address.

Note that the above target (184467440737095) is equal to the maximum value of a signed 64-bit number (9223372036854775807) divided by the difficulty (100000) divided by two.

Subsequent attempts to mine a PoS block without the testnet receiving a new block should fail with the exact same target score as the previous attempt.

You can run the GUI simultaneously with the command line client, and you can run multiple of each simultaneously if you have nothing better to do. RPC is wide open (no authentication) so you can also connect with netcat or similar.

There's nothing in particular this public beta is checking for other than PoS blocks are being awarded at the expected rate, and don't generate any errors or exceptions. If you find other bugs, they probably existed (unless, possibly, they have to do with block validation/stacking) before this release, but I'd still love to hear about them. I am aware that the debug prints don't seem to go in order, this is a natural effect of non-linear syncing. Don't worry if the last block "added" in the command line is 269.


The next release (2.0.0a6 internal, 2.0.0a7 public release) will be a complete revamp of the source code. Everything will be more modular, streamlined, and efficient. In its current state, the goals of 2.0 are outgrowing the bounds of the current source code. Adding PoS involved a significant amount of code rework, so future versions will be more versatile for adding functionality. They will also have additional data embedded in the blocks in order to indicate things like block type. This code rework will be a forking change, and will likely come with a new genesis block.

The GUI is also going to be revamped, as I mentioned earlier, to use a new graphics engine I've been writing.

Quick recap of working 2.0 features in 2.0.0a5:
-Merkle Trees (instead of ECDSA) (Quantum-computer resistant, so large quantum computers couldn't be used to forge signatures for addresses)
-Variable-tree size (for addresses that can sign more transactions, but take more space for private key)
-OB (outstanding balance) table (instead of UTXO, or unspend transaction outputs) (Runtime complexity of finding address balance is O(1) rather than O(n) where n is number of unspent transactions)
-Proof-of-Work based on authority certificates
-Proof-of-Stake based on self-made 'null' certificates and transaction history
-Full transaction history lookup for any address, instantaneous balance lookups due to blockchain design

And the features that the current protocol would support, given a client with client-side code to handle:
-Partial blockchain storage
-Manual multisig (Merkle Tree roots broken up across multiple owners)

In "gethistory" requests, there is (currently) no distinction between PoS and PoW blocks.

Code:

gethistory C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1207:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1208:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1209:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1210:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1211:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1212:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1213:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1214:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1215:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1216:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1217:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7

Block 1215 is PoS, as would be visible looking at the null certificate for the block.

Testnet is, naturally, about getting things *working* rather than *efficient*, but you suggestions for efficiency improvements for the current code or proposed features are also welcome.

Testnet coins have no value. Don't mine them for profit. Don't sell them. Don't buy them. Testnet can be reset at any time, and coins WILL NOT transfer from the current testnet to any future valuable blockchains.

[ie007cheung]

@Vorksholk, great efforts on the new release. Much appreciated!