Also not able to connect:


Here are the servers it tries to connect to:

When attempting to connect to these with raw socket connections, they all fail except for pascalcoin1.ddns.net:4004, which responds "Your IP is blacklisted:192.168.0.180:64873".

Sounds similar to the mini-blockchain implementation pioneered by Cryptonite: https://bitcointalk.org/index.php?topic=713538.0

The "safe box" could be compared to the mini-blockchain radix-tree-based balance sheet, where the hash of the safe box is embedded into blocks, so that a user's copy of the safe box can be validated against the blockchain.


As far as why it needs a blockchain, I would assume the blockchain acts as a means of maintaining consensus on the contents of the "safe box" although it isn't referenced directly for transaction history/data/validity.

Sorry for the silence.

I'm working (completely separately from CureCoin) on a project that I believe will be a significant step forward for blockchain security for alternative cryptocurrencies. It's an interesting (and much more secure + scalable) solution to cross-blockchain security than anything that exists today (namely merge-mining). We're going to use the technology for CureCoin 2.0 (for blockchain security reasons including preventing compromised university keys from being able to fork the network), and waiting on that technology to be available is the current delay.

Aside from some nips and tucks, the cc 2.0 sourcecode is primarily only waiting on an overhaul to its consensus mechanism. Merkle signatures work, the mini-blockchain works (but needs some tweaks), the networking code will be optimized a bit but works, etc. etc. To my knowledge, all non-display-related bugs in the current (few months ago) alpha release were related to block desynchronization. This overhaul can't be done until the project I'm working on (which unfortunately I can't give any details on right now) comes to fruition, because the cc2.0 consensus code will be heavily based on the a working version of that project. As soon as that project goes into public alpha/beta, cc2.0 will have a beta release which works with that project's alpha/beta network, and will closely mirror that project's development cycle leading up to that project's launch. CureCoin will be the first blockchain to adopt that new technology, so expect some hiccups during the beta(s). Unfortunately, I can't provide a meaningful timeline on that other project. We wanted to have a working (internal/private) alpha of that other project a few weeks ago, and we're close to getting that up and functioning, but it's a ways off from public release (few months? we'll see.).

I kept waiting to make any kind of announcement until I had more concrete details about a release schedule for that other project. It sucks to come here and say "we're working on something cool, sorry I can't give you any details or timeline," but it's been long enough that that kind of announcement is necessary.

There is always an option for releasing cc2.0 in-line with the previous plans (standard consensus algorithm), and then do a hard-fork to it to implement this new security technology when it becomes available and usable. However, causing a network hard-fork only a few months after launch isn't ideal, and the codebase would likely forever live with the solution "bolted-on after launch" rather than cleanly integrated from the beginning. This wouldn't be the end of the world--any existing blockchains which adopt the security technology will be required to do a similar hardfork. Given the complexity of both projects though, releasing a blockchain that will hard-fork a few months later is certainly not very graceful.

Hey! Snapshot date still won't be for a while, but it'll also probably be a 'rolling' snapshot where balances are recorded weekly.

Hey merc, is your client still stuck on block 645? If you type "getinfo" in the client, what is the block hash of your latest block? As of right now, the latest block appears to be 1212 with block hash 3A47C5DB73C1DFDB431E211732F1259A73EC82AC53F1EFEB389CAFAE5BF1FF6D.

The daemon will spam data for a while while it's syncing, you can see more in-depth progress (or lack there-of, in the case of desynchronization issues) by typing "getblock" into the client periodically. The spam is mostly caused by network 'reverb' or delayed block processing, which is something I'll try to address in the next beta release to make the debug output more useful.

As promised, SigmaX beta 3: http://1.curecoinmirror.com/sigmax/SigmaXTestnetBeta3.zip Thanks for testing!

No problem, thanks for reading! Let me know if you have any questions! Cryptocurrency security is a fascinating topic, and I certainly don't know all of it either.

And I'd like to clarify I'm not trying to attack your project or anything--I'm excited about it, I love the dev activity, the roadmap is interesting.

What kind of heuristics do your legitimate nodes use to recognize attacker blocks? Is it a checkpointing system? Even if you do have nodes that can recognize these blocks somehow, unless it's actively communicating to the network to ignore the blocks (like signing a message as some form of authority that denounces the block, or something of the like), passively refusing to propagate the blocks won't stop a well-connected network from forking.

Attacking a chain isn't necessarily easy, but I wouldn't imagine it being much harder than running your own pool, blocking the daemon's outgoing traffic, mining a bunch of blocks faster than the rest of the network, and bringing it back online to propagate.

You're correct that 51% gives a chance of messing with the chain, not a guarantee. Variability could throw a wrench in it, but over the long term a slightly-higher-than-50% hashrate would outstrip the chain, and the attacker could simply wait until variability works in their favor to bring their attacking node(s) back online. The attacker has time on his/her side, because they decide when to submit their growing chain to the network.

