[ANN][EC]▲ Eclipse ▲ Ring Signatures | Anonymous | TOR | Stealth Addresses

[Eclipse Crypto]

stop launching scam coins. thanks.

I love deleting posts from trolls who don't even bother to read.

Get a life child.

[1715628240]

1715628240

[1715628240]

1715628240

[1715628240]

1715628240

[1715628240]

1715628240

[BleedCrypto]

can't download Windows QT from Mediafire
Please change this sh*t storage on something better
mega.nz as example
Good luck, dev!

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

We still need to move from mediafire, but the Mac wallet is at http://www.mediafire.com/download/wa9i3b2pi8rprdh/Eclipse-Qt.dmg

We just finished building it. We'll move from mediafire soon.

awesome.  ty for this!

[notsofast]

Hi all, we are hoping a pool operator will decide to add EC soon to increase the ability for everyone to mine more easily.

Please continue to check back.

You'd have a chance if your broken source on github would compile

Eclipse is the 12-year-old Indian kid's coin, every time. Broken source, every time. Abandoned before a pool, every time.

I should know, the few times I've bothered to mine I get about 75% of the coin supply before every other node leaves and the coin dies.

I am not a 12 year old Indian kid and we are working on it.  There have only been 105 blocks mined so please stop making assumptions.

OK, since this post I've monitored the thread and I'm convinced you aren't Niitassin the 12-year-old Indian kid who serially releases cryptocurrencies called Eclipse or Eclipsecoin and abandons them.

The "insert an image of an eclipse here" is the kind of jokey voicing I've come to recognize from his ANN threads. And he was talking about implementing the same library.

But he wasn't forking SDC to fix its broken anon and you are, so that's good. I'm mining. Best of luck.

[OSMIUMCOIN]

[stoner19]

Don't forget, there will be a bonus issued to miners who use superninjapool.tk over the next few weeks!

[Eclipse Crypto]

Hi all, we are hoping a pool operator will decide to add EC soon to increase the ability for everyone to mine more easily.

Please continue to check back.

You'd have a chance if your broken source on github would compile

Eclipse is the 12-year-old Indian kid's coin, every time. Broken source, every time. Abandoned before a pool, every time.

I should know, the few times I've bothered to mine I get about 75% of the coin supply before every other node leaves and the coin dies.

I am not a 12 year old Indian kid and we are working on it.  There have only been 105 blocks mined so please stop making assumptions.

OK, since this post I've monitored the thread and I'm convinced you aren't Niitassin the 12-year-old Indian kid who serially releases cryptocurrencies called Eclipse or Eclipsecoin and abandons them.

The "insert an image of an eclipse here" is the kind of jokey voicing I've come to recognize from his ANN threads. And he was talking about implementing the same library.

But he wasn't forking SDC to fix its broken anon and you are, so that's good. I'm mining. Best of luck.

Thanks for your support. We really didn't do our background research on the name "eclipse". None of us had heard of a coin called eclipse, so we thought it was a cool name that conveyed "hiding". It just turned out to be a strange coincidence, especially with the jokey voicing, as you say.

We hope to build a little steam and get some loose ends like a website, branding, etc., together so this looks like a real coin. Window dressing is the last thing we thought about. We spent all our time prior to launch just making sure we got the crypto right. You'll see that the part we fixed is technically correct according to the latest literature, taking into account best practices. That still can't be said for the fix that shadowcash has planned.

[y_0]

Why are you guys spamming the SDC thread and Slack?

I don't see any spamming in the thread... I posted the 'fix' to SDCs anonymity bug because it concerns SDC, does it not?
What I posted is very relevant to SDC. It's not like I was talking about rainbows and butterflies.

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.

The fact that $G$ = $aG^*$ is but a little lemma whose proof that I found in the margins of my notebook.

I will use the additive notation, since this is what is used for Elliptic Curves, but it's just a convention.  Multiplicative notation is just as fine.

Lemma *:  Let $K$ be a cyclic group of order $n$.  Let $G$ be a generator of $K$, i.e. $<G> = K$.  Then, $\forall H \in K \exists a \in \{0, \dots, n-1\}$ such that $aG = H$.

Proof:  Assume $K$ is a cyclic group of order $n$ and $G$ generates $K$ and let $H \in K$.  By definition of cyclic groups, since $G$ generates $K$, there exists an integer $a \in \{0, \dots, n-1\}$ such that $aG = H$.  -- see https://en.wikipedia.org/wiki/Cyclic_group . 
Q.E.D. of Lemma *.

