Mining on suprnova now.
Down with the stupid SDC trolls! I knew their time would come.
Topic: Eclipse is the first TRULY cryptographically anon coin (bye bye SDC) (Read 452 times)
February 29, 2016, 03:50:55 PM
February 29, 2016, 01:56:35 PM
did Eclipse just kill off SDC?
sounds like it to me. bye bye SDC trolls, hello Eclipse!
taken from original thread: https://bitcointalksearch.org/topic/annec-eclipse-ring-signatures-anonymous-tor-stealth-addresses-1378922
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.
sounds like it to me. bye bye SDC trolls, hello Eclipse!
taken from original thread: https://bitcointalksearch.org/topic/annec-eclipse-ring-signatures-anonymous-tor-stealth-addresses-1378922
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.
Jump to: