Zkool: includes t-address (@hanh would you want to change this?)
Edge: includes t-address
(Help me fill this)
Step 2: Deprecate t-addresses in UAs
This is a bit tricky. We can’t really enforce this, but my idea is to get a ZIP simply saying that including t-addresses in UAs is deprecated and that wallets shouldn’t do that anymore. At least we have something “formal”.
Something that the ZIP could also specify, but even trickier and harder to enforce, is for wallets to stop accepting UAs including t-addresses (when sending ZEC) after some specified time (i.e. when the main wallets stop including them). Not sure about this though.
Regardless, I’ll try to start sketching the ZIP
Step 3: Create a new UA?
Even wallets stop adding t-addresses in UAs, users won’t have total certainty that the UA they have does not have a t-address (sure, they can always check using some tool, but I don’t think that’s a reasonable expectation). Thus we could create a new UA type, with a different prefix, that MUST NOT contain a t-address.
On one hand, I think that it will be extremely annoying to have Yet Another Address Type. On the other hand, maybe UA usage is still low enough to make this happen not very painfully. Not sure. What people think?
I absolutely support this change. It was intuitive what using a Z address and T address meant (in terms of privacy implications). That is no longer the case with Unified addresses and something we should remedy ASAP.
Ywallet already allows for custom receiver sets, though the default is full. Zkool also has full ua default but exposes all of the receivers as well. Providing the shielded-only ua as default makes sense but given the movement away from sapling anyways I’m not sure of the advantage of that over just exposing the orchard receiver. Yeah not sure about the reverse-enforcement and another addy type.
I think it’s worthwhile being able to combine Sapling and Orchard, so that we have two address types (transparent and new the “shielded UA”) instead of three (transparent, Sapling, Orchard). The “shielded UA” could even have some prefix starting with z to make it clearer.
It kind of remove a soft incentive to migrate to the latest pool. If you ask me some money and you give me the address of an old-ass pool, imma look at you different you know what I mean.
The only thing that I think is unfortunate is that removing transparent receiver capabilities from Revision 1 addresses is that it removes the possibility of having expiry metadata attached to a transparent address, but I guess that’s an okay tradeoff.
The most important thing will be for wallets to adapt, as you note. There’s a more general problem that deserves consideration, though:
Unified addresses are intentionally opaque; it’s not possible to distinguish what kinds of receivers they contain by casual inspection. As we’ve seen in recent discussion, this presents a pitfall for users, who may not fully understand the capabilities that they’re giving out. The problem is that a complex string encoding that is intended to provide collision resistance is not really the right way to display the capabilities of an address to the user who’s giving it out - this should be a problem of wallet UX, not the string encoding. Even if we did something like include metadata about the receiver types in the human-readable prefix of the string encoding, this would not be comprehensible and would be misunderstood by the vast majority of users.
In short, I don’t think that the address encoding is the right vehicle for conveying this information.
If you don’t include both Sapling and Orchard receivers when giving out an address, it removes a privacy capability, namely the capability for the sender’s wallet to avoid a pool-crossing transaction that reveals the transaction amount. If they only have Sapling funds and you give them an Orchard-only address, then the amount of the transaction is likely to be publicly revealed.
Can’t we block those types of risky transfers? As in wallets being a bit forceful to get users to upgrade to the latest pool and if they do not, then then cannot sent to the most recent pools?
Honestly it’s currently too complicated. I work in tech, I’m no expert but I grasp the basics. People not working in tech don’t stand a chance understanding those addresses details and I think it’s a problem.
There are already two z-addr formats that are mutually-exclusive: Sprout and Sapling. Users often did not notice the difference. The only reason this did not create more confusion than it did was because only wallets built around a zcashd full node supported Sprout, and zcashd also supported Sapling so we could hide the UX problem by being the only actual wallet implementation. But there were problems with users attempting to pay Sprout addresses from their Sapling-only mobile wallets and getting frustrated that the z-addr didn’t work.
Then you have the other set of users who don’t even notice the difference between t-addrs and z-addrs, and think that because it’s a Zcash address, it’s private. That’s a different problem to solve, but it is more evidence for the point that “z-addr” is not neat and clear.
I don’t think the human-readable prefix should encode all the metadata, but I think it should encode the basic fact of whether or not the address is or contains transparent addresses. We shouldn’t rely on wallet UX for users to be able to determine this.
We could even define a separate prefix to encode transparent addresses so we can add metadata to them, but personally I don’t think we should spend time adding capabilities to transparent addresses.
My whole point is that “contains a transparent receiver” isn’t a binary indicator of privacy, and shouldn’t be treated as such.
As with everything, the answer is “it’s complicated.”
We can’t block these transfers at the protocol level; the most that we could do there is something along the lines of “restrict pool-crossing transfers to power-of-ten amounts.” I’d be supportive of such a protocol change; this would encode into the protocol something that the sprout-to-sapling migration tool did internally.
The advantage to this is that cross-pool transfers would leak a lot less information. It would also basically force wallet developers to implement something equivalent to the sprout-to-sapling migration tool in each wallet. That in itself would be good, although it adds UX friction: a user who opens their wallet might not be immediately able to send a payment if they don’t have enough in their wallet to get to the next power of ten, so this would require wallets to perform automatic migration of funds. And that is complicated by the need to access the spending keys in order to perform migration; such a migration tool should create migration transactions in a way that doesn’t provide any ability to use timing to link the transactions for a wallet, and if (for mobile wallets) the spending keys are only available when the phone is unlocked, it means that the user may have to have multiple interactions with their phone at different times in order to get their funds moved over.
This is additionally complicated by hardware wallets. Automatic migrations / automatic shielding are impossible for funds stored on hardware wallets; they require a user interaction for each transaction (which completely prevents doing something like the Sprout-to-Sapling migration tool did inside zcashd).
Disagree here. “Crypto addresses” themselves are a primary UX of today.
A user should visually be able to quickly tell if a T-address is included in an address outside of wallet apps. On exchanges, in text messages, when pasting a donation address to their blog, etc.: it needs to be obvious to normies. IMO anything including something transparent should start with a “t”.
How many people who have just bought some ZEC on an exchange, and are using it with their multicoin wallet with transparent protocol support, even have any idea that they are getting no privacy protection?
A user has to actually go and learn the difference. Where is that going to happen? It’s most likely that the wallet UX is going to teach them. So the wallet UX should give them all of the information that they need to make those judgements. I have for ages wanted the confirmation screen for transactions to provide an explicit checklist of the privacy properties of the transaction, and that’s the whole reason we introduced the “transaction proposal” as an intermediary step in transaction construction, so that a wallet could display the privacy properties of the proposed transaction before it’s executed.
I would remove sapling and keep transparent and orchard. The idea is to get rid of Sapling (alongside sprout) and have a simple duality shielded (1 pool) transparent 1 pool.
(@hanh would you want to change this?)