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

Hopefully we'll be able to do more marketing after 2.0 launches, we're always open to marketing ideas. Some team members have been busy approaching companies and looking for potential partnerships, but that's a long, slow process riddled with red tape, unfortunately. We might try for something more 'sleek' as far as logos go, although I do like our current one.


PoS will be significantly more simple in 2.0 than in 1.0, once implemented. Wallets will automatically stake when online, and since the blockchain is nothing more than an ordered list of transactions, each address will stake its entire balance at one time. We're still throwing around all kinds of implementation ideas and numbers, but it might look something like this: staking Curecoin requires an address with 2500 or more Curecoin. A wallet with the private keys for this address will, if the address has not sent any transactions in the last 21600 blocks (@3 minutes per block, that'll be 45 days), attempt to mine a PoS block, where the miner will create and sign their own PoS certificate. All of this will be automatic, and wallets will be able to be set in 'PoS-only' mode, where they won't respond to any requests to send coins. Receiving coins will not alter your staking timer. There'll be something in the GUI to indicate PoS-mintage activity, but it won't require any user interaction. Just keep your wallet open . Additionally, PoS won't provide significant income, it might be somewhere around 0.5% to 1.0% yearly under perfect conditions. Curecoin isn't designed to be a pump-and-dump hyperinflationary coin, the goal is to provide a reasonable store of value. I hate to throw around the word 'stable' in anything related to crypto--but the network doesn't have any crazy interest rates, block payouts, or anything of that nature. Everything is predictable, scalable, and anything that changes changes very slowly. Valuation, hype, and emotions seem to have far more affect on value though.

GPUs provide significantly higher performance than CPUs, especially with the removal of BigAdv.

On the low end (around $130), the 750 Ti pulls respectable numbers, getting around 60-80k PPD, and would probably give you around 10-15 Curecoin per day at current difficulty.

In the mid range (around $300), you could grab a 780 off of eBay, which would pull somewhere around 120-180k PPD, and would probably give you around 25-30 Curecoin per day.

In the high range (around $500), you could grab a 980 off of Newegg, which would pull more than 380k PPD, and would probably give you around 55-65 Curecoin per day. Some people have reported these going to 450k and beyond.

If you're interested in getting into folding as a side hobby, the 750 Ti is a great card to start with--small thermal and electrical footprint, sufficient for light gaming if you don't fold 24/7, based on the same architecture as the 900 cards (Maxwell), affordable, and also commonly used for mining.

Awesome! Great work!

The price sure responded significantly.

I was excited to have a PoS interface, how long will that take to implement? Is it still possible to stake through the debug console?

Also: What is a relatively inexpensive but relatively cost-effective hardware to mine curecoins with? I don't necessarily expect to get the costs back in the future, but I would be interested in earning more points. I used to fold with my laptop but I don't want to stress it out.

Great stuff

looking fwd to it!

the only minus I can see so far is the design of the logo/coin.

Maybe changing the coin logo for curecoin 2.0 could be an idea.

I hope you guys are working on marketing too

I'm also putting together a detailed protocol packet, that will probably be out during the first week of alpha 1 testing. It'll be a detailed document explaining most of the nuances of the Curecoin protocol, from address format to Merkle Trees to block priority to difficulty calculations to block and certificate formats etc.

While alpha-testing-stuff will be posted here, I'll probably start a new ANN thread to make the alpha experience cleaner and easier.

CC 2.0.0a1 will be available in testnet-mode late in the evening on June 7th (MST). Here's a teaser of the final alpha GUI (shoutout to Mike for making sure we didn't end up with something the programmer designed!):



The address book feature probably won't make it into 2.0.0a1. I've learned I can't keep delaying to add stuff, as nothing ever actually gets released.

As the picture shows the testnet alpha will include:
-Merkle Tree addresses
-Backwards syncing
-Certificate mining

On a protocol level, multisig works fine (and appears on the network as a perfectly-normal address). However, there isn't currently software to support multsig, it could be done by hand by anyone with a bit of protocol knowledge.

Still in the works are PoS and mobile wallets.

Along with the 2.0.0a1 package, I'll throw in a VanityGen program--but since there's the possibility of something minor changing in the addressing method (maybe altering the length, or the checksum size, or whatever based on community input), don't invest a lot of computing power into making a vanity address. It's a proof-of-concept, and something to have fun with.

For the release, I'll have two 'work servers' set up, which I'll also release a client for. They'll assign pointless work (a variety of hashes) that the clients will compute and return to the server to get certificates. Don't make any optimized mining programs or anything, these are just to simulate doing actual meaningful work to earn certificates based on computational output. Neither these work servers nor the work clients will appear in the final 2.0.0 release.

As for a schedule, as stated earlier 2.0.0a1 will release on June 7th in the evening my time, might be June 8th in the morning for some people.

Around two weeks after that (so, around the 21st) I'll spend about a week doing various bug fixes that the community found, and adding any features suggested that the Curecoin team likes.

That means on the 28th (or thereabouts, say +/- 2 days?) I'll release another client (2.0.0a2) with those bugfixes and possible feature additions, and the community has another two weeks of testing.

