Merkle Signatures, an alternative to the popular ECDSA- and RSA-based signature schemes, are quantum-computer-resistant, as they rely only on the existence of a one-way hashing function (such as SHA256, SHA3/Keccak, Whirlpool, etc.). Both the cryptographic integrity and efficiency of hashing functions has been well-researched, which intrinsically makes Merkle Signatures a secure means of proving ownership and preventing forgeries of transaction information.

My earlier articles regarding Bitcoin trading drew a lot of interest. The information supplied in my publishing about the Profit Secret app, which is an automated trading bot that does analysis and trading around the clock with reliability and efficiency, is a core part in the good response from users. In the coming week, I will be publishing a much more fleshed-out graphical guide to Merkle Signatures and how addresses are derived from a tree, however as it stands the current code I have been developing for generating Curecoin addresses has proven sufficiently efficient for use in a cryptocurrency network. Addresses capable of signing 4k+ distinct transactions take a few seconds for a modern computer to generate (using only one core), and addresses capable of signing up to 2^16 transactions are available. For those familiar with the concept of a Merkle Tree, each bottom ‘leaf’ of the tree is one individual signature (a Lamport Signature). As such, proving a signature for a transaction involves publishing the hashes of the private keys of a Lamport Signature interlaced with half the private keys to represent the binary of the hash of the transaction message, as well as the authentication path up the tree to prove the top node-which is the main component of the Curecoin address.

The Curecoin address (example: C1NYDLCX7O2V5U3H566DPJVSR7MNGBKLZOXGG2MVVCC3UNPMQTO52FWBVQ) can be split into four distinct parts:
The starting ‘C’ denotes Curecoin
The ’1′ denotes the address ‘type’ (the number of signatures the address is capable of signing). 1=4096, 2=8192, 3=16384, etc.
The next four digits are a partial checksum. For example, if we changed the address to C1NYDLCX7O2V5U3H566DPJVSS7MNGBKLZOXGG2MVVCC3UNPMQTO52FWBVQ (where we changed an R to an S) Curecoin would be able to determine that this address is not valid, as the hash of the remaining address would not, when formatted and substringed, equal “NYDL.” Curecoin addresses will likely be shorter in the official release, I am using the full length 256-bit output of SHA256 for the addresses. It would be trivial to only use the first x number of bits determined to be secure (current estimates are pointing to 160 being far beyond secure).
The last (and by far the largest) portion of the address is the hash sitting at the top of the Merkle Signature Tree.

A visual example will make this a lot simpler to digest (haaa…).

Curecoin will also have a versatile Multisignature system. At will, people will be able to generate addresses which have multiple sets of private keys. Additionally, the network will support assigning rules to a multisignature address, such as how many private keys exist for the address, how many are required to spend money, and which ones have override capabilities. The rules for each multisignature address will be stored in the blockchain, and the creation of a multisignature address will cost a small amount of Curecoin to offset the data it adds to the blockchain. A few use case examples:

1.) A business holding a large number of Curecoin wants to protect their holdings. They transfer their Curecoin to a multisignature address which has 11 private keys, 7 of which are required to send funds. Each of the 11 private keys is generated at a geographically-diverse, secure location, and only the top hash (normally the address) of the private key Merkle Tree is sent to a central authority, who combines all these addresses to produce the multisignature address. They then create a special transaction which creates the multisignature address on the network, while defining the rules of behavior. In this case, they set 11 total private keys, and a minimum of 7 required to spend funds. Finally, the allow three of the addresses (those kept in the most secure places) to have ‘override’ capabilities-these three addresses, when all used together, can override the 7 requirement. As thus, a hacker would have to obtain the private keys for either three of these override addresses, or 7 distinct addresses (two of which could be the override addresses) to steal the coins. However, say the company were to experience a massive data loss. As long as either they still have 7 of their 11 original private keys, they can spend the Curecoins, and send them to other addresses. Additionally, if they lose more than 4 of their addresses, but still have the three override addresses, they can use only these three special addresses to spend their Curecoins on the network.

2.) A person wants to protect their Curecoins, so they create a multisig address with five signatures, two of which are required to send transactions, no override addresses. They put each private key on a different thumb drive, and put two in banks, one in an attic, one in a tin can in the backyard, and give one to a friend. In the event of a house fire or bank heist, they are still able to have access to their Curecoins.

3.) A business wants to create a voting trust for spending money. Each member on a 12-member board has their own private key, and these 12 private keys are used to create a multisig address with 12 private keys, requiring seven to spend money. No overrides. Thus, a majority of key holders must agree to spend money for a transaction to be possible.

 

Read More

It’s been a few weeks since our last update, as there isn’t anything too terribly exciting about rewriting existing protocols and features. Out of a touch of boredom yesterday, I have been playing around with some GUI ideas.

The front page shows the most recent five transactions, and gives brief details about the sending activity of the wallet. On the bottom, you have a few statistics about your wallet and the network, latency being the lowest-latency peer you are connected to. The bottom navigation tabs are straight-forward. The last tab (Explorer) can be toggled to an Address Book, an Accounts Page, a Transaction History, a Console Passthrough, or a Network Statistics page. The Console Passthrough will function similar to current -Qt Help->Debug Window.

The block explorer will allow for basic functions-look up the balance and history of an address, see the transactions of a specific block, and see what University was responsible for each block. We want the basic functionality of a block explorer built into the -Qt wallet to eliminate the need to rely on third parties to provide accurate and reliable information pertaining to account balances. However, fancy web-based block explorers will likely be created for the currency by third parties, and are encouraged.

Another modification to existing cryptocurrency structure-we are restructuring the address/private key storage.The new system will rely on an individual address model. Each address can be encrypted or decrypted at will. Forgetting the password for an address will render it unusable-and all coins that it contains will become inaccessible. No one can reset your password for you. Addresses can be publicly or privately named. If you have a popular donation address, you can purchase a public name for your address (called an alias) which can be used in lieu of your numerical address for transactions. Privately named addresses are names assigned to addresses in your own wallet, affecting only you. These make transaction histories easier to read. In the above screenshot, four out of five of the recent transactions occurred on addresses that are either in the address book (for outgoing transactions) or in your receiving book (for incoming transactions).

Read More

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.

Read More

Back in the comfort of my own home and the post-conference energy boost that’s likely the direct result of misinterpreted dehydration, I’m going to post a quick summary and update about the conference and some eye-opening ideas that were introduced, call it a night (morning?), and sleep in my own bed, with sheets that aren’t folded under a heavy mattress, and near an AC that actually does what I tell it to do (usually).

The conference went incredibly well, the the entire experience was a thrilling introduction into the world of organized cryptocurrency. We got a table near the exit, so many people passing by our display had already seen a large majority of the other conference presences, which led to an unexpected, but arguably beneficial information track. People from all backgrounds, levels of knowledge, and interests had to ask… “How can mining help find a cure?”

Here’s a picture of the dev team at the conference table:

On the left we had a laptop with the FAHViewer showing a protein simulation running with a touchscreen-lots of fascinated fingerprints streaked across in all directions. On the right, we had a monitor displaying a captioned version of the Curecoin introduction video. Left to right: Jake (FifthGhostbuster/FifthGB) Josh (Cygnus-XI), Curtis (FifthGhostbuster/FifthGB), and Maxwell (Vorksholk, me).

We had three explanations that we provided-a simple top-level approach of explaining the observable mechanics of the system-folding goes in, Curecoin comes out. We can explain that! The next channel was the science-based channel, which developed as a direct result of a surprising number of people fascinated by the protein folding aspect of the project-a refreshing, well-appreciated shift from the grind of cryptocurrency discussion. The final channel was based around the cryptocurrency, the future ideas for certificate blockchains, P2P certificate authority verification, decentralized voting systems to remove suspicious universities from network access, quantum-computer-resistant signing algorithms, and any other smaller aspect of the system.

