With all the cool stuff that’s being added to Zashi, I’m kind of blown away that we still can’t generate new T-addresses. Often times receiving to a T-address is unavoidable, why are we forced to reuse the same T-address over and over again in Zashi?
I really appreciate all that amazing work that’s been going into Zashi, but this has me dumbfounded. It seems so fundamental.
They announced that this will be fixed soon. Related: Why does zashi re-use the same receiving t-address? - #21 by pjv
Did you link to the correct post? I don’t see any developer mention that.
It was a bit further up in that linked topic here:
A couple posts down from that one he indicated Q2 as the timeline for it. About 9 days left in Q2 and while all kinds of new, hyper-niche, featurific additions have landed in zashi in the mean time, this most basic, most fundamental to actual, usable, pragmatic privacy, this simple piece of elemental basic crypto-currency plumbing that has tons of examples of open source prior art in over a decade of development of bitcoin and other crypto wallets all over the place, has inexplicably not managed to arrive in zashi. It’s honestly unbelievable.
What did we add that is “hyper niche?”
For taddr rotation, we need to solve a security issue that involves core, and core has been focused on 6.1 and Zallet.
If user receives funds to multiple taddrs and then shields them all at the same time, it reveals information to potential attackers. They will have some ability to determine that they are from the same wallet. For example, if the attacker sends funds to a taddr, they can then monitor when those funds are shielded and gain information from the other balances that were shielded simultaneously. There is some discussion about leakage minimization by spreading the shielding out over time, which could be a usability issue as the user cannot send funds from a taddr in Zashi.
How many people on planet earth own a keystone device?
I ordered one just so I can use it to store shielded Zcash on a hardware wallet. Having the ability to securely store shielded Zcash “at rest” is crucial for privacy in my opinion and you don’t want to store larger amounts on Zashi itself (because of the inherent security issues of mobile phones, not the software itself). And privacy is the biggest differentiator of Zcash, so that’s a very important feature to have.
Would it be great to have support for shielded addresses in more widely used hardware wallets like Trezor? Absolutely. But Keystone support is still a great step in the right direction in my opinion.
That doesn’t mean that having more than one t-Address isn’t crucial, it absolutely is. But it also needs to be designed right, especially in how you deal with a situation where you have multiple UTXOs on different t-Addresses that haven’t been shielded yet.
In an ideal world you would shield every incoming transaction to a t-Address immediately, but that would require Zashi to be active in the moment you receive the transaction. You cannot do push notifications to wake up the app in case of an incoming transaction, that would require to give the t-Addresses to a server and violate privacy.
However, once you have multiple unshielded UTXOs on different t-Addresses (on the same one it doesn’t matter) you have no easy way out anymore:
And how do you communicate all of these subtleties to a user without messing up the UX?
I would probably go with a UX design which goes like this:
So, at least one then.
Not criticizing supporting hardware wallets. I’m criticizing the development priorities and choices.
My point was that both are very important features and should be pursued in parallel, which seems to me what is happening.
The Zashi + Keystone integration significantly boosted ZEC in the shielded pool. Calling Keystone integration a misguided dev priority is ironic. ZCG funded Ledger and Trezor integrations for shielded addresses years ago, but those failed due to Ledger and Trezor’s priorities. Know the history before criticizing those driving Zcash’s future.
A privacy coin that forces to funnel you through a single transparent address. Is this a privacy failure that was left in on purpose? I am beginning to think so. Nobody fails to address such a blatant gaping hole.
It is not rocket science to figure out how to do that. Auto-shielding that takes each utxo and shields them individually. Why act like this is a blocker? Here, we figured it out.
Let’s say I have 5 Bitcoin utxos that I want to move to shielded ZCash. As it stands, as far as I understand this requires me to:
How crazy is that?
And as far as I understand the only way privacy could be preserved while using ZCash is to create a temp wallet for every transaction and then sweep back to a main one that you only use shielded txns with. Quite a hazard.
On the surface that does seem plausible, but you are also asking Zashi to choose the increments to break up into. Depending on how it’s done that could also be a privacy leak.
Say you have 5 ZEC or 0.005 ZEC , it’s supposed to automatically choose a % of that to break into separate UTXO transactions correct?
if it’s a fixed % an attacker could search the Blockchain for clusters of transactions of the same amount, 1, 1, 1, 1, 1 and the timing of those transactions, every 15 mins or whatever, and then correlate those TX to the same wallet.
I’m not saying it’s an insurmountable problem but it’s not quite as simple to solve as it may seem on the surface. That’s why I’m glad Zcash has brilliant Devs on our team that understand these things and can come up with ways to mitigate the risks.
No breaking down needed, just shield each UTXO individually.
Example:
utxo0: 5 ZEC
utxo1: 6 ZEC
utxo2: 1 ZEC
In a sane world, we would have each of these at a different t-address, they’d all have individual routes they followed being brought in from wherever. They are associated or not, it is not your problem. The user knows if they are associated.
After that you shield each utxo individually. They are for different t-addresses. Randomize the timing or let the user decide when to shield each.
They get shielded, go into shielded pool. Life is good. Percentages and all the other things that made you experience analysis paralysis will be irrelevant.
You’re talking about timings and amounts as if they matter. The users know how to deal with these, they are used to it. You not giving people the ability to have rotating t-addresses is not helping. It is making things worse.
For clarification, I’m not part of the Zashi team so my comments have no bearing on what they do or don’t add to it.
Best to refer to @joshs post above regarding the upcoming release.
For sure, not you specifically but wallet developers. I hope @joshs takes a look sooner than later. ZCash has potential and let’s get this resolved once and for all. It is already late but better late than never. Let’s stop backlogging this.
also, does anyone know how can i get a static shielded address that does not rotate ?