Okay. We'll put it on something better. We are almost done building the mac wallet.

Mediafire is up. But it doesn't matter. We are going to move hosting the Qts to github when we get the mac wallet built, which should be done within an hour or 2.

We deleted your post.

We have a minimum information entropy requirement.

Noob: 100 words of information entropy
Jr: 75 words of information entropy
etc.

We might raise the numbers depending on how many stupid people choose to spurt banal one-liners.

Thanks for the heads up about the site, need to look into why it needed rebooting!

Not at all. No one has touched the link. It's on mediafire.

We looked into it. Mediafire is down. If it doesn't come up soon, we'll host it somewhere else.

We can tell by your avatar that you don't own any SDC.

That's great to hear and we appreciate any constructive feedback, especially from those experienced in the XMR community.

You sound to me like a scared SDC bagholder.  Did I hit the nail on the head??

SDC looks to be converging on a reasonable fix, but not a recommended one.

Originally, they took the scalar hash then multiplied it by the private key and then used it for the scalar multiple of the group generator (two different types of "multiply" here but I didn't invent this convention). Math looks like

I = H(K_i)xG

That was the very wrong way.

Now they take an arbitrary point on the curve by hashing the time stamp, trying to map it to a point, then using that point as a generator. This takes advantage of the fact that all curve points on a prime field can be full generators. The new generator is G*

I = H(K_i)xG*

There is a relationship between G and G*, namely one is a multiple of the of the other:

G = aG*

But in this case G* is "unknown log", so G is protected by discrete log hardness.

In general, however, it is not good to try to use a generator to hash scalars to a curve. They already learned this lesson once.

No SDC got bloody de-anoned 100%.

If you think you are using at anonymously, you are bloody mistaken.

Yes, we have an internal roadmap. But before we make it public, we need to see for ourselves what kind of potential there is for an anonymous coin.

Our motivation was to get some people who know cryptography and math (us) together with a coin that has good anonymity. We aren't for bells and whistles until the potential of the underlying protocol is fully realized. However, if you like bells and whistles, those that come with shadowcoin are pretty good.

If you insist, our near-term plans are twofold and a little technical.

1. First, we need to bring the bitcoin secp256k1 library to the entirety of the Eclipse code base. This means not only using it as an API for patching the broken shadowcash ring signatures (which we have done), but also to use it for all of the operations over secp256k1. This also means integrating Schnorr signatures, which are native to the bitcoin secp256k1 library.
2. Second the current implementation needs proper blockchain pruning.

Just a reminder about our Twitter promo!  We've had a good number of responses so far.   

As usual, smooth has beautiful insight, but it's not an insight that wasn't also obvious to us.

It's important to understand that SDC ported the cryptonote ring signature system to the bitcoin codebase, almost in it's entirety. You can see what I mean in the naming of the methods:

CN: hash_to_ec --> SDC: hashToEC
CN: generate_key_image --> SDC: generateKeyImage
CN: generate_ring_signature --> SDC: generateRingSignature

Why is this important? Because where SDC has an opportunity to deviate, they may create security flaws. Here, they chose to use curve secp256k1, which has a number of useful properties, most notably the potential for an very efficient implementation, as has been created by bitcoin. In choosing secp256k1, they had no template function by which to map a scalar hash (SHA256d) to an EC point. So they did the most "obvious" and provably wrong thing, they took the scalar multiple of the EC base point, using the hash as the scalar.

Shen discovered this flaw, we absolutely do not want to take credit for his insight.

In general, SDC did not deviate significantly from cryptonote elsewhere from what we can tell. Thus, since they followed the cryptonote recipe, the rest of the ring signature system will be as secure as cryptonote for the simple reason that there are not many ways to screw it up. Once you have the EC point from the hash, generating the signature and key image is identical to the cryptonote method.

We hope to offer Shen Noether a bounty for a review of our method.

It's not "just a fix". You actually have to know what you are doing and be able to do it correctly. It's not like we fixed a typo somewhere. Shadowcash didn't know what they were doing and got completely de-anoned. They are still trying to figure out the correct way to do it.

We are very interested. Obviously, we can't post pictures yet, but we are currently discussing the look.

A comment from one of the devs: "i like it, only thing that is an issue with me is that the planet in the center (or whatever it is) makes me think of a negative connotation (like no smoking or whatever)....i mean, if it were more planet-y, i like it".


Also, it is "eclipse crypto", not "coin" because there are technically more than one "coin" here.

Is it possible to give the "e" less of a negative connotation?

We are also discussing a bounty. We know this is work.

To hell with it, here comes the cat out of the bag.

Eclipse is the first truly cryptographically anonymous coin based on the bitcoin protocol.

It is forked from shadowcash, which was completely de-anoned. See here: https://shnoe.wordpress.com/2016/02/11/de-anonymizing-shadowcash-and-oz-coin/

You will see from Shen Noether's write-up that they used a cryptographically insecure hashToEC function.

Here, we replaced their hashToEC with a cryptographically secure variant. Right now shadowcash is still not anonymous. Eclipse is anonymous.

The writeup linked above describes how the shadowcash hashToEC is broken, so I won't go into it here.

We use what is known as "try-and-increment hashing to an elliptic curve". It is a simple algorithm that is used in several cryptosystems. Key image with our algo goes like this:

1. take a scalar hash (e.g. SHA256d) of the public key (k) and map it to x on the secp256k1 discrete field
2. determine whether this x is a quadratic residue of secp256k1
3. if x is not a quadratic residue, set x = x+1 and go to 2
4. else x is a quadratic residue so keep the point x, y, where y is the positive solution to x for secp256k1, let's call this point p
5. multiply the point p = (x,y) by the scalar representing the private key x, such that key image I = xp

You can verify this is our algo by looking at secp256k1_hash_to_ec_xy_bytes() in our source tree at src/secp256k1/secp256k1/src/secp256k1.c. Rather than re-invent the wheel, we used bitcoin's secp256k1 library to determine the suitability of x and to find it's root to map point x,y.

Happy mining!


Edit:

I forgot to add that anyone who investigates may come across a caveat about try-and-increment where it is subject to "timing attack". Timing attack is absolutely not relevant to ring signatures though, because everyone already knows what a timing attack might reveal: the curve, the input k, and the scalar hash algorithm used. Going back to the original cryptonote white paper, the private key x is protected by discrete logarithm hardness.

Edit:

We have a whitepaper coming that goes into more detail and summarizes Shen's work.

A few on the team have been mining on your pool since you opened it up and superninjapool . tk has been rock solid.

One thing: if you tweaked the source to remove the secp256k1 dependency in sigringu.cpp, please rebuild with the latest commit.

Removing the dependency will, when validating certain kinds of sending transactions, result in an uninitialized array with essentially random values. This means your node will reject some valid transactions.

We guess you probably fixed it by modifying the autoconf generated configure file, but if you changed the source you might run into the problem described.

Thanks again for your pool services!

Thank you.  Shot you a PM as well.

Looks like ec.suprnova.cc is up and running, okay to mine there?