Importantly, it does work! The growth in the Orchard pool is, IMO, a demonstration of the success of UAs.
3 Likes
Yes!
I meant from day one. Evidence shows that when the tooling caught up they started serving their purpose
I want to point out another rationale that was present here: if a given exchange currently only supports transparent payments, and they added support for parsing unified addresses, then the ability to have UAs containing both transparent and shielded receivers meant that the exchange would start to observe just how many of their users would transact with shielded if they could. That would then become an internal metric by which engineers at the exchange could justify the cost of adding shielded support.
Put another way, part of the intent of allowing UAs to contain transparent receivers (while requiring shielded receivers) was to increase privacy overall, by encouraging users to give out UAs anywhere they would normally have given out a t-addr. Senders who supported shielded (or added support for it later) would automatically start using shielded instead of transparent, and senders who only support transparent would have an incentive to do so.
As @nuttycom observes, this clearly failed, because the transparent-only senders never added UA parsing. (I put some of the blame here on the sandblasting attack, which DoSed us Zcash ecosystem engineers and prevented us from having the time to do Orchard wallet deployment and outreach work post-NU5 such as ensuring UA promulgation).
1 Like
Iām not sure itās time to use the past tense on this one! Gemini recently expressed interest in adding UA parsing, and there are the new DEXes coming online like NEAR and Maya that will come with new user interfaces.
If more services do start supporting Zcash and parsing UAs, and if wallets continue to generate UA that contain t-receivers, then more and more users will have a user experience of things ājust workingā, with no error messages and no need to take extra steps.
In my humble opinion, that would accelerate shielded address adoption world-wide.
3 Likes
The regular t encoding for transparent addresses does not allow for additional metadata like address expiry. This was the rationale for removing the requirement that a UA contain a shielded receiver in Revision 1 UAs (which are allowed to be fully transparent):
as of Revision 1 there are uses for transparent-only UAs and UVKs that are not covered by the existing formats. In particular, they can use Metadata Items to represent expiration heights/dates as described in Address Expiration Metadata, or source restrictions as proposed in ZIP 320.
(The source restriction approach would have been instead of TEX addresses, but ended up not happening because Binance refused to depend on any additional libraries for address parsing. That in itself is proof that they never would have added UA parsing, even if weād had time to engage with them about it in 2022 after NU5 activation.)
In any case, I feel justified in having pushed for UAs to start with a u instead of a z. The argument at the time was that there was a bunch of existing user mindshare and docs that said āif the address starts with a z, itās a z-address and privateā, which does not hold for UAs because they can contain transparent receivers. Having UAs start with a u instead was a signal to the user that these were not necessarily fully private.
If we decide to have a UA revision that rejects any transparent receivers, then we might be able to consider having it start with z. However, the ability for UAs to contain not just data (payment receivers) but metadata (e.g. address expiry) means that there are potentially other ways for UAs to be generated that make them linkable (e.g. selecting an expiry height based on the expected lifetime of the underlying key material and using that same height in all addresses), so whoever is writing the Revision 2 update need to take considerable care here.
3 Likes
This is not āproofā.. itās impossible to say what would happen in a counterfactual universe.
If Zcash had increased in market cap by a factor of 100 in some other universe where most other things were held constantā¦ then would Binance have added UA parsing?
How about 1_000, how about 10_000 ?
I believe that thereās a persistent tendency to assert that historical narratives are scientific. They arenāt.
It behooves us, on this forum, to express our beliefs more carefully.
Which is not to say that I disagree with āpushing for UAs to start with a u instead of a zā.. only that I believe itās critical to refrain from āscientismā in our thinking.
I think this would align with the āpop cultureā understanding of the addresses, that ātā addresses are not private and the ānon-tā addresses are private.
Thinking from the Zenith UX perspective, we can make the change so our UAs never have a transparent receiver, so if the user needs to share a transparent address for an exchange, that receiver would never be exposed as part of a UA.
1 Like
Yep, just making sure wallets donāt generate transparent-including UAs would be a good first step
6 Likes
3 Likes
Nice! A github link to the code would be awesome!
2 Likes
Case in point. https://x.com/palantiri21/status/1921998512406872390
We need to keep transparent addresses separate from shielded receivers. Itās imperative and something we will change in Zashi immediately.
5 Likes
Sigh. Was it necessary to wait in the first place? One could say itās obvious in retrospect, but really, it must have always been obvious to those knowing unified addressed contained t-addrs.
Sadly I didnāt and Iām just crossing fingers that I didnāt dox myself in the past. Hope is not what Iām in Zcash for though.
1 Like
Josh, I donāt want to make a comment, I love your team, just definite high priority this issue, please.
2 Likes
I know that our dev teams are overloaded but itās also quite discouraging how long suggestions like this can sit around on GitHub without getting a response.
The forum feels like the only place to truly get attention, but here it can quickly become ātoo many cooks in the kitchenā.
Regardless itās good to hear that change is coming for UAs in Zashi.
3 Likes
It is an important issue and timely as well
Maybe we should discuss vote labeling on the forum here for increased visibility?
Instead of āMaximum Privacyā three options have been mentioned as more suitable replacements for UA that leak t addresses.
- Shielded Privacy
- No privacy
- Partial privacy
Personally my vote is for Partial Privacy with a link to this thread so users better understand the privacy risks inherent UA composition currently.
What makes you think āPartial Privacyā wont get merged? It seems more descriptive and accurate than the other 2 options. It is important for Zcash users to be made aware of privacy limitations of UAa before they use them
1 Like
āPartial privacyā is going to create unnecessary confusion and nobody is going to click and read a forum post. Theyāll install Monero and move on.
Already having a no-privacy option is a lot to burden users with, so letās not add more non-sense.
1 Like
Josh said that theyāre removing it so I donāt see a need to discuss here.
I put in the code change request because it was a five minute fix to change the phrasing rather than the deeper UA code, and to prompt discussion for a more long term fix, which Iām glad that we all had in various channels.
1 Like
2 Likes
Said they are going to isnāt the same thing as have already done. This should be a top priority fix. When will it happen?
Every day that passes with the status quo more potential Zcash users may have their privacy unintentionally harmed.
I think your 5 minute fix is an improvement and merging the pull request would demonstrate demonstrates good faith while we await the permanent fix