Wallet Guide The Zcash wallet layer: keys, transactions, and light-client synchronisation 2 Hierarchical key derivation (ZIP 32)4 Compact blocks (ZIP 307)

3 Addresses and viewing keys (ZIP 316)

This section passes from the keys of an account to the addresses and viewing keys that a wallet hands out. It defines the diversifier index and the recovery of an index from an address, the raw encodings of receivers and keys, the unified container with its jumbled string encoding and its viewing-key form, the unified address at an index of a viewing key, the extensions of Revision $2$ of ZIP 316, and the recipient addresses a sender handles.

3.1 Diversifier indices

The address layer meets two requirements.

(R1)

Each payee receives an address unlinkable to every other address of the same holder, while all of them are spendable by one key and recoverable from one seed (protocol specification, §“ $\mathsf{DiversifyHash}^{\mathsf{Sapling}}$ and $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ Hash Functions”, security requirements; ZIP 32; ZIP 316, “Rationale for address derivation”). Each shielded protocol meets (R1) with diversified addresses.
(R2)

Transparent, Sapling and Orchard receivers coexist, each with its own format. A recipient publishes one string, from which the sender selects the most preferred receiver type it supports, and whose characters a sender can check (ZIP 316, “Motivation” and “Requirements”). ZIP 316 meets (R2) above the protocols, with unified containers (§3.3) and their jumbled string encoding (§3.4).

The Ironwood Guide constructs the Orchard key tiers, the diversifier map and the diversified base (§“Viewing keys” and §“Diversified addresses”). This subsection adds the diversifier index, shared by Sapling and Orchard and used by transparent derivation.

The Orchard address at index $j$ of an incoming viewing key $(\mathsf{dk},\mathsf{ivk})$ is that of the Ironwood Guide, §“Diversified addresses”, Construction “Diversified address”, cited and not re-derived: $d:=\mathsf{FF1\text{-}AES256}_{\mathsf{dk}}(\mathrm{LE}_{88}(j))$ , $\mathsf{g_{d}}:=\mathsf{DiversifyHash}^{\mathsf{Orchard}}(d)$ , which is $\mathsf{GroupHash}(\texttt{z.cash:Orchard-gd},\mathsf{LEBS2OSP}_{88}(d))$ unless that is the identity and the fallback point $\mathsf{GroupHash}(\texttt{z.cash:Orchard-gd},\varepsilon)$ otherwise, and $\mathsf{pk_{d}}:=[\mathsf{ivk}]\,\mathsf{g_{d}}$ ; the address is $(d,\mathsf{pk_{d}})$ . For each scope $s\in\{\mathsf{ext},\mathsf{int}\}$ of an account (Construction 2.14) the pair $(\mathsf{dk}_{s},\mathsf{ovk}_{s})$ is the first and the second $32$ bytes of $\mathsf{PRFexpand}_{\mathrm{LE}_{256}(\mathsf{r_{ivk}}_{s})}([\mathtt{0x82}]\,% \|\,\mathsf{I2LEOSP}_{256}(\mathsf{ak})\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{nk% }))$ (Ironwood Guide, §“Viewing keys”), and $\mathsf{ivk}_{s}$ is the incoming viewing key of the scope. The address at index $0$ is the default address of the scope (protocol specification, §“Orchard Key Components”; ZIP 32, “Orchard diversifier and OVK derivation”).

Definition 3.1 (Diversifier index).

For a $32$ -byte diversifier key $\mathsf{dk}$ and an index $j\in\{0,\dots,2^{88}-1\}$ , the diversifier at index $j$ is

d_{j}:=\mathsf{FF1\text{-}AES256.Encrypt}(\mathsf{dk},\texttt{""},\mathrm{LE}_% {88}(j))\in\{0,1\}^{88},

the FF1 mode of NIST SP 800-38G over AES-256 with key $\mathsf{dk}$ , radix $2$ , length $88$ and the empty tweak (Crypto Guide, §“Format-preserving encryption and FF1”, Construction “The FF1 mode of NIST SP 800-38G”; protocol specification, §“Pseudo Random Permutations”). The map is the same in both shielded protocols; only the key differs.

1.

For Orchard, $\mathsf{dk}=\mathsf{dk}_{s}$ of the scope $s$ , as above.
2.

For Sapling, $\mathsf{dk}$ is the diversifier-key component of the account’s Sapling extended spending key: $\mathsf{dk}_{m}=\mathsf{truncate}_{32}(\mathsf{PRFexpand}_{\mathsf{sk}_{m}}([% \mathtt{0x10}]))$ at the master key and $\mathsf{dk}_{i}=\mathsf{truncate}_{32}(\mathsf{PRFexpand}_{I_{L}}([\mathtt{0x1% 6}]\,\|\,\mathsf{dk}_{\mathsf{par}}))$ for a hardened child, with $I_{L}$ the left half of the child’s derivation output (ZIP 32, “Sapling master key generation” and “Sapling child key derivation”); Sapling key derivation is cited and not constructed.

The diversifier $d_{j}$ , and the index $j$ , are valid for a protocol if and only if that protocol’s $\mathsf{DiversifyHash}$ does not return $\bot$ at $d_{j}$ .

3.

Orchard: $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ is total, so every index is valid, a scope has exactly $2^{88}$ addresses, and the default diversifier is $d_{0}$ (ZIP 32, “Orchard diversifier and OVK derivation”).
4.

Sapling: $\mathsf{DiversifyHash}^{\mathsf{Sapling}}(d):=\mathsf{GroupHash}^{\mathbb{J}(r% )*}_{\mathsf{URS}}(\texttt{Zcash\_gd},\mathsf{LEBS2OSP}_{88}(d))$ , a hash into the points of order $r_{\mathbb{J}}$ of the Jubjub curve that returns $\bot$ on some inputs (protocol specification, §“ $\mathsf{DiversifyHash}^{\mathsf{Sapling}}$ and $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ Hash Functions”, §“Jubjub” and §“Group Hash into Jubjub”, cited and not constructed). Approximately half of all indices are valid (ZIP 32, “Sapling diversifier derivation”); the probability under the specification’s random-oracle model is derived in §3.6. The default Sapling diversifier is $d_{j}$ for the least valid $j$ (same section).

Totality of $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ removes the search for a valid index. The Sapling failure rate matters when one index must serve several protocols at once (§3.6).

Index-choice rules, specified (protocol specification, §“Orchard Key Components” and §“Sapling Key Components”, notes). Orchard diversifier indices SHOULD NOT be chosen at random; ZIP 32 specifies their use in hierarchical deterministic wallets. Address generators MAY encode information in the diversifier index, recoverable by a holder of $\mathsf{dk}$ (Lemma 3.3). For Sapling, generators MAY encode information in the diversifier itself, and it is RECOMMENDED to encode it in the ZIP 32 diversifier index instead, so that only a holder of $\mathsf{dk}$ reads it.

Proposition 3.2 (Distinct diversifiers).

(a)

For every diversifier key $\mathsf{dk}$ the map $j\mapsto d_{j}$ is a bijection from $\{0,\dots,2^{88}-1\}$ onto $\{0,1\}^{88}$ . In particular distinct indices give distinct diversifiers, and a wallet issues the indices $0,1,2,\dots$ over the whole index space without a repeated diversifier.
(b)

If instead $k$ diversifiers are drawn independently and uniformly from $\{0,1\}^{88}$ , the probability $P$ that two coincide satisfies

$1-e^{-k(k-1)/2^{89}}\leq P\leq\frac{k(k-1)}{2^{89}},$

so a collision becomes likely once $k$ is of order $2^{44}=\sqrt{2^{88}}$ ; at $k=2^{44}$ the bounds are $0.393$ and $0.500$ .

Proof.

(a) The map $\mathrm{LE}_{88}$ is a bijection from $\{0,\dots,2^{88}-1\}$ onto $\{0,1\}^{88}$ , and $\mathsf{FF1\text{-}AES256}$ under a fixed key and tweak is a bijection of $\{0,1\}^{88}$ (Crypto Guide, §“Format-preserving encryption and FF1”, Proposition “FF1 is a keyed bijection on $\mathcal{X}$ ”); the composition is a bijection. (b) The Math Guide, §“The union bound and a birthday calculation”, Proposition “Birthday bound”, with $N=2^{88}$ . □

