Any removal of anything where tokens are stored requires doing one thing first: setting expectations years ahead.
Not saying I’m for or against a specific removal (pool or transparent), I’m saying there’s a method to enact those types of changes and we have not built that first step yet.
Here’s how we represent addresses for receipt.
I really like your idea of explicitly reporting privacy properties in the send interface…
I don’t see what the alternative is? Just because “contains a transparent receiver” isn’t a binary indicator of privacy, that does not mean that users shouldn’t be able to easily tell if it contains a transparent receiver.
Let’s keep things simple. We can add a wall of text every time the user tries to copy their address to send to someone else, or we can just use a prefix to indicate the inclusion of a transparent address.
There will be always more nuance about transaction privacy but just because we don’t have a perfect solution to convey that it doesn’t mean we shouldn’t do the obvious thing that will greatly mitigate the risk that people are facing right now.
That’s unrelated to the issue at hand. It doesn’t matter if we add this checklist, the user can still copy their transparent-address-including UA and paste it everywhere else before they even try to send a transaction.
I’m not suggesting a wall of text. Imagine you see this on the screen where you can share your address:
Can receive Orchard funds
Can receive Sapling funds
No transparent capabilities
or:
Can receive Orchard funds
Can receive Sapling funds
Can receive transparent funds
Address expires on 2025-05-31
It doesn’t have to be complicated; it can be iconographic, where you can click into an icon to learn more. Wouldn’t that be better than requiring a user to understand the encoding prefix?
It’s mental friction for normies. No one should have to see this information unless they want to dig deeper. If we design the wallet right, this is superfluous.
I honestly don’t think that’s better. What is Sapling and Orchard? More importantly, how will the user know that “can receive transparent funds” might mean “I can dox myself if I post this publicly”?
vs
t = transparent =risky
z = shielded = safer
If my wife looks at her wallet, she will have zero clue as to what the address prefix means. She will not know to look at it in the first place.
The notion that “z” means “safe” to anyone but long-term Zcash insiders is just ludicrous.
What about using a vanity prefix?
I don’t really understand the question? No prefix is going to have as much detail as my strawman example of UI above.
Please leave those judgments to actual users. I don’t think historically devs have shown the best understanding of what users do or do not do.
If we say z-prefix is secure is keep it that way for 10+ years, z-prefix will become known the be the secure address. Certainly, wallets should also help and warn users that when they use a t-prefix, it is completely transparent. For me, as a user, it’s always been very clear that t-addrs are transparent and z-addrs are shielded, very simple, very nice.
Now that’s just my opinion above, but I’m not saying I’m right. I’m saying I’m curious what non-devs think.
That notion seems already widespread in the Zcash community:
Sure, for novice users it might not be obvious, but in the same way, a novice user will have no idea what Sapling, Orchard, or “can receive transparent funds” mean.
In addition, it’s much easier to teach a novice user that t is risky and z and safer than to teach the subtleties of different pools and whatnot.
Again this is trying to ditch a easy solution which addresses some part of the community in favor of a sketch of a solution that we have no idea if properly addresses a bigger part of the community (and even then there is nothing stopping us from doing both)
My initial idea for Step 3 of the plan is to change Revision 1 of ZIP 316 as follows:
umm. going from Z to U then back to ZU will be even more confusing for long time Zcashers imo.
I mean, it was actually “zs” before, and not just “z”. I figured most people didn’t pay attention to the second letter, but I might be wrong.
There is also no way around it I think, it can’t be “zs” so it must be z + some other letter.
I’m fine with zu being the HRP for Revision 1 addresses.
why are we again overcomplicating things actually tho?
seems like not sth the devs should focus on right now.
lets make sure all wallets use Orchard only UA by default in a soon enough timeframe and T or UA with transparent as second option if the user wants to recieve from exchanges or other places that need that transparent part.
that should be the easiest solution? no?
@pacu perhaps we can ask CEX’s, DEX’s, and folks with skin in the game what they prefer because what ever is done will need some serious “buy-in”?
It’s a simple change to the ZIP and the implementation.
We can do both at once. Yes, the priority is to make sure the wallets stop including transparent in UAs, but we can get the next step rolling. Certainly it does not need to happen right now and we can work on it in the background.
I understand the frustration but I’m one of the biggest haters of overcomplicating things and I don’t think this particular thing is overcomplicating things 
But certainly it’s important to keep in mind that these are two different tasks with different priorities.
ive seen the simple changes that were supposed to take weeks take months - so im not super optimistic 
unfortunately since no one is actually supporting UAs there’s not much impact so there’s some positive aspect of that because they don’t actually have any skin on the UA game yet. If they had, changing any of this would have been much more troublesome than it is.