What we want people to do during the alpha testing:
-Have fun. Spam transactions. Try to double-spend coins.
-Leave the client running.
-Try the client on a variety of OSes, network configurations, etc.
-Try the client with different versions of Java.
-Run the client with tons of RAM. Run the client with tiny amounts of RAM. See how performance is affected.
-Kill the client while it's doing something, see if it recovers when you relaunch it.

What we don't want people to do during the alpha testing:
-Attack nodes on the network.
-Report 'slow' as a bug for anything (if something's particularly slow, give some details. It's not a bug, it's a concern).
-Sell testnet coins.

We will be giving out testnet coins freely in IRC (#curecoin). They're worthless. Don't buy them from anyone. Don't sell them to anyone. Testnet will likely reset several times before 2.0 even launches.

Additionally, for actual bugs or important optimizations or thorough analysis of the cryptography we're using, I'll give out bounties in real Curecoin, paid on the 1.0 network. Of course, when 2.0 actually releases, all 1.0 coins will be convertible to the 2.0 network. The size and awarding of these bounties is completely subjective--you're not going to get coins for saying something's slow. If you find a way to make it significantly faster, I'll throw you some coins.

2.0.0a will of course be open-source. One of my main tasks right now is thoroughly commenting all of the code. That being said, if you have any questions about implementation, protocol, or anything else, I'd be happy to explain. Not sure if I'm going to put source code up on Github, or just host a .zip file. When we launch the final product, it'll certainly be on Github.

I think I have sufficient servers to serve the downloads for 2.0.0a. Please treat my mirror servers gently

Working on some code optimizations, the old method of address storage used a sorted array of addresses for the public ledger, which has obvious growth concerns  (making the network difficult to grow beyond ~5,000,000 addresses during testing) due to the computational cost of insertion into the organized list. As a result, I'm reworking the database code to use a non-organized address list with hash maps.

The initial intention of the organized list was so that the ledger could be 'hashed' as part of the ledger verification, where the hash of the ledger at that point in time would be published in each block. However, I believe the same functionality can be achieved with a chronologically-organized list that doesn't rely on any computationally-heavy insert function, rather adding new address information at the end of the list, and updating old addresses in memory using hash maps. Hoping for a public Alpha with the new database organization structure in the next, say, 3-5 days.

With that alpha, I'll set up a signature server so everyone can see how that works, and it'll give out certificates based on pointless computational work as a demo, where you connect the client to the server, it does the pointless work, gets certificates, and certificate mining will run the blockchain.

As a side note, the client will not be required to keep a copy of the blockchain--the only data each client needs to retain is the ledger and the last x blocks. Currently, the software doesn't delete old blocks, but as the blockchain grows in size (due to large signatures generated by the Merkle scheme) the blockchain will only be stored by explicit full nodes, which anyone can run if they wish to contribute to the network. This should alleviate any concerns about scalability with such large signatures. A signature count is part of the address database, and for a new transaction to be validated it must validate as the nth signature of that address, stored in the public ledger. This makes accidental misuse of Lamport signatures as multi-time signatures impossible without requiring the full blockchain stored, which has been a major problem during development.

As well, PoS should still be possible, where clients only keep x number of blocks which covers the PoS range, so addresses can mine PoS blocks and the network validates them by checking that NO outgoing transactions from that address have occurred in the last x blocks. It's not as robust as other PoS methods, but reduces the attack vector of long-aged coins having priority. By getting rid of the stake weight system, PoS block priority would be decided by only a stake hash (previous block + address) falling under the PoS difficulty target, where block decisions are based on network propagation and longest-chain determination.

Transactions would be stored in a buffer of sorts until confirmed by a block, at which point they are applied to the ledger; any addresses that spend more than their balance will have transactions rejected based on the order in which they were received by the node which publishes the next block. As such, unconfirmed coins CAN NOT be spent, and will appear only as 'potential' coins in the receiver's wallet until a block confirms the validity of the transaction. This is another trade-off of not using a blockchain based on unique transactions. All transactions which are, on their own, smaller than the sender's balance will propagate through the network, and the block miner will determine the final transaction inclusion. Any transactions which are, after block publication, impossible (due to exceeding the now-updated address balance) will be dropped by all nodes on after-block ledger and transaction buffer cleanup. While a ridiculous amount of thought and planning has gone into network security without a full blockchain or transactions being explicitly spent, please let me know if you think of any potential problems with this method. It will be VERY clear to clients on the network that coins ARE NOT guaranteed at all until confirmed. We're looking at a blocktime around 2 minutes.

Network timing will be based on client clocks, with an allowable deviation of probably 15 seconds. Blocks will have the miner's time stamped into them, however if they are more than 30 seconds off from clients, they will not be accepted by those clients. Being off-time from the network will cause you to fork off. I'm still trying to find a more elegant solution to this. Suggestions more than welcome.

Sorry for the wall of text, I haven't wanted to post an update until I was very sure about some implementation details.
Also been playing around with graphics design when I hit coders block, here's the splash screen for 2.0A:



And very sorry about all the delays, making 2.0 has been much more difficult than I anticipated.

We had in my country few years ago similar case of charity organisation lead by one local celebrity which was arrested at one moment because of taking about 90% of all donations to personal fund.

With crypto coins is better situation because of transparent money flow, but intension of developer of some coin projects are always questionable.

I do not want to sound negative but in general 99% coin projects are for devs personal wealth growth and nothing else.

Coinomat.com pioneered instant crypto to crypto exchange in 2013 and now also offers various crypto to fiat solutions to provide additional liquidity for supported cryptocurrencies. Coinomat was the first project to offer this and it will always remain our top priority.

Normally, to withdraw to a bank account you need someone to send you the funds from their local bank, so it can be a problem if there aren't many local exchanges happening. Traditionally, transfer costs are a hassle, can cost up to 3% of the amount and take 2-3 business days.

With Coinomat you can easily send funds to any Visa or Master card in the world instantly, with no wait time.





If you need to buy altcoins with bank transfers it can be a real problem and there arn't a lot of providers out there. We enable our users to load their Coinomat account with a bank transfer and buy any coin we support. To mitigate volatility effects, first the account is credited and only after that, a user can purchase the crypto of his choice.
Transfers from most countries are accepted (except for US)



We offer custom debit cards which can be loaded with cryptocurrency and work in ATM's all over the world. Card costs $40 and are delivered within a week after successful order (users need to provide Personal ID and Proof of residence). The card is not tied to a personal bank account and works more like stored value card. After the card is delivered, a user is able to load it from their Coinomat account.

Offering these services, we cover basically all major ways to buy and sell your crypto. Liquidity is what the cryptocurrency scene is lacking at the moment, and providing more fiat liquidity can be a great popularity booster for Bitshares.

Absolutely disgusting Always do due-diligence when choosing charities! Even with the regulations for income reporting, some still get away with this stuff.

this is sad that people cheat for money, and that it is related to disease like cancer.
humans can be awful and too evil  

* i feel that this is not the case with F@H and curecoin and foldingcoin

Four Cancer Charities Accused of Fraud

http://www.wsj.com/articles/four-cancer-charities-accused-of-fraud-1432063345

Quick update, still playing around a bit with the skeleton of 2.0 before we have a live beta, I'll be posting bits and pieces throughout the next week or so.

The first morsel of code is the address generation code, which has been displayed earlier. After some modifications, a tad bit of optimization, and the introduction of multithreading, here's the almost-finished product, wrapped up in a JAR file you can run with the command line. The Merkle Tree generation scheme is outlined here: http://1.curecoinmirror.com/Curecoin%20Signatures%20Compressed.pdf

You can access the compiled program to benchmark address generation performance here: http://1.curecoinmirror.com/AddressGen.zip
Normal Curecoin addresses will be between 14 and 18 layers. Authority addresses will be above 25 layers. The AddressGen program loves eating memory. Start it as java -Xmx500M -jar AddressGen.jar to reduce memory usage.

And the source code here: http://1.curecoinmirror.com/AddressGenSource.zip

Generating a Curecoin address takes a fair share of time given the nature of Merkle Trees--ALL Lamport signatures must be generated when the address is created.

For anyone interested in generating vanity addresses, here's a simple VanityGen application: http://1.curecoinmirror.com/VanityGen.zip
Source code to the vanitygen app is pretty boring. If you really want it, extract the jar file as a zip, the source code is zipped in there.

All good thanks for your time and help.

Hey, shot you a PM.

@Vorksholk Hi i am new to CureCoin i have the software running on my computer how do i go about joining team
#224497?? do i just add it to the team part of the software or is there something else i have to do? thanks for your help.

Happy one year CureCoin!!!   

hehe but merkle trees are in all coins, including bitcoin ;-)

The Greek finance minister will not allow CC in Greece ... With that name of a tree  

Sorry, couldn't resist ...

The staking instructions are in the knowledgebase pages. There is no staking button per-say, but the wallet will start staking automatically when unlocked:

Follow the instructions at the bottom of this page and you should be good:
    https://www.curecoin.net/knowledge-base/13-knowledge-base/mining-curecoin/38-what-are-the-proof-of-stake-details 
BTW - you don't need the single quotes around your command for it to work.

Here's a rough schedule:

April 26: VanityGen address app
April 26: Test code for certificate authority verification and message signing
April 28: Blockchain database code
May 10: Final certificate format (and software to generate/sign/verify certificates)
May 17: GUI and full daemon (beta, may nor may not have multisig working)
May 17: Final whitepaper
If multisig doesn't make it into the May 17 beta, it'll be out a week or two later at most.

And then whenever we and the community think the evolving beta is stable and workable, we'll launch the final blockchain.

A large portion of the 2.0 source base is/will be rewritten code based on existing currencies. It's all 'from scratch,' but most of it doesn't have anything special about it.
Things that are special:
-Curecoin v2 Addressing (Merkle Trees)
-Blockchain format (similar in spirit to 'cryptonite xcn' (not to be confused with Monero/etc.))
-Certificate format (Outlined before on forums)
-Multisig addresses

You can look at some of the fun code for addressing and Merkle Tree generation:
http://www.curecoinmirror.com/CC2.0Code.zip