Unified Address TODOs

[str4d]

• [ ] Ensure that current UA specification satisfies the requirements in #470.
• [ ] Define a common standard for HD unified addresses
  • From a single seed, derive the Sapling / Orchard / transparent spending keys for the same account number, and then treat them as the same "unified account".
• [ ] Define Unified Viewing Keys
• [ ] Define Unified Spending Keys?
  • This likely makes sense in the HD case, to have a USK correlated with an account.

Open questions:

• Should HD UAs be detectable (in UVKs / USKs, not the UAs themselves) vs arbitrarily-constructed ones?
• Should we even allow arbitrarily-constructed UAs / USKs (bucket of spending keys), or would that just be confusing to users vs a USK correlated with an account?

[daira]

Are UVKs only full viewing keys? Is there an ivk equivalent, or can UVKs be a mixture of fvks and ivks? (I would be fine with them being fvk-only, I think.) Do they have a separate HRP (say "v" and "vtest")?

[daira]

Does the UA restriction of only having one element of each type also apply to UVKs?

In UAs there is a clear motivation for this restriction: you're only going to send to the "best" address that you support, so multiple addresses of the same type just add ambiguity without any extra utility.

UVKs have different semantics: they represent a view capability to some subset of transaction information, taking the union over several viewing keys. I can't see any corresponding argument for restricting this to one viewing key of each type.

[str4d]

Are UVKs only full viewing keys? Is there an ivk equivalent, or can UVKs be a mixture of fvks and ivks? (I would be fine with them being fvk-only, I think.) Do they have a separate HRP (say "v" and "vtest")?

I think there could be used cases for both, so I'd be inclined to use the prefixes ufvk and uivk (I don't think brevity is as necessary here, given that FVKs in particular aren't short).

For transparent P2PKH keys, a U{F,I}VK would contain the extended public key for the account, from which the "diversified transparent addresses"could be obtained for UAs via non-hardened derivation.

[str4d]

Does the UA restriction of only having one element of each type also apply to UVKs?

In UAs there is a clear motivation for this restriction: you're only going to send to the "best" address that you support, so multiple addresses of the same type just add ambiguity without any extra utility.

UVKs have different semantics: they represent a view capability to some subset of transaction information, taking the union over several viewing keys. I can't see any corresponding argument for restricting this to one viewing key of each type.

It depends on how you view the relationship between them. At a purely technical level, all of these are just wrappers around lists of objects. However, at a user level, I'm inclined to match the semantics of UAs and UFVKs etc. (it doesn't make sense to me that you could always have a UFVK corresponding to a UA, but it might not be possible to generate a UA corresponding to a UFVK).

[daira]

Being able to generate a UA corresponding to a UFVK or UIVK does make sense to me as a motivation for an only-one-of-each-type restriction on the latter.

Note however that if you only have a UIVK, you don't have enough information to derive the diversifier deriving key dk. So it's unclear what diversifier to use in that case, unless you just pick a random one. Another option is to have a UIVK include dk.