[ANN] CureCoin 2.0 is live - Mandatory Update is available now - DEC 2018

[Vorksholk]

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.

[1714142789]

1714142789

[1714142789]

1714142789

[URSAY]

Four Cancer Charities Accused of Fraud

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

[SalimNagamato]

Four Cancer Charities Accused of Fraud

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

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

[Vorksholk]

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.

[coinomat.com]

VOTE FOR

Vote for CureCoin to be added at Coinomat.com https://coinomat.com/coinvoting.php
Coinomat.com offers bank transfers, withdrawals to Visa/Master cards, and custom debit cards for all the cryptocurrencies on its platform.
On top of that, instant exchanges to all supported cryptocurrencies and e-currencies are available.

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.

Various fiat exchange features:

- Instant exchanges to all other cryptos on our platform.

- Withdrawal to any Visa or Master card issued by any bank in the world.

*This is a great way to provide your coin with liquidity, especially for users who live in the countries with less crypto exposure.

Crypto purchasing and selling with bank transfer

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)

Withdrawal to a custom bank card

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.

Head over to our voting page and get things started!

https://coinomat.com/coinvoting.php

Social
twitter.com/coinomat
facebook.com/coinomat
support@coinomat.com

*Exchange directions provided for supported coins

More program details here: https://bitcointalk.org/index.php?topic=1053407

[marcetin]

Four Cancer Charities Accused of Fraud

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

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

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.

[Vorksholk]

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.

[Vorksholk]

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

[Vorksholk]

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.

[cryptoconomist]

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

[natmccoy]

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.

[Vorksholk]

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.

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.

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.

[natmccoy]

Great staking concept. Long maturation period, somewhat high minimum; encourages holding.

I see the 750ti has 3 different ports, will only the hdmi port on my laptop be sufficient or are the DVI or display port needed?

It's also available on overstock to buy with bitcoin (although slightly higher cost).

[Vorksholk]

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.

[Vorksholk]

Great staking concept. Long maturation period, somewhat high minimum; encourages holding.

I see the 750ti has 3 different ports, will only the hdmi port on my laptop be sufficient or are the DVI or display port needed?

It's also available on overstock to buy with bitcoin (although slightly higher cost).

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.

[natmccoy]

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.

[pallas]

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.

I have solar panels and what I can tell you for sure is that there are a lot of ways to use the extra energy better (I.e. more profitable) than mining any crypto.

- sending it back to the grid
- accumulating it to use at night or during bad weather
- trying to use high power appliances when sunny instead of at low cost hours (ex. night)
- heating by heat pump instead of gas or oil
- buy an electric car
 
Etc.

Moreover solar panels generate electricity only when sunny, so not suited to full time power consuming jobs.

I think you should plan solar panels for your house or office regardless of mining. Then you might want to use it for mining as well... But you'll see at the moment.

[Vorksholk]

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.

[natmccoy]

Thanks guys! Just the kind of reality check I was looking for. Maybe one day... For now I'll just offer curecoin buy support to encourage established folders.

[Vorksholk]

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.