Actually, all the code for the frontend has been written by @jcalfee already including a hosted-wallet solution that is a requirement for STEALTH in the frontend.
Dan didn't give up, he actually build it 100%. What he didn't want to do is run a business that hosts the wallets and offers STEALTH transactions. That's why the STEALTH feature is not merged into the main BitShares UI. Back then, Dan sold STEALTH tokens to kencode in the hopes he would just turn the switch on and run the wallet-hosting company.
W.r.t. confidentiality, the current Stealth implementation does indeed not support Ring signatures, but does stealth transactions. From here
The above quote demonstrates that while a Monero ring signature may be a "smaller" anonymity set, stealth addresses mask the receivers identity while the ring signature guarantees plausible deniability. When RingCT is activated in January, 2017 the amount of Monero spent in each RingCT transaction will also become protected.
In our case, amounts are hidden by another feature called Pederson Commitments using a blinding factor (weird crypto math).
That said, please don't believe everything you can read on the internet.
Thanks for writing this one up.
Based on your comments, I have to say that it seems like really bad design that using the current STEALTH implementation requires hosted wallets - this probably has severe implications in terms of liability and would make hosted wallets a big (and dare I say, easy to bring down) target in the ecosystem.
You mention in your other reply (ctrl+f stealth-receipt) that stealth receipts have to be kept server-side .. this appears to me as a very strange requirement, take #monero, (arguably? based on my research anyway) the best solution in terms of privacy/fungibility right now..
There is no such requirement.
I am sorry, I didn't make it clear in the first place.
STEALTH transfers requires to store a 'receipt' for every transfer you receive. Those receipts can be stored in a hosted wallet, but don't need to be. You could also write them down, or store them in your local browser storage, or some other means of storage. It is just that the "hosted wallet" solution would make it easier for users to do so, because it all happens transparently through a server storing the encrypted wallets entirely (including the receipts).
I agree that ring signatures are someone easier to use from the user's perspective.
Thanks for clearing that up.
It seems to me that this is a very fragile solution - as you are well aware, most users would lack the technical sophistication to kept such receipts safely (eventual data loss being my main concern here), which really only leaves the hosted wallet option.
I am inferring from the information that you have provided so far that it is game over if the user loses the receipts?
In that case, all of the user's balances are one third-party-company-going-away step from the void.
It is possible (quite possible, in fact) that I misunderstood something, but if the picture I painted above does match what the technology can do.. then I don't see how even someone technical like me could get the warm fuzzy feeling (tm) using this technology..
In timeless words by timeless people.. sh.t happens.
Yep. Fortunately, you could also store an encrypted receipt on the blockchain using a
customoperation. It would just end up being slightly more expensive to store them on-chain. It's not like there aren't cool solutions to that 'storing' problem. Not having that problem would be nicer though - of course.Well, if you manage to secure the private keys for your accounts, you should be able to do so as well for receipts. You could easily store them next to the wallet of private keys in your browser (though that would require regular backups instead of just a single backup) - but I (and probably also Dan) agrees that the storage problem in the STEALTH solution is somewhat delicate.
Shit doesnt need to happen. Thats just a poor excuse. Why does security continue to be the bottle neck for many of these crypto currencies.
What about this? https://steemit.com/bitshares/@vikx/anonymity-and-decentralization-an-application-for-the-stealth-hidden-transactions-of-the-graphene-bitshares-steem
@vikx shows that all it requires is a separate account with '~' prepended to it.
Is this what you're referring to?
Thanks xeroc for your reply. I'm certain you have more info about the stealth functionality, especially the GUI elements that I've never seen. I do recall providing @dantheman with feedback on his intended GUI design but I don't recall him offering much if any dialog about it. Some of that I believe can be found either on the bitsharestalk forum or in github issues.
Also, I was under the impression the primary reason dan didn't move ahead any further with stealth was he couldn't or didn't find a method to protect/backup the password he found acceptable. Not sure if his subsequent work on password recovery in steem is applicable to the (same / similar) problem in stealth or not.
BTW, is the jcalfe GUI work available as MIT open source on github?
Thanks again for all you do for this ecosystem. If it weren't for you I am certain BitShares would not be the great product it is!
One last thought - are you aware of any discussions past or present concerning a proper and thorough code audit of graphene? Is that even possible (i.e. are adequate specs available for an independent 3rd party audit service to perform such an audit)?