I ordered one just so I can use it to store shielded Zcash on a hardware wallet. Having the ability to securely store shielded Zcash “at rest” is crucial for privacy in my opinion and you don’t want to store larger amounts on Zashi itself (because of the inherent security issues of mobile phones, not the software itself). And privacy is the biggest differentiator of Zcash, so that’s a very important feature to have.
Would it be great to have support for shielded addresses in more widely used hardware wallets like Trezor? Absolutely. But Keystone support is still a great step in the right direction in my opinion.
That doesn’t mean that having more than one t-Address isn’t crucial, it absolutely is. But it also needs to be designed right, especially in how you deal with a situation where you have multiple UTXOs on different t-Addresses that haven’t been shielded yet.
In an ideal world you would shield every incoming transaction to a t-Address immediately, but that would require Zashi to be active in the moment you receive the transaction. You cannot do push notifications to wake up the app in case of an incoming transaction, that would require to give the t-Addresses to a server and violate privacy.
However, once you have multiple unshielded UTXOs on different t-Addresses (on the same one it doesn’t matter) you have no easy way out anymore:
- If you shield them all together in one transaction you link the t-Addresses, which is obviously not good for privacy reasons.
- But if you shield them in separate transactions you now have a timing issue. Meaning, one could still correlate them if they are shielded at the same time or close together.
And how do you communicate all of these subtleties to a user without messing up the UX?
I would probably go with a UX design which goes like this:
- Always rotate the t-Address which is shown to the user (under receive) if the last one has been used. Give the user the ability to manually request a new one, even if the last one hasn’t been used yet (so he can give out different t-Addresses to different users). But limit the gap, to make discovery possible in case of a recovery from the seed phrase. That’s pretty much the standard design used in most Bitcoin wallet, so it’s what users would expect. Don’t break user expectation.
- If Zashi is active when a transaction is incoming automatically shield it, without any user intervention.
- If Zashi is opened and a single transaction was incoming also automatically shield it, without any user intervention.
- If Zashi is opened and multiple transactions were incoming randomly select one and shield it and set a random timer and commit it to the app state. Once that timer is up shield the next one and so on. Give the user the ability to shield faster, but warn them about the privacy implications.