BitShares already has a STEALTH feature that is fully secure and functional on a blockchain level. It has been ready for over a year and there is documentation and a tutorial about it on docs.bitshares.eu.
You are viewing a single comment's thread from:
If average Joe don't know about it and can't use it , I don't see much value on it.
I disagree @xeroc. It only has a partial solution of blinded transactions. Moreover these type of transactions are only available in the cLI-wallet which will never see mainstream adoption or use. The capability is pretty close to worthless. I have personally evaluated this functionality and found it to be severely lacking in utility.
It is nowhere near the level of confidentiality that Monero has. It may compete with Dash in terms of the level of protection it provides, but but only if a GUI interface were provided and I doubt anyone will bother to invest the effort to do that.
Even @dantheman gave up on that before he left to pursue Steemit.
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
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)?
I've heard this mentioned here and there.
A few questions:
searching for "bitshares stealth site:docs.bitshares.eu" brings this up, with one mention of stealth, that links to a nonexistent page. Searching for "bitshares stealth" leads one here, which is great, for programmers. I looked around the website to find the tutorial you mentioned, without success.
I am running a fairly old release of the GUI, but quickly skimming through changelogs yields no results about STEALTH being baked in the official GUI - any idea why it was (apparently) never implemented?
According to cryptofresh, about 0.01% of the BTS supply makes use of the feature - related to no GUI support no doubt?
And perhaps most important of all, if there is already a working solution, why is all this time, money, attention and developer effort being spent reinventing the wheel?
Thanks for all the information provided. I've replied to #2 above, and concerning #4, do you think that the technology being developed now to replace the stealth we have is a superior solution?
In my view, not even touching on the hardcore cryptographic aspects, if those stealth-receipts you mention are not needed with the new solution, that's already enough of a reason in my book.. what are your thoughts on this?
All I know about what is currently "in development" is that there is something in development. I would need specs and documentation for that before I can make an opinion on it and I have asked ken numerous times to provide it. No response so far. Not seen ken's testnet that he promised for Christmas last year either.
From the top of my head, I think there are 4-5 different ways of adding some sort of privacy to the blockchain level. 2 of them are already available on BitShares and there is nothing technically preventing us from adding more.
However, there is the incentives that currently only lies on those that hold STEALTH tokens, to actually build something useful on it. I personally have thought about adding the current STEALTH feature into python-bitshares, but don't see a reason to work on code that earns a profit to someone else.
That said, STEALTH doesn't have a technical problem, it rather has a political and economical problem on BitShares -- currently.
100% agree that we should have access to the technical inner-workings of the new system. As you know I have not been around much lately (pretty much due to the stealth-stall), so I just assumed such documents would exist - it seems rather silly to be funding such work without knowing exactly what is being funded, and if the technology being implemented is even sound to begin with - before any line of code is even written.
The good-natured side of me would say that @kencode has been too busy or that perhaps there has been some sort of miscommunication, I hope it is something like that - because I 100% agree with you, we need such technical documentation.
Apparently there is also a GUI since 2016. Here is a post (in Russian) about it.
Stealth client is located in here: https://github.com/cryptonomex/graphene-ui/releases/