Now, since the elliptic curve that is secp256k1 is a group whose order is a prime, then it is a cyclic group.  This is because all groups that have prime order are cyclic -- for a proof, see : http://planetmath.org/proofthateverygroupofprimeorderiscyclic.  For some clarification that secp256k1 has prime order, see : http://bitcoin.stackexchange.com/questions/38108/order-of-group-of-points-of-secp256k1 and the answer by Akater which references the documents defining standard curves, for instance SECG -- http://www.secg.org/sec2-v2.pdf -- to which secp256k1 belongs.

Therefore, by (*), $G = aG^*$ is true.

[Bank_sy]

I liked your previous work more, just need to make the E a little smaller and maybe bolder.

[Eclipse Crypto]

Rewards have been sent to everyone who has followed and registered so far!  The offer still stands!! 

Eclipse Twitter Promotion!

In order to star to bring awareness to Eclipse, we are going to be making a large push on Twitter and rewarding our followers who participate!

The first promotion will reward users with 15 EC simply for following twitter.com/EclipseCrypto and providing your EC address.

Step 1: Sign on to Twitter and follow twitter.com/EclipseCrypto
Step 2: Fill out this Google form to provide us your address so we can track activity without annoying you every time: http://goo. gl/forms/ga2gcFsUsO (copy/remove space)

Here are the rules:
1: Obviously you've gotta be a follower
2: You have to have at least 50 REAL followers (we'll verify on TwitterAudit)
3: Participate and earn EC

That's it.  Stay tuned to the thread and we'll have regular promotions to earn additional EC!

[Bank_sy]

Why are you guys spamming the SDC thread and Slack?

I don't see any spamming in the thread... I posted the 'fix' to SDCs anonymity bug because it concerns SDC, does it not?
What I posted is very relevant to SDC. It's not like I was talking about rainbows and butterflies.

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.

The fact that $G$ = $aG^*$ is but a little lemma whose proof that I found in the margins of my notebook.

I will use the additive notation, since this is what is used for Elliptic Curves, but it's just a convention.  Multiplicative notation is just as fine.

Lemma *:  Let $K$ be a cyclic group of order $n$.  Let $G$ be a generator of $K$, i.e. $<G> = K$.  Then, $\forall H \in K \exists a \in \{0, \dots, n-1\}$ such that $aG = H$.

Proof:  Assume $K$ is a cyclic group of order $n$ and $G$ generates $K$ and let $H \in K$.  By definition of cyclic groups, since $G$ generates $K$, there exists an integer $a \in \{0, \dots, n-1\}$ such that $aG = H$.  -- see https://en.wikipedia.org/wiki/Cyclic_group . 
Q.E.D. of Lemma *.

Now, since the elliptic curve that is secp256k1 is a group whose order is a prime, then it is a cyclic group.  This is because all groups that have prime order are cyclic -- for a proof, see : http://planetmath.org/proofthateverygroupofprimeorderiscyclic.  For some clarification that secp256k1 has prime order, see : http://bitcoin.stackexchange.com/questions/38108/order-of-group-of-points-of-secp256k1 and the answer by Akater which references the documents defining standard curves, for instance SECG -- http://www.secg.org/sec2-v2.pdf -- to which secp256k1 belongs.

Therefore, by (*), $G = aG^*$ is true.

I'm a bit lost, are you saying that SDC testnet fix is valid?

[Eclipse Crypto]

Why are you guys spamming the SDC thread and Slack?

I don't see any spamming in the thread... I posted the 'fix' to SDCs anonymity bug because it concerns SDC, does it not?
What I posted is very relevant to SDC. It's not like I was talking about rainbows and butterflies.

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.

The fact that $G$ = $aG^*$ is but a little lemma whose proof that I found in the margins of my notebook.

I will use the additive notation, since this is what is used for Elliptic Curves, but it's just a convention.  Multiplicative notation is just as fine.

Lemma *:  Let $K$ be a cyclic group of order $n$.  Let $G$ be a generator of $K$, i.e. $<G> = K$.  Then, $\forall H \in K \exists a \in \{0, \dots, n-1\}$ such that $aG = H$.

Proof:  Assume $K$ is a cyclic group of order $n$ and $G$ generates $K$ and let $H \in K$.  By definition of cyclic groups, since $G$ generates $K$, there exists an integer $a \in \{0, \dots, n-1\}$ such that $aG = H$.  -- see https://en.wikipedia.org/wiki/Cyclic_group .  
Q.E.D. of Lemma *.

Now, since the elliptic curve that is secp256k1 is a group whose order is a prime, then it is a cyclic group.  This is because all groups that have prime order are cyclic -- for a proof, see : http://planetmath.org/proofthateverygroupofprimeorderiscyclic.  For some clarification that secp256k1 has prime order, see : http://bitcoin.stackexchange.com/questions/38108/order-of-group-of-points-of-secp256k1 and the answer by Akater which references the documents defining standard curves, for instance SECG -- http://www.secg.org/sec2-v2.pdf -- to which secp256k1 belongs.

Therefore, by (*), $G = aG^*$ is true.

I'm a bit lost, are you saying that SDC testnet fix is valid?

That's not the topic of that math. The other dev is just clarifying mathematically where I asserted the relationship G = aG*, and showing how it is valid.

That was actually a response to a post on the SDC thread where someone without much math knowledge was questioning what I said.

You can't respond to them in their thread or you will get deleted.

So our other dev decided just to do it here. He proved the relationship holds for all group elements G* over a prime field because G is a generator for the group. Our other dev is a real precise mathy-type who doesn't let anything go in the way of math reasoning.

Oh, and to answer your question, I said "G is protected by discrete log hardness". So the exploit that de-anoned their chain in the first place is now protected by a cryptographically hard problem. However, I also observed that the way they are doing it (maybe to save CPU cycles) is not advisable in general. I can show a couple of reasons why.

Here's essentially where they pick their generator in their current plan:

Code:

uint256 hash = Hash(Params().pszTimestamp, Params().pszTimestamp + strlen(Params().pszTimestamp));

What's this do? It takes the hash of the same time stamp string used for the genesis hash and will use it to map to a generator.

Then this generator is used for every ring signature in the entire block chain.

Now, if, for some reason anyone ever solves a for

G = aG*

Then the whole system comes crashing down. Every signature will be deanoned. Period.

You may be thinking that the discrete log problem holds here and you would be right. But, on the most practical level it is a single point of failure. Of lesser potential issue is why did they pick that timestamp? There are zillions of seemingly obvious strings and numbers that could be used to seed the generator. Why not the name of the coin, why not "Satoshi Nakamora", why not "Alan Turing", etc. etc? Admittedly this second potential for nefarious intent is far-fetched, but it exists nonetheless, and is a valid cyptographic concern because it leaves some wiggle room that compromises the "rigidity" of the crypto system.

Our system has neither this single point of failure nor arbitrary parameter.

I'll further add that this seemingly simple solution used by shadowcash undoubtedly occurred to the creators of cryptonote. Why didn't the cryptonote devs use this solution of a generator with "unknown" log? Why would they not want to make their system save CPU cycles and further find the group point in constant time? Why did they use a curve where they could solve the root (or find a residue for the root they found)?

These are rhetorical questions, but very important to ask.

[Eclipse Crypto]

Could we get a block explorer that shows the current coin supply?

Yes. We are working on all this. We are still nailing down the following:

1. Finalize branding, logos, etc., pay the bounty
2. Add enough Website Content to satisfy exchanges
3. Block explorer (probably fairglu's) -- this much of the list will get us on yobit and/or bleutrade
4. We need to decide on where to host the Qt wallets so we can track downloads (not mediafire)
5. Finalize the medium-term development road map
6. Get the whitepaper finished (post bleutrade/yobit, pre bittrex)

It seems like a straightforward list, but we have multiple devs and we have to reach consensus about every little thing.

Once we finalize all decisions, we should proceed through the list pretty fast, although we will pace 4 & 5 to ensure we spend enough time at the smaller exchanges before we move to the larger.

[chrisvl]

Could we get a block explorer that shows the current coin supply?

Yes. We are working on all this. We are still nailing down the following:

1. Finalize branding, logos, etc., pay the bounty
2. Add enough Website Content to satisfy exchanges
3. Block explorer (probably fairglu's) -- this much of the list will get us on yobit and/or bleutrade
4. We need to decide on where to host the Qt wallets so we can track downloads (not mediafire)
5. Finalize the medium-term development road map
6. Get the whitepaper finished (post bleutrade/yobit, pre bittrex)

It seems like a straightforward list, but we have multiple devs and we have to reach consensus about every little thing.

Once we finalize all decisions, we should proceed through the list pretty fast, although we will pace 4 & 5 to ensure we spend enough time at the smaller exchanges before we move to the larger.

Host qt on bitbucket

[Bank_sy]

Could we get a block explorer that shows the current coin supply?

Yes. We are working on all this. We are still nailing down the following:

1. Finalize branding, logos, etc., pay the bounty
2. Add enough Website Content to satisfy exchanges
3. Block explorer (probably fairglu's) -- this much of the list will get us on yobit and/or bleutrade
4. We need to decide on where to host the Qt wallets so we can track downloads (not mediafire)
5. Finalize the medium-term development road map
6. Get the whitepaper finished (post bleutrade/yobit, pre bittrex)

It seems like a straightforward list, but we have multiple devs and we have to reach consensus about every little thing.

Once we finalize all decisions, we should proceed through the list pretty fast, although we will pace 4 & 5 to ensure we spend enough time at the smaller exchanges before we move to the larger.

sounds good but 3,4,5,6 are pretty much a parts of 2

[Eclipse Crypto]

Could we get a block explorer that shows the current coin supply?

Yes. We are working on all this. We are still nailing down the following:

1. Finalize branding, logos, etc., pay the bounty
2. Add enough Website Content to satisfy exchanges
3. Block explorer (probably fairglu's) -- this much of the list will get us on yobit and/or bleutrade
4. We need to decide on where to host the Qt wallets so we can track downloads (not mediafire)
5. Finalize the medium-term development road map
6. Get the whitepaper finished (post bleutrade/yobit, pre bittrex)

It seems like a straightforward list, but we have multiple devs and we have to reach consensus about every little thing.

Once we finalize all decisions, we should proceed through the list pretty fast, although we will pace 4 & 5 to ensure we spend enough time at the smaller exchanges before we move to the larger.

sounds good but 3,4,5,6 are pretty much a parts of 2

Exchanges don't require a roadmap or whitepaper.  Is there more you think we should be doing?  We're more than happy to accept help if you feel this isn't suitable in the short term.

[Akbarkoe]

i have a problem if i open the wallet QT.
ERROR LOADING BLKINDEX.DAT



How to fix it?

[NextGenCrypto]

i have a problem if i open the wallet QT.
ERROR LOADING BLKINDEX.DAT



How to fix it?

I think you just have to try to open it again.  Common error with Qt's.

[Akbarkoe]

i have a problem if i open the wallet QT.
ERROR LOADING BLKINDEX.DAT



How to fix it?

I think you just have to try to open it again.  Common error with Qt's.

I open that again still the same
I dont know how to fix it? any problem with the wallet QT?

[NextGenCrypto]

i have a problem if i open the wallet QT.
ERROR LOADING BLKINDEX.DAT



How to fix it?

I think you just have to try to open it again.  Common error with Qt's.

I open that again still the same
I dont know how to fix it? any problem with the wallet QT?

I haven't had any issues.  Try deleting everything except your wallet.dat from your eclipsecrypto roaming folder and restart.

[Eclipse Crypto]

Could we get a block explorer that shows the current coin supply?

Yes. We are working on all this. We are still nailing down the following:

1. Finalize branding, logos, etc., pay the bounty
2. Add enough Website Content to satisfy exchanges
3. Block explorer (probably fairglu's) -- this much of the list will get us on yobit and/or bleutrade
4. We need to decide on where to host the Qt wallets so we can track downloads (not mediafire)
5. Finalize the medium-term development road map
6. Get the whitepaper finished (post bleutrade/yobit, pre bittrex)

It seems like a straightforward list, but we have multiple devs and we have to reach consensus about every little thing.

Once we finalize all decisions, we should proceed through the list pretty fast, although we will pace 4 & 5 to ensure we spend enough time at the smaller exchanges before we move to the larger.

sounds good but 3,4,5,6 are pretty much a parts of 2

We are going to go through the process in due time. First you get on small exchanges for price discovery and distribution. Then you go on big exchanges. There is no rush here. Miners can get out early at a smaller exchange with some good profit. And believers can hold for bigger exchanges or implementation of roadmap features.

We won't put the cart in front of the horse.

We are going to put some website content up within the day. For now, the community should start to try to help us get on yobit or bleutrade.

In the meantime, here is a block explorer with rich list: https://chainz.cryptoid.info/ec/