[IMAGE: https://www.eff.org/files/styles/resized_banner/public/issues/og-nsa-1.png]
Not all is well on Bitshares land
As many of you are aware, drama erupted some weeks ago as allegations and accusations started flying in a flurry of accusations, promises and eventually, cliffhangers.
We have been waiting for developments (pun intended) on this matter ever since, and except for a few question dodged here and there, not much appears to have changed.
The big casualty ?
Private transactions in the #bitshares blockchain.
This is not a small issue.
The choice is ours - a dystopian future where our every transaction is publicly associated with our identity forever, where the government and a myriad of for-profit companies know everything we buy (and who we buy it from, and how often, and so on).. or a reality where we get to maintain our financial privacy while having the convenience and advantages of using blockchain technology - in other words, true digital »»»cash«««.
The #monero guys got this one right.
[IMAGE: http://i.imgur.com/4DidW7B.png]
I am of the opinion that this enforced transparency on the #bitshares blockchain has cost us dozens, if not hundreds of thousands of users over the years - and that by continuing to delay its implementation, we will continue not onboarding many more.
In a competitive technological area such as this, failure to address such a basic point as the privacy of the users of the system ("bitshares: the telnet of blockchain") can and WILL eventually relegate the project to obscurity, as better solutions come along.
NOW is the time to expand our influence and become a safe haven for intelligent people looking to leverage blockchain technology to improve life & liberty. A FULLY PRIVACY-DEVOID SYSTEM IS A COMPLETE OPPOSITE OF THAT.
We must find a solution to move forward.
tldr
@chris4210, @kencode work whatever it is that you guys have to work out between yourselves, but don't forget what we're trying to accomplish with #bitshares, and do not for even one second doubt that creating a secure, private, confidential system where humans (dogs coming soon) can store value digitally is FUNDAMENTAL for this technology to do good in the world.
Graphene / #bitshares still has an edge. For now. With totalitarian-like full transparency, I'm reasonably sure we will never see widespread adoption of the network.
And that would be a damn shame.
Work it out guys! And keep us posted.
You don't imply it? Actually, you state very explicitly right at the top that privacy features are "the big casualty" of the disagreement between Ken and Chris. Your intention may not be to FUD Bitshares, but that is exactly what you are doing.
>The big casualty ?
>
>Private transactions in the #bitshares blockchain.
I want it resolved too. But what does this have to do with stealth? Again, Ken's work on stealth continues. Granted, it should NOT be necessary for @onceuponatime to provide alternative funding (which I am thankful for). But that is another matter entirely!
>all I want is for this very important matter to move forward, so that we can all keep pushing #bitshares >forward.
@karnal | May 30, 2017, 9:02 p.m. | Votes: 7 | [
VOTE ]
I believe that it is obvious from both the surrounding context of the wording and the general tone of the text (in your opinion, FUD, in my opinion, attempting to galvanize the community and the main protagonists of this episode into finding a solution by reminding everyone of the greater good in doing so) that what you claim is not the case.
Likewise, I find it in extremely poor taste that you use your extreme weight on this platform to downvote this post to oblivion, but self-evidently you see the motivation behind this action differently.
Just remember this: we're both invested in BTS and we both want it to succeed.
As for the rest - let's just agree to disagree.
@karnal | May 30, 2017, 8:35 p.m. | Votes: 5 | [
VOTE ]
I've heard this mentioned here and there.
A few questions:
1) 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.
2) 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?
3) According to cryptofresh, about 0.01% of the BTS supply makes use of the feature - related to no GUI support no doubt?
4) 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?
@xeroc | May 31, 2017, 8:31 a.m. | Votes: 4 | [
VOTE ]
> do you think that the technology being developed now to replace the stealth we have is a superior solution?
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.
@xeroc | May 31, 2017, 7:34 a.m. | Votes: 4 | [
VOTE ]
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.
@karnal | May 31, 2017, 8:09 a.m. | Votes: 3 | [
VOTE ]
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.
@karnal | May 31, 2017, 8:31 a.m. | Votes: 3 | [
VOTE ]
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.
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)?