Decide where in the key tree ZIP 320 ephemeral addresses should go

[str4d]

We have a few options that we need to decide between:

• Take "unused" addresses within the existing chain of change addresses for an account (scope 1 at the is_change level of the path, where in BIP 44 it is treated as a boolean).
  • This risks that the "ephemeral" addresses become linked to the rest of the transparent part of the wallet, if the wallet seed phrase is used in a wallet that behaves like a regular Bitcoin-style wallet and links change outputs together. Linkability can occur in two ways:
  • If the recipient TEX address sends funds back to the ephemeral address, and the transparent wallet then treats it as change.
  • If the second transaction in a TEX payment doesn't get mined, the transparent wallet treats the output as change, and then the "ephemeral" address gets reused with the same TEX recipient in a subsequent transaction.
• Use the scope 2 at the is_change level (effectively turning that level into an enum within Zcash).
• Use the scope ZCASH_DOMAIN_SEPARATOR | 0 at the is_change level (same as above, but providing domain separation from any accidental collisions against other specifications that may themselves have said "just use 2").
• Use a different key tree derived from the wallet seed phrase but not derived from the account's transparent IVK.
  • This would mean that the IVK / FVK doesn't see everything in the wallet, which is less desirable.
• Derive a path in the key tree deterministically from the recipient TEX address (i.e. have a 1:1 mapping between TEX addresses and the "ephemeral" addresses we connect to them).
  • The other approaches can be recovered by the usual BIP 44 dead reckoning (count from zero until you reach the gap limit). This one would require storing additional metadata in memo fields within the transaction.

[str4d]

With the middle three options, it is possible to determine solely from the transaction graph structure which outputs went to TEX addresses: if an ephemeral address is observed, then for any transaction spending from that address, its transparent outputs are TEX addresses.

With the first option, this isn't possible because there is no way to distinguish between a change address and an ephemeral address. You'd need to store the recipient address map in a memo field.

With the last option, ephemeral addresses aren't detectable directly, and instead you need to rely on metadata conveyed in e.g. memo fields for detection.