Hi, all. @daira and I have put together a proposal for adding optional expiration metadata to unified addresses. The proposal is here, comments are welcome: [ZIP 316: MUST-understand metadata items and Address Expiration Metadata by nuttycom · Pull Request #759 · zcash/zips · GitHub](https://ZIP 316: MUST-understand metadata items and Address Expiration Metadata)
Is there a reason why each address type doesn’t have separate metadata accommodations for expiry height, vs expiry block?
The way it reads, a user might be forced to expire all addresses at once (by height and-or time), but they may intend different expirations for different addresses.
I’m not sure what you’re asking here. A unified address expires all at once, but you can create as many different unified addresses as you want with different expiration heights/times.
The rationale behind offering both heights and times is that there may be contexts where you want to generate an address and don’t have current block height information (say on an offline device) but still want to limit how long that address will remain usable. In general it’s preferable to use an expiration height if you have height information available.
I probably don’t understand-recognise how the ZIP spec is written.
For the context of Binance (let’s assume all centralized exchanges suffering KYC-AML-MICA etc etc compliance specs)
Does the current plan allow for a UA/T-addr with the anti-shielded in metadata to exist without an expiration?
The expiry metadata is not required. However, I think that setting an address expiration date is generally a good idea in many cases; for example, it helps make it easier to do key rotation, because you can stop scanning with a given key once all the addresses you have derived from it have expired. If I am trying out a new wallet, for example, I don’t want to have to commit to continuing to scan with that new key forever just because I gave the address out.
This change is also motivated by the Binance use case; one of their questions has been what to do about users who have stored their existing transparent deposit address in their wallets or as a withdrawal address for other exchanges or services. This is a challenging problem to mitigate now because address expiration was not previously implemented; we can’t retroactively expire the transparent deposit addresses that Binance has previously given out (without a protocol change) but we can mitigate this kind of problem going forward.
I think @noamchom is asking whether it would be possible to have different Receivers expire at different times. This could be useful: it would allow greater decoupling between the time at which you update the address you use for someone and the time at which subsets of Receivers expire — because each UA could contain receivers for this period and the next, allowing validity periods to overlap.
However, using that feature would at least double the length of encoded UAs. More importantly, it is not possible to include more than one Item (either a Metadata Item or a Receiver) having the same typecode without breaking compatibility with current Consumers. To support sets of Receivers with different metadata, you would have to include some kind of container structure within a new Item. Current Consumers would not understand that structure, and so would ignore the Receivers inside it (unless the new container Item were MUST-understand, which would break compatibility entirely).
I think it is preferable to deploy the simpler scheme described in the PR. Then we can consider whether to spend effort on addresses that provide forward security properties (forward unspendability and forward transaction confidentiality · Issue #2044 · zcash/zcash · GitHub), and/or implement an address registration scheme to allow automated updating of addresses (Address Registration Protocol · Issue #340 · zcash/zcash · GitHub).
In addition to address length, the UX complexity of parts of a UA expiring at different times seems highly undesirable to me. It’s better to just pick the lower bound and then your counterparty has to get a new address from you later. The fact that a UA is a few different receivers in a trenchcoat already leaks through to the user experience all too often, and having parts of the UA expire would make that even worse.
Thanks, that is correct. I hadn’t understood the term Receivers earlier
(is it correct to think of them similar to how normal, single T or Z addresses work?
but they’re encoded within the UA)