Hey everyone, here's SigmaX Beta 2: http://1.curecoinmirror.com/sigmax/SigmaXTestnetBeta2.zip and source is also available both in the zip file and on github: https://github.com/Vorksholk/SigmaX

This release fixes the transaction generation code (you can now send transactions), block syncing code (fixed recursion bug with the block queue), and adds an equality test for transactions to eliminate invalid blocks created by network "reverb" where the same transaction gets included multiple times in a block.

As usual, let me know if you have any bugs. While the old testnet client v1 will work with the new daemon, a small modification was also made to the miner to fix the way it handles block formatting with transactions, so you need to use the updated miner as well. Source code for the client, daemon, and miner are all in the zip, Github only has the important code (the daemon).

Back of napkin math is ~7 million curecoins in actual circulation.

The PoW/Folding mintage schedule can be found here: https://docs.google.com/spreadsheets/d/1BY-ezmmVbooFwa3dzJZowpYmxEu9HgO2o5FeR7Evc-U/edit#gid=0. The maximum number of coins isn't a fixed quantity due to PoS, but the maximum float the network can reach anytime in the next decade hovers around 30m.

Perhaps the term 'beta' should have been reserved for a more polished release, there's still fairly significant development before an actual launch of SigmaX, but we wanted to indicate the large reorganization of the core code since the latest cc2.0 alpha.

