My main objective with this disscussion is to raise awareness so we can avoid what happened last time when UA’s were first introduced and none of the exchanges or wallet devs had ample time to update.
My understanding is Revision 2 adds:
Support for MUST-understand Typecodes and Address Expiration Metadata.
Two new Unified Address variants:
zu addresses (prohibited from containing transparent receivers — for better privacy signaling).
tu addresses (allow transparent receivers augmented with metadata).
For Unified Viewing Keys: new uvf/uvi prefixes, removal of the shielded-item requirement, and support for P2SH viewing key items via BIP 388.
I have some questions:
Wallet devs, IF this is adopted as is, will you support it?
Users, is this new format easy to understand and would you support it?
I am still digesting these changes so I will keep an open mind on my personal opinions as of now.
Shielded only UA’s have been the default best practice for a little while. I don’t think most users would notice any change there really from codifying it. Transparent view keys sound like an easier way to watch a transparent address in-wallet besides just watching it with something else, and if that fixes an issue then ok, the other address types have vks. I don’t really understand any further rationale for them beyond that. Address expiry seems pretty nifty, something thats been kinda stewing for long time. I haven’t read into zip248.
I have mixed feelings. I think it is the right thing (it would be step 3 from my suggestion), but I think it will take a long time for projects to adopt it and may create additional confusion. It is super important that we get this right this time so if people have feedback now is the time!
I’d like orchard to get their own address representation → zo. Sapling receivers are mostly unused since there are no wallet that supports sapling only. Retire u and have zu for the future. Most users will only see/use the explicit addresses t & zo. They are easy to understand. If an exchange/vendor needs something more custom (like tex), they provide a zu address. IMO, users should not have to face complex behavior/semantics.
This is a great question, I didnt think about address books which historicially Ive always liked AND to me are very intuitive to what folks are used to.
I agree, I think the community addressed this well and making u… addresses officially shielded-only would be a good way of accomplishing the intent with little impact to wallet devs.
I would think that if the ephemeral address type was at least different enough from normal addresses, than non-compatible wallets simply could not send to them in any case. For the use case, I think about things things that are timelocked like on chain voting in the more typical form where some registered voter sends a proof in a 0 value memo saying who they vote for, and the election ends when the address expires. A fundraiser round where somebody matches donations, round ends when address expires. Maybe if you change accounts and therefore addresses quite a bit, the old address is still good and you might not ever see anything mistakingly sent to it after you migrate forward.
I can see how it would be useful to “deprecate” an address, but I don’t think this would accomplish that. You’d still need to set an expiration date and then forced to rotate when it hits. And if you change accounts before that expiration, you still have the problem.
The point I’m trying to make is that there are a small amount of use cases where it would apply, most people will set defaults far into the future so they don’t have to deal with the hassle of tracking who they gave an address that needs to be rotated. Small user base, big hit to wallet devs to implement, and combined with memo bundles coming, it feels like this setting up the wallet devs to fall behind and have another “We released new functionality that no one can use because the wallets don’t support it”.
I’d like to add that address books with unified addresses are tricky to do right because the address on chain is a receiver and will not match the UA. I have several users ask why the address on the transaction history isn’t their UA. IMO, they are enough scammers out there that saying it is unexpected sounds like a scam.
User side - Raw format? Not really intuitive. Most users won’t understand, and honestly, they shouldn’t have to. If this leaks into user decision-making, it becomes friction.
But if wallets default to `zu ‘where possible’ and handle expiration silently (like invoices or one-time addresses), then it becomes simpler, not more complex.
So I’d support it, but only if the ecosystem commits to strong default + abstraction, not exposing this complexity directly to users.
It’s very useful to be able to rotate keys; you can only do this if you know that nobody’s going to be sending you funds at a key that has been lost or compromised.
Ideally, it would be possible to set expiry heights for addresses that are forced to be respected at the consensus layer, but that’s not a practical change to make right now. So this is intended to be the next-best thing.
Note also that with Tachyon moving away from what we have traditionally considered to be “addresses” entirely, there will be similar concerns that we should build in to the design of what is expressed in Tachyon payment requests. I know that @ValarDragon has had some ideas about how a sequence of tags that can be used for PIR can be derived by a sender/recipient pair; I hope that this will also be designed with some sort of expiry in mind.
We do need to think about what role UAs will play in the Tachyon migration. I think that an orchard-only address representation that doesn’t have additional metadata will make that migration harder.
This can only be related to transparent addresses, right? In the wallet, the recipient address that’s displayed to the user should be the address that they recognize as one that they’ve given out; we do this in ZODL, by determining which UA controlled the receiver in the transaction and then displaying that UA.
For tu addresses, this can be resolved by displaying both addresses, the transparent address that’s visible on the chain and the tu address it corresponds to.
Yeah, because you/your wallet extracted the receivers of your UA, and matched the receiver on chain with one of them. But naturally, the UA is not the one they see on chain.
