That would require a “MUST-understand” Metadata Item, and so it would only work if we’d specified those from the start. As it is, it doesn’t work because existing UA Consumers won’t enforce MUST-understand Metadata Items.
[Edit: this is no longer true of the current ZIP 320 proposal proposal that relies on Revision 1 UAs. Those specify the MUST-understand requirement in such a way that existing Consumers won’t recognize the UA. So the current proposal uses exactly this idea.]
What do you mean by Existing UA consumers and why would they not apply them? 
Yes, but you want to introduce req- metadata as part of the address expiration feature, don’t you?
Update: We have received confirmation from Binance that we have successfully passed their compliance review and can proceed with implementing the new address type. Binance did not indicate a preference between the TEX Address and Traceable Unified Address options, so I’ve reached out to inquire about their position. If they do not express a preference, we will need to quickly decide which implementation approach to take.
I am going to schedule a meeting for early next week with Hanh, Kris, Daira, and Pacu to discuss implementation details and create a project plan. We also need to determine the most effective methods for coordinating with wallet developers, exchanges, and other relevant parties to ensure a smooth integration process. Following the meeting, I will update the community with our planned course of action.
When ZIP 316 was first specified, we made a mistake and essentially made all receiver types optional, which means that current wallets implementing ZIP 316 can ignore metadata items. The proposed change to ZIP 316 in ZIP 316: MUST-understand Metadata Items and Address Expiration Metadata by nuttycom · Pull Request #759 · zcash/zips · GitHub would fix that going forward, but existing wallets would ignore a flag that says “you must send only from transparent sources”. So, instead of doing that, we would have a new receiver type, and Traceable UAs would contain only a single receiver of that type. Existing wallets would then have nothing that they know how to send to, and would (ideally) alert their users that they need to be upgraded to support that.
When a wallet is upgraded to support the new receiver type, it will then know that, for that receiver type, it can only send from transparent sources.
If we go with TEX addresses instead, existing wallets will just say “This is not a valid Zcash address” which is confusing.
Not having must-understand metadata from the start was a real oversight; if we had introduced that from the start, then we wouldn’t have this problem.
I’m kicking myself because I always intended the expiry metadata use case, but when we introduced UAs I didn’t push for it at the time (because it was in the middle of NU5 development and our hair was already on fire), and if I had we probably would have had must-understand metadata and wouldn’t now be in this situation where we can’t count on wallets respecting metadata.
Maybe it’s fortunate that UA parsing isn’t ubiquitous yet, because if we can get all of the known parsers to change, then we can mostly count on must-understand metadata items being available going forward and source-restriction metadata will then make sense. But even if all the parsing libraries get upgraded, it will take a while for users to update their wallets to a version with the new behavior.
Well, with a UA, transparent wallets will say “not a valid address” and the handful of wallets that understand UA will say “unknown receiver”. I’m not sure it is much better.
Regarding the req- metadata, you could consider upgrading all the wallets that support UA. There aren’t many. It is pretty much needed for the expiring addresses since there is no point of having optional revocation.
I don’t consider the error reporting to be as big a deal as I think @nuttycom does, because I don’t think any existing wallets do that well. What I do consider a big deal is that this is the right way to add address types going forward, and avoids introducing a significant amount of tech debt in librustzcash that we wouldn’t be able to get rid of any time soon (short of removing transparent addresses entirely).
Yes, that’s absolutely the intention. I don’t think there are too many UA parsers in the wild yet.
I think yous may be talking at cross purposes. If I’m not mistaken, @hanh means “upgrade all of the UA parsers now and say to Binance that we think that’s sufficient.” @nuttycom is talking about the longer term when we can consider non-upgraded parsers to be “sufficiently old” to not worry about them.
I don’t think the former is sufficient, because you can’t (for good reason) actually take people’s old wallet implementations away from them. You have to deal with the fact that there are conformant implementations in the wild that would ignore the metadata and send to the P2PKH Receiver in a transaction with shielded inputs. Binance’s stated requirements made it clear that’s not acceptable to them (and I absolutely do not want to risk that we do a bunch of work to implement something, and then they come back to us saying it’s not acceptable for this reason). The proposed alternatives don’t have that problem.
Besides, adding a new Receiver type is not complicated and involves less long-term tech debt than adding a new top-level Bech32m encoding. It might be a bit of a hack, but it works perfectly well.
Also, note that if we’re comparing the two alternatives in the ZIP 320 draft (tex addresses and a Traceable P2PKH Receiver type), then the fact that there could have been a different proposal using a new Metadata Item instead of a new Receiver type, is not a relevant argument against the Traceable P2PKH Receiver alternative. Both the compared alternatives involve adding an address type, regardless of whether it’s part of a UA or a top-level type.
Now I do understand, thank you very much for the explanation 
I don’t really think there are any implementations in the wild, if by that you mean implementations that we don’t know about.
It works, but IMO it is a big hack. In any case, how are you going to implement expiring addresses without mandatory metadata?
Why cant the Zaddress and viewing keys (or other methods) be modified to make it compliant? It seems like private transactions to the outside world AND a shared ledger/compliance information between user A and user B only would help with an opt-in compliance for other future use cases as well.
Viewing keys essentially reveal too much information. We did, in the initial list of proposals for Binance, suggest an approach that included a way of providing a reply-to address along with a proof that that shielded address was the source of funds, but Binance rejected that approach. I don’t know the reason for their rejection.
Regardless of the situation with Binance, this is functionality that we’d like to add, potentially with protocol support (for example, with dedicated fields in the transaction format) but it’s not something the ECC team has the additional bandwidth to implement at the moment, even though a fair amount of the work (or at least closely related work) has already been done (ZIP 304: Message signing and verification for Sapling addresses by str4d · Pull Request #210 · zcash/librustzcash · GitHub).
The idea here is that when a parser is updated to understand receiver typecode 0x04, then that parser will also be updated to conform to ZIP 316 Revision 1, which defines “MUST-understand” metadata items. Existing wallets will not understand typecode 0x04 until they are updated, and so they don’t risk sending to Binance. They do risk sending to other addresses in violation of the expiry metadata, but there’s not anything we can really do about that; we just have to hope that end users update to the latest releases of their wallets once such releases are made available.
I agree that it should be possible to update the wallet implementations relatively quickly; it’s just a question of how long it then takes for users to upgrade. I don’t really see the 0x04 typecode as any more of a hack than the tex address; they’re semantically the same - the sender has to obey different rules for that kind of recipient.
I was referring to the pool_exclusion metadata that I think is not a hack.
The main reason I prefer tex is because it can be easily implemented and confined to the wallet front end. It is also easily recognizable (I still hope that they will be deprecated soon).
PS: Not being able to visually know what receivers a UA includes, is a complaint I got from users several times.
Color coding! 
I meant as part of the standard and once it’s copy pasted / printed / etc.
Color coding in the UI is a good idea but some people are color blind.
I understand this complaint, but one cannot infer the privacy properties of a transaction that one is about to make by looking at a unified address - and the same may be true even if you’re talking about bare Sapling addresses! It depends upon what funds you have available to spend.
As a consequence, I think it is the responsibility of the wallet to understand the privacy implications of the transaction, and to report those to the user in an understandable fashion, so that the user can consent. In the zcashd wallet, because it’s a CLI interface and not an interactive UI, we require the user to select the privacy properties ahead of time, and I believe that Ywallet does something similar. With an interactive UI, though, I think it’s possible to have a much richer interface, where once a user requests a transaction, the confirmation screen can have details about that transaction’s privacy implications.
The wallet should of course always attempt to make the most-private transaction it can, but then obtain the user’s consent before sending.
So yes, UAs are opaque, but IMHO since users may not be aware of the mix of notes in their wallets (and ideally would not need to be aware of this - or even be aware that there are multiple pools!) this can actually be a feature. Addresses in general, across cryptocurrencies, are not user-friendly; wallets should be interpreting the meaning of these opaque strings for users.
I understand your point but it is frustrating to a user to come to a coin and get a completely different paradigm even for something as common as an address.
Imo, users should be eased into zcash rather than be immediately faced with a several things to learn.
Their first reaction to UA is usually to ask how to make one with a single receiver.
I tell them it defeats the purpose but they just roll their eyes.