Found a few bugs with the public testnet:
-Transactions can get stuck in the pending transaction container
-Stack overflow due to some semi-recursive behavior in block addition having to do with the blockQueue (demoed in techbyte's screenshot)

Not sure if someone purposely submitted a malicious block (which, if someone did, thanks! That's one of the major goals of testnet is testing extraneous conditions), or whether this is a result of some block malformed by the miner, but either way it needs to be fixed in the daemon. For now, I've removed that broken block (which was numbered 38?) from the main seed node.

The stack overflow error is pretty simple, basically a block that's ahead of the current longest chain is added to a queue, which is useful when syncing with the network to handle blocks that come into the client out-of-order, to prevent needless refetching. However, the block queue is tried when a block is added, so we call addBlock(some block), and then it sees the block in the queue (38, which is 10 above the current chain right now) and calls addBlock(block_38), which itself calls addBlock(block_38) until it overflows. So that bug should just be a matter of pulling the block queue attempts out to the addBlockAndSave() feeder method, so that it only gets called when a new block is being introduced to the Blockchain environment, rather than recursively suiciding.

I'll have more time to work on this tomorrow.

Does the command line stay open?

The first beta of SigmaX TESTNET is available: http://1.curecoinmirror.com/sigmax/SigmaXTestnetBeta1.zip

As usual, this isn't mining for profit. These testnet coins are worthless.

Expect stuff to be broken. Currently, the miner dies after it gets one block, I'm way too tired to troubleshoot multithreaded applications, so that's on the docker for the next few days.
Try to break stuff, let me know when it does.

The download contains the daemon, command-line client, and the miner. On Windows, you can just double-click. On linux/mac, open a terminal, cd to the containing directory, and use "java -jar xxx.jar" where xxx.jar is the jarfile you want to run.

If you want to compile the source yourself, the source for all of the jar files are in a folder titled "Source."

Thanks for testing!!

The snapshot will probably be done on a weekly basis after SigmaX launch, continuing for a year. The first one won't be until SigmaX launches, which won't be until Curecoin 2.0 launches, so fairly far away.

So, status update:

In the next ~24 hours, we're gonna release a testnet of SigmaX, which will be using a CPU-mined SHA256. I really like the idea of hard-drive mining, so I'm aiming to switch out the SHA256 to hard-drive mining for SigmaX's next testnet release. We'll do a bit of testing on this thread first, and when it seems ready we'll make a separate thread dedicated to SigmaX.

To clarify a few items: CC1 and CC2 coins are equivalent, neither network will be in any form of competition with the other, CC2 is just an extremely-involved hard-fork, and CC1 converts (and is burned in the process) to CC2.

So there are really two coins we are talking about: Curecoin and SigmaX. There shouldn't be a significant overlap between the two considering markets, since SigmaX is designed to close the hole in the market that CC2 leaves behind (decentralized PoW-based solution).

For CC2, all CC1 coins will be (at the holder's leisure) available for immediate, 1:1 conversion to CC2. The SigmaX idea is that, regardless of whether they are still holding coins on CC1 or have moved to CC2, they would receive SigmaX for holding their Curecoin on a weekly (?) basis for the payout period.

I agree--Ideally we'd just launch CC2, and have that be that. But since it isn't difficult work for someone to fork CC2 to create a PoW-based blockchain, and since there is market incentive to do so, it seems to be in Curecoin's best interest to be the provider of that inevitable PoW blockchain.


It basically comes down to this: There's a fairly large portion of the cryptocurrency community who don't believe in the security assurances of a certificate blockchain, so they'll want a PoW-based chain. CC2 brings enough improvements and new technology that there's incentives for people to fork CC2, remove certificates, and add traditional PoW. Since someone will eventually do it, we figure that the Curecoin ecosystem mind as well benefit from it by creating the PoW-chain, giving a large portion of it to Curecoin holders, and using it to incentivize Curecoin folding for the distribution period.

Ideally we would just have Curecoin 2.0, but there's no way to "lock down" the code (especially in the spirit of open-source, trustworthy software), and the market incentives for a quantum-resistant, mini-blockchain PoW crypto would cause someone to make their own, at which point the Curecoin ecosystem doesn't benefit at all.


Thanks! This is basically where we are at--large giveaway of SigmaX to Curecoin holders from some time-release mechanism (either time-locked transactions or a block subsidy system). Balancing the premine percentage is certainly important--too much and we turn the PoW crowd away to their own solution, too small and there's no reason to even develop SigmaX because it doesn't benefit the Curecoin ecosystem. We're entertaining the idea of a 1:1 payout for all circulating Curecoins, currently.

CPU power is a tough cookie to crack in such a way that GPUs aren't useful too. A lot of GPU-resistant hashing algorithms are memory-hard, but as GPUs evolve with faster RAM, this gap closes. As well, the best GPU-resistant algorithms I've seen essentially put GPUs and CPUs on equal computational footing, which results in people still using GPUs to mine (primary example: cryptonight). ASICs aren't great either... centralization, high-electrical usage, high cost-of-entry.

The only option we are left with without GPUs, CPUs, and ASICs would be hard-drive based mining (such as BURST), which is certainly a viable option.


Initial release of SigmaX testnet (using CPU-bound SHA-256 initially) in the next 24 hours. Based on how that performs, we'll set a timeline for tidying up the shared code between the two currencies, and subsequent launch of cc2.0.

Thanks for the kind words! We're not opposed to using some ideas from DPOS (like a consensus mechanism to decide on block timing and block size), but our goals for cc2.0/SigmaX (quantum-resistant signatures, mini-blockchain, etc.) can't be done as a Bitshares asset, since we wouldn't control the lower-level portion of the network.

At this point the predominant idea seems to be some form of subsidy or time-locked coins paid out to holders of Curecoin, rather than a lump sum at the beginning. As such, for the entire distribution period, folding to get Curecoin would also earn SigmaX, because the folding payouts would be eligible for payouts of SigmaX.

Making SigmaX pure SHA-256D shouldn't (at least, in the first year or whatever the distribution period is) significantly restrict distribution, because people can still fold with GPUs to earn Curecoin, which in turn pays out SigmaX weekly.

Paying out some cc2.0 coins to SigmaX folders is an interesting idea. It'd probably be for a fairly short period of time, since we don't want to have control over the distribution of either currency after the dispersion period.


Unfortunately, coding something into the source code that requires a burn of SigmaX or Curecoin for the operation of their network is impossible--a programmer can just alter the source code.

A 20%+ development fund will certainly turn users away--we'll probably do no development fund on SigmaX, and a few percent subsidy on cc2.0. Using hard drive space as a mining mechanism in SigmaX is certainly interesting--perhaps we could follow in the footsteps of BURST in the PoW design. We are leaning away from CPU/GPU mining on SigmaX since we believe those are better utilized for folding on cc2.0, although ASIC-dominated networks do seem more centralized since the barrier to entry is higher. Using hard drives and ASICs seems to alleviate that issue somewhat.

SigmaX probably won't have PoS (or will have a neutered version of PoS, to alleviate general concerns about security holes in PoS systems). Curecoin 2.0 will have the neutered PoS system, which doesn't involve stake weight, and fits into a "jigsaw" blockchain to make network forks using PoS impossible. As for the mintage, we'll probably go fairly low (1-3% yearly interest), since larger interest rates punish users who actively spend and accept the token (by making it deflationary), and the interest rate is cumulative, which results in PoS overshadowing other mintage mechanisms if not carefully planned in the long run.

For your proof of support, that's almost exactly the current plan for SigmaX, except that the snapshot will be weekly, so every week for a year or so, we'll pay out some amount of SigmaX (if we did a year distribution, it would be 1/52 of the total payout weekly) to holders of Curecoin based on their current balance. This serves a few purposes: users can fold with CPUs/GPUs for the first year and still receive SigmaX for their work (earn Curecoin directly, which then earns SigmaX weekly), and encourages users to invest in Curecoin if they want SigmaX. We might do a hybrid solution, which does a decently large payout based on a snapshot block of cc1.0 before SigmaX launches, and then smaller weekly payouts thereafter. The total amount paid out over that distribution period will be about 40-50% of the SigmaX network's eventual float. Any input on this?

For the Curecoin PoS, we might do a decaying PoS rate, so that during the first year, the interest rate is x%, then the year after is 2/3x%, etc. to kickstart PoS, but ensure that it doesn't overshadow other mintage methods in the long-run, since it is cumulative.


It is unfortunate that years of code can be copied and pasted, but in general the community follows the original developers unless they have a good reason not to (like a fork that offers decentralized PoW). The Ethereum forks aren't getting much attention despite the recent explosion in Ethereum, since Ethereum has the first mover advantage, and also has the development expertise behind it. Personally I believe that if we create both Curecoin 2.0 and SigmaX, we've got most of the community's desires covered, so there isn't a large spot for a fork to capitalize on, since both those who believe in the research-based PoW and those who only believe in decentralized PoW both have an option.

Totally agree about the "missed boat"--and those who weren't aware of Curecoin before can fold some now and throughout the distribution period to get SigmaX as well, which would benefit the Curecoin ecosystem

We could remove the existing code from Github and only release it upon actual launch, and there's also ways to obfuscate code to make reverse-engineering harder, but neither are really in the spirit of the open-source cryptocurrency community, and obfuscating just makes the job harder. There's also advantages to having easily-reversable code--people with knowledge of Java can easily verify that executables we provide are safe. The problem about a future decentralized-PoW fork is mainly a symptom of a larger issue--that there's a large open spot in the market for that currency that Curecoin just doesn't cover. By providing both Curecoin 2.0 and SigmaX, I think we reasonably close in on both sides of the market, so forks would have to do something more innovative and beneficial to the community to succeed, which gets back to the fundamentals of open source.

At this point, it looks like SigmaX, if released, will have a significant portion (around 50%?) distributed to folders. Probably on some form of time-release schedule.

The GPU mining could take power away from actual research. Perhaps we could use traditional SHA-256 instead, so that only ASICs, which aren't capable of doing any useful scientific calculations, are used for the network's security.

That was certainly our initial reason for the 1% premine idea. If we go for a 50% premine or similar, it would interfere with a more "pure" distribution model, but the network's security is still decentralized, since all blocks are PoW. If we do a large premine/distribution to Curecoin holders, then it would have to be time-released to avoid flooding the initial supply. Whether that means coins are paid out to addresses but "frozen" until a certain block, or a block subsidy is aggregated and paid out weekly, there's a few options. As you point out, this would add additional demand for Curecoin, since people would be receiving SigmaX for holding it, which is certainly supportive of the Curecoin ecosystem.

The hope with the large payout to Curecoin holders is that it can be done transparently (so people won't feel they "missed the boat," since the idea will be announced in advance, and they can buy Curecoin if they want to get SigmaX that way), and that the continual security of the network doesn't depend on the distribution, since it is pure PoW. For sure, it isn't perfect by any means.

The only coins eligible for the "conversion" (trying to find a better word, since people keep their Curecoin) are ones that have been paid out to folders, ones paid out to traditional miners through the normal block reward, and dev funds that have already been paid out. None of the premine that hasn't been paid out to folders will be eligible for conversion. So basically any coins that end users have earned will be eligible, none of the cold storage premine (remaining dev funds + pending folding rewards) will be eligible. Dev funds that have already been paid out (according to the initial mintage schedule) are a grey area. Perhaps those could be converted and reserved for bounties and the like.

SigmaX won't have any dev fund, but how do people feel about this idea otherwise? Releasing them at the same time probably isn't practical given our team size, but they could be within a week or two of eachother, probably.


We still need people able to test on testnet, and the issue is mainly a PoW fork of the finished cc2.0 code, which would have to be open sourced. And to top it off, Java is ridiculously easy to reverse engineer. Which for open-source projects is great since people can open the compiled binaries and verify that nothing's wrong with them, but would make closed-source even harder.

On a sidenote, would people be interested in some sort of Q & A livestream in the near future?

Sorry, this is going to be a long post.

Hey everyone, didn't realize there'd be such a backlash to this SigmaX idea. If the Curecoin community doesn't like this idea, we won't do it. That being said, I'd like to make sure everyone understands the goals of SigmaX.

SigmaX is basically a more "pure" rendition of the cc2.0 code. Same core technology (quantum-resistant algorithms, mini-blockchain, virtually-inexistant currency scripting language), without the certificate system. There's a fairly large portion of the cryptocurrency community who have avoided our project on the basis of centralization. In 1.0, the centralization is, of course, the large premine for the folding payout pool. In 2.0, it will be the certificate signature authorities.

We see the benefits as:
Since it is so similar to the 2.0 code, it'll work as a great stress test of some of the currently-untested (in a high-impact environment) technologies we're using. Additionally, it'll be great for testing new features on, before putting them on the 2.0 network after the release of both.
Its more "pure" format lends itself well to mainstream adoption, which would get more attention for the Curecoin project.

It basically boils down to this:
When we release cc2.0, someone's going to fork it and slap a PoW on it. If they do it, the Curecoin community doesn't benefit at all--any press they get revolves around the "great decentralized quantum-resistant blockchain known as xyz," current Curecoin holders won't have any stake in the network, and the Curecoin ecosystem wouldn't be the de-facto go-to quantum chain solution. SigmaX targets the market of people who are uninterested in Curecoin anyway because of its centralization.

We're not doing a premine(other than the one paid out to curecoin holders)/instamine/ICO/IPO/crowdsale/devfund.


You bring up some good points--we don't want to dilute cc2.0 holders, so releasing SigmaX with some time-release premine paid out 1:1 for cc1.0 holders, and then keep the PoW mintage schedule the same as originally planned for cc1.0 might be a good option.

If we end up doing SigmaX, the snapshot block# will be very close to the release (no earlier than block 108000 which will be in about three weeks, and probably later), and will be published as soon as we decide on it. We could also do a time-released premine which pays out on a weekly basis for, say, a year based on current cc1.0/cc2.0 holdings.

The curecoin.net website does need an overhaul for sure.



For your first point, that was our initial thinking, but people's discussion of that diluting cc1.0 holders makes sense too.

As for specifics, we're thinking of roughly a similar mintage schedule to curecoin 1.0/2.0, a block time of 2-3 minutes, a quadratic weighting algorithm for difficulty targeting, and a custom hashing algorithm that'll make treechains easier to implement in the future, if there's interest.

We wanted to avoid people burning Curecoin cause we don't want people leaving the Curecoin ecosystem, but that's a good discussion idea to bring up as well.


As I noted above, it basically boils down to knowing that someone will fork cc2.0 after release, slap PoW on it, and it won't benefit the Curecoin ecosystem at all. SigmaX makes it so that PoW fork is under the Curecoin project, and benefits cc2.0.

As for time, SigmaX is closely related to the cc2.0 code, so most of the codebase for both is developed together. SigmaX is basically cc2.0 minus a few features (folding certificates, PoS).

Your vote has been counted though, if the community is against this idea, we're not going to pursue it.


If we do SigmaX, the snapshot will be after block 108000 (about three weeks away), and will be announced as soon as we decide on it.

The last thing we're trying to do is dilute the curecoin ecosystem--the logic is that, after release, cc2.0 will be forked and slapped with PoW, and that won't benefit Curecoin at all, since it's not the same development team, and Curecoin owners wouldn't have any stake in that 3rd party fork. So instead, we can create that fork, give Curecoin owners stake in the new network, and use it as a high-impact testing environment for cc2.0 updates.


Both coins would be largely based on the same codebase, so there's not much overhead (on the programming side, at least) to maintaining both.

100% PoS is still heavily criticized, and has significant security flaws. However, if people think a 1:1 premine of SigmaX paid out to current Curecoin holders and then a PoW schedule that models original 1.0 mintage schedule would be a good solution, it's certainly on the table.

The motto of Curecoin is certainly that PoW is a waste of resources, both energy and equipment. That being said, PoW does serve one very legitimate purpose--the ultimate decentralized security. And while I (and the Curecoin community) believe that a blockchain can function perfectly fine using a certificate system which distributes network control to trusted public universities, there are many people in the community that demand PoW-based networks for a variety of use cases.

In summary, SigmaX aims to provide a PoW-secured quantum-computer-resistant blockchain. After cc2.0 launches, it's only a matter of time until a 3rd party forks it to a pure PoW system. SigmaX does that preemptively, and gives Curecoin holders stake in the PoW fork of the project they've supported. Additionally, since it would be a product of the Curecoin development team, any press or attention SigmaX gets will spill over to Curecoin. After the launch of both coins, SigmaX would be used for final testing of features, to act as a testing buffer in front of cc2.0. SigmaX targets a different part of the market (people who don't believe the certificate system is decentralized enough), although admittedly there is certainly overlap.

And again, if the majority of the Curecoin community is against this idea, we won't launch it.

At this point, the most likely plan for SigmaX (based on all of your guys' feedback) is this:
-Do a 1:1 issue of SigmaX to Curecoin. Emission schedules up for discussion (weekly for a year based on continual cc1.0 holding to avoid accidentally causing market swings?).
-Make the SigmaX mintage schedule model follow Curecoin 1.0 minus the PoS
-The conversion of Curecoin 1.0 to SigmaX doesn't involve burning--you keep your Curecoin, and you receive SigmaX. When 2.0 launches, your cc1.0 converts 1:1 to cc2.0, as has always been the plan.

What are people's thoughts on this idea?

For anyone who isn't on the slack community or IRC (already posted there), here's an optimized CUDA miner. Gets >40% performance improvement on pre-Maxwell, and ~10% improvement on Maxwell GPUs.

I have source and binaries here: https://github.com/Vorksholk/Sia-CUDA-Miner
KlausT also accepted my pull request and compiled his own binaries: https://github.com/KlausT/Sia-CUDA-Miner

The binaries I compiled seem to run a few percent faster (maybe due to compiler flags), but it's within an insignificant margin of error.

If you're building on Ubuntu (and have the CUDA toolkit and the cURL development library installed, of course), something like this should work for 6xx and 7xx cards (plus the Titan, Titan Black, Titan Z, Quadro K5xxx/K6xxx, Tesla K10/20X/40/80):

and Maxwell + future:

Note that the 750 Ti has compute capabilities 5.0, so despite being Maxwell, you'll want to use the older compilation. You can change the "30" in compute_30 and sm_30 to another number depending on your specific card. Check out https://en.wikipedia.org/wiki/CUDA, and just remove the period from the correct compute capability version that corresponds to your card. Older 5xx cards are compute 2.0 or 2.1.

For reference, a 980 Ti with an overclock to 1500 MHz gets 1850 MH/s.

You have your wallet unlocked for staking, right?

If you're at full 90-day stake weight, I'd guess somewhere around 10k coins split across a bunch of addresses should be staking daily if not more.

Someone PM'd me to discuss the 1% of first year mintage of SigmaX for folders, so I'd like to open that discussion up to the community.

I'd like to clarify a few points about the relationship between Curecoin and SigmaX:
-SigmaX and Curecoin 2.0 are entirely independent blockchains
-SigmaX will be purely proof of work, using a treechain-friendly hashing algorithm
-Curecoin 2.0 will still launch, likely within two or three weeks of the successful SigmaX full launch
-SigmaX will be the 'bleeding-edge' production test for updates to the Curecoin 2.0 code in the future. Things will go SigmaX testnet -> Curecoin 2.0 testnet -> SigmaX mainnet -> Curecoin 2.0 mainnet
-Curecoin 2.0 will only be mineable through folding

We wanted to premine a small amount of SigmaX and give it out to current holders of Curecoin to reward you guys for sticking with the project. The 1% figure was chosen since we figured that it'd be small enough that the general cryptocurrency community wouldn't be bothered by it.

If people want a larger percentage to go to Curecoin users, there's a few ways to do it:
-Simply premine a larger amount
-Have a permanent or decaying block subsidy for each SigmaX block that pays to a public address we control, and we'd do payouts of that using our traditional pool setup
-Have a larger premine mature gradually in the future, and do periodic payouts from that
-Have a larger premine mature all at one point in the future, and do the payouts at that point

And again, there's no dev fund, IPO/ICO/crowdsale for SigmaX.

Thanks! Just for clarification to anyone who watches that video, the PoS isn't related to folding, but rather is part of the PoW component.