That would be awesome, especially if you live in a very sunny area. However, as pallas pointed out, you'd have to have a lot more than ~500W of solar panels, unless you only wanted to run the 980 Ti during the day. When I talk about solar, I'm completely spitballing, but I'd guess that between solar panels, components, and power storage, it'd cost north of $2000. A machine with a 980 Ti that's good at folding would probably run you a minimum of $925:
-$90 mobo
-$50 CPU
-$60 PSU
-$25 Hard Drive
-$50 RAM
-$650 GPU

You might get slightly cheaper with used parts or if you have existing hardware. Anyhow, that'll probably draw somewhere around 300W at the wall at full power, which would be around 223kWh/mo. Some quick googling shows $10,500 for an 815 kWh/mo system (with apparently a 30% subsidy in many states, bringing that price down to around $7350). That's $9.02 per kWh/mo, so that's around $2011.46 in infrastructure costs, assuming solar panel production scales appropriately, whereas in reality the cost per kWh/mo will probably increase as you decrease the size of the panel deployment.

Thanks!

The 750 Ti needs to be plugged into a PCI-e port on a motherboard, so you'll have to put it in a desktop machine. You can't plug desktop GPUs into laptops, except for someone who hacked together a thunderbolt to PCI-e adapter that I'd doubt would work well for folding. It'll need a moderately-good PSU as well.

For anyone interested, here's what a certificate looks like:

