For those unfamiliar with Curecoin 2.0, it’s the next-generation cryptocurrency our team is currently working on. To clear up some confusion, I’d like to quickly revisit some frequent concerns:
-> Yes, all Curecoin 1.0 (the current version of Curecoin, which you can earn today by folding) will transfer over to Curecoin 2.0 in a 1:1 ratio.
-> Yes, the new Curecoin 2.0 will have a similar mintage schedule, though it won’t be identical. At most, we’re talking about a 5-10% change in either direction, and there will be community discussion leading up to this.
-> We are not yet decided on if/how Proof-Of-Stake will work in the new currency, but all current PoS mining rewards will transfer over to Curecoin 2.0, of course.
-> The codebase is entirely written from scratch
-> Binaries for all major desktop platforms (Windows, Linux, Mac OS X) will be available at launch
-> Certificate delivery will be at the discretion of the issuing authorities, but will be subject to community/developer approval and testing
-> A testnet of cc2.0 will be available before release for public testing
-> Development will be more public when we get into the interesting portions of cc2.0, right now we’re just recreating existing cryptocurrencies with minor changes tailored to what we’re specifically building.
-> Addresses will most likely be based on Merkelized Lamport Signatures. This prevents against quantum computing attacks.
-> There will most likely be no ‘mining’ element of cc2.0-all computational power put into the system will be doing actual scientific computational research.
-> If there is to be a method of mining, a Proof-Of-Capacity (Check out Burstcoin) may be a candidate, as it is low-energy, serves the same purpose, and doesn’t interfere with computational power going to research.
-> All undistributed premine (which currently pays out to the folding pool) will be destroyed, as it will no longer be needed.
-> Dev funds will be switched from a premine model to a block subsidy model. Dev funds already paid out will transfer as normal coins.
-> Certificate blockchain will require all full nodes to keep a full blockchain, though future work could be done to create distributed clusters of peers who, when combined, hold the blockchain with parity.
-> Merchant integration will be made easier with a set of easy-to-use ActionResponse listeners, where you tell the client ‘do xyz when <address> gets <amount>’ or something similar.
-> Blockchain scripting will be much simpler and less advanced than Bitcoin, in order to save space, and prevent piggy-backing + blockchain bloat.
-> Transaction messages will be constrained to a traditional ASCII set.
-> The Curecoin developers will only be holding their personal coins, as the new system will distribute coins in a decentralized manner based on computational work.
-> Yes, folding (or other scientific computation) pools are possible, and will be made easy due to the design of the certificate system.
-> The GUI will either include a blockchain explorer, or a downloadable blockchain browser will be a separate application, available upon release.
-> Thin client mode will allow a user to run one internet-connected node, and then use other ‘thin clients’ which sign transactions locally, and then proxy those transactions through the live node.
-> Both a GUI and a command-line daemon will be available upon release for all major Desktop OSes.
-> Adding a university or other research institution will involve both dev consensus and community agreement, as per forum discussions.
-> Research institutions interested in participating in Curecoin 2.0 will need to be doing research which, when completed, is released to the public in full. Most distributed computational networks fit this requirement.
-> Significant community interest in an institution which doesn’t strictly adhere to the above guidelines may be considered, depending on conditions.
-> The inherent motive to behave badly as an institution which is enabled to sign certificates will be reduced by the potential of balance-based voting to remove or suspend signing authorities.
-> Block time will likely be reduced to the 2-5 minute range.
-> ASICs will no longer be useful on the Curecoin network.
-> A certificate’s ability to mine a block can only be determined by the person putting computational work into the network, and not by the issuing authority.
-> All mintage will be most cost-effective on consumer hardware.
-> If New York Bitlicenses both pass and require licensing for Curecoin, Curecoin will simply refuse use for New York citizens, and make a good-faith effort to prevent New York citizens to download or participate in the network.
-> We have no idea what exchange rates will be at release or after release of cc2.0. Investing in cryptocurrencies is high risk. Be careful. Be smart.
-> The only premine will be done for cc1.0 to cc2.0 conversion in a public manner.
-> During the infancy of the currency, it may be troublesome for research institutions to integrate certificate signing. We would be more than happy to help with implementing such a system. Additionally, if a research institution desires to start distributing work but does not have a means of signing certificates, we can act as a temporary signature authority. After a few months of the cc2.0 network running in a stable manner, the goal is for the Curecoin devs to not have any signature authority, nor have access to any private keys for creating signatures for certificates. Ideally, this will be the case from the start.
Curecoin 2.0 is rolling into development full-steam-ahead, though the final product is still quite a ways off. I have been working on finishing up the networking aspect of Curecoin 2.0, and the next job to tackle will be blockchain formatting and structure. After that, we’ll establish the standards for certificate creation and verification, flesh out the remaining portion of under-the-hood code, create the GUI (which will likely wrap around the daemon), and create the block explorer.
The P2P networking aspect of Curecoin 2.0 is very similar to existing currencies. Clients can connect to known nodes (which are hard-coded in, and can be added manually by the user) to acquire additional connections. Anyone behind a firewall will have limited connection abilities, as is present today in Bitcoin. Peers constantly chatter about network status, unified time synchronization, etc., and will automatically prune their peerlist for the lowest-latency peers, constantly replacing high-latency peers. In this way, the network automatically optimizes itself for the amount of time taken for all active, healthy nodes to encounter new blocks.
Difficulty retargeting for certificates will be based on a standardized distribution of recent block timestamps weighted for more recent blocks to have more pull.
On release, the devs will provide a number of low-latency, geographically-distributed initial sync nodes on high-performance networks. Blockchain syncing will involve downloading large chunks of the blockchain from a low-latency, high-bandwidth peer, and then verifying hashes and signatures with arbitrary peers.