Topic: [ANN] CureCoin 2.0 is live - Mandatory Update is available now - DEC 2018 - page 79. (Read 696254 times)

So hows this little sham going? Have we actually folded proteins or just pretending to? Or are we still spending everything on cases of wind and brain control research?

Quick Reminder:

Livecoin Exchange has been added to CureCoin's official Exchange Index:

     Livecoin now available for CURE/BTC trading

Livecoin: Trade BTC & Altcoins for Fiat
(CureCoin trading for BTC only, however on Livecoin BTC can be traded directly for Fiat)

For those who haven't tried it, Livecoin has a really smooth user experience ... here's a preview video:

Happy Trading!

In the last few days, Google reported that its D-Wave X2 outperforms single-core classical computers by a factor of more than 10⁸ for some traditional optimization problems.

Researchers believe that cracking ECDSA is possible with a modified version of Shor's algorithm. Bitcoin uses 256-bit ECDSA (Secp256k1) for signing transactions, which researchers estimate to require somewhere around 2000 qubits to successfully attack. Google's D-Wave X2 has around 1000 qubits. It's also extremely important to note that this isn't a general-purpose quantum computing, but rather built specifically for quantum annealing, so it isn't capable of implementing Shor's algorithm (or Grover's, for people concerned about mining). Also important to note is that far more qubits may be required for error checking, where tens of physical qubits might be required for each logical qubit.

Of course there's no proof yet that a quantum computer can attack these problems in real life at such a scale, although rudimentary quantum computers have successfully run Shor's algorithm to factor small numbers (which applies directly to RSA, which uses the difficulty of factorization to derive security from).

At any rate, it's great to investigate solutions (like Merkle Trees) that we believe to be impossible for quantum computers to compromise given the pace of development in that field.

There's no paper wallet?!

yes...hope it will get a lot more attention and more folders power

Very good cause for this coin. Hope we can get more attention for this coin.

Oh, and a team member Ivan has been working on putting together a calculator for people to estimate hardware costs and whatnot.

Here's how it looks: http://1.curecoinmirror.com/calculatordemo.html If anyone has anything they'd like added to the calculator, let me know! One feature I have considered is a drop-down to pick the video cards being used, but that seems to messy, given the wild differences different hardware configurations, drivers, etc. can produce (My overclocked 980 Ti gets about 550,000 PPD if running 24/7, although I can find sources on the internet that talk about it running as high as 800,000, and that's a huge margin for a calculator to assume).

We're just starting to test it, so let us know if you find any bugs or abnormalities. It isn't feature-complete yet.

Yup, there will be a full swap from CC 1 to CC 2. Given the nature of the new blockchain, it probably won't be automated (1.0 addresses don't make any sense in the context of 2.0) so there will be a semi-automated manual process for the conversion. 1.0 and 2.0 will run alongside each other for a while to facilitate this.

How many cc 1.0 coins have been distributed from mining + folding is easy to estimate. CureCoin has been out for about 585 days, which means 585 days of mining + folding. This should even out to around 9360 coins per day (7488 for folding, 1872 for mining), which equals 5,475,600 coins. Currently, about 23,499,116 coins "exist" on the network (most are not in circulation), the vast majority of which are tied up in the premine addresses used to pay out folders their 7488 coins per day, meaning that, staking factors not considered for premine addresses, there should be about 16,180,000 (which is 21,655,600 - 5,475,600) premine coins that aren't in circulation.

So, if the network reports 22,499,116 coins existing, and we should have about 16,180,000 coins still sitting in the premine holding addresses, then the 1.0 network should have about 6,319,116 total coins in circulation. As a result, it would appear that approximately 5,475,600 coins are from folding+mining, and 843,516 coins have been created from PoS.

This doesn't include dev payouts. I'm not sure of the actual monthly payout, but it shouldn't change the reserved premine numbers by more than a few percent.

And a quick reminder for anyone who doesn't feel like trudging through the last 20+ pages of forum posts: CC 2.0 will eliminate premines, except for the premine created to convert 1.0 coins to 2.0. We won't be paying out from a premine (or at all, the coins will be generated by coinbase on the network for folding, so we don't have to touch them), and the dev funds will also be created as coinbase in some fashion. So on 2.0, whatever number the network reports as the current coin supply will be the total coins in circulation.

Additionally (not sure if I've mentioned this before on the forums), 2.0 will have official burn addresses. While it may seem a bit silly, it'll allow any premined coins that weren't claimed during the conversion process to be officially destroyed, so they won't be counted as part of the coinbase, and everyone can be entirely sure that the coins are, indeed, gone--the burn addresses will be provably invalid, because the network won't allow outgoing transactions from them. Burn addresses have always been something that were obviously impossible addresses (such as an address made entirely, except for the checksum, of the same digit), but mathematically possible. While that was sufficient for everyone to agree that the coins WERE actually gone, network-enforced burn addresses are a cleaner, more elegant solution.

So in summary, there are somewhere around (including a high rough estimate for dev funds) 6,508,689 CureCoins that are currently in circulation and would be eligible for 2.0 conversion if it were to happen right now (realistically, it'll probably be within 1/2 a year or so, but the fact that 1.0 and 2.0 run side-by-side will slightly complicate this). If people are really interested in an exact number, I could have Josh give us a precise total on the current premine holdings .

thanks for the work and the good answers
so there will be swap of CC 1 to CC 2, and after we stop maintaining/mining/trading the CC 1 network ?
is there stats how many CC 1 coins already distributed with mining+folding+staking ?

finally fixed (again) one of the GPU so my ppd improved a little

No DCN has agreed to be a CA yet; the initial 2.0 release will be us signing certificates for publicly-verifiable stats pulled directly from the DCNs. As the project gains momentum and Curecoin-related computation accounts for a higher and higher amount of their computational power, the hope is they will take over as CAs.

Testnet is going great! There's a beta a few posts up with binaries to try out, and we just added PoS.

The current, 1.0 coin has a premine that we payout from, and doesn't offer anything interesting (in regards to the technology itself) that sets Curecoin apart from any other cryptocurrency. We believe the features in 2.0 (Quantum-computer-resistant signatures, a ledger that grows in size with the number of addresses in active use rather than the number of transactions on the network (as in, if the number of users stays constant, and they all use the same number of addresses as they did earlier, the network doesn't take additional storage to run), and a jigsaw-stacking blockchain to prevent forking will interest people beyond the main goal of incentivising computational research.

As much as possible, 2.0 will adhere to the exact same RPC calls that 1.0 does, to make it easier for exchanges to trade it.

That's the golden question.

I don't understand how CC2 will work
did Stanford or other scientific researcher/university even agree to be a CA/issue curecoins ?
how is the testing going?
there is sometimes talks about CC2 and then weeks of silence. i can understand the development can take a very long time
what is wrong with current model and coin (besides not getting security updates lately, and premine which folders community currently trust)
will exchanges accept CC2 ?

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

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):

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

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

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.

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.

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:


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.

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

thanks

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

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