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.