Unified Addresses Composition

I realized today that there’s an additional problem with transparent address rotation that hasn’t previously been discussed publicly, and so I just want to note it here for posterity.

If a wallet performs standard BIP 44 address derivation of successive transparent addresses (on any chain), users should not believe that activity on these addresses is guaranteed to remain unlinked from one another forever. Here’s the flaw:

Suppose that one wallet does everything right (they avoid linking those addresses together via observable wallet behavior in querying light wallet servers and/or block explorers, they never spend funds from multiple addresses together in a single transaction, and they avoid on-chain temporal linkability.) Even in this case, there’s a risk that the user may some day import their seed phrase into a wallet that does not take the same care to avoid linkability. Suppose that as part of that wallet’s “restore” procedure, it queries a block explorer with all of the transparent addresses within the transparent gap limit, to search for funds. At this point, these addresses are all linked to one another by the adversary that is running the block explorer.

This is the current behavior for essentially all transparent-only Zcash wallets, and I believe is also a problem for Zcash wallets that provide shielded functionality but also offer transparent address rotation.

Basically, do not be deceived by the idea that transparent address rotation can solve a privacy problem for you, except in very constrained use cases. On-chain address linkability should not be the only threat in your threat model, and you should be concerned about linkability leaks when using any wallet that offers it.

5 Likes