Imagine you're attacking a network with a private pool. The legitimate network is at block 10,000 (which includes the transaction you want to double-spend), with 100 MH/s of mining power. You bring 102 MH/s online for your private pool. The legitimate pool has no knowledge of your private pool. In the beginning, due to random chance, the legitimate network gets ahead, and hits block 10,010 when your private pool has only gotten to block 10,008. You bring a bit more mining power online (or just wait for the inevitable swing of randomness), and by block 10,030 on the legitimate network, your private pool has hit block 10,032. You bring your node back online, the network forks back 32 blocks. What if you were still behind at block 10,030? Maybe you'd be ahead at block 10,040, and do even more damage. The naive solution to this is simply have peers refuse to fork past more than x blocks, but that can become dangerous if the network does, during normal operation, get that far out of sync due to something like a protocol disagreement (something like a BIP update gone awry), since the network would permanently divide into two (or more) fragments. And it doesn't necessarily have to be a user who's providing all of the hashing power--it could be an existing, popular pool who decides to "go rogue," feed bad data to miners, and use them to fork the network.  

Let's now say your network's seed nodes have the ability to detect this, and not propagate the 32 malicious blocks. Unless all of the nodes are connected to one another through your controlled nodes, those blocks will still propagate on the network. Basically the litmus test here is whether the network would continue to run if your seed nodes went down. If so, then passive refusal won't prevent the attack. Now, in the event that your nodes are actively managing the network--either by signing a message that checkpoints blocks as an authority that the rest of the network trusts, or by some other similar mechanism that either marks blocks as guaranteed-legitimate or certainly-illegitimate. Mechanisms like this would also raise concerns about centralization and the network being brittle and subject to break during non-malicious but unpredicted conditions.

I have no idea how your proof-of-reliability mechanism will function when launched (do you have any literature on it to read, or a brief summary anywhere?), but for now I'll just discuss it as if it is proof of stake, although I understand you're planning to make significant improvements/modifications on top of that protocol.

Proof of stake introduces an interesting complication to network forking, but also creates a new attack vector. Proof of stake (as it traditionally is implemented) gives priority/weight to transactions which consume larger quantities of coin-days. As such, an attacker could buy a large quantity of coin on an exchange and transfer it to addresses they own, wait until they reach max stake age, and then attack the network with significantly less than 51% of the total network float. The amount it would require depends on how active other people are with staking and how much outstanding coin age will be consumed by others legitimately while they attempt their fork, but under certain conditions such a fork could be successful with a quite small portion of the network float.

Additionally, when combined with proof-of-work, proof-of-stake blocks could be the extra 'icing on the cake' to push their network power over 51%--stake weight saved in reserve to use if variability doesn't work in the attacker's favor. Even non-malicious but greedy nodes (who spend time offline until reaching maximum stake age on lots of transactions, then coming online) could cause grief for a laggy network. One proposal for eliminating (or greatly reducing) this issue is to require that the blockchain is 'layered' (something like a minimum number of proof-of-stake and proof-of-work blocks in any given 'frame' of contiguous blocks). This would at least require an attacker to have mining power AND stake weight. Other solutions involve coin-age being only used to calculate reward but not "priority" (in the form of a greater chance of mining a block with x coins).

Anyhow I'm rambling, but if you want to discuss the types of attacks you've tested that your network has been able to thwart on testnet, or the security features your hard-coded nodes have, I'm all ears. But exchanges (a primary entry point for new users to get involved) are hesitant to list coins that have particularly low difficulties, because of the responsibility they have for user balances, which even non-malicious forks could disrupt.

And at the end of the day, if miners don't expect to at least break even on their efforts, they're unlikely to mine. Which makes all of the above attacks much easier. I understand price not being your primary goal--and that's a great approach to crypto-currency in general, and means you care about development, features, long-term support, etc. But a secure network is the foundation for the entire project, so there needs to be some acceptable security mechanism. Whether that be some semi-centralized checkpointing solution, or some alternate miner incentive (like a 'colored coin' or address reputation to give them voting power on something important), or your proof-of-reliability, this is certainly something to think about before those 100B coins hit the markets.  

As you know, proof of work is a security mechanism--someone needs to (essentially) match the hashing power of the rest of the network, and then they can freely fork blocks, create double-spends, etc. I know you're planning to implement another security mechanism, "proof of reliability," which I haven't seen explained yet, but understand it as an improvement over proof of stake. But until that's implemented (or even afterwards, depending on your implementation), your network's security only comes from the cost (in servers) of attacking the network.

It's not so much about pushing the chain along to process transactions, but to keep those transactions locked in the chain safely.


People would probably be perfectly fine with the 100 billion coins paid out over a longer period of time, perhaps for as long as you think it'll take to get new security measures in place.

I understand that, but this is a discussion about security. Miners (generally) won't mine below breakeven.

Hmm, alright. Well best of luck, but I doubt the coin will get any meaningful amount of mining (and, hence, security) once the market stabilizes, since it'll be flooded.

There'll still be hobbyist miners I suppose, but people won't be able to break-even with the cost of electricity.

Let's say it takes a miner 3 hours to mine a block on a CPU consuming 140W. Then a block costs a miner $0.063. Assuming 1,000 people participate in the bitcoingarden thread, and they each get the equivalent of 2000 blocks, that would mean they would have to refuse to sell under a valuation of their free coins of $126, or the market would need to support $126,000 (296.47 BTC) in sells.