The specification notes that an $88$ -bit diversifier is not unguessable at the $128$ -bit security level and that randomly chosen diversifiers collide near $2^{44}$ choices; the keyed permutation removes the collisions, provided indices do not repeat (protocol specification, §“ $\mathsf{DiversifyHash}^{\mathsf{Sapling}}$ and $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ Hash Functions”, notes). One further reason for a keyed permutation is ZIP 32’s: it makes the diversifier sequence of each account pseudorandom and uncorrelated with that of any other account, so issued diversifiers do not reveal how many addresses have been generated (ZIP 32, “Sapling diversifier derivation” and “Orchard diversifier and OVK derivation”). The Ironwood Guide supplies Assumption “FF1-AES256 as a pseudorandom permutation” (§“Diversified addresses”) and the unlinkability proposition only.

In Orchard, $\mathsf{dk}_{s}$ is derived from the full viewing key of scope $s$ , so a holder of the account’s Orchard full viewing key computes $\mathsf{dk}_{s}$ for both scopes, hence the index of any diversifier of the account (Lemma 3.3; ZIP 32, “Orchard diversifier and OVK derivation”). In Sapling the same capability belongs to the extended full viewing key, of which $\mathsf{dk}$ is a component. A holder of the incoming viewing key $(\mathsf{dk},\mathsf{ivk})$ of one scope has this capability for that scope only.

Lemma 3.3 (Index recovery and ownership).

Let $(d,\mathsf{pk_{d}})$ be an Orchard address and $(\mathsf{dk},\mathsf{ivk})$ the incoming viewing key of some scope.

(i)

The value $j:=\mathrm{LE}_{88}^{-1}(\mathsf{FF1\text{-}AES256.Decrypt}(\mathsf{dk},% \texttt{""},d))$ is defined for every $d$ and every $\mathsf{dk}$ , and $d_{j}=d$ . Decryption alone therefore proves nothing about ownership.
(ii)

The address $(d,\mathsf{pk_{d}})$ is the address of $(\mathsf{dk},\mathsf{ivk})$ at some index if and only if $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{DiversifyHash}^{\mathsf{Orchard}}(d)$ ; the index is then unique and equals $j$ .
(iii)

A holder of an account’s full viewing key decides whether $(d,\mathsf{pk_{d}})$ belongs to the account, and at which scope and index, by applying (ii) with $(\mathsf{dk}_{\mathsf{ext}},\mathsf{ivk}_{\mathsf{ext}})$ and then with $(\mathsf{dk}_{\mathsf{int}},\mathsf{ivk}_{\mathsf{int}})$ . Both tests succeed only if $\mathsf{ivk}_{\mathsf{ext}}=\mathsf{ivk}_{\mathsf{int}}$ , which has negligible probability for keys with $\mathsf{use\_qsk}=\mathsf{false}$ under Assumption 2.16 and the hypotheses of Lemma 2.9.

The Sapling case of (i) and (ii) is the same with $\mathsf{DiversifyHash}^{\mathsf{Sapling}}$ , the test of (ii) failing when it returns $\bot$ . For (iii), both tests succeed only if the two Sapling incoming viewing keys are equal; this volume does not bound that probability for Sapling.

Proof.

(i) FF1 decryption is the two-sided inverse of encryption under every key and tweak (Crypto Guide, §“Format-preserving encryption and FF1”, Proposition “FF1 is a keyed bijection on $\mathcal{X}$ ”), and $\mathrm{LE}_{88}$ is a bijection. (ii) If $(d,\mathsf{pk_{d}})$ is the address at index $j^{\prime}$ , then $d=d_{j^{\prime}}$ , so $j^{\prime}=j$ by (i) and Proposition 3.2 (a), and $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{DiversifyHash}^{\mathsf{Orchard}}(d)$ by the Ironwood Guide’s Construction “Diversified address” (§“Diversified addresses”). Conversely, if $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{DiversifyHash}^{\mathsf{Orchard}}(d)$ , the address at index $j$ is $(d_{j},[\mathsf{ivk}]\,\mathsf{DiversifyHash}^{\mathsf{Orchard}}(d_{j}))=(d,% \mathsf{pk_{d}})$ . (iii) If both tests succeed, then $[\mathsf{ivk}_{\mathsf{ext}}]\,\mathsf{g_{d}}=[\mathsf{ivk}_{\mathsf{int}}]\,% \mathsf{g_{d}}$ with $\mathsf{g_{d}}\neq\mathcal{O}$ in a group of prime order $p_{\mathsf{Vesta}}$ , and both scalars lie in $\{1,\dots,p_{\mathsf{Pallas}}-1\}$ with $p_{\mathsf{Pallas}}<p_{\mathsf{Vesta}}$ , so $\mathsf{ivk}_{\mathsf{ext}}=\mathsf{ivk}_{\mathsf{int}}$ . Its probability is bounded as in the proof of Proposition 2.17: after the replacement of Assumption 2.16, at most $2/p_{\mathsf{Vesta}}$ by the Ironwood Guide’s Lemma “Distribution of $\mathsf{ivk}$ ” (§“Viewing keys”), plus the distinguishing advantage, equality being efficiently decidable. □

Unlinkability of the addresses of one key is cited with its assumptions. For Orchard it is the Ironwood Guide, §“Diversified addresses”, Proposition “Unlinkability of diversified addresses”: for two keys generated independently with $\mathsf{use\_qsk}=\mathsf{false}$ , an adversary that holds $\mathsf{ak}$ , $\mathsf{nk}$ and $\mathsf{ovk}$ of both keys and chooses indices $j_{0}$ , $j_{1}$ and $j^{\prime}\notin\{j_{0},j_{1}\}$ distinguishes which key produced the third address with negligible advantage, conditioned on the three diversifiers being pairwise distinct. Its assumptions are the Ironwood Guide’s “Pseudorandomness of PRF expansion”, “Joint hiding of the viewing keys”, “FF1-AES256 as a pseudorandom permutation”, “GroupHash as a random oracle”, “DDH on Pallas” and “Discrete logarithms on Pallas”. Account keys are admitted as such keys by Lemma 2.9, the win event being decidable by the challenger; the addresses of one key at distinct indices have distinct diversifiers by Proposition 3.2 (a). For Sapling the protocol specification argues the same property under DDH on the prime-order subgroup of Jubjub, with $\mathsf{GroupHash}^{\mathbb{J}(r)*}$ modelled as a random oracle, through IK-CPA key privacy of ElGamal (§“ $\mathsf{DiversifyHash}^{\mathsf{Sapling}}$ and $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ Hash Functions”, notes; Crypto Guide, §“Key privacy”). This volume does not prove the Sapling case.

Remark 3.4 (Chosen-diversifier oracle).

Suppose that the holder of an incoming viewing key gives an adversary the address of that key at any diversifier the adversary chooses. The adversary then breaks unlinkability outright: given an address $(d^{\prime},\mathsf{pk_{d}}^{\prime})$ , it requests the address at $d^{\prime}$ and compares the returned transmission key with $\mathsf{pk_{d}}^{\prime}$ . The two are equal if and only if the key is the same, the base $g_{d^{\prime}}$ being a point other than the identity in a group of prime order. No other privacy property is affected. Implementations SHOULD avoid providing such a chosen-diversifier oracle (protocol specification, §“ $\mathsf{DiversifyHash}^{\mathsf{Sapling}}$ and $\mathsf{DiversifyHash}^{\mathsf{Orchard}}$ Hash Functions”, notes). An interface returning the address at a requested index gives no chosen diversifier (Lemma 3.5), but it returns the issued addresses themselves: it links every address whose index the requester queries, and under sequential issuance (Proposition 3.2) small indices reach every issued address.

Lemma 3.5 (Index queries give no chosen diversifier).