{C5225PU2X6QBBZGCQEJBYEIMTRTVPAOEMFCIDR:vorksholk:181673:CureLabs:166:1c18b3a078485bd6abf5eed35360f05fabdc937db5cf3608ac1cb81d6dd066ef},{nLTF5pmMQuU50iZi:4K8T5hhe7oznCuuj4OoO::kWDAZ7F4sHO9Y6XNImI6:5wRUYhl5gik2sn5/::cNF6nxF1IQjGy4lcixrK:oLdWHxBZxwODRlh1::GKcGf3Cvi+F3QdOe:LmPONIgImd9BKsLhSeZr::
K5iUncf0QPegwlaLggLQ:CFDVDA+zXURqlusL::ByspOfAuvSXXYp+/:T8nt3hqjwX9DISTIrQmg::c4ynnaATXPBzrole:Y7MIiJCi4WSCXHsgOmia::iaQYe0dw6oQsgpUcTLXD:g09Mg8m4oq/V182e::
V4L99qibElyYsiDs:dzkw6iNBdQUACyLmnlP8::ZWdwIoOOuucS2oAw:vBCo6nCzIxXUOgbyqAbO::X32x5EbJpxOnOf2H:7kn18NFQ5cgZeb4TMK1k::59UMMSj2om4O2+kc:Vj989COGp3G7O9ICqhQx::
dPR9jTcmgXwmQJ8K:QNyk0yoHniPhJsCuhqvk::VyKKuvcaAZev24bC:CKIUQS0dcf2KQUZeF6vo::eo3Za3ty2uT0x7fd:NDx8fzZqzfHyhaW9SKxu::pKDoj5eZfGsld4at:q8JOAdeNGcWtcYT5qkju::
CdsgXh2x0jtlikfawUPm:Cb+9P/UMWzUzkOoI::VAYksmDYibP1HLKRDwxf:F885/lR2svO0rP8s::gKlBtFh8Gs3uoLbAUdH2:V7tARzbvz5ioaxL+::breftoETgDohNMepxBV7:fi1lrDqPIw2Uq6Uv::
Pa0mCQhAkr8c2GfL2tkv:8VIgl/Z7OkxYae2y::XLIZ3qcahGzrusT0fkUE:RZ0pIfWKrjzl60hy::ovfHMFk1nuBZkjA4:lmLpW6DWyuKq6TrxwS4I::DTUkm1cPCS/M77+z:KCmgmQCdnJCaqHCNMl7p::
wWJqx3Pbstmk5pVfL3nv:BXOEDPxa1lNr4HjB::AvE7qpYqUcHxRi2j:u0WThfoOg9tyRHI2vFy4::0Fmt8p5WPvfi0pFb:ku1joM73TvYB44mciHfY::gRIOS5iaortXoyQFmGx1:eFr1qhNHhZGObDSZ::
NVIiBcnvW+LKv3Ux:f2NGoxLFTfY35OPsowVK::hTntVLkogl82Dx39XZCq:HK5D5hXqfwvV6id8::xqe0hgf1c5lyb7RNROmH:8LnkslPDu29kdOki::hRPr9bDdOyWME3xnzTYB:n3fX/xq9RZkRCNoI::
n6nMDUl/aqhmPN/M:xj2Q3UaL5spkMJXgn10q::egnOqreDDIO0WQjn:O5Lia9ckbosPwlaYKW79::u4D1FGqNm8LRTIIN:qtruT1Z26ZrYpOQLddI4::KK/3Nivfd4Yc1Sqh:QVi0c9scDdwvlBSkuxTb::
HVG2Z7X7N2XpzUlv7Ng8:HpcB48JVMlupMBsB::JryyhXwX0zqUoK4QSefl:7EiTeK+9Zmvm+5X8::uQoqcc6ii63UIIGVoNDy:jHAt/yDfeL/DZOQL::yhPIvzI28GdRvANZPUw8:zBIdDr46ArQuBmp3::
QaDSVU4bGTQ94FUZ:pkNFzEbLcJpgkBlga3is::AUz8tsl90722FiZORm4u:G1NrUakvSHFzeKZY::27rQmKrCH0aqVm42yQOv:rBXXT5Kc8nZYYd9h::Iy9x1h51LL1J0gmx:ScmpVOQQqcncF4JmbY1M::
ySA5Pi/HdjT51a95:ADbdBFte84OXUAKvckjQ::vM88TQ+BHaOcn+xl:3mbhE9ao2OqUxkIN7Ywt::xrKhEctl8M3RtHCsxOEy:npdd14O5J6ws6VLr::1zowrVzRKGfOiM6gctRq:4/vggUlVy5S6B3f7::
Rcegz7nXs8hgGkwypNui:pZktK92HqO8oXOo7::9nis97ThGdZ7PwRM:FjdftCLn1bPapzvFrF2w::HeKKG5iB7fCEOD9diaZS:r0JYa3yGnIaDq5Cz::GjAZl3MLJ5hsneZMovMw:NB3LTRfYx2vXmOww::
waMgC6DuT6MDeZKV:TvXGcyPS9ZxInWv4Avvk::KcWI27MCROTsdFd6ksbl:diYxcCksuALCAjNn::vqthawXa37f2P04AtT6K:+whLLlPvps7iN3Rc::2vFzKAkLRb9hYRp2Tdxq:4E1Uj6b99UGIByKB::
XPsgRxFUYo7Ivs8b:L2ABBYa3eYRLcDLalDG4::3MyQX9GW2zxATXMijnc0:PSdVfPc9X4WUxZKe::vCnAtdL9p0XrpiUQxnJN:TyULk+aN8hANYKsw::IBcn6WZ0ECmEXyww:1XEuSJhy7Thwp50Zh1gM::
AtftvT2U0ANdh6MB:ozbqmliDQURYMGcbNr27::tD0dSIWoh8WZVqNH:UHOZoQXeKOTHUYrlB9EQ::NAEXIf4ar0ihEoeYGp97:qRKpXFohqrBr1Q4K::nxKOVCXXyf3MCmQ2:Fbc9XmczNtLHQHF1MVOl::
kAzogeBI4WGYXwbWDykA:kUatwL4ooRrcv50I::/Icqv//UkpnDA8zq:UTfD5d5Z3vHNzF5F2hEy::Ifiqrm0WT2bBLo69qkD2:qx1ZPIyHc+tZ693e::pniHeIHsudPiT6vcT0jl:GhfEmfmF6uhUTBfx::
KyrTBLlNPpqijVFfWjT0:8TeDGgqMAs3k4fFD::0aoH85ykVTHdK7705SL6:zHLoVt3rM9xFYKNL::IpFva5jbr7Rte2KXFDPQ:HOZr5vs60UPaD/Vl::wDvDKBbn3CxzhMBt:prpZiUAQQzeevPqZKx6b::
JNnFQW7Np7pLLCeDGf4F:6tNGFtBvo1dkQMmM::sZaTCTixgz7jKuyRFGtp:4HjcmNwlO/tnfuqB::mF8qJXxiQsSsaCUpZrIn:7K7WsGmxQi3t3nx/::feQ16nGYbckrjcKa9HQc:1wHmPuxvrBkIGxVj::
r8qmJmkCU/3jHlgP:bcx4yU61aGMeVawGyA4B::GI979hvpXoIsQ5+z:4XCRPghZPRPYygfS85pe::FPMudOW2v4ImqCzo:b3Qb5jPacJ7Uc6cLpcix::EAApzwtVeuWbEuWWy3fF:JJmNPrr2dV5J+4P/::
0G2r71xk6xEXTSjFmSeM:rA2U54j/qD8UlMk/::pS53glMubwSwB2cR:ExVa1jzDNpzGVuR1dArF::U4tu0Tb7ZrC4qcTkc6US:DZfynWGmyS/8e5Lp::I6rwMFiGzsrqePOg8wT8:oCt8TJ5KwtY55Oqi::
iYY2BRzXSQpgA6vKu2G3:0huWLfXZAzJBYa13::3wfoVxLR2W0HyAG9:FXuKnR3QFHbPOzMuEB9P::x6bkK9Kne06DJG5Y:1q4CwRBt14vVvWkKVV2n::AEeXOHRVm3WeEem5dNDY:4tjicAfDMotNb4cE::
s0vUedq16mPj4xkPIIWQ:GQGoL5wpa9tFzYtf::xYWTLZdM4jGUlQgX:ht6By0JUXUOJp0WL4ZiF::LSJZFLGtRbvmaypCkh6Z:Lt/KkZrSeVtcGib9::gQnf8ZUhpIdc0Xeu:Qz9IU8jQh1cjXyIlHZ6h::
spuKQQprXOFI+UA0:p8oUHdyi3dBLSNPOPiWL::aqgziSBETitLEhXsg977:qfTS5ct7abgkgKXG::WEecHJZ2eKhKzDCN:x9MwzoSSudTSW9Bnqc3F::5d1d4OOoIjBRHD2v:vhvI3f0pHx4bPyas5era::
Ht1nacuW5D4q2oxEFuir:X7u6OoRbEsFBzriP::4XCGbKUPuFsT5gJA:RLthVlHUfCLzRpjihra7::f9G60Yyrbi6Dewyrn8mm:UEr0UwNCXpzmgzoF::
HV6HZADYI41J648IFWUV:QZMDwY/VHBu0sCtPhduq2oo+JmIx38ANof0dqj8HUMSXGxCLamNPj3In3ZYsvhhLMmhlqm3tzCVRhAWa/zFToQ==,
Ye8p4EYdxQEO/wULzGhs/S/KlrTMRCSProEF+tPgrTk=:6EG4gwHV2JHU/GScbaKP8J4yfDxY6YqyPX+bhMBO210=:rxeU5hBSkpFDey5Asv6YtScqSOI3tyU0VHrJBXWMKf0=:
I9Gn8kO2vX2Em8NjymyX+b06dy7orMihS292Ijsi7m4=:VY5XaAKidJ91Q36ByjI6GLskjnpamcmWOdOjvtMelj8=:G30LRRrS71wShYNb0O1QQHpTIDx6I4u0bpj7LPQqugg=:
Devj5IQYnFQXVY+OER4HRka3xmTey4fr11QMZ+6eIEU=:0SEZVT/wPDG6kbEQdJvA7aXmuD8+ZAJzMgOFhF6zE4w=:vWOoqWpZD4KgraMJTBTUIWrDk2lJrznbqnbsXM4jR5A=:
FtDM08ARDNKkgIRceG7phi/7C1KCtcXz5zywVEjEjO0=:yqm3dWPM51mZZsI7x5Ar4EgKhIGzn2VS5+zaQbPH1Lk=:sh/pQqUuFRNqWaGX8zqjHUemY5RFVx0mLqjcWtzljew=:
t4R61Vdp4woIjx/KYxLZHF5kfYqcT/td0vlZUcpREqw=:iLs9BUEgOpCiAhQfw/xplAMGil8I3G0JqN/SXr8GY3A=:fCC68pDjLWlfEqHsng7nhTdimvEaE43cGM0wPUUZHV8=:
mWyG0eobi5gNqWYFIZbxkkMnpZadcJhgIJP+XVfE1ks=:6K5LGj5yYsZu+IG7YkhZoRTLAZJV5WIFs8oUCVR5sSs=:kgPYvTDml7pAq/7XCNqv9kfydccRH4ObdMU0uAupJek=:
WTyuno8Sgfhu/TWy4VfyO40hK+0k12rmrpnUJJ2hU6Y=},
{81944}