Most new altcoin markets can't support anything near a 300 BTC dump, meaning that the price will fall way below miner breakeven.

And a network where a high-end consumer CPU can mine 8 blocks a day with a 20-second block target is pretty cheap to attack. That's 4320 blocks per day, or 540 high-end consumer CPUs that comprise the entire network's hashing power. That's about 220 high-end servers, like a c4.8xlarge on EC2. At the average spot pricing of $0.32 per box per hour, the network will cost $70.40 per hour to fork, plus an extra few dollars to ensure 51% is maintained.

If you wanted the network to cost, say, $500/hr to attack, you'd need a 7.10x increase in hashing power, which would mean a miner would need a block to be worth $0.4473, making the per-user-reverse-ICO-payout worth $894.60 per user, or $894,600 in total. That's 2104.94 BTC.

The market would need to buy that reverse-ICO at 2104.94 BTC (putting the currency's market cap at $4,472,997.50) to reach $500/hr cost to fork the network.


Anyhow, I could be wrong (or missing something major), but you might want to re-think the distribution or coin emission curve before you pay out all those coins. You could do a slow-release over a long period of time (still to the same giveaway users), or something else. If you plan to make Espers very feature-rich and well-supported to justify a $4.5 million market cap, a slower premine distribution would give you time to reach it before people lose faith in the market and the network's security dwindles to pure hobbyist miners.

Is this math correct?

Reverse-ICO reserve is 100,000,000,000 coins (20% of total supply), split on April 18th between everyone on the bitcoingarden thread. If 1000 people participate, that's 100,000,000 coins per person, which is equivalent to mining 2000 blocks.

HMQ1725 coin, can't mine with sgminer unless someone adds the algo. CPU miner shows quark because Ocminer just hacked in this modified version of quark into the quarkcoin.c file in cpuminer and so the flag stays the same. If you used tpruvot's with -a quark, it wouldn't work.

Hey everyone, SigmaX Beta 3 coming this weekend to patch the desynchronization issues.

There's quite a bit of confusion about SigmaX in the last two pages, so I'll give the 2-minute summary:
Curecoin 2.0 and SigmaX are different blockchains. Neither exist yet (both are in testing). They share much of the same code base, and in general development of one contributes to development of the other due to their similarity.

Curecoin 2.0 is our main/primary focus, and contains several unique features over Curecoin 1.0 and other existing cryptocurrencies, namely quantum-computer-resistant signatures, a mini-blockchain, a "jigsaw" blockchain that uses PoS as a security mechanism without the risks exposed by traditional PoS, and a certificate blockchain.

Since the certificate blockchain forces Curecoin 2.0 to be more centralized than some people in the crypto-community are comfortable with, we expect someone to create a pure-PoW fork of Curecoin 2.0 when it finally launches. As a preemptive measure, we figured we'd develop that PoW solution ourselves, so that it contributes to the Curecoin ecosystem.

Holders of Curecoin 1.0 (the only 'real' blockchain we currently maintain) will be able to convert their Curecoin 1.0 holdings 1:1 to Curecoin 2.0. The networks will run simultaneously, with Curecoin 2.0 eventually replacing 1.0 in its entirety, once the conversion period is over.

SigmaX will be PoW. PoS may be added, that's still up for discussion. People who own either Curecoin 1.0 or Curecoin 2.0 during the first (year? 6 months?) after launch will receive weekly payments of SigmaX as an extra reward for participating in Curecoin.

Curecoin 2.0 will be 'mined' by folding. SigmaX will be mined by hashing of some fashion (probably using a hard-drive mining algorithm as was pioneered by BURST).


If there's still any confusion as to how all of this fits together (it's confusing, I know), let me know and I'd be happy to explain further.

As I mentioned before, this weekend SigmaX beta 3 will be public, to do additional stress testing on my fixes for the blockchain synchronization issues people reported in beta 2. Thanks!

There aren't any sites like Nicehash offering HMQ1725 mining (yet), but you could rent servers from EC2/Vultr/QuadraNet/DigitalOcean/Atlantic.net/VexxHost/etc.
A few pages earlier in the thread, there are instructions for compiling both the wallet and external (pool) miner on Ubuntu 14.04.

Yup. I'm sure they'll update the op with it and the pool when they get the chance

Nah no worries I've already mined a ton, just roll whatever you were gonna send into your airdrop/reverse-ICO thing

Windows binary of the ocminer's pool miner.

http://1.curecoinmirror.com/cpuminer-hmq1725.zip

Direct compilation of Ocminer's github repository, use at your own risk, yada yada. Seems to be running about ~50%-70% faster than the built-in solo miner. Tested working on an Intel (i7-5820k) and AMD (8350) with Win7 and Win10. And for anyone nervous about binaries, you only lose ~4% speed by running it in a VM, which is where you should run binaries from random people on the internet anyway.

Sorry about all the disgusting dlls, it's Cygwin and I'm not a Windows guy.

Here ya go:


That works for Ubuntu 14.04. Wallets aren't portable because of libdb version.