Let $\mathsf{dk}$ be either diversifier key of an Orchard key with $\mathsf{use\_qsk}=\mathsf{false}$ . Under Assumption 2.16, the hypotheses of Lemma 2.9, and the Ironwood Guide’s Assumption “FF1-AES256 as a pseudorandom permutation” (§“Diversified addresses”), an adversary without $\mathsf{dk}$ that obtains the diversifiers at $q$ indices of its choice obtains a given $d$ , fixed independently of $\mathsf{dk}$ , with probability at most $q/2^{88}$ plus its distinguishing advantages against the two assumptions and, for an account key, the loss of Lemma 2.9. This volume does not prove the Sapling case.

Proof.

Replace $\mathsf{dk}$ by a uniform $32$ -byte string independent of the other keys; by Assumption 2.16, applied after Lemma 2.9, the probability changes by at most that distinguishing advantage and the loss of that Lemma, the win event being decidable. Then replace FF1-AES256 keyed by $\mathsf{dk}$ with a uniform permutation of $\{0,1\}^{88}$ ; the probability changes by at most the distinguishing advantage. Repeated indices add nothing, so let the adversary query $k\leq q$ distinct indices. Each image is uniform on the values not yet returned, so the $i$ -th image is the first to equal $d$ with probability

\prod_{j=1}^{i-1}\frac{2^{88}-j}{2^{88}-j+1}\cdot\frac{1}{2^{88}-i+1}=2^{-88};

summing over $i\leq k$ , $d$ is returned with probability $k\cdot 2^{-88}\leq q\cdot 2^{-88}$ . □

3.2 Raw encodings

The items of unified containers carry the byte encodings below. Each is stated with the validity condition that a decoder applies.

Definition 3.6 (Raw receiver and key encodings).

(a)

An Orchard raw payment address has $43$ bytes, $\mathsf{LEBS2OSP}_{88}(d)\,\|\,\mathsf{pk_{d}}^{\star}$ , where $\mathsf{pk_{d}}^{\star}=\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{P}}(% \mathsf{pk_{d}}))$ is the $32$ -byte compressed encoding of the Pallas point $\mathsf{pk_{d}}$ (Ironwood Guide, §“Fields, groups, and encodings”). A decoder MUST treat the address as invalid if $\mathsf{abst}_{\mathbb{P}}$ returns $\bot$ or the identity (protocol specification, §“Orchard Raw Payment Addresses”).
(b)

A Sapling raw payment address has $43$ bytes, $\mathsf{LEBS2OSP}_{88}(d)\,\|\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{% J}}(\mathsf{pk_{d}}))$ , with the compressed Jubjub encoding. It MUST be considered invalid if $\mathsf{abst}_{\mathbb{J}}$ returns $\bot$ , if the encoding of $\mathsf{pk_{d}}$ is non-canonical, or if $\mathsf{pk_{d}}$ is not a point of order $r_{\mathbb{J}}$ , the identity included (protocol specification, §“Sapling Payment Addresses”).
(c)

An Orchard raw full viewing key has $96$ bytes,

$\mathsf{I2LEOSP}_{256}(\mathsf{ak})\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{nk})\,% \|\,\mathsf{I2LEOSP}_{256}(\mathsf{r_{ivk}}).$

It MUST be considered invalid if $\mathsf{ak}$ , $\mathsf{nk}$ or $\mathsf{r_{ivk}}$ is not the canonical encoding of an element of its field ( $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , $\mathbb{F}_{p_{\mathsf{Vesta}}}$ ), if $\mathsf{ak}$ is not the $x$ -coordinate of a point of $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ other than the identity, or if the external or the internal incoming viewing key derived from it is $0$ or $\bot$ (protocol specification, §“Orchard Raw Full Viewing Keys”).
(d)

An Orchard raw incoming viewing key has $64$ bytes, $\mathsf{dk}\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk})$ . It MUST be considered invalid unless $\mathsf{ivk}\in\{1,\dots,p_{\mathsf{Pallas}}-1\}$ (protocol specification, §“Orchard Raw Incoming Viewing Keys”).
(e)

String forms. No Bech32 or Bech32m encoding exists for an individual Orchard payment address, incoming viewing key or full viewing key; the unified encodings of §3.4 are their only strings. A Sapling payment address keeps a standalone Bech32 string, with human-readable part zs on Mainnet and ztestsapling on Testnet (same sections).
(f)

Transparent receivers. A P2PKH (pay-to-public-key-hash) address pays to the $20$ -byte $\mathsf{hash160}$ of a $33$ -byte compressed ECDSA validating key; a P2SH (pay-to-script-hash) address pays to the $20$ -byte $\mathsf{hash160}$ of a redeem script that the spender reveals and satisfies (Crypto Guide, §“The transparent layer’s hashes”). Their raw encoding prefixes two version bytes to the hash and is written in Base58Check (protocol specification, §“Transparent Addresses”). Inside a unified container a transparent receiver is the bare $20$ -byte hash, without the two version bytes (ZIP 316, “Requirements for both Unified Addresses and Unified Viewing Keys”).

One Orchard raw address serves both pools of the Orchard protocol (§3.3).

3.3 Unified addresses

ZIP 316 defines Revision $0$ , the format of this subsection and of §3.4, and Revision $2$ , which adds metadata items, splits the address prefix into a shielded-only and a transparent-enabled form, and renames the viewing-key prefixes (§3.7); Revision $1$ is withdrawn (ZIP 316, “Revisions”). The revision of a container is read from its human-readable part. The status of ZIP 316 is that of Table 1; everything Revision $2$ adds is specified in the sense of Definition 1.1.

Definition 3.7 (Unified container).

For $n\in\{0,\dots,2^{64}-1\}$ , $\mathrm{compactSize}(n)$ is the variable-length integer of Bitcoin that ZIP 316 cites:

\mathrm{compactSize}(n):=\begin{cases}[n]&\text{if }n<253,\\ [\mathtt{0xFD}]\,\|\,\mathsf{I2LEOSP}_{16}(n)&\text{if }253\leq n<2^{16},\\ [\mathtt{0xFE}]\,\|\,\mathsf{I2LEOSP}_{32}(n)&\text{if }2^{16}\leq n<2^{32},\\ [\mathtt{0xFF}]\,\|\,\mathsf{I2LEOSP}_{64}(n)&\text{otherwise},\end{cases}

the range of $n$ fixing the form. An item is a pair $(\tau,v)$ of a typecode $\tau\in\mathbb{N}$ and a byte string $v$ . The raw encoding of a container with items $(\tau_{1},v_{1}),\dots,(\tau_{k},v_{k})$ , where $\tau_{1}<\dots<\tau_{k}$ , is

\mathsf{raw}:=\mathop{\big{\|}}_{i=1}^{k}\mathrm{compactSize}(\tau_{i})\,\|\,% \mathrm{compactSize}(\mathrm{length}(v_{i}))\,\|\,v_{i}.

Both $\tau_{i}$ and $\mathrm{length}(v_{i})$ MUST be at most $\mathtt{0x2000000}$ ; since $\mathtt{0x2000000}\in[2^{16},2^{32})$ , each takes at most $5$ bytes and an item header at most $10$ .

Typecodes $\mathtt{0x00}$ and $\mathtt{0x01}$ are transparent, $\mathtt{0x02}$ and $\mathtt{0x03}$ shielded, and $\mathtt{0xC0}$ to $\mathtt{0xFC}$ designate metadata items, items that are neither receivers nor viewing keys (§3.7). A unified address (UA) is a container whose non-metadata items are receivers, in the raw encodings of Definition 3.6 under the typecodes of Table 3. A unified full viewing key (UFVK) and a unified incoming viewing key (UIVK) are containers whose non-metadata items are full, respectively incoming, viewing keys (§3.5); UVK denotes either. No typecode exists for Sprout.

Validity. Every container holds at least one non-metadata item. A Revision $0$ UA, and a Revision $0$ UVK, holds at least one shielded item. A Revision $2$ shielded-only UA holds no transparent item; a Revision $2$ transparent-enabled UA may consist of a single P2PKH receiver, and a Revision $2$ UVK need hold no shielded item. A Consumer MUST reject a container

(i)

that violates the containment rule of its revision;
(ii)

in which a typecode repeats, or which holds both $\mathtt{0x00}$ and $\mathtt{0x01}$ ;
(iii)

which holds only metadata items;
(iv)

whose items are not in ascending typecode order;
(v)

which has bytes after the last item;
(vi)