The first chunk of data ({C5225PU2X6QBBZGCQEJBYEIMTRTVPAOEMFCIDR:vorksholk:181673:CureLabs:166:1c18b3a078485bd6abf5eed35360f05fabdc937db5cf3608ac1cb81d6dd066ef}) is the human-readable part of the certificate, and is what is signed by the certificate authority. The address there is the address that the certificate will pay out to if a block is mined with the certificate. In Bitcoin-speak, this address will receive the coinbase transaction. The 2nd string (vorksholk) is the arbitrary data section. This will be used by people who want to pool mine, as they will put the pool address where the coinbase destination address goes, and they will put their username in the arbitrary data section. This is limited to a length of 40 characters--which means it could fit a curecoin address. P2Pool, anyone? The third part (181673) is the max nonce. This means that this certificate can be hashed with nonces from 0 to this number in an attempt to solve a block by getting a hash under the required difficulty. The fourth part (CureLabs) is the name of the issuing institution. CureLabs and CureSystems will be the names of the two issuing authorities on the Alpha testnet. The firth part (166) is the block number, and the sixth part (1c18b3a078485bd6abf5eed35360f05fabdc937db5cf3608ac1cb81d6dd066ef) is the previous block hash. By design, certificates can't be 'stored' for later use, as that'd make 51%-style attacks easy. Certificates are bound to a block AND a hash (binding them to a hash helps prevent network forks by keeping people on the same fork as the certificate authorities), so they must be used now-or-never. People could, of course, receive a certificate that is capable of mining a block and never redeem it, similar to finding a winning nonce in traditional mining and not publishing the block.

