Four Cancer Charities Accused of Fraud

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

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

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.

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

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

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.

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.

It would be epic to couple a 980-ti with a solar system. Assuming it could be done for $1,500-$2,000; at 2,000 satoshi, 80 curecoins per day, and a bitcoin price of $400 that could pay for itself in: 6 to 9 years...  

At 10,000 satoshi, and $250 per bitcoin it could pay for itself in 2 to 3 years.

Total back of the napkin calculations from a noob who just googled GPU power consumption and solar panel costs   but I'd appreciate input. As a molecular biologist, environmentalist, and crypto and curecoin enthusiast I may be willing to tackle such a project if the math appears close.

Perhaps it could claim solarcoin as well.

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.

Still squashing the last few bugs before I can release the 2.0 daemon, unfortunately.

I'm sure people want to see progress, so here's a zip file of the source code, with the networking code (the major headache source) over here removed, since it's gonna be completely overhauled tomorrow:
http://1.curecoinmirror.com/MainProgram.zip

Here's the current status:
-Need networking code fixed
-GUI (separate app) is bugged out
-A bit more refining is needed for the blockchain storage.

To launch the 2.0.0a1 daemon in a working condition, I need the networking code solid, and the blockchain storage tightened up a bit. I'm going to head off to bed as it's about 1 in the morning and I've been staring at code since morning, and I'm sure >90% of my productivity was in the first 10-ish hours of working. I have some stuff in real life to tend to tomorrow, so I'm hoping to get a daemon out by tomorrow evening, but we'll see, this morning I thought this would be a simple addition of networking code, and it seems that's just not the case.

Objects in there that are broken have been replaced with some default object so they compile for other tests.

And you'll notice the 2nd constructor in Block isn't finished, that's gonna take about 10 minutes to do, just don't have the brainpower to do it and test right now.