Why does Zashi only allow 1 Transparent address?

Zcash Apps Zashi
1

With all the cool stuff that’s being added to Zashi, I’m kind of blown away that we still can’t generate new T-addresses. Often times receiving to a T-address is unavoidable, why are we forced to reuse the same T-address over and over again in Zashi?

I really appreciate all that amazing work that’s been going into Zashi, but this has me dumbfounded. It seems so fundamental.

2 Likes
2

They announced that this will be fixed soon. Related: Why does zashi re-use the same receiving t-address? - #21 by pjv

2 Likes
3

Did you link to the correct post? I don’t see any developer mention that.

1 Like
4

It was a bit further up in that linked topic here:

A couple posts down from that one he indicated Q2 as the timeline for it. About 9 days left in Q2 and while all kinds of new, hyper-niche, featurific additions have landed in zashi in the mean time, this most basic, most fundamental to actual, usable, pragmatic privacy, this simple piece of elemental basic crypto-currency plumbing that has tons of examples of open source prior art in over a decade of development of bitcoin and other crypto wallets all over the place, has inexplicably not managed to arrive in zashi. It’s honestly unbelievable.

4 Likes
5

What did we add that is “hyper niche?”

For taddr rotation, we need to solve a security issue that involves core, and core has been focused on 6.1 and Zallet.

If user receives funds to multiple taddrs and then shields them all at the same time, it reveals information to potential attackers. They will have some ability to determine that they are from the same wallet. For example, if the attacker sends funds to a taddr, they can then monitor when those funds are shielded and gain information from the other balances that were shielded simultaneously. There is some discussion about leakage minimization by spreading the shielding out over time, which could be a usability issue as the user cannot send funds from a taddr in Zashi.

3 Likes
6

How many people on planet earth own a keystone device?

7

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.
4 Likes
8

So, at least one then.

Not criticizing supporting hardware wallets. I’m criticizing the development priorities and choices.

9

My point was that both are very important features and should be pursued in parallel, which seems to me what is happening.

10

The Zashi + Keystone integration significantly boosted ZEC in the shielded pool. Calling Keystone integration a misguided dev priority is ironic. ZCG funded Ledger and Trezor integrations for shielded addresses years ago, but those failed due to Ledger and Trezor’s priorities. Know the history before criticizing those driving Zcash’s future.

2 Likes