That chunk of spam in the middle is a 20-layer signature. The first 100 parts (those separated by "::") comprise a 100-bit Lamport signature. To sign a message, the message is hashed, and the first 100 bits from the hash are used. For each position in the 100 bits (positions 0 through 99), there are two Lamport keys. For each bit, one of the two Lamport keys is revealed, depending on whether that bit is a zero or a one. This means 200 total keys comprise a full Lamport keypair. These are all hashed together and used as one leaf in the Merkle Tree. The Merkle Tree that signed the above message has 20 layers, which means 2^19 (or 524,288) keypairs. As such, the above address can sign 524,288 messages safely. When verifying the certificate signature, clients take two steps: they hash the 100 private parts of the Lamport signature so they have a total of 200 ordered parts of the signature. They then climb back up the (in this case, 20-layer) Merkle Tree using the data in the above chunk of spam as layers. The signature number determines what number Lamport Signature was used in signing the message, and is then used to determine the order of the climber and adjacent branch. The tree is climbed, and if the end hash at the top is the same as the 32-character Base32 hash in the address (in this case, A1H6CHCCRZZKW67NRSUHCQGWI4GWVYOCXGKYF6) then the certificate validates.

Finally, that end chunk is the signature index, so that's used to calculate the Lamport Signature Keypair's original leaf position so the tree can be climbed in the correct order.