any of whose items fails the validation of its encoding (Definition 3.6; §3.5).

A Consumer MUST ignore items with typecodes it does not recognise, with the exception stated in §3.7; a Consumer therefore parses a container that holds unrecognised items.

Same-account rule. Within one UA or UVK, all receivers, full viewing keys and incoming viewing keys derived hierarchically SHOULD belong to the same account at the ZIP 32 or BIP 44 account level, or, for ZIP 48 and FROST UVKs, to one set of signers able to generate independent addresses for that spending authority. FROST key material MUST be derived according to ZIP 312 and ZIP 2005, in particular ZIP 2005, “Usage with FROST”.

Sources: ZIP 316, “Encoding of Unified Addresses”, “Requirements for both Unified Addresses and Unified Viewing Keys” and “Receivers”.

The ascending order makes the raw encoding a function of the set of items, so a representation that discards the order reproduces the same encoding, provided it retains unrecognised items (ZIP 316, “Rationale for Item ordering”). This order is not the priority order below.

Typecode	Item	Receiver	UFVK item	UIVK item
$\mathtt{0x00}$	transparent P2PKH	$20$	$65$	$65$
$\mathtt{0x01}$	transparent P2SH	$20$	—	—
$\mathtt{0x02}$	Sapling	$43$	$128$	$64$
$\mathtt{0x03}$	Orchard	$43$	$96$	$64$

Table 3: Typecodes and item lengths of Revision

0

, in bytes. In Revision

0

Producers MUST NOT include typecode

\mathtt{0x01}

in a UFVK or UIVK, and Consumers MUST treat it as unrecognised there. The Priority List of preference is

\mathtt{0x03}

, then

\mathtt{0x02}

, then

\mathtt{0x01}

\mathtt{0x00}

(at most one of the two is present), the reverse of the encoding order. Receiver lengths are those of Definition 3.6; the viewing-key lengths are those of §3.5:

65=32+33

(chain code and compressed key),

128

for

(\mathsf{ak},\mathsf{nk},\mathsf{ovk},\mathsf{dk})

64

for

(\mathsf{dk},\mathsf{ivk})

, and

96

for

(\mathsf{ak},\mathsf{nk},\mathsf{r_{ivk}})

(ZIP 316, “Encoding of Unified Addresses” and “Encoding of Unified Full/Incoming Viewing Keys”).

Receiver selection. The Sender of a payment to a UA MUST use the receiver of the most preferred type that it supports, by the Priority List Orchard ( $\mathtt{0x03}$ ), Sapling ( $\mathtt{0x02}$ ), then P2SH ( $\mathtt{0x01}$ ) or P2PKH ( $\mathtt{0x00}$ ); an unrecognised item is treated as absent, with the exception of §3.7. A wallet MAY let its users configure which receiver types it can send to, and MUST NOT let them change the order of the Priority List except by opting into an experiment, whose specification MAY add to the list and SHOULD keep the preference for more recent shielded protocols (ZIP 316, “Encoding of Unified Addresses”, “Transfers” and “Experimental Usage”). The Orchard receiver belongs to the Orchard protocol, not to a pool: one $\mathsf{ivk}$ trial-decrypts both Orchard-pool and Ironwood-pool note ciphertexts (ZIP 326, “Scanning for Ironwood-pool and Orchard-pool notes”), and the Ironwood pool changes no address structure or encoding (ZIP 229, “Abstract”). The pool in which a payment to an Orchard receiver is made is fixed by the routing rule of §11.2, which carries the prohibition of ZIP 326, “Wallet key-generation restrictions”, on paying external receivers in the Orchard pool; the Priority List is unchanged.

3.4 String encoding: F4Jumble and Bech32m

The Bech32m checksum does not cascade: a user who checks only the beginning and the end of a long string can miss an adversarial substitution of an inner receiver. ZIP 316 therefore passes the whole payload through F4Jumble, an unkeyed four-round Feistel construction that approximates a random permutation of the entire byte string, so that every output character depends on every input byte. It states two goals (ZIP 316, “Jumbling”).

(i)

Near second-preimage resistance. Given $q$ honestly generated UAs or UVKs, an adversary does not produce a valid one that it controls, knowing at least one constituent private key, whose string matches one of the targets on a chosen set of characters, for concreteness the first $n$ and the last $m$ .
(ii)

Nonmalleability. Without any private key, an adversary does not produce a valid UA or UVK usefully different from a target, for example with its shielded receiver removed, that matches the target on the checked characters.

Generic attacks bound what is achievable: about $w\,c^{n+m}/q$ for (i) and $w/p$ for (ii), where $w$ is the work to produce and verify one UA or UVK, $c$ the size of the character set and $p$ the probability that a random decoding is valid and useful (ZIP 316, “Discussion”). Jumbling is not authentication. F4Jumble is unkeyed, so anyone can jumble and checksum a wholly substituted address, and an address is still obtained or verified through a trusted channel; jumbling raises only the cost of partial-match and malleation attacks against a genuine string.

Construction 3.8 (F4Jumble).

Let $\ell_{H}:=64$ and $\ell_{\mathsf{MAX}}:=(2^{16}+1)\,\ell_{H}=4194368$ . For $i\in\{0,1\}$ and byte strings $u$ , with the first argument of BLAKE2b the personalisation,

	$\displaystyle H_{i}(u)$	$\displaystyle:=\mathrm{BLAKE2b\text{-}}(8\ell_{L})\bigl{(}\texttt{UA\_F4Jumble% \_H}\,\\|\,[i,0,0],\ u\bigr{)},$
	$\displaystyle G_{i}(u)$	$\displaystyle:=\text{the first }\ell_{R}\text{ bytes of }\mathop{\big{\\|}}_{j=% 0}^{\lceil\ell_{R}/\ell_{H}\rceil-1}\mathrm{BLAKE2b\text{-}512}\bigl{(}\texttt% {UA\_F4Jumble\_G}\,\\|\,[i]\,\\|\,\mathsf{I2LEOSP}_{16}(j),\ u\bigr{)},$

an $\ell_{L}$ -byte hash and an extendable-output function in the sense of the Crypto Guide, §“Hash functions and the random oracle model”, Definition “Extendable-output function”, for the lengths $\ell_{L}$ and $\ell_{R}$ below. For a byte string $M$ of length $\ell_{M}$ with $38\leq\ell_{M}\leq\ell_{\mathsf{MAX}}$ , let

\ell_{L}:=\min(\ell_{H},\lfloor\ell_{M}/2\rfloor),\qquad\ell_{R}:=\ell_{M}-% \ell_{L},

split $M=a\,\|\,b$ with $\mathrm{length}(a)=\ell_{L}$ , and let

	$\displaystyle x$	$\displaystyle:=b\oplus G_{0}(a),$	$\displaystyle y$	$\displaystyle:=a\oplus H_{0}(x),$
	$\displaystyle d$	$\displaystyle:=x\oplus G_{1}(y),$	$\displaystyle c$	$\displaystyle:=y\oplus H_{1}(d),$

and $\mathsf{F4Jumble}(M):=c\,\|\,d$ (ZIP 316, “Solution”). Figure 2 shows the four rounds.

Each personalisation has $16$ bytes: $13+3$ for $H_{i}$ and $13+1+2$ for $G_{i}$ . They are pairwise distinct, differing at byte $12$ between the $H$ and the $G$ family and at bytes $13$ to $15$ within a family, and distinct from the three personalisations of key derivation in Table 2 and from that of $\mathsf{PRFexpand}$ , Zcash_ExpandSeed. Being of one length and distinct, they are prefix-free tags, so BLAKE2b under these personalisations is modelled as independent random oracles (Crypto Guide, §“Domain separation and personalisation”, Proposition “Domain separation yields independent oracles”).

Refer to caption — Figure 2: The four rounds of F4Jumble (Construction 3.8) on the unequal halves $a$ ( $\ell_{L}$ bytes) and $b$ ( $\ell_{R}$ bytes). Each round replaces one half by its XOR with a function of the other half, which it leaves unchanged: $G_{0}$ of $a$ into $b$ gives $x$ , $H_{0}$ of $x$ into $a$ gives $y$ , $G_{1}$ of $y$ into $x$ gives $d$ , and $H_{1}$ of $d$ into $y$ gives $c$ . Blue boxes are the extendable-output functions $G_{i}$ , with $\ell_{R}$ output bytes; amber boxes are the hashes $H_{i}$ , with $\ell_{L}$ output bytes. The names are those of the cells of Example 3.11. The structure is the content of Proposition 3.9.

