Unified Addresses Composition

Community Collaborations protocol
41

In test. It should be out next week. Any users of the SDK will be able to gen UAs without taddrs.

6 Likes
42

Great news. Thanks for the update!

1 Like
43

I appreciate your feedback @emersonian, and we will strive to do better! Your PR came in while we were sprinting to make Zashi 2.0 deadline, and I should have prioritized reviewing it earlier. On the other hand, I’m happy that it resulted in an open discussion and removing the transparent receiver from the UA entirely.

7 Likes
44

Is there any action necessary on behalf of Zashi users?

45

All that will be necessary is to update your Zashi wallet. You’ll start getting shielded-only UAs by default, and a new UA will be presented every time you go to the “receive” screen.

Longer-term, we also intend to introduce address rotation for the Zashi transparent address; however, doing so involves some UX challenges that need to be solved. The problem with having a rotating transparent address is that if a wallet receives funds at multiple different transparent addresses, we don’t want the fact that those addresses belong to the same wallet to be revealed either when communicating with the light wallet server or when shielding those transparent funds. What this means is:

  • Only the funds from a single transparent address may be shielded in a single wallet action
  • When querying the light wallet server for transparent UTXOs, only a single address may be queried at a time.
  • Performing either of these actions should be done in a way that doesn’t permit linking via heuristic timing correlations.

It’s the last bit here that makes things difficult in a couple of different ways. The approach that we’re taking for ephemeral addresses is that we use a Poisson process to determine a random time that the wallet should check for funds held by each ephemeral address in the case of failed transactions or funds being returned to such an address. These checks will be scheduled to be run approximately once a day. For ephemeral addresses (which under normal circumstances should never hold funds) this is essentially fine; there can be a slight delay in recovery. But for regular transparent addresses, we don’t want users to potentially have to wait hours to receive and use their funds.

In order to fully solve the correlated-retrieval problem for regular transparent addresses, we’ll need to make a change to the light client protocol, such as is suggested in Add transparent data to the `CompactBlock` format. by nuttycom · Pull Request #1781 · zcash/librustzcash · GitHub. This will mean that light wallets no longer need to explicitly make UTXO requests to the light wallet server. But then, we also require funds to be shielded before they can be used, and this is where the real UX hassle comes in, because users might need to wait to shield funds in order to avoid revealing the relationship between addresses.

We’ve chosen to not start doing transparent address rotation yet because, in absence of a solution to these problems, it’s better for users to be aware that they’re linking their transparent address behavior (by making it obvious that they’re reusing the same address) than it would be for us to release a transparent address rotation feature in a way that could give users a false sense of security.

5 Likes
46

It was quick considering the interface redesign. Thank you!

2 Likes