ZIPs 32 and 316: Refine how IVK components are derived, and other cleanups

[daira]

Co-authored-by: str4d jack@electriccoin.co
Co-authored-by: Kris Nuttycombe kris@electriccoin.co
Co-authored-by: Deirdre Connolly deirdre@zfnd.org
Signed-off-by: Daira Hopwood daira@jacaranda.org

[dconnolly]

Some small fixes/comments to add

[nuttycom]

ACK

[dconnolly]

An alternative idea from @str4d:

Amend orchard key tree to derive ask, nk, 2 rIVKs, one for recipient, one for change.

Both halves use the same nk and ak in their viewing keys

Would have to change how ovk and d_k are derived

prf_expand only depends on ak and nk, not rIVK

Only need adding an extra bit of data to the key tree

@str4d correct me

[str4d]

What we decided on was the following:

• Add a new domain separator for PRF_Expand
• Derive a "change FVK" from the "normal FVK" via the same process as how we derive dk and ovk for Orchard.
• From this "change FVK", derive "change ivk", "change ovk" and the "default change address" using the normal process.

Then when spending notes:

• Send change to the default change address (we never use diversifiers for change, regardless of whether the notes we spent came from diversified addresses).
• Make payment outputs recoverable with the normal ovk, and change outputs recoverable with the change ovk.

This has the following effects:

• The normal FVK provides full visibility into payments and change.
• The normal ivk provides visibility only into incoming payments.
• The normal ovk (if used) provides visibility only into outgoing payments.
• The UFVK and UIVK formats are unaltered (so we can undo a bunch of the changes in this PR).
  • There's little-to-no rationale for exposing the change ivk or ovk to someone (it would provide a very weird view), but if it were necessary, just provide two UIVKs.

[str4d]

I've reverted all refinements to ZIP 32, in line with the above decision. There were refinements to ZIP 316 that I left in place (specifically the fix to how transparent IVKs were defined, which we want to retain).

[dconnolly]

✅

[nuttycom]

ACK