# New KDFs for UAs, UIVKs, and UFVKs

## Orchard

Most of the Orchard key tree works as-is. We only need one additional KDF to derive $\mathsf{rivk_{change}}$, and we derive it from the same data as $\mathsf{ovk}$ and $\mathsf{dk}$:

$K = \mathsf{I2LEBSP_{\ell_{sk}}}(\mathsf{rivk})$
$\mathsf{rivk_{change}} = \mathsf{ToScalar^{Orchard}}(\mathsf{PRF^{expand}}(K, [\mathtt{0x83}] \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{ak}) \,||\, \mathsf{I2LEOSP_{256}}(\mathsf{nk}))$

## Sapling

$I = \textsf{BLAKE2b-256}(\texttt{"Zcash_SaplingChg"}, \mathsf{EncodeExtFVKParts}(\mathsf{ak, nk, ovk, dk}))$

$I_\mathsf{nsk} = \mathsf{ToScalar}(\mathsf{PRF^{expand}}(I, [\mathtt{0x17}]))$
$R = \mathsf{PRF^{expand}}(I, [\mathtt{0x18}])$
$\mathsf{nsk_{change}} = (I_\mathsf{nsk} + \mathsf{nsk}) \pmod{r_\mathbb{J}}$
$\mathsf{nk_{change}} = [I_\mathsf{nsk}] \mathcal{H}^\mathsf{Sapling} + \mathsf{nk}$

let $\mathsf{dk_{change}}$ be the first $\ell_\mathsf{dk}/8$ bytes of R and let $\mathsf{ovk_{change}}$ be the remaining $\ell_\mathsf{ovk}/8$ bytes of R.

The change full viewing key is then $(\mathsf{ak}, \mathsf{nk_{change}}, \mathsf{ovk_{change}}, \mathsf{dk_{change}})$

Note: the reason we have to have a separate nk_change for Sapling is that ivk is only derived from ak, nk in Sapling, whereas for Orchard it is also derived from rivk.

## Transparent

### Full viewing key derivation for a P2PKH receiver in UFVKs

If I have a UA derived from an HD seed, we should be able to provide a UFVK that gives full visibility into all of the actions corresponding to the UA.

To achieve this, it should be possible to derive an $\mathsf{ovk}$ from the UFVK but not from the corresponding UIVK.

### Spec

A "full viewing key" for a P2PKH receiver is the concatenation of two values derived for the BIP 44 path `m/32'/coin_type'/account'`:
- The chain code `c`.
- The public key `pk`.

The IVK for a P2PKH receiver is the same two values, but derived for the BIP 44 path `m/32'/coin_type'/account'/change`, where `change` is `0` for the external IVK, and `1` for the change IVK.

We desire the following viewing properties for the transparent key tree, to match the shielded key trees:

- A holder of the FVK can derive external and change IVKs, and external and change OVKs.
- We get the former from BIP 44, as the `change` child path is non-hardened.
- We need to design the KDF to ensure the latter.
- A holder of the external IVK cannot derive the change IVK, or any of the OVKs.
- The former property is obtained from BIP 44 (domain separation via `change`).
- We obtain the latter by ensuring we don't derive OVKs from IVKs.
- A holder of the external OVK cannot derive the change OVK, or any of the IVKs.
- We need to design the KDF to ensure the former.
- We obtain the latter from BIP 44, since we don't derive IVKs from OVKs (we derive them from the FVK).

To satisfy the above, we derive the OVKs from the transparent FVK $(c, pk)$ as follows:

$I_\mathsf{ovk} = \mathsf{PRF^{expand}}_{\mathsf{LEOS2BSP}_{256}(c)}\big([\mathtt{0xd0}] \,||\, \mathsf{ser_P}(pk)\big)$

where $\mathsf{ser_P}(pk)$ is $33$ bytes. (TODO: ensure ZIP 316 specifies the $33$-byte form.)

Let $\mathsf{ovk_{external}}$ be the first $\ell_\mathsf{ovk}/8$ bytes of $I_\mathsf{ovk}$ and let $\mathsf{ovk_{change}}$ be the remaining $\ell_\mathsf{ovk}/8$ bytes of $I_\mathsf{ovk}$.

## Path syntax for UAs

> TODO: Update this from the Slack conversation.
> [name=str4d]

u/coin_type/comma_separated_receiver_indices/account[?di=diversifier_index]

- The `?di=diversifier_index` is optional, because it indicates a specific diversified address, whereas the rest of the path indicates the common spend / view authority.

Example:

u/133/0,2,3/0?di=0