Proposition 3.9 (F4Jumble is a permutation).

For every $\ell_{M}$ with $38\leq\ell_{M}\leq\ell_{\mathsf{MAX}}$ , $\mathsf{F4Jumble}$ is well defined and is a bijection of the $\ell_{M}$ -byte strings. Its inverse maps $c\,\|\,d$ , with $\mathrm{length}(c)=\ell_{L}$ , to $a\,\|\,b$ computed by

y:=c\oplus H_{1}(d),\quad x:=d\oplus G_{1}(y),\quad a:=y\oplus H_{0}(x),\quad b% :=x\oplus G_{0}(a).

Proof.

Well defined. From $\ell_{M}\geq 38$ , $\ell_{L}\geq 19$ ; from $\ell_{L}\leq 64$ , the output length $8\ell_{L}$ of $H_{i}$ is admissible for BLAKE2b. If $\ell_{M}\leq 128$ then $\ell_{R}\leq 64$ and one block of $G_{i}$ suffices. Otherwise $\ell_{L}=64$ and $\ell_{R}=\ell_{M}-64\leq 2^{16}\cdot 64$ , so $\lceil\ell_{R}/\ell_{H}\rceil\leq 2^{16}$ and every counter $j$ fits $\mathsf{I2LEOSP}_{16}$ ; this is the reason for $\ell_{\mathsf{MAX}}=(2^{16}+1)\,\ell_{H}$ .

Bijection. Each of the four steps replaces one half by its XOR with a function of the other half, which it leaves unchanged, and $r=p\oplus q$ implies $p=r\oplus q$ . Each step is therefore inverted by recomputing the same function of the unchanged half, and the composition of the four inverses in reverse order is the stated map, a two-sided inverse. This is the argument of the Crypto Guide, §“Format-preserving encryption and FF1”, Proposition “Feistel is a bijection regardless of the round functions”. Unequal halves change nothing, since $G_{i}$ maps into $\ell_{R}$ bytes and $H_{i}$ into $\ell_{L}$ bytes, the lengths of the halves they are XORed into. □

ZIP 316, “Heuristic analysis”, motivates the number of rounds.

Construction 3.10 (Unified string encoding).

Human-readable parts of Revision $0$ : u for a UA, uview for a UFVK and uivk for a UIVK on Mainnet; on Testnet test is appended (utest, uviewtest, uivktest). Let $\mathsf{raw}$ be the raw encoding of Definition 3.7, $\mathit{hrp}$ the human-readable part and $\mathsf{padding}$ the human-readable part in US-ASCII right-padded with zero bytes to $16$ bytes.

1.

Producer. It MUST ensure $\mathrm{length}(\mathsf{raw})\leq\ell_{\mathsf{MAX}}-16=4194352$ , and outputs $\mathrm{Bech32m}(\mathit{hrp},\mathsf{F4Jumble}(\mathsf{raw}\,\|\,\mathsf{% padding}))$ , the Bech32m encoding of BIP 350 with its length restriction ignored.
2.
Consumer. It MUST decode as follows, rejecting the string at the first failure:
1. (1)
  
  decode with Bech32m, rejecting an incorrect checksum;
2. (2)
  
  reject a decoded byte string shorter than $38$ or longer than $\ell_{\mathsf{MAX}}$ bytes;
3. (3)
  
  apply $\mathsf{F4Jumble}^{-1}$ (Proposition 3.9);
4. (4)
  
  reject a result that does not end in the $16$ -byte padding of the string’s human-readable part, and remove that padding;
5. (5)
  
  parse the rest as a raw encoding, rejecting the whole string if any rule of Definition 3.7 fails.

UFVKs and UIVKs use the same procedure under their own human-readable parts (ZIP 316, “Encoding of Unified Addresses”, “Encoding of Unified Full/Incoming Viewing Keys” and “Usage for Unified Addresses, UFVKs, and UIVKs”; BIP 350).

The padding supplies the redundancy that defeats the generic nonmalleability attack, since a random decoding must end in the exact $16$ bytes, and gives the human-readable part the same protection against malleation as the payload, which may help against cross-network substitution and against confusion of an address with a viewing key (ZIP 316, “Usage for Unified Addresses, UFVKs, and UIVKs” and “Heuristic analysis”).

Length rules (ZIP 316, “Rationale for length restrictions” and “Efficiency”). The $38$ -byte minimum is Revision $2$ ’s: one P2PKH item of $22$ bytes and the padding. Revision $0$ specified $48$ bytes. No set of items valid in Revision $0$ has an encoding of $22$ to $31$ bytes (the smallest Revision $0$ input is $45+16=61$ bytes), so the difference is unobservable except in the error reported, and a Consumer supporting Revision $2$ MAY apply either minimum to Revision $0$ strings. A Consumer that cannot support strings up to $\ell_{\mathsf{MAX}}$ MUST support those with $\ell_{M}$ of at least $256$ bytes; a full implementation supports $\ell_{\mathsf{MAX}}$ .

Display rule, specified (ZIP 316, “Requirements for both Unified Addresses and Unified Viewing Keys”). If the string of a UA or UVK is shown in an abridged form, at least its first $20$ characters MUST be shown. The rationale is the ZIP’s (“Rationale for showing at least the first 20 characters”). After the longest Mainnet human-readable part of Revision $0$ , uview, and the separator 1, $14$ characters remain, $70$ bits of jumbled data at $5$ bits per character, below the target of $2^{125}$ against classical attacks, and multi-target attacks are possible; $20$ is an absolute minimum and a wallet may show more. Only a prefix counts, because displays that show different substrings let a user compare only the characters common to all of them, and because checksum characters complicate the analysis of partial matching.

Item sizes. A Sapling or Orchard receiver item has $1+1+43=45$ bytes (typecode, length, $11$ -byte diversifier and $32$ -byte transmission key), a P2PKH receiver item $1+1+20=22$ bytes, and the padding $16$ bytes. Hence a UA with Sapling and Orchard receivers has $\ell_{M}=106$ , and one with P2PKH, Sapling and Orchard receivers $\ell_{M}=128$ (ZIP 316, “Efficiency”).

Example 3.11 (A unified address, end to end).

Let the seed be the $32$ bytes $\mathtt{0x00},\mathtt{0x01},\dots,\mathtt{0x1f}$ , on Mainnet, with the Orchard account $9$ at $m_{\mathsf{Orchard}}/32^{\prime}/133^{\prime}/9^{\prime}$ (Definition 2.7), the external scope and the index $j=1$ . Every value below is computed by script from the seed.

Receiver. The diversifier key $\mathsf{dk}$ is the first half of the $\mathtt{0x82}$ expansion of the account’s full viewing key, and FF1 encryption of $\mathrm{LE}_{88}(1)$ gives $d_{1}$ (Definition 3.1):

$\mathsf{dk}$	82cc9d79742fe5ae9a142b9336a98677b154fe20401eb18998dbed915b0453ce
$\mathsf{LEBS2OSP}_{88}(\mathrm{LE}_{88}(1))$	0100000000000000000000
$d_{1}$	3fadf8edb20a3301e8260a
$\mathsf{pk_{d}}^{\star}$	a311f4cbd54d7d6a76baac88c244b0b121c6dc22a8bcce15898e267829fc1e01

Decryption $\mathsf{FF1\text{-}AES256.Decrypt}(\mathsf{dk},\texttt{""},d_{1})$ returns $\mathrm{LE}_{88}(1)$ , so $j=1$ , and the ownership test $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{DiversifyHash}^{\mathsf{Orchard}}(d_{1})$ of Lemma 3.3 holds for the external $\mathsf{ivk}$ . It fails for the internal $\mathsf{ivk}_{\mathsf{int}}$ , although $\mathsf{dk}_{\mathsf{int}}$ also decrypts $d_{1}$ , to the index $184814530803446824004762235$ : recovery alone proves nothing, and the test on $\mathsf{pk_{d}}$ decides. The neighbouring diversifiers are $d_{0}=\mathtt{e340636542ece1c81285ed}$ and $d_{2}=\mathtt{987fd74a2256c596a66f83}$ ; that consecutive indices give unrelated strings illustrates the Ironwood Guide’s Assumption “FF1-AES256 as a pseudorandom permutation” (§“Diversified addresses”) and is not evidence for it.