A lot of work, huh? The exact same process happens for every transaction on the network, too. As you would expect, signatures that large sure do add a bit of weight to the blockchain. As a result, we're using a blockchain that's not required in-full to be able to operate. A public flatfile ledger is modified by confirmed blocks, and 'checkmarked' by hash in each block. Once a block is older than the PoS range (21600 blocks, most likely) it can be deleted. The default implementation we are using in 2.0.0a1 will keep the entire blockchain, however if/when the blockchain becomes large enough in the future to warrant it, peers could manually delete blocks, and the client will eventually automatically delete blocks when using more than the space allocated by the user.

By design, the client won't switch forks to a blockchain that's longer than the current one if the forking point is more than 10 blocks back, so once a transaction has 10 confirmations, only a manual intervention to fix some massive network problem could ever reverse that transaction (unless of course some significant network segmentation occurred in which half of the network was on one fork and half on another fork that were divergent more than 10 blocks ago, in which case the transaction would exist on one chain and not on another). We'll test to see how this works on testnet in alpha, but the idea seems very solid on paper.

Blocks are applied immediately to the ledger upon receipt. When a block is orphaned, the transactions from that block are reversed in the ledger, and the transactions for the replacement block are immediately executed. As such, coins should not be assumed safe until confirmed by a few blocks. 10 blocks is nearly a sure-fire guarantee.

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.

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.

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

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.

Hey, shot you a PM.

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

On counterparty you should be receiving FLDC, and if you are on team 224497 and have a matching account on cryptobullionpools.com, you should be receiving Curecoin to your Curecoin wallet, which isn't tied to Counterparty

In the next 4-5 weeks we'd like to have a preliminary public pre-alpha with:
-Merkle Addresses
-Simplified Blockchain
-Certificate System

The simplified blockchain will behave similar to that in Cryptonite (XCN).
[/quote]

In August 2014

[/quote]
My goal is to have an alpha for people to test and play around with (testnet, basically) sometime in January of 2015, but there may be smaller public tests leading up to that to test specific features, performance, etc.
[/quote]

And now you are talking about months for a beta and that you will have more time this summer...

Excuse my French BUT WTF

When will cc 2.0 come out? in a few months, this summer, next year or never?


[/quote]

Yeah sorry, I've been very busy lately. cc2.0 beta in by the end of April, hopeful launch in May depending on beta feedback, then the summer to add additional features/tweaks after the 2.0 release.

Looking at hopefully pushing out a public beta in the next two months, I'll be able to put a lot more time in over the summer. If people are interested, I can post more source code, though the last source code post I put up got a whopping seven hits.


We're chasing a bug right now in the statsAuth page occasionally showing old data for people who don't earn a payout every day.

Just a quick update, historical payout stats are nearly complete, and they'll launch this Sunday. Nothing beautiful, but has the basics.

Thanks, looks great!

GTX 770s are compute v3.0, so you need ccminer30.exe.

Good idea, I'll bug josh about putting that in OP


TBH, I'm not sure if the Outstanding figure on chainz factors in PoS, but somewhere around 3.6 million coins in circulation sounds about right.

Yup, centralization has been a big hindrance so far, hopefully we can fix most of that soon. It'll still be somewhat-centralized around the research institutes, but that's a drastic improvement from the current system. Marketing/etc. will become more of a priority once we have more to market, aka 2.0

Yeah, I left it running and it seems to have evened out.

In other news, is someone spamming suprnova with bad shares? 2.81% efficiency, 44,114,977 rejected shares.

Nope, both are at a 100% acceptance rate (after about 10 minutes of running). I'm wondering if the hashrate is being reported incorrectly, or maybe pool difficulty is just playing tricks.