Topic: [ANN][XST] Stealth-Coin.com | Tor | StealthText, World's first anonymous SMS Tx! - page 54. (Read 748429 times)

Yep...

http://www.engrish.com/

LOL
Do you see market history?  

No Bob's fake walls, no pump  R.I.P. XST

Price drop to 5800k 

Stealthcoin is on top with 110BTC volume!

Price drop to 5800k  

Before addressing the criticisms raised in this thread, I would like to express my sincere appreciation for these criticisms. Although some believe the manner in which they have been introduced may not be optimal to promote civil discourse, they are valuable criticisms nevertheless, and help to strengthen crypto-currencies in general. It is far better to address weaknesses in crypto systems during implementation than it is to address attacks after deployment.

Chandran signatures [1] make use of a common reference string. The common reference string generator (CRSGen) is a necessity for a model that does not require a random oracle, as described in [1]. CRSGen produces a string that is used as an input to a key generation function. The key generation function produces the user's public-private key pair. This key pair has specific properties in that it is a member of a particular mathematical group. In principle, key generation can be replaced by a cryptographic one-way function if the random oracle assumption is introduced.

Admittedly a more difficult issue to address is one of "unlinkability/untraceability", which boils down to the potential for a double spend. In short, Chandran signatures require the generation of a secret random parameter, g, that serves as an input to a "commitment" to a specific key in the key ring. This commitment basically identifies the public key from which the money is spent. The problem is that any number of g can be produced, creating the potential for any number of commitments to the specific public key.

In reality, this same issue exists with CryptoNote ring signatures except that the CryptoNote system incorporates a key image, I, into signing and verification, such that I can only ever be used once. A similar approach can be taken with Chandran signatures. As presented in [1], a key image I can be incorporated into Step 3 of signing and appended to the final signature. In addition to other parameters, Step 3 commits to the public keys of a subset of the ring. Just as with CryptoNote ring signatures, such a modification would commit to the key image and prevent its use for double-spends.

[1] Chandran N., et al. Ring Signatures of Sub-linear Size Without Random Oracles. ICALP 2007, LNCS 4596, pp. 423–434, 2007.


-- Hondo

results of what its its not really their problem i mean they looked at the paper they gave an opinion and they are already not thinking about it.

to sum it up its just not really somethign that is viable but it is doable but comes with conditions..loads of them

its better to go back to the drawing board and start again they are looking at the wrong paper end of story

how many people do you want to look it over before you realise its not gonna happen!

you are talking about a dev team that have ported most of their coin and even removed copyright and put their own

gmaxwell: it's not clear to me that its 'doable',

there may be related schemes in that family which are applicable (I haven't researched further)

, but the particular paper cited is of a technique which is not usable as is.

And looks like it would not be advantagious if it were possible to modify it to make it usable.

its not doable the way they are implying its unlinkable/tracable

Stealthsend will be a new coin. It's stated clearly on some of the Stealthcoin papers...

All righty. Since longandshort was posting the IRC chat including some of the stuff I was asking, I figure I'll post my perspective for anyone that might actually care.

The conversation in the bitcoin channel was somewhat misleading and really didn't answer me satisfactory.  Frankly, it's not their job and, as longandshort posted, they don't really know if it can be implemented or not given the limited information presented.  They're also looking at it from the perspective of bitcoin.

Since I was mentioning Monero in there, one of their devs invited me into one of their channels where I was able to ask a few more questions.

Regarding the paper I posted that outlines how Chandran signatures can be traceable etc. Apparently it has not even been peer reviewed. So I'm left with the assumption that while it could be implemented, it would be questionable as to whether or not it would be sound.

So I was thinking about the whitepaper and what it actually said.  Two things stood out to me, the first that it was talking about CN and then about burning Stealthcoins to Stealthsend coins.  One of the key issues is the blockchain.  For example, CN and bitcoin blockchains are completely incompatible. In addition, trying to implement something like Chandran sigs into a bitcoin core would be a massive undertaking.  I mention the bitcoin core since it appears the source for Stealthcoin is based on that given the copyright notice although there's probably been some mods to it as well.  Either way, I simply don't see how Stealthsend could be added into the blockchain after the fact especially given the time frame.

Given all that, the only way I can see potentially having Stealthsend in the time frame outlined is if it was based on CN with its own blockchain or perhaps some sort of dual blockchain scheme.  That would sort of fit with the whitepaper talking about burning one for the other.  In addition, changing CN to use Chandran sigs would be a much easier task but as I said, whether or not it would be cryptographically sound would still be up for debate.

And with that, I'm done with this Chandran sigs/Stealthsend topic as I spent far too much time looking into something that the devs should have been more clear about.  Good luck to everyone.

Before addressing the criticisms raised in this thread, I would like to express my sincere appreciation for these criticisms. Although some believe the manner in which they have been introduced may not be optimal to promote civil discourse, they are valuable criticisms nevertheless, and help to strengthen crypto-currencies in general. It is far better to address weaknesses in crypto systems during implementation than it is to address attacks after deployment.

Chandran signatures [1] make use of a common reference string. The common reference string generator (CRSGen) is a necessity for a model in that does not require a random oracle, as described in [1]. CRSGen produces a string that is used as an input to a key generation function. The key generation function produces the the user's public-private key pair. This key pair has specific properties in that it is a member of a particular mathematical group. In principle, key generation can be replaced by a cryptographic one-way function if the random oracle assumption is introduced.

Admittedly a more difficult issue to address is one of "unlinkability/untraceability", which boils down to the potential for a double spend. In short, Chandran signatures require the generation of a secret random parameter, g, that serves as an input to a "commitment" to a specific key in the key ring. This commitment basically identifies the public key from which the money is spent. The problem is that any number of g can be produced, creating the potential for any number of commitments to the specific public key.

In reality, this same issue exists with CryptoNote ring signatures except that the CryptoNote system incorporates a key image, I, into signing and verification, such that I can only ever be used once. A similar approach can be taken with Chandran signatures. As presented in [1], a key image I can be incorporated into Step 3 of signing and appended to the final signature. In addition to other parameters, Step 3 commits to the public keys of a subset of the ring. Just as with CryptoNote ring signatures, such a modification would commit to the key image and prevent its use for double-spends.

[1] Chandran N., et al. Ring Signatures of Sub-linear Size Without Random Oracles. ICALP 2007, LNCS 4596, pp. 423–434, 2007.


-- Hondo