Container. The UA has one item, so its raw encoding (Definition 3.7) is the header $\mathrm{compactSize}(\mathtt{0x03})\,\|\,\mathrm{compactSize}(43)=\mathtt{032b}$ followed by the $43$ -byte receiver $d_{1}\,\|\,\mathsf{pk_{d}}^{\star}$ , $45$ bytes in all. The padding is $\mathtt{75}$ (u) followed by fifteen zero bytes, so $M$ has $\ell_{M}=61$ , $\ell_{L}=30$ and $\ell_{R}=31$ . The cells of Construction 3.8:

$a=M[0..30)$	032b3fadf8edb20a3301e8260aa311f4cbd54d7d6a76baac88c244b0b121
$b=M[30..61)$	c6dc22a8bcce15898e267829fc1e0175000000000000000000000000000000
$x=b\oplus G_{0}(a)$	e6f1529b03a0ad0a4209da8e4365ca14a5988bf1d03084a1c326f929c574ca
$y=a\oplus H_{0}(x)$	37b358eb784bb2b315fd35c595628cfa9aa8045ef271728dd0cbf84dc81a
$d=x\oplus G_{1}(y)$	ad26d7fb043e09cbf18e8f4d80d2b423ecb01719170463d644be4c76daab6b
$c=y\oplus H_{1}(d)$	98979f9a7d2dfce7b1616a8d2b9975f87878171b6fcf33b303f770b4aa64

The header, the diversifier and the padding are legible in $a$ and $b$ , and in neither $c$ nor $d$ .

String. The $61$ bytes of $c\,\|\,d$ regroup into $98$ five-bit symbols, the last padded with two zero bits. With the human-readable part u, the separator 1 and the $6$ -symbol checksum, the string has $1+1+98+6=106$ characters:

u1nztelxna9h7w0vtpd2xjhxt4lpu8s9cmdl8n8vcr7actf2ny45nd07cy8cyuhuvw3axcp545y0ktq9cezuzx84jyhex8dk4tdvwhu4dl

Decoding reverses each stage of Construction 3.10, and $\mathsf{F4Jumble}^{-1}(c\,\|\,d)=M$ . The string equals the unified-address test vector for account $9$ and index $1$ of the zcash-test-vectors suite, which ZIP 32, “Test Vectors”, names.

3.5 Unified viewing keys

Definition 3.12 (Unified full and incoming viewing keys).

A UFVK and a UIVK are containers of Definition 3.7 under the string encoding of Construction 3.10 with their own human-readable parts; a Consumer MUST use the decoding procedure of Construction 3.10. Their items, at the receiver typecodes, are the following.

1.

Orchard, $\mathtt{0x03}$ : the $96$ -byte raw full viewing key, respectively the $64$ -byte raw incoming viewing key, of Definition 3.6.

Sapling, $\mathtt{0x02}$ : in a UFVK the $128$ bytes

	$\displaystyle\mathsf{EncodeExtFVKParts}(\mathsf{ak},\mathsf{nk},\mathsf{ovk},% \mathsf{dk})$
	$\displaystyle\quad:=\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{J}}(\mathsf% {ak}))\,\\|\,\mathsf{LEBS2OSP}_{256}(\mathsf{repr}_{\mathbb{J}}(\mathsf{nk}))\,% \\|\,\mathsf{ovk}\,\\|\,\mathsf{dk}$

of ZIP 32, “Sapling helper functions”, which SHOULD be derived from the account-level extended full viewing key; in a UIVK the $64$ bytes $\mathsf{dk}\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{ivk})$ , valid only if $\mathsf{ivk}\in\{1,\dots,2^{251}-1\}$ (protocol specification, §“Sapling Incoming Viewing Keys”; ZIP 316 notes the exclusion of $0$ ). The Sapling UIVK item carries $\mathsf{dk}$ beyond the specification’s Sapling incoming viewing key, which is $\mathsf{ivk}$ alone (protocol specification, §“Sapling Incoming Viewing Keys”); $\mathsf{dk}$ maps an index to a diversifier and back, so a UIVK yields addresses at indices (Construction 3.16) and recovers the index of a diversifier (Lemma 3.3).

3.

Transparent P2PKH, $\mathtt{0x00}$ : the $65$ bytes $\mathsf{c}\,\|\,\mathsf{ser}_{P}(\mathsf{pk})$ of a $32$ -byte BIP 32 chain code and a $33$ -byte compressed public key, the last $65$ bytes of the BIP 32 extended public key serialisation (BIP 32, “Serialization format”). The UFVK item is the key at $m/44^{\prime}/\mathit{coin\_type}^{\prime}/a^{\prime}$ , the account level of BIP 44, and the UIVK item its external (non-change) child at $m/44^{\prime}/\mathit{coin\_type}^{\prime}/a^{\prime}/0$ .

The current viewing-key types reuse the receiver typecodes; future types MAY use others. The Priority List does not govern viewing keys: a Consumer normally takes the union of the information of all items (ZIP 316, “Encoding of Unified Full/Incoming Viewing Keys”).

The transparent item omits the BIP 32 depth, parent fingerprint and child number; the format is ZIP 316’s. That the child number of the account-level key would reveal the account index is this volume’s inference, not a statement of the ZIP. The Sapling UFVK item carries no chain code, so a UFVK supports no non-hardened Sapling child derivation below the account.

Construction 3.13 (Attenuation of a UFVK to a UIVK).

Item by item, with the typecode preserved:

1.

a Sapling full viewing key to its incoming viewing key (protocol specification, §“Sapling Key Components”), with $\mathsf{dk}$ carried over;
2.

an Orchard full viewing key $(\mathsf{ak},\mathsf{nk},\mathsf{r_{ivk}})$ to the external-scope incoming viewing key $(\mathsf{dk},\mathsf{ivk})$ (Ironwood Guide, §“Viewing keys”);
3.

a transparent P2PKH account key to its child at non-hardened index $0$ by BIP 32 public-to-public derivation (BIP 32, “Public parent key $\to$ public child key”).

Items with unrecognised typecodes, and items of experiments the user has not opted into, MUST be dropped (ZIP 316, “Deriving a UIVK from a UFVK”). The treatment of metadata items is stated with them, in §3.7.

Assumption 3.14 (Independence of the per-protocol key trees).

For a wallet seed $S$ (Definition 2.1) and an account index $a$ , the Orchard account key of Definition 2.7, the Sapling extended spending key at $m_{\mathsf{Sapling}}/32^{\prime}/\mathit{coin\_type}^{\prime}/a^{\prime}$ of ZIP 32 and the BIP 32 extended private key at $m/44^{\prime}/\mathit{coin\_type}^{\prime}/a^{\prime}$ are jointly computationally indistinguishable from three independently generated keys of the respective protocols: a uniform Orchard spending key with a uniform chain code, a uniform Sapling master-derived key and a uniform BIP 32 key.

The assumption has a heuristic basis and no proof. It follows if BLAKE2b-512 under ZcashIP32Sapling (the Sapling master key) and HMAC-SHA512 under the key Bitcoin seed (the BIP 32 master key) are modelled as random oracles independent of BLAKE2b-512 under ZcashIP32Orchard, and the Sapling and BIP 32 hardened child derivations as PRFs keyed by the parent chain code (HMAC as a PRF: Crypto Guide, §“PRFs from hash functions: length extension and keyed BLAKE2”; ZIP 32, “Sapling master key generation” and “Sapling child key derivation”; BIP 32, “Master key generation” and “Private parent key $\to$ private child key”). Lemma 2.5 proves the Orchard component and nothing more.

Proposition 3.15 (Capabilities of a unified viewing key).

Let the keys of one account be generated from a seed, with $\mathsf{use\_qsk}=\mathsf{false}$ for the Orchard component, and let Assumption 3.14 hold.

(a)

From a UFVK the following are computed: for Orchard, the incoming and outgoing viewing keys of both scopes and $\mathsf{nk}$ , hence receipt, spend and outgoing detection (Proposition 2.15); for Sapling, the same through ZIP 32’s internal key derivation; for transparent keys, every external and internal address and the transparent outgoing viewing keys (Construction 2.18). No secret that is infeasible to compute from its own component becomes feasible from the whole UFVK: in particular the Orchard $\mathsf{ask}$ (Ironwood Guide, §“Key capabilities and scope”, Proposition “Capability separation”, part (a)), the Sapling spend authorising key and a transparent private key.
(b)

A UIVK gives receipt detection for the external scope in each shielded protocol it carries, and no spend detection for its shielded items: $\mathsf{nk}$ is infeasible to compute from an Orchard $(\mathsf{dk},\mathsf{ivk})$ (Ironwood Guide, §“Key capabilities and scope”, Proposition “Capability separation”, part (b)), and internal-scope receipt is neither detected (Proposition 2.17) nor derivable (Proposition 2.20). A transparent UIVK item yields the external addresses $m/44^{\prime}/\mathit{coin\_type}^{\prime}/a^{\prime}/0/j$ and not the internal ones. Spends of transparent funds are public on the transparent chain, so their visibility is a property of the chain, not of the key.

Metadata items confer no viewing authority (§3.7), so the statements hold for containers of either revision.

Proof.

Componentwise. The computations of (a) and (b) are those of the cited constructions applied to each item. For the separations: by Assumption 3.14 the components are indistinguishable from independently generated keys, so a reduction given one component generates the others itself. An algorithm that outputs a secret of one protocol from the whole container thus yields an algorithm that outputs it from that protocol’s component alone, with the advantage of Assumption 3.14 added; the success of either is efficiently decidable, by recomputing the public key or viewing key from the output. The per-component statements are Propositions 2.15, 2.17 and 2.20 with the Ironwood Guide, §“Key capabilities and scope”, Proposition “Capability separation”, under the assumptions named there, for Orchard; ZIP 32 and the protocol specification, §“Sapling Key Components”, cited, for Sapling; and Assumption 2.19 with BIP 32, “Security”, for the transparent keys. The transparent spend clause is a property of transparent inputs, which name the outpoints they spend in the clear. □

3.6 Deriving unified addresses

Construction 3.16 (Unified address at an index).

Let $U$ be a UIVK. Choose one index $j\in\{0,\dots,2^{88}-1\}$ , which MUST be valid for every item of $U$ :

1.

for an Orchard item, always;
2.

for a Sapling item, if and only if $\mathsf{DiversifyHash}^{\mathsf{Sapling}}(d_{j})\neq\bot$ , with $d_{j}$ the diversifier of the item’s $\mathsf{dk}$ at $j$ (Definition 3.1);
3.

for a transparent P2PKH item, if and only if $0\leq j\leq 2^{31}-1$ and BIP 32 derivation of the child at index $j$ succeeds; it fails with probability below $2^{-127}$ (BIP 32, “Public parent key $\to$ public child key”).

Each receiver is derived from its item at the same $j$ : a Sapling or Orchard receiver as the address at index $j$ of $(\mathsf{dk},\mathsf{ivk})$ (protocol specification, §“Sapling Key Components” and §“Orchard Key Components”; Ironwood Guide, §“Diversified addresses”, Construction “Diversified address”), and a transparent P2PKH receiver as the $\mathsf{hash160}$ of the non-hardened BIP 32 public child $j$ of the external key, so that its path is $m/44^{\prime}/\mathit{coin\_type}^{\prime}/a^{\prime}/0/j$ (BIP 44). Items with unrecognised typecodes, and items of experiments the user has not opted into, MUST be dropped; metadata items are treated in §3.7 (ZIP 316, “Deriving a Unified Address from a UIVK”).

Proposition 3.17 (Indices valid for a unified key).

Let $V(U)$ be the set of indices valid for every item of a UIVK $U$ .

(a)

If $U$ has only an Orchard item, $V(U)=\{0,\dots,2^{88}-1\}$ .
(b)

If $U$ has a transparent item, $V(U)\subseteq\{0,\dots,2^{31}-1\}$ , a fraction $2^{31}/2^{88}=2^{-57}$ of the index space, so $U$ has at most $2^{31}$ unified addresses.
(c)

Let $U$ have a Sapling item, and let $\mathrm{BLAKE2s\text{-}256}$ in $\mathsf{GroupHash}^{\mathbb{J}(r)*}$ be modelled as a random oracle, the model of the protocol specification, §“Group Hash into Jubjub”, notes. The events that the indices are valid for the Sapling item are independent over distinct indices, each of probability

$\pi:=\frac{h_{\mathbb{J}}\,(r_{\mathbb{J}}-1)}{2^{256}}=\frac{8\,(r_{\mathbb{J% }}-1)}{2^{256}}\approx 0.4528,$

with $h_{\mathbb{J}}=8$ the cofactor and $r_{\mathbb{J}}$ the prime subgroup order of Jubjub (protocol specification, §“Jubjub”); an index is invalid with probability $1-\pi\approx 0.5472$ . ZIP 32’s “approximately half” and ZIP 316’s probability $1/2$ are this value rounded.
(d)

With a Sapling and a transparent item, $V(U)$ is the set of indices below $2^{31}$ that are Sapling-valid and at which BIP 32 derivation succeeds; its expected size lies within $2^{31}\cdot 2^{-127}=2^{-96}$ of $\pi\cdot 2^{31}$ .

For the Sapling key of account $9$ of the seed of Example 3.11, $4527$ of the indices $0,\dots,9999$ are valid, a fraction $0.4527$ , and index $0$ is valid.

Proof.

The set $V(U)$ is the intersection of the per-item valid sets of Construction 3.16, which gives (a) and (b), distinct indices giving distinct receivers.

(c) Distinct indices give distinct diversifiers (Proposition 3.2 (a)), hence distinct inputs to $\mathrm{BLAKE2s\text{-}256}$ , whose outputs $h$ are then independent and uniform on $\{0,1\}^{256}$ . The group hash returns a point if and only if $P:=\mathsf{abst}_{\mathbb{J}}(h)\neq\bot$ and $[h_{\mathbb{J}}]\,P\neq\mathcal{O}$ (protocol specification, §“Group Hash into Jubjub”). The map $\mathsf{abst}_{\mathbb{J}}$ reads $h$ as a $255$ -bit integer $v<q_{\mathbb{J}}$ and a sign bit $\tilde{u}$ , rejecting $v\geq q_{\mathbb{J}}$ and $v$ with no curve point (protocol specification, §“Jubjub”). Each point with $u\neq 0$ is the image of exactly one $h$ , since $u$ and $q_{\mathbb{J}}-u$ have different parities, and each of the two points $(0,\pm 1)$ is the image of two. The curve has $h_{\mathbb{J}}r_{\mathbb{J}}$ points and its $h_{\mathbb{J}}$ -torsion subgroup, the kernel of $[h_{\mathbb{J}}]$ , has $8$ points: $(0,1)$ , $(0,-1)$ and six with $u\neq 0$ . The strings $h$ for which the hash succeeds are thus in bijection with the points with $u\neq 0$ outside that subgroup, of which there are $h_{\mathbb{J}}r_{\mathbb{J}}-2-6=8\,(r_{\mathbb{J}}-1)$ , so $\pi=8\,(r_{\mathbb{J}}-1)/2^{256}$ .

(d) Parts (b) and (c) and Construction 3.16 (3) combined by linearity of expectation over the $2^{31}$ indices below $2^{31}$ , each of which fails BIP 32 derivation with probability below $2^{-127}$ . □

Remark 3.18 (Default addresses).

ZIP 316 fixes neither an order in which a wallet searches for a valid index nor a default unified address. The only normative defaults are ZIP 32’s per-protocol default diversifiers: for Sapling $d_{j}$ with $j$ the least valid index, for Orchard $d_{0}$ (ZIP 32, “Sapling diversifier derivation” and “Orchard diversifier and OVK derivation”). Issuing the unified address at the least index valid for every item is designed but unspecified (Definition 1.1).

Index $0$ and recovery across wallets, specified (ZIP 316, “Deriving a Unified Address from a UIVK”). Index $0$ is invalid for a Sapling item with probability $1-\pi$ (Proposition 3.17), so a wallet that requires a Sapling receiver often issues its first unified address at a later index, while some wallets, earlier than ZIP 316 or without a Sapling component in their unified addresses, always generate a transparent P2PKH address at index $0$ . Therefore every Zcash wallet, whether or not it supports unified addresses, MUST assume that transparent funds may exist at diversifier index $0$ of each ZIP 32 account, even where it would never generate a unified address at that index; reliable recovery of funds when key material moves between wallets depends on this. Its use in restoration is stated in §6.2.

3.7 Revision 2 containers

Definition 3.19 (Metadata items).

The following is Revision $2$ of ZIP 316, specified (Definition 1.1).

1.

Human-readable parts. A UA is either shielded-only, with human-readable part zu, which MUST NOT hold a transparent item (typecode $\mathtt{0x00}$ or $\mathtt{0x01}$ ), a Consumer rejecting any that does, or transparent-enabled, with tu. A UFVK uses uvf and a UIVK uvi; on Testnet test is appended. The human-readable part distinguishes a Revision $0$ container (u, uview, uivk) from a Revision $2$ one.
2.

Metadata items, typecodes $\mathtt{0xC0}$ to $\mathtt{0xFC}$ (Definition 3.7), MAY affect the interpretation of the container, MUST NOT be selected as receivers and MUST NOT confer viewing authority.
3.

MUST-understand items. Typecodes $\mathtt{0xE0}$ to $\mathtt{0xFC}$ are MUST-understand: a Consumer that does not recognise such an item MUST regard the whole container as unsupported and not process it further. This is the exception to the ignore rule of Definition 3.7.
4.

Registry. Typecodes $\mathtt{0x04}$ to $\mathtt{0xBF}$ are unassigned; $\mathtt{0xC0}$ to $\mathtt{0xDF}$ are metadata that need not be understood, none assigned; $\mathtt{0xE0}$ is the Address Expiry Height and $\mathtt{0xE1}$ the Address Expiry Time, permitted in zu and tu addresses and not in Revision $0$ ; $\mathtt{0xE2}$ to $\mathtt{0xFC}$ are unassigned MUST-understand metadata; $\mathtt{0xFD}$ to $\mathtt{0xFFF9}$ are unassigned; and $\mathtt{0xFFFA}$ to $\mathtt{0xFFFF}$ are experimental. Producers MUST NOT include items whose typecodes are unassigned or not permitted for the type of the container.
5.

Address expiry items. An item of typecode $\mathtt{0xE0}$ holds the Address Expiry Height, an unsigned $32$ -bit little-endian integer; a UA carrying it MUST be considered expired when the height of the chain exceeds that value. An item of typecode $\mathtt{0xE1}$ holds the Address Expiry Time, an unsigned $64$ -bit little-endian Unix time; a UA carrying it MUST be considered expired when the current time is after that value. A Producer MAY include either, both or neither.
6.

Retroactive rule. A Revision $0$ container MUST NOT hold a MUST-understand metadata item, and a Consumer MUST reject one that does.
7.

Derivation. To derive a UIVK from a UFVK, or a UA from a UFVK or UIVK, a Consumer MUST understand every MUST-understand item of the source. The derived container MUST be Revision $2$ if the source holds any metadata item, and SHOULD be Revision $2$ if the source is. A UIVK derived from a UFVK MUST retain its $\mathtt{0xE0}$ and $\mathtt{0xE1}$ items unmodified. A UA derived from a UFVK or UIVK that carries $\mathtt{0xE0}$ (respectively $\mathtt{0xE1}$ ) MUST carry $\mathtt{0xE0}$ (respectively $\mathtt{0xE1}$ ) with a value at most that of the viewing key. Metadata items that need not be understood and are unrecognised are dropped under Constructions 3.13 and 3.16.
8.

Containment. Revision $2$ drops the rule that a UVK holds a shielded item, and admits a tu UA that consists of one P2PKH receiver (Definition 3.7). Revision $2$ also admits a P2SH viewing-key item, which lies outside this volume; Table 3 is that of Revision $0$ .

Sources: ZIP 316, “Revisions”, “Metadata Items”, “Address Expiration Metadata”, “Typecode Registry”, “Requirements for both Unified Addresses and Unified Viewing Keys”, “Deriving a UIVK from a UFVK” and “Deriving a Unified Address from a UIVK”.

A Consumer that predates Revision $2$ does not recognise the Revision $2$ human-readable parts. Requiring MUST-understand items to appear only under those parts therefore enforces the MUST-understand rule even against such a Consumer (ZIP 316, “Rationale for making Revision 0 UA/UVKs with MUST-understand Typecodes invalid”).

Sender rules for expiring addresses, specified (ZIP 316, “Address Expiration Metadata” and its “Rationale”). The expiry height of a transaction is its field $\mathsf{nExpiryHeight}$ (Ironwood Guide, §“The transaction format”). A Sender supporting Revision $2$ MUST set a nonzero $\mathsf{nExpiryHeight}$ in a transaction to a UA with an Address Expiry Height, and MUST NOT send the transaction if the $\mathsf{nExpiryHeight}$ it would otherwise construct exceeds that height; lowering $\mathsf{nExpiryHeight}$ to the address’s value instead would reveal the destination’s expiry on chain. With only an Address Expiry Time, it SHOULD choose $\mathsf{nExpiryHeight}$ so that the transaction expires no more than $24$ hours after the current time. With both items both restrictions apply, and with several recipient UAs in one transaction all their constraints apply. A wallet MUST NOT send to an address it knows to have expired, and its error SHOULD suggest obtaining a current address. The choice of $\mathsf{nExpiryHeight}$ is stated in §9.3.

Linkability through metadata (ZIP 316, “Address Expiration Metadata”). Diversified UAs derived from one UIVK that hold only Sapling or Orchard receivers and no metadata are unlinkable (§3.1); with metadata items present this no longer holds, and it is RECOMMENDED that the expiry height and time of distinct derived addresses vary. Re-issuing the same receivers with different expiry metadata yields a visually distinct address that is directly linkable to the original, since the receivers are shared.

3.8 Recipient addresses

Definition 3.20 (Recipient address).

A recipient address is one of the following:

1.

a transparent address, P2PKH or P2SH, in its Base58Check encoding (Definition 3.6 (f));
2.

a Sapling payment address in its Bech32 encoding (Definition 3.6 (e));
3.

a unified address (Definition 3.7, Construction 3.10 and Definition 3.19);
4.

a TEX address (transparent-source-only address): the Bech32m encoding, with human-readable part tex on Mainnet and textest on Testnet, of the $20$ -byte validating-key hash of a P2PKH address. It is obtained from a Base58Check P2PKH address whose decoding has $22$ bytes beginning with the lead bytes $[\mathtt{0x1C},\mathtt{0xB8}]$ (Testnet $[\mathtt{0x1D},\mathtt{0x25}]$ ) by removing them, and it is parsed by requiring the human-readable part and exactly $20$ decoded bytes (ZIP 320, “Specification”).

Sprout addresses are not recipient addresses: no transaction adds value to the Sprout pool, and no typecode exists for them (§14.2; ZIP 316, “Requirements for both Unified Addresses and Unified Viewing Keys”). A Sender paying a TEX address, as any output of a transaction, MUST spend only transparent (P2SH or P2PKH) outputs in that transaction, and SHOULD send only to transparent outputs (ZIP 320, “Specification”; §11.3).

Two predicates on recipient addresses, defined here, are used by payment construction and by ZIP 321 (ZIP 321, “memo”; §14.2).

(i)

An address is memo-capable if and only if it is a Sapling payment address or a unified address that contains a Sapling or Orchard receiver, since a memo travels only in a note plaintext (Ironwood Guide, §“The note plaintext”). A memo reaches the recipient of a unified address only when the Sender selects a shielded receiver.
(ii)

An address is transparent-only if and only if it is a transparent or TEX address, or a unified address whose non-metadata items are all transparent receivers, which is possible only as a Revision $2$ tu address.