As well, we noticed three main groups of people-those interested from purely a speculative investment point of view, those interested in primarily the science of the project and seeing the coin as simply a vehicle by which to arrive at communal incentivization of expediting computational research, and then the blend demographic who were interested from primarily a financial perspective, but appreciated the system for its philanthropic basis, and for the end goal of computational research. Overall, the conference introduced us to an amazing group of people ranging from scientific enthusiasts to crypto-geeks to press personnel to the refined unique characters which made up the general population’s conference representation.

In talking with such a wide variety of enthused, coffee-infused people, a few interesting points came up, one of which I want to go into greater detail today.

Bitlicenses. New York, in the competitive times that are states setting precedents for legislation, is moving full-speed-ahead on publishing legal guidelines for the use of Bitcoin. While I will be the first to admit I have not had the time to fully settle in and read the entire proposed piece of legislation, a few parts stick out at me as the word of the law and the spirit of the law conflicting.

Let me start off this platform for an open discussion with this: I am pro-regulation in most cases. It is the government’s job to protect the small players-the people who don’t have access to insider information. The small-time investors put a bit of money in because they believe in a project, not because they have the power to manipulate it and steal from others. Cryptocurrency manipulation runs rampant in today’s markets. On a daily basis, new coins are released, powerful miners, developers, and other assorted insiders collude, pump coins, generate interest, and take advantage of the inflow of fresh cash which is in hopes of a recovery from the last artificial spike and crash  to take money away from those who don’t have an inside into the system. As it functions today, many people lose money in unfair ways. Investing in a company, stock, or currency you have faith in shouldn’t be something you have to worry about manipulation in. Just as the stock market ideally works today, people invest in something because they believe it has potential. Businesses made for the purpose of artificially inflating stock prices to take advantage of traders are not only doing something nearly everyone agrees is immoral-but are also breaking well-known legislation in most, if not all, developed countries.

Such a system does not currently exist to curb the scamming of deceived small investors in the world of cryptocurrency. As one of the developers of a cryptocurrency which hopes to break away from this image and emerge as a legitimate player in legitimate markets, such market manipulation is harmful. Such market corruption is damaging to the image of cryptocurrency the community so desperately needs to improve.  Such market collusion pushes small investors-people putting in a few hundred dollars into the world-sewn boxing ring of crypto battles-to become disillusioned, disheartened, and defeated. Crushing the lifeblood of a product is no way to treat a customer base, is no way to treat people who believe in your project, and is certainly no way to move towards further public and governmental acceptance of cryptocurrency.

In summary of the above wayward confusion neatly separated into two innocent paragraphs, regulation can be good. Not only is regulation an inevitable step towards mass market adoption, regulation is an essential step towards mass market adoption. It is required for the very big players to play. However, the important differentiation here it ensuring that the very big players don’t change the rules of the game for themselves. As the proposed, early-draft legislation from the New York state government stands, Bitlicensing would be an expensive, required step towards providing money services based on cryptocurrencies based in New York, or having anything to do with anyone in New York. To step back, let’s analyze whether geopolitical lines arbitrarily corralling a segment of the U.S. population into a smaller subservient government working within the graces of a larger legislative body dictate much about internet traffic. As it stands, packets sent from one computer to another pass through a multitude of different parts of different states, countries, and international areas to reach their destination. They do not do so in a manner which is easily controlled, changed, or even predicted. As such, a transaction involving only people in two states which don’t even touch New York may see traffic routed through New York. Assuming that the word of the law doesn’t consider this a transaction through New York, we can simplify the model to any transaction where one or more end parties (sending, receiving) are based in the Empire State. In such a case, providing a money service to a user in New York would appear to be illegal without the use of a bitlicense. In the proposed systems, bitlicenses have the likelihood to be prohibitively-expensive to obtain and maintain.

For the current system Curecoin uses, with payouts from a central system (subject to change with the introduction of the certificate blockchain), this would likely put our payment system under fire. The spirit of this legislation, as I interpret it, essentially dictates that regulations are meant to keep consumers safe-to protect the small investors, the low-volume traders from a repeat Mt. Gox incident. The spirit of this legislation is one that is not only logical, but also one that has been long overdue in the crypto world. However, the way the bill is worded (and a fancier post tomorrow will delve into more detail once I have time to read the legislation in its entirety and form a fully-baked opinion on the matter), collateral damage is likely to occur where it wasn’t intended to spread. Systems like Curecoin using a hold-over payment system until the final Curecoin software is released, and other currencies doing any kind of centralized distribution, would be subject to legislation not intended for them. Such legislation would not be a problem if bitlicenses were trivial to obtain and use, while still protecting speculators and other users of the money service. Exchanges that don’t run with money or get attacked by hackers successfully are an essential component of the crypto world, and holding them legally responsible for their actions is a fresh breath of air. However, if by cost bitlicenses stop cryptocurrencies from being created to follow certain distribution models, lots of potential innovation is scrapped, public trust in the system is forced into the centralized hands of financial institutions large enough to pay exorbant amounts of money to acquire such licensing, and movements towards other alternate solutions, such as anonymous coins, become likely.

From the perspective of all parties involved-from regular interested citizens to software developers to large and small business to governments around the world-sane, logical, well-debated legislation is an essential component of a successful future. The current bitlicense system would prevent the creation of bitcoin banks. The legislation, as it is presented now, would require any person or business holding other people’s currency to have it fully represented in alternate cash. Which means, if we hold a large amount of Curecoins in cold storage for payouts, we have to have, on-hand, the US dollar value for all of those coins. It’s even worse for banks, who can’t even function as normal banks, but only as cold storage for Bitcoin, a system curtailing the very essence of the banking industry today. Such stifling legislation was certainly not intended to hurt large financial institutions who were planning on conducting perfectly legal, reasonable bank practices with cryptocurrencies. They were also not meant to target large coin distribution systems. They were created to protect consumers from asset loss, and were done in such a way that the system in which assets could potentially be lost would be prevented from ever existing.

This is not the final draft of the legislation, there is a 45-day comment period for everyone to submit comments to the New York State Government pertaining to the proposed legislation. I have no doubt that this system will be improved greatly before launch-but now is the time to act. It is much easier to change legislation before it is passed, and in this case, much less damaging both to the cryptocurrency world and any players, bit or small, who are interested in providing financial services related to cryptocurrencies. A more detailed post will follow tomorrow or the next day with specific information, accommodated by my own text analysis of the proposed legislation. I am no lawyer, and I am no financial advisor, so I’ll be deferring to many final judgements from qualified professionals who have already expressed their opinions online.

In the event that such a system were to pass, Curecoin would be required to put forward a good-faith effort to stop any New York citizens from taking any part in the Curecoin network. If this becomes a potential requirement, we will modify the pool to block New York IPs and to force all users to agree that they are not from New York to begin using the service. Clearly, this legislation is damaging to consumers-New Yorkers who already own and hold Curecoin, who will no longer be, due to legal requirements, supported by the Curecoin project. This may not be necessary after the introduction of a certificate  blockchain due to Curecoin no longer having direct (or even indirect) control over the coins.

As a summary, legislation and regulation is a good step in the right direction for protecting consumers and allowing large financial institutions to work with the currency in a sane manner. However, the currently proposed legislation likely not only oversteps the bounds of federal financial regulation, but also clearly doesn’t properly serve its intended purpose, and certainly doesn’t minimize collateral damage. Talk with your government. Hop on #curecoin on freenode, let’s talk.

Read More

As the BTC:Chicago conference draws closer, the Curecoin devs have been busy putting the finishing touches on booth materials. After getting proofs from two local print shops, one of which didn’t understand the value of crop marks, we got information cards printed. The QR-code will guide interested conference-goers to additional information about the project and about folding@home.

Looking forward to talking with people at the conference! It’s not too late to get a ticket.

Read More

Forum user yavuzc78 is flexing his watermelon-carving skills (post here):

Read More

Welcome to the new curecoinfolding.com! In honor of the best place to get artificially-flavored, tongue-staining drinks on the cheap, 7/11/2014 marks the date of this blog’s rebirth-from the ashes of hardware reviews and software tips into everything under the sun related to Curecoin as a whole.

For anyone unfamiliar with Curecoin, check out our website: curecoin.net. Curecoin aims to merge cryptocurrency with computational research, currently centered around protein folding utilizing Stanford’s Folding@Home project. We are no affiliated with Stanford.

This blog will be updated once or twice a week with the latest internal ramblings of the dev team, any exciting developments in Curecoin’s growth, and anything else worthy of mention. At present, we have finalized most of the materials for the conference, here’s a quick preview of the banners that will appear at our table:

In an unrelated tangent, I made a post on the bitcointalk forums about alternatives to ECDSA public/private key pairs. To summarize (full post: Lamport and Lamport-esque Signatures) Bitcoin uses ECDSA for generating addresses and for signing transactions. When you create a Bitcoin (or any other derivative currency) address, your wallet generates a public/private key pair, and then uses the public key to create an address with the help from irreversible hashing functions:

ECDSA, like many other public/private key algorithms implemented widely today, relies on one or more mathematical algorithms which are considered ‘hard’ to do in reverse (by hard, I mean the collective computational power of the world would take longer than the age of the universe to do the function in reverse properly). Such algorithms include the prime factorization of large numbers.  In many cases this hardness refers only to classic computational methods-where we are working with ones OR zeroes. Quantum computing introduces algorithms like Shor’s algorithm, which, with a small modification, could attack ECDSA public keys, revealing the private key to an unauthorized third party. The private key should, as its name hopefully implies, stay private. You use it when you sign a Bitcoin transaction, but you never actually reveal it to the network, just like you never teach someone how to forge your signature on checks. This private key is stored in your wallet.dat file. However, upon signing a message, other participants on the network need to verify that you actually signed it. As such, you have to reveal your public key the first time an address spends Bitcoin (it was previously protected behind the figurative mask of hashing functions). This public key is first re-computed into an address by the network, and if it matches your address, the signature is checked against the public key. If that too matches, then you (or someone with your wallet) signed off on a transaction, and the network validates the transaction.

As such, an address on the Bitcoin network is not vulnerable to quantum computer attacks until it signs a transaction. However, after you sign one transaction with an address, your public key is revealed, and anyone with the ability to run Shor’s algorithm would be able to derive your private key and spend your Bitcoins. While one can safely assume that no powerful quantum computers exist today, the chance that a third party building a successful quantum computer might find lack of vocalization of their achievement to be the most personally beneficial route is high-leaving cryptos with little or no time to prepare and transition to a quantum-computer-resistant signature mechanism.

Due to the nature of quantum computing, hashing functions (like SHA256 or RIPEMD-160, which ‘lose’ data while the algorithm runs) are quantum-computing-proof, and thus are prime candidates for being used in a signing algorithm resistant to quantum computing attacks. A mechanism for signing a single message using hashing functions has existed for decades, and is known as the Lamport Signature Scheme (Lamport Signing @ Wikipedia). This method has a few intrinsic flaws which make it impractical for cryptocurrency transaction verification and address generation:
-> One-time signatures (would require either address chaining or changing addresses every transaction)
-> Large public key
-> Large signature footprint

The first issue can be resolved by creating a Merkle Tree: (Merkle Signing @ Wikipedia)
The second issue can be resolved by using a public key that is a hash of the normal public signature. Additionally, the top level of the Merkle Signature Tree above could be used as a public key, and would have a footprint the length of the hashing function.
The third issue is much harder to tackle, however it has been attacked by CMSS (https://eprint.iacr.org/2006/320.pdf). Even with a system such as CMSS in place, the signature alone occupies multiple kilobytes. This size could be further reduced by using smaller hashing functions, by using standard compression for storage, and by implementing partial-chain clients, who would work in P2P clusters to share signature information when needed.

There is no promise that Lamport-esque signature schemes will be implemented in Curecoin now or in the future, it is simply a proposed solution to the quantum computing problem that the Curecoin developers are further investigating.

Read More