A major reason for the choices we’ve made thus far are because we consider the operator of any light wallet server as an adversary, and we don’t want to give people a false sense of security; a compromise of the light wallet server that allows an adversary to link addresses that an individual using Zashi believes is private is worse; with a non-rotating transparent address, the user knows that they’re linking their spends and receipts.
I also want to point out the follow-up post: Unified Addresses Composition - #47 by nuttycom
The problem with transparent addresses isn’t merely that there’s a risk of linkability any time the wallet is interacting with the light wallet server (you’ll note that I’ve been pushing hard to mitigate some of these risks via https://github.com/zcash/lightwallet-protocol/pull/1, which was just merged this week, and my work supporting and reviewing https://github.com/zcash/lightwalletd/pull/534 which adopts those protocol changes.) The problem is also that, if at any time in the future, someone uses a Zcash seed in a wallet that doesn’t correctly handle transparent address fund discovery, then privacy is lost.
All this is to say that while address rotation superficially looks like an easy win, it’s a trap that we’re trying very hard to defang. If there were an obvious solution that was guaranteed to preserve a user’s privacy then we would have done it already; transparent address rotation and gap limit exploration have been finished in the wallet backend for many months now. But it’s exactly our concern for users’ privacy that have caused us to explore these questions, and the fact that there aren’t fully airtight solutions are the whole reason we haven’t integrated transparent address rotation into Zashi yet.
Once you leak a bit of information, you can never take that leak back. None of this is as easy as we try to make it look.
I understand the privacy concerns with respect to the light wallet servers but at least metadata you leak to them is not going on the blockchain, ready to be inspected by anyone at any point in the future they’d like. I’d much rather expose myself to an adversary running the light wallet server than put it on the blockchain.
I appreciate your detailed reply and I agree on some of the nuance you are pointing out but I still think not pushing the rotating transparent addresses to the userbase due to these concerns constitutes analysis paralysis and it is the worse of both worlds.
As it stands, it is impossible to receive something on your wallet, shield it and then spend it via CrossPay or whatever because people only support depositing to transparent addresses generally and then the wallet goes and exposes itself by sending the change to the transparent address even if your transaction to NEAR was done using a shielded address, it will leave breadcrumbs pointing to your transparent address.
As I said before, as much as I want to like and get onboard with ZCash, it simply openly falls short of its privacy promises at this current state. Therefore it is just a temporary investment vehicle for me that I am more than eager to sell once it stops gaining value against Bitcoin.
I’d love to like ZCash and evangelize it but at this state anyone I would talk to would call me out on this obvious privacy failure.
ZCash after all these years continues to not be ready for prime-time, unfortunately.
I dunno, man. I can’t see how you can look at as complex a tradeoff as this one, and conclude that all the thinking and work we’ve done on it is somehow ignoring the problem, or makes Zcash “not ready for prime-time”.
Your engineering choices might be different. Your threat modeling might be different. Other wallets make different choices; YWallet gives you the ability to rotate transparent addresses and expose yourself to those risks. Why not use a wallet that’s closer to your ideal?
In that other thread I was talking to the YWallet developer, he never mentioned it being supported. If anything he talked about how challenging it is to support it and that’s why they haven’t. As far as I could tell from using it, that didn’t seem to be the case.
Your argument is that if we allow users to rotate transparent addresses, they may be associated to you by a malicious light wallet server provider. Which is a valid argument on its own but to act like that caveat is a good reason to not provide the ability to rotate transparent addresses seems like taking it a little too far.
So because light wallet providers may associate these transparent addresses anyway, we are just forcing everything through the same t-address and putting the association into the blockchain?
Would it be an acceptable tradeoff if Bitcoin wallets still reused the same address for all deposits and change because light wallet providers can associate these addresses and lookups anyway? Or if they didn’t allow selecting the utxos you want to spend yourself? Because you know, you are asking the light wallet provider for the balance of an address anyway.
What? No, we don’t ask the light wallet provider for the balance of an address.
And yes, I think that Bitcoin’s attempt at obfuscation is utterly meaningless. It’s security theatre, it’s worse than useless in that it misleads people into a false sense of security.
The important thing is that this not happen silently, and this is why we’ve been doing all the work on ephemeral addresses for swaps. But for the non-ephemeral transparent addresses provided by the wallet, we don’t want to give users a false sense of security.
We’re also attempting to balance this against UX concerns. That’s why the changes to lightwalletd are in the works, to try to get the UX good enough that we can actually rotate transparent addresses. There will still be some UX downsides, though - for example, if you exhaust the gap limit, you’re forced to make a transaction to refresh it, and if you have to randomize the timing of shielding operations it also gets annoying.
Interesting, he indeed does say that but recently in this thread [0] he talks about how it is challenging when asked why Ywallet doesn’t have it. I’ll have to check further with him.
[0] can’t link, user too new – /t/unified-addresses-composition/51024/52
What? No, we don’t ask the light wallet provider for the balance of an address.
In Bitcoin-world that’s basically what they do. Ask for the utxos of a certain address. I assumed that’s from where the concerns with a malicious light wallet server stemmed. If not from that, what do they stem from then?
Whenever this topic comes up it seems the conversation keeps going in circles. Some say it is scheduled and in backlog, coming soon. Some say it is already there, some say it has implementation challenges. Some say it is easy but we aren’t doing it due to some other privacy consideration etc.
On the UX note, I do agree. It presents some certain UX challanges but it could be made opt-in. An advanced mode like that is sorely needed.
Send max minus fees to spend a utxo fully is not present in Zashi and other prominent wallets as far as I can tell. No way to select which utxos to spend. If all of those pieces were in place, certainly it would fit into a natural UX flow.
You’re also entirely right that gaps in addresses are potentially problematic but even Electrum UI is doing a great job these days expressing these in a non-confusing manner. And doing sequential HD wallet scan is pretty standard practice these days with any chain that has HD wallets.
An opt-in mode to enable utxo selection along with transparent address rotation would make both sides of this debate satisfied.
I see the YWallet’s support for send max minus fees, which is nice and I also see the Key Tool now. It allows creating more transparent addresses but as new accounts under account manager. It does not account for change from certain unshielding transactions.
Ah, okay, yes, that’s different from asking for a balance, and that is indeed where the concern for linkability comes from (and what we’re aiming to fix with https://github.com/zcash/lightwalletd/pull/534 and the attendant functionality).
@nuttycom have you ever read any of the social media promoting zcash and zashi that is being constantly posted by the zcash foundation, josh s, the electric coin company, etc. (frankly there are so many entities that i have no real sense of who is who and what is what)?
I’ve posted some egregious examples in other threads and I’m not going to re-post them here, but these entities are definitely making all kinds of privacy claims for zcash and zashi with zero disclosure of the current gaping privacy hole that re-using a fixed taddr over and over definitely is.
People who do not understand what a taddr is who are using zashi right now because they read that it’s the most private way to do crypto are leaking more than a bit of information. I understand the plumbing well enough to work around this issue by creating my own ephemeral t-addresses via ephemeral installs (and subsequent uninstalls) of zashi on a burner phone. I’d wager that a meaningful proportion, maybe most, zashi users do not.
I don’t disagree with any of your valid concerns and they should be solved and the solutions implemented, but like @rotateaddr I think you are emphasizing the lesser risk in your arguments here. The false sense of security has already been created by the ZEC marketing machine. People are out there leaking more than a bit of information and simple t-address rotation with one-time use, ephemeral addresses would do far more good in minimizing that currentbad leaking than it would bad in creating an additional false sense of security.
The people who you are worried about gaining a false sense of security from rotating t-addresses have a sophisticated enough understanding of what they are doing to be able to read and grasp your disclosure / warning. The people who are right now leaking a lot of linkage on the public blockchain forever are already suffering from a false sense of security and the results of that are already being cemented into the public blockchain forever in every single block that is mined.
that gets me the ephemeral address but the rest of the work-around involves the burner zashi install auto-shielding the ZEC in the t-addr and then being able to send the now-shielded ZEC privately to my “permanent” zashi wallet’s shielded address.
Even though Zashi wallet displays a single fixed t-address (at the moment), the wallet can actually receive to any t-address generated by the seed phrase. Test with a small amount. To confirm the wallets are the same, Zashi’s t-address might be index 2 in Coleman’s tool. Let us know what you see
That’s a useful and valid workaround but all the more reason for the Zashi UI to just allow seeing any later index. Seems like all the plumbing is in place for it if it is able to receive it.
Yup, that’s exactly the workaround I have been using at this point and it is so frustrating. If Zcash marketing wasn’t making claims the kinds they are making, it would maybe be more acceptable but as it stands the path of least resistance is extremely not private.
Can you explain what you mean here? I was under the impression that the static t-address was always being shared with the swap provider as the refund address?
