This thread is nothing more than a baseless scam accusation. It's product of a review of XST's StealthSend whitepaper which never made it into production. The XST developer promised to deliver his spec without testing or having it peer reviewed. This is by definition vapor and as a result smart investor exited Stealthcoin. Rather than accept reality they've chose to smear one of the leading pioneers in the privacy space, Shadow.

The review happened on the fly by a few of the Bitcoin core developers: Greg Maxwell and Andytoshi.
A log is available here: http://pastebin.com/uaFHZUm2

Quote From Greg Maxwell regarding XST:

bjjb: At the same time I would argue that Hondo has demonstrated good work ethic and some integrity.  I do not think that he is the type of person to profit like that.  It seems very counter to my experiences with him.
[01:38am] bjjb: If this is truly a work of his passion, maybe he will find a way to make it work. I do appreciate the skeptic professional opinions tonight - they are rare in the trade scene.
[01:40am] nessence joined the chat room.
[01:40am] gmaxwell: You can't really honest effort yourself through something that is just not applicable, and probably not through not knowing what you're doing. ... and you speak of integrity, but launching some speculative asset when you've not done the work?  I don't think that is something that speaks of integrity.


This thread serves as a recovery for people who chased riches without doing their due diligence before investing in XST. BobSurplus who is a known scammer was pumping Stealthcoin and people still refused to recognize the scam.

The SDC richlist is available here: http://sdc.blockexplorer.cc/richlist/ There is nothing truthful about the scam accusations made by these poor souls who suffered at the hands of their own ignorance.

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