The support of transparent addresses in Shielded Wallets has been less than perfect. One reason is that shielded addresses offer much better privacy than transparent addresses, so why bother with the latter?
Considering that 90 % of the funds are still in transparent addresses, a migration plan is crucial. Without it, the majority of the funds will likely remain in their current state.
That’s one of the reasons why I started a nearly complete redesign of the Ywallet engine. The new engine handles:
Multiple transparent addresses per account based on the seed phrase;
Automatic scanning of transactions
Autonomous Transparent Synchronization; Without this, users need to synchronize their shielded funds even if they only have transparent coins.
These features allow users to import a transparent wallet alongside fully shielded ones.
For example, here is a demo of what it entails.
Scenario: I have a wallet seed that has received/made transactions at several sub-addresses (using Ledger, for instance)
When I restore this account, the wallet automatically scans transparent addresses. It recognized that addresses 0-9 are in use. However, it did not find an address farther down because the gap was too large.
The user knows there should be more funds, so they manually rescan with a higher gap limit. The wallet finds these addresses and updates the balance and transaction history.
All this happens in under a minute because the synchronization status (shielded funds) is unaffected.
Graphene OS could publish an incoming viewing key if they want people to see their incoming transactions.
IMO, the Zcash account model is much too complex. Sure, Zcash engineers understand it well, but it requires a lot more explanations than it should. At the end of the day, most people I know stick to transparent addresses (and it defeats its purpose).
For instance, did you know that for the same seed, Zashi may give you a different address than Zingo/ZecWallet/Ywallet (with 50% odds)?
Try this seed phrase: “real sausage gather pumpkin toilet addict party garden hover village offer wasp abstract search aisle coil forward ticket dice ethics copper panther emerge zoo”
The zcash_keys crate is right there. It provides a correct and complete implementation of ZIP 316 address generation. Ywallet and Zingo should just use it, and then we would have uniformity across the ecosystem.
And ZIP 316 is designed the way it is so that it stays as close as possible to the BIP 32 account-based address derivation model as possible. When generating a ZIP 316 Unified address, the account ID and child key index both have to agree across all the shielded receiver components (with the child key index corresponding to the shielded diversifier index.
By requiring that all the diversifier and child key indexes agree, we can ensure that there isn’t any possibility of “cross-leakage” of receivers between addresses; if you generate two different addresses and give them to two different people, you don’t want those people to be able to identify that they came from the same person because one of the parts of the address was inadvertently shared. It’s an important security property for the ecosystem that address derivation work consistently as specified in ZIP 316.
The other important thing to discuss here is change addresses. If a wallet does not correctly separate change addresses from normal external recipient addresses, a third party holding an incoming viewing key for the wallet can detect when received notes are spent, violating a fundamental and important property that is desired from incoming viewing keys: namely, a party holding an IVK should not be able to determine anything about when received funds are spent. YWallet and Zingo also behave incorrectly here, although I believe that Zingo is in the process of fixing this.
These wallets were generated before unified addresses existed. I will not change the transparent address’s derivation path and invalidate funds because of ZIP 316.
PS: I knew the reason. It was a quizz for the non-experts.
Why would it invalidate funds to use the correct derivation path when generating unified addresses? The wallet still has control over the funds.
We face similar problems with respect to making it possible to restore from a zcashd embedded wallet seed in Zashi. The fact that it’s a hassle is irrelevant; we have to support spending those funds (or migrating them to a unified account) anyway.
By “invalidate,” I mean that an updated version of the wallet app would use a different derivation path and, therefore, a different transparent address. The funds would appear missing unless that wallet also monitors the previous address.
Even if it monitored the old address, the user could be confused about where his funds are.
Anyway, my original point was that this is too much to know for a user with more than one crypto in his portfolio.
Rotating addresses is a standard feature that lots of crypto wallet users are familiar with. IMO, one of the the things we need most in the Zcash ecosystem is for providers to use ZIP 316 compliant address parsers. If we can get that to happen, then there is one address type - unified addresses, one approach to address rotation, and things get much simpler for users.
