Unified Addresses Composition

Community Collaborations protocol
1

Greetings to all developers!

Before I bring up one of the most important UX issues in our wallets in my opinion, a bit of background:

About a month ago I found this call from @nuttycom to write a small TypeScript parser library that could be embedded in various services, for example Gemini exchange could use this for their customers to specify their UA address and the parser would automatically extract the Sapling address from there, since due to technical limitations they can only support this type of address.

I tried to find a freelance developer on the TypeScript forum who could do this, but two people told me that they don’t know enough about Zcash to do it. So I started looking at the source code and realized that the best way to do this is with the Rust library for Zcash addresses. Fortunately, I have an understanding of how things work because I working in Python for my business tasks. But I didn’t know Rust or TypeScript and decided to just get started on my own, using neural network, and then ask for help from those who are fluent in the topic to fix both parts if needed. I’m grateful to Kris and @1337bytes for refactoring my attempt and now we have a second version of reliable and well optimized code with strict parameters (zaddr_wasm_parser on npmjs). Anyone can check how it works in practice because there is a test html file in the repository to decompose UA into components.

Now I’ll get to the proposal part. While testing, I found that all popular wallets for Zcash offer by default to use a UA address that contains an Orchard (also formalized UA-format), a Sapling (Z-address) and a transparent T-address.

And potentially with this transparent part there is the problem of revealing information that the user would not want to share. And it seems that none of the UX wallets report this. (I could be wrong about all the wallets and apologize in advance if I did.)

In practice, this T-address from UA is completely unused anywhere today, but it can be extracted with this or other open source parser. And if a user interacted with the exchange with their transparent address, and then shared the UA with an unlimited number of people by tweeting it or posting it on this forum (which happens quite often), then they are potentially revealing all their activity with the exchange: deposits and withdrawals. I was honestly surprised by this finding. And I think that wallet users should be warned about such things in advance, in the application interface.

I suggest @pacu to discuss this part at the next Arborist Call and formulate ways to solve this issue. Either remove the transparent address from UA, which is used by default, since it is completely unused anywhere at the moment. Or think about appropriate warnings on the page with that address.

And by the way, anyone may use the test html to take the clear Orchard to share it without risk of revealing unnecessary information.

Thank you for your attention!

FYI @joshs @peacemonger @hanh @zancas

13 Likes
2

Thanks @artkor. Also it’s good remind everyone that removing T addresses alone doesn’t solve all issues either since a static UA can be used to link different aliases/accounts to a single address :scream:. For more information on ways to protect yourself @hanh has some good documentation on diversified addresses in YWallet which don’t contain a T address :blush:.

4 Likes
3

Thanks for grabbing these items falling through everyone’s busy hands! :raising_hands::folded_hands:

I’ll check this out. Let’s get together next week to fit it somewhere in my backlog. :flexed_biceps:

2 Likes
4

Agreed, thanks for raising this @artkor! :folded_hands:t4: Speaking for Zashi, we are planning to address this by NOT generating UAs with transparent receivers anymore once we will be implementing address rotation. We will completely separate shielded and transparent addresses. We have set other priorities for Q2 but if we have any spare time, we will work on this as a priority (so far it is slotted on our roadmap with other functional tech debt items for Q3).

4 Likes
5

To add a little color to what @andrea said here, when we designed Unified Addresses, we had a couple of different goals in mind. We needed an encoding for Orchard addresses, and we wanted to make it easy for wallets to implement an “upgrade path” where, upon creation of a new shielded pool, funds naturally begin to migrate into that pool. On that account, I think that Unified Addresses have been a resounding success.

The other major goal that we had for Unified Addresses was to make things easier for users in the Zcash ecosystem by making it so that they would only have to deal with one address type. That goal hinged upon Unified Address parsing being integrated into exchanges and wallets that only interact with the transparent pool, and on that front, I have to say that Unified Addresses failed. None of the transparent-only partners, even those who are relatively engaged, have implemented Unified Address parsing that I’m aware of. So, having learned from that failure, the plans for Zashi are this:

We’re planning to take a bit of a page from the EZcash book, such that the Unified Address displayed by Zashi whenever the user opens the “Receive” pane will be a freshly generated diversified address without a transparent receiver, that uses a time-based mechanism for choosing a diversifier index. The diversifier indices chosen for these addresses will be outside the range of BIP 44 “child” address indices, and as such it won’t even be possible for these UAs to contain transparent receivers. Zashi will display a separate transparent address that can be manually rotated, in keeping with how this is done for transparent wallets, using the recently added “gap limit” indexing approach to ensure that funds received at these transparent addresses remain recoverable after restoring from seed.

This approach to address rotation is now the default that is implemented in zcash_client_backend and zcash_client_sqlite. If you request a fresh UA with a transparent receiver, it chooses a transparent child index sequentially within the “gap limit.” If you request a fresh UA with only shielded receivers, the diversifier index is chosen by taking the current time and adding an offset that ensures that no transparent address may be derived at that index.

5 Likes
6

I wonder if we should update the UA spec to only allow shielded components, and use the regular “t” encoding for transparent addresses. This way it will be always clear if an address is transparent or not.

How much breakage would we get if we did that?

6 Likes
7

Can the HRP of the encoding of the add a t when it has one ?

ur1t….

u nified
r evision 1
t includes transparent

1 Like
8

The hrp cannot include 1

1 Like
9

Zingo offers an Orchard-Only UA as a receiving address, by default.

3 Likes
10

Thanks for the excellent explanation. :smiling_face_with_sunglasses:

This is obviously nothing new, I learned about it over two years ago when the NH team supported NU5 in the block explorer, if I remember correctly thanks to a question from @palmar in a @yoditar talk about using the Zcash Block Explorer.

Since then I have been using unified addresses that only contain shielded receivers so as not to expose the T address that is contained in the full unified address. Another practice I do is to send to a single-use account and from there make the transaction public.

The last mentioned is very advanced for a basic user just as it is complicated for them to understand the unified addresses that were implemented to make their life easier and nowadays are often more complicated for them even if we don’t believe it.

That’s why I was in favor of the changes made by Hanh in YWallet where he implemented being able to set the main address from the wallet settings, or what I suggested a long time ago in ZingoLabs where a unified address only Orchard is what is used as the default address.

It may have its nuances in terms of use cases and possible problems, but there is a very big reality and that is that where partners did NOT implement unified addresses and today what was created to facilitate the use of addresses in Zcash, now coexists with T, Z, (diversified) and TEX addresses.

Yes, quite a tangle not only for the basic user, even the more advanced ones I’ve seen have problems, and all this without mentioning to them that with unified addresses you can make several combinations between pools and you end up having more addresses in a wallet than in a delivery office. :grinning_face_with_smiling_eyes:

3 Likes
11

I realize and guessed that, but I don’t know at exactly what point the practice of disclosing a transparent address changed.

1 Like
12

Great!

It’s good that more users are finding out what’s going on or that more developers are implementing improvements in the different projects. :+1:

1 Like
13

Yes. By scanning several unified addresses, I was able to see the transparent addresses of some users. Since then, I’ve only shared my Orchard address directly and haven’t had any issues. My T address isn’t known to anyone.

1 Like
14

Not “if” but “when”.

If we can quickly and objectively agree that t-address components in UAs are not a net benefit today, and will be even more problematic as Zcash scales, it seems like you’re right to suggest removing them from the spec now.

  1. Are t-address components in UAs a net benefit to Zcash users today? No. They add far more unnecessary complexity than real user benefit.
  2. Are t-address components in UAs likely to net benefit Zcash users in the near future? Leaning strongly toward unlikely. There’s no clear upcoming use case that justifies the extra risk and confusion.
  3. Will t-address components in UAs be a net benefit when Zcash exceeds 1M users? Absolutely not. Mixing transparent addresses into UAs at scale would be a serious mistake. It undermines privacy expectations, creates UX pitfalls, and damages the clarity and strength of Zcash’s shielded narrative.
5 Likes
15

Let’s do it. I can sketch a ZIP maybe next week but it would be great if someone else kicked that off.

2 Likes
16

This would need to be a Revision 2 UA type. I would recommend that it extend from Revision 1; it will need to choose a new HRP.

1 Like
17

I hope one day we can ONLY use one address: Orchard. Meanwhile, do we really need to use UAs? I don’t understand the technical details, but if we can only use an Orchard, Sapling and Transparent address, without UAs, to interoperate with each other, It would be better. In other words, can we remove UA from Zcash and the wallets?

1 Like
18

Orchard-only addresses are UAs. There is no separate encoding defined for Orchard.

Also UAs offer important features (like address expiration metadata) that aren’t widely used yet but we would like to see propagate through the ecosystem.

3 Likes
19

Good to know! Thanks for clarifying this, nuttycom :+1:

20

Well imagine that after being done with Z3 development our team starts working on post quantum implementation, and they find out that they have to use a new shielded pool for 100% quantum resistance shielded ZEC. Then UAs will support it effortlessly provided that wallets abide by ZIPs 315 and 316.

That’s how the UA pattern was supposed to work

2 Likes