The Zcash ArboretumThe Complete Arboretum PDF

2 Hierarchical key derivation (ZIP 32)

This section derives every key of a wallet from one seed. It fixes the seed and its fingerprint, the hardened-only derivation of Orchard spending keys and the standard account path, and the passage from an account spending key to the key components that the Ironwood Guide constructs from a spending key, including the alternative branch of ZIP 2005. It then constructs the internal keys of an account and proves the separations between the two scopes, bounds the probability that an account key is invalid, and closes with the domains of key derivation.

2.1 Wallet seeds

Definition 2.1 (Wallet seed).

A wallet seed is a byte string S with 32≤length⁢(S)≤252, where length⁢(S) is its length in bytes (MUST). The method that generates S MUST give it at least 256 bits of entropy; the requirement extends to any mnemonic or input randomness from which S is obtained (ZIP 32, “Specification: Wallet seeds”). Every key of every account of the wallet is derived from S: the account spending key in §2.3, and what recovery needs beyond S in §2.4.

Every key of every account is a deterministic function of S, so a seed space of lower entropy is searched once for all accounts, and across many wallets as a multi-target search that matches the first derived addresses or viewing keys against a set of observed ones (ZIP 32, “Rationale for the 256-bit entropy requirement”).

Construction 2.2 (Seed fingerprint).

For a wallet seed S, the seed fingerprint is

𝖲𝖾𝖾𝖽𝖥𝖯⁢(S):=BLAKE2b⁢-⁢256⁢(Zcash_HD_Seed_FP,[length⁢(S)]∥S),

unkeyed BLAKE2b with a 32-byte output and the 16-byte personalisation shown, over the single length byte of S followed by S; the length fits one byte because length⁢(S)≤252. It MAY be used to identify the seed of a hierarchical deterministic wallet. Its string form is Bech32m (BIP 350) with human-readable part zip32seedfp and the 32 fingerprint bytes as data; no short tag is defined (ZIP 32, “Seed Fingerprints”). A partially created transaction carries the fingerprint together with a derivation path, so that a signing party locates its key (§12.3).

A partially created transaction relies on collision resistance of BLAKE2b-256 under this personalisation (Crypto Guide, §“Security notions: preimage, second-preimage, and collision resistance”, Definition “Collision resistance”); Lemma 2.5 additionally models it as a random oracle, so that the fingerprint reveals nothing of the keys. The fingerprint of a full viewing key is constructed with the key components, in §2.4.

2.2 Hardened-only derivation

ZIP 32 instantiates its hardened-only derivation for Orchard with the master-key domain ZcashIP32Orchard, a 16-byte BLAKE2b personalisation that SHOULD be disjoint from every other BLAKE2b domain separator of Zcash, and the child-key domain 𝟶⁢𝚡⁢𝟾𝟷, a lead byte of 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽 (ZIP 32, “Specification: Hardened-only key derivation”, “Instantiation”, and “Specification: Orchard key derivation”). An Orchard extended spending key is a pair (𝗌𝗄,𝖼) of 32-byte strings, where 𝗌𝗄 is a spending key in the sense of the Ironwood Guide, §“The spending key and the spend-side secrets”, and 𝖼 is the chain code (ZIP 32, “Orchard extended keys”). Only hardened derivation is defined for Orchard: child derivation fails at every index i<231. ZIP 32 defines no extended full viewing key for Orchard; a full viewing key has no child-derivation capability for which a chain code would serve. For 0≤i<231 write i′:=i+231.

Construction 2.3 (Orchard master key generation).

For a wallet seed S (Definition 2.1), let

I:=BLAKE2b⁢-⁢512⁢(ZcashIP32Orchard,S),

unkeyed BLAKE2b with a 64-byte output, and let 𝗌𝗄m:=I[0..32) and 𝖼m:=I[32..64), the first and the last 32 bytes. The master extended spending key is m𝖮𝗋𝖼𝗁𝖺𝗋𝖽:=(𝗌𝗄m,𝖼m)=:𝖬𝖪𝖦(S) (ZIP 32, “Hardened-only master key generation” and “Orchard master key generation”).

Construction 2.4 (Orchard child key derivation).

For a parent extended spending key (𝗌𝗄𝗉𝖺𝗋,𝖼𝗉𝖺𝗋) and an index i∈{0,…,232−1}: if i<231, derivation fails; otherwise

I:=𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝖼𝗉𝖺𝗋⁢([𝟶⁢𝚡⁢𝟾𝟷]⁢‖𝗌𝗄𝗉𝖺𝗋‖⁢𝖨𝟤𝖫𝖤𝖮𝖲𝖯32⁢(i)),

a 64-byte string, and 𝖢𝖪𝖣((𝗌𝗄𝗉𝖺𝗋,𝖼𝗉𝖺𝗋),i):=(I[0..32),I[32..64)). Here 𝖨𝟤𝖫𝖤𝖮𝖲𝖯32⁢(i) is the 4-byte little-endian encoding of i, and 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽k⁢(t)=BLAKE2b⁢-⁢512⁢(Zcash_ExpandSeed,k∥t) is the Ironwood Guide, §“Pseudorandom functions and field reductions”, Construction “Expansion function” (ZIP 32, “Hardened-only child key derivation” and “Orchard child key derivation”). The parent chain code is the key of the expansion; the parent spending key is message data.

Lemma 2.5 (Pseudorandomness of derived spending keys).

Assume the following.

  1. (i)

    BLAKE2b-512 under the personalisation ZcashIP32Orchard and BLAKE2b-256 under the personalisation Zcash_HD_Seed_FP are modelled as random oracles (Crypto Guide, §“The random oracle model”, Definition “Random oracle”), independent of each other and of every other personalised use of BLAKE2b (Crypto Guide, §“Domain separation and personalisation”, Proposition “Domain separation yields independent oracles”), and of every other derivation from S that is modelled as a random oracle.

  2. (ii)

    The seed S has min-entropy at least 256 bits, the reading of the entropy requirement of Definition 2.1 that the lemma uses.

  3. (iii)

Let N be a fixed finite set of distinct nodes of the Orchard derivation tree rooted at m𝖮𝗋𝖼𝗁𝖺𝗋𝖽, each reached by Construction 2.4 along hardened indices, and let T be the subtree spanned by the paths from the root to the nodes of N. Then the spending keys of the nodes of N, the chain codes of those nodes of N that are not a proper ancestor of another node of N, and 𝖲𝖾𝖾𝖽𝖥𝖯⁢(S) are jointly computationally indistinguishable from independent uniform 32-byte strings. For an adversary making q random-oracle queries, the distinguishing advantage is at most q⋅2−256 plus one PRF advantage for each node of T whose chain code keys a derivation in T; there are at most as many such nodes as T has edges.

Proof.

A hybrid argument (Crypto Guide, §“The hybrid argument”, Lemma “Hybrid lemma”). Game 0 is the real experiment. Game 1 answers every oracle query whose input is determined by S (the master query of Construction 2.3, the input of 𝖲𝖾𝖾𝖽𝖥𝖯 and the inputs of the other modelled derivations) by fresh uniform strings, independent of S. The two games differ only if the adversary itself queries such an input. In Game 1 its view is independent of S until that happens, so each of its q queries does so with probability at most 2−256 by hypothesis (ii), and the games differ by at most q⋅2−256. In Game 1 the pair (𝗌𝗄m,𝖼m) and 𝖲𝖾𝖾𝖽𝖥𝖯⁢(S) are independent uniform strings.

Then visit the nodes of T that have a child in T, each parent before its children. At such a node v the chain code 𝖼v is, by the earlier hops, a uniform string that is used only as a 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽 key and is not released, because v is a proper ancestor of a node of N. The hop replaces 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝖼v by a uniformly random function. The children of v in T have distinct indices, hence distinct inputs [𝟶⁢𝚡⁢𝟾𝟷]⁢‖𝗌𝗄v‖⁢𝖨𝟤𝖫𝖤𝖮𝖲𝖯32⁢(i), so their 64-byte outputs become fresh uniform strings (Ironwood Guide, §“Pseudorandom functions and field reductions”, Lemma “Independence of domain-separated expansions”, first conclusion, applied to a uniform key; its statistical-distance clause is not used). The hop costs the PRF advantage of a reduction that samples every other node itself and forwards the queries of v to its oracle. In the last game every released value is a fresh uniform string; the chain codes of proper ancestors, which are not fresh relative to their children, are exactly those the lemma does not release. □

Remark 2.6 (The spending key as a leaf capability).

In Construction 2.4 the parent chain code keys the expansion and the parent spending key is message data, so deriving children requires the pair (𝗌𝗄,𝖼). A 32-byte spending key alone derives no child: by Lemma 2.5, without 𝖼 the children are pseudorandom (ZIP 32, “Orchard child key derivation”). A wallet that keeps 𝗌𝗄𝖺𝖼𝖼𝗍 and not 𝖼𝖺𝖼𝖼𝗍 keeps no power to derive keys below the account.

2.3 The standard account path

Definition 2.7 (Account spending key).

For a wallet seed S, a coin type t and an account index a∈{0,…,231−1},

(𝗌𝗄𝖺𝖼𝖼𝗍,𝖼𝖺𝖼𝖼𝗍):=𝖢𝖪𝖣⁢(𝖢𝖪𝖣⁢(𝖢𝖪𝖣⁢(𝖬𝖪𝖦⁢(S),32′),t′),a′),

the path m𝖮𝗋𝖼𝗁𝖺𝗋𝖽/𝑝𝑢𝑟𝑝𝑜𝑠𝑒′/𝑐𝑜𝑖𝑛⁢_⁢𝑡𝑦𝑝𝑒′/𝑎𝑐𝑐𝑜𝑢𝑛𝑡′. The purpose index is 32′=𝟶⁢𝚡⁢𝟾𝟶𝟶𝟶𝟶𝟶𝟸𝟶, following BIP 43; the coin type is the SLIP 44 value, 133 on Mainnet and 1 on Testnet, every test network sharing the value 1; accounts are numbered sequentially from 0, as in BIP 44. All three levels are hardened. The account spending key is 𝗌𝗄𝖺𝖼𝖼𝗍; no construction of this volume uses 𝖼𝖺𝖼𝖼𝗍 (Remark 2.6). A wallet implementing Orchard ZIP 32 derivation MUST support this path for every account in {0,…,231−1}, MUST support generating the default payment address, at diversifier index 0, of every account it supports, and MAY generate further diversified addresses of an account (ZIP 32, “Key path levels” and “Orchard key path”).

The path ends at the account. Addresses are not path children: an account has 288 diversified addresses per scope, the images of the diversifier indices (Ironwood Guide, §“Diversified addresses”, Construction “Diversified address”). There is no change level. A shielded output does not show its address on chain, so returning change to the originating address is indistinguishable from using a change address; the wallet separates change from received funds by the internal scope below the account (§2.5; ZIP 32, “Key path levels”). Figure 1 shows the derivation from the seed to the addresses of both scopes.

Refer to caption
Figure 1: Derivation of the keys of one account, from the seed S through the master key and the hardened levels 32′, 𝑐𝑜𝑖𝑛⁢_⁢𝑡𝑦𝑝𝑒′ and a′ to the account spending key 𝗌𝗄𝖺𝖼𝖼𝗍, whose chain code is dropped; then the key components, the full viewing key 𝖿𝗏𝗄, the internal full viewing key 𝖿𝗏𝗄𝗂𝗇𝗍, the incoming and outgoing viewing keys of each scope, and the addresses at each index j. Solid edges are those of a key with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾; dashed edges are the 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 sources of 𝖺𝗄ℙ, an input, and of 𝗋𝗂𝗏𝗄, through 𝗊𝗌𝗄 and 𝗊𝗄. Each derivation edge carries its expansion byte or operation; unlabelled edges are projections into a tuple or inputs. Each one-way edge also carries the assumption under which it is one-way: PRF, the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” (§“Pseudorandom functions and field reductions”); RO, a random oracle (BLAKE2b under ZcashIP32Orchard for 𝖬𝖪𝖦, 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 for the diversified base); DL, its Assumption “Discrete logarithms on Pallas”; JH2, the joint hiding assumption of both scopes stated in §2.5. Colours give the lowest key tier that computes a node. The separations the figure depicts are proved in §2.5.
Example 2.8 (The account path of a fixed seed).

Let S be the 32 bytes 𝟶⁢𝚡⁢𝟶𝟶,𝟶⁢𝚡⁢𝟶𝟷,…,𝟶⁢𝚡⁢𝟷⁢𝚏, on Mainnet (coin type 133), account 0. The pairs (𝗌𝗄,𝖼) along the path, in hexadecimal, are:

Node Value
m 𝗌𝗄 7eee3c1017870990a3dd6891b82f80be8976c1e7dc20d60817a5e88e8b2cd4b8
𝖼 ab8b7a00509ef20e469b5292b61d474b7cffcb1657924cda720250ae40526677
m/32′ 𝗌𝗄 93af0a87c2e4704d8825e145557c6a5d4dcbc9016170e276a2080a2dc9eb0f87
𝖼 6e1e808d410d6d1f84e62e67c8b60e80e5ee4de5021d575c0433a625d609c45c
m/32′/133′ 𝗌𝗄 149fcee594a2a03de277ab919f22611d0ef6aa8e8e9a0bef32f01a0bcb0e8c4c
𝖼 07d13fdeccd21da16b467f8e785edc32f74ceeb541bede0394647f10fdb7114f
m/32′/133′/0′ 𝗌𝗄 b67d8d87cab9189500afb45dbca9f92c924c1de9d9ee1451be4a78313cb223b4
𝖼 7ff0a6392e144d4c8f45bca21fb7827b508446ac069890aefbebbe388b7a84c0

The last spending key is 𝗌𝗄𝖺𝖼𝖼𝗍, and it is valid in the sense of §2.6; the last chain code is 𝖼𝖺𝖼𝖼𝗍, which no construction uses. The master spending key agrees with the first Orchard test vector of ZIP 32, “Test Vectors”.

2.4 Orchard key components of an account

The Ironwood Guide constructs from a spending key 𝗌𝗄 the components 𝖺𝗌𝗄, 𝗇𝗄 and 𝗋𝗂𝗏𝗄 (§“The spending key and the spend-side secrets”), the spend validating key 𝖺𝗄ℙ and its coordinate 𝖺𝗄 (same subsection), the full viewing key 𝖿𝗏𝗄=(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄), the incoming viewing key scalar 𝗂𝗏𝗄=𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝗂𝗏𝗄𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄), and (𝖽𝗄,𝗈𝗏𝗄) as the two halves of

𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽LE256⁢(𝗋𝗂𝗏𝗄)⁢([𝟶⁢𝚡⁢𝟾𝟸]⁢‖𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝖺𝗄)‖⁢𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝗇𝗄))

(§“Viewing keys”), and the diversified addresses (§“Diversified addresses”). These constructions are the 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾 branch (Ironwood Guide, §“The spending key and the spend-side secrets”, Remark “Scope of the key derivations”; protocol specification, §“Orchard Key Components”). They are cited, not restated; this subsection supplies 𝗌𝗄:=𝗌𝗄𝖺𝖼𝖼𝗍 and the 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 branch.

Lemma 2.9 (Account keys as uniform spending keys).

Let R be a result of the Ironwood Guide about a key generated with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾, stated as a bound on the probability of a win event W in a game G whose challenger receives the output 𝗌𝗄 of key generation (Ironwood Guide, §“The spending key and the spend-side secrets”, Definition “Spending key and key generation”), runs in time polynomial given 𝗌𝗄, and decides W. Let G𝖺𝖼𝖼𝗍 be G with 𝗌𝗄:=𝗌𝗄𝖺𝖼𝖼𝗍 at a fixed account path, the adversary 𝒜 also receiving 𝖲𝖾𝖾𝖽𝖥𝖯⁢(S) and the spending keys at a fixed finite set of other account paths, and let V be the event that 𝗌𝗄𝖺𝖼𝖼𝗍 passes the discard conditions of that Definition (made exact in §2.6). Let ℬ be the adversary of G that samples those extra inputs as independent uniform 32-byte strings, answers the random-oracle queries of 𝒜 by lazy sampling, and runs 𝒜. Then

|Pr⁢[W⁢ in ⁢G𝖺𝖼𝖼𝗍∣V]−Pr⁢[ℬ⁢ wins ⁢G]|≤2⁢δ1−ρ−δ,

where δ is the advantage bound of Lemma 2.5 for the distinguisher of the proof and ρ is the probability that a single draw from a uniform 𝗌𝗄 is discarded, negligible by the Ironwood Guide’s Lemma “Rejection in key generation” (§“Viewing keys”); the bound assumes ρ+δ<1. Every key-side result of the Ironwood Guide therefore holds for 𝗌𝗄𝖺𝖼𝖼𝗍 up to this loss.

Proof.

The key 𝗌𝗄𝖺𝖼𝖼𝗍 is only computationally close to uniform, so the statistical-distance clause of the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (§“Pseudorandom functions and field reductions”) does not apply; the proof is a reduction. Both V and W are decided efficiently by the challenger. A distinguisher for Lemma 2.5 receives either the real values (𝗌𝗄𝖺𝖼𝖼𝗍, the other spending keys and 𝖲𝖾𝖾𝖽𝖥𝖯⁢(S)) or independent uniform strings, runs the challenger and 𝒜 on them, and outputs 1 exactly on W∧V; a second distinguisher outputs 1 exactly on V. Write a:=Pr⁢[W∧V] and v:=Pr⁢[V] for the real values, and au, vu for the uniform ones. Then |a−au|≤δ and |v−vu|≤δ, with vu=1−ρ. With uniform inputs, the extra inputs are independent of the key and distributed as ℬ samples them. Key generation outputs a single uniform draw conditioned on acceptance, so Pr⁢[ℬ⁢ wins ⁢G]=au/vu. Hence

|av−auvu|≤|a−au|v+auvu⋅|vu−v|v≤2⁢δv≤2⁢δ1−ρ−δ,

using au≤vu and v≥vu−δ. □

Construction 2.10 (Key components under use_qsk).

The flag 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄∈{𝖿𝖺𝗅𝗌𝖾,𝗍𝗋𝗎𝖾} is chosen at key generation. For a spending key 𝗌𝗄, in both branches

𝗇𝗄:=ToBase⁢(𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝗌𝗄⁢([𝟶⁢𝚡⁢𝟶𝟽])).
  1. 1.

    If 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾: 𝖺𝗌𝗄, 𝖺𝗄ℙ, 𝖺𝗄 and 𝗋𝗂𝗏𝗄 are those of the Ironwood Guide, and 𝗊𝗌𝗄=𝗊𝗄=⊥.

  2. 2.

    If 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾: a spend validating key 𝖺𝗄ℙ∈ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌)∖{𝒪} with even y-coordinate, that is, with bit 255 of its star encoding equal to 0, is an input, obtained by a method outside this construction, for example a directly generated 𝖺𝗌𝗄 with 𝖺𝗄ℙ=[𝖺𝗌𝗄]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁, or FROST distributed key generation. Then

    𝖺𝗄 :=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(𝖺𝗄ℙ),
    𝗊𝗌𝗄 :=𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾32⁢(𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝗌𝗄⁢([𝟶⁢𝚡⁢𝟶⁢𝙲])),
    𝗊𝗄 :=𝖡𝖫𝖠𝖪𝖤𝟥.𝖽𝖾𝗋𝗂𝗏𝖾⁢_⁢𝗄𝖾𝗒⁢(Zcash ZIP 2005 qk-derivation v1,𝗊𝗌𝗄, 32),
    𝗋𝗂𝗏𝗄 :=ToScalar⁢(𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝗊𝗄⁢([𝟶⁢𝚡⁢𝟶⁢𝙳]⁢‖𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝖺𝗄)‖⁢𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝗇𝗄))),

    where 𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾32 keeps the first 32 bytes and 𝖡𝖫𝖠𝖪𝖤𝟥.𝖽𝖾𝗋𝗂𝗏𝖾⁢_⁢𝗄𝖾𝗒⁢(𝑐𝑜𝑛𝑡𝑒𝑥𝑡,𝑚𝑎𝑡𝑒𝑟𝑖𝑎𝑙,𝑙𝑒𝑛𝑔𝑡ℎ) is the function that ZIP 2005 specifies, cited to it and not constructed; no property of it is assumed.

The components 𝗂𝗏𝗄, 𝖽𝗄, 𝗈𝗏𝗄 and every address are computed from (𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄) by the Ironwood Guide’s constructions in both branches, so they depend on 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄 (ZIP 2005, “Changes to the Protocol Specification”, §4.2.3 “Orchard Key Components”, and “Usage with FROST”). No edition of the protocol specification carries this branch.

Wallet rules. A wallet MUST generate every key of one ZIP 32 account with the same value of 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄 (ZIP 326, “Wallet key-generation restrictions”). The rule of the same section on Orchard-pool funds and 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 keys is stated once, with routing (§11.2). The value of 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄 is not part of the recovery information, so a wallet restoring from a seed scans with both values (ZIP 326, “Scanning when restoring from seed”; §6.2).

Class (Definition 1.1): how an account whose keys are to be recoverable from the seed with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 derives 𝖺𝗄ℙ from 𝗌𝗄𝖺𝖼𝖼𝗍 is fixed by no ZIP; it is designed but unspecified.

Remark 2.11 (Scope of the key results).

Lemma 2.9 and every later key-side result of this volume (separations, hiding, validity bounds) is claimed for 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾 only. For 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 the trapdoor 𝗋𝗂𝗏𝗄 is an expansion keyed by 𝗊𝗄, and a result would need BLAKE3 in its key-derivation mode modelled as a PRF, which is not assumed, and a hypothesis on the source of 𝖺𝗄ℙ. Constructive statements, which state what is computed from what, hold in both branches.

Proposition 2.12 (Key recoverability).

For 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾, every spending, full viewing, incoming viewing and outgoing viewing key and every address of an account is a deterministic function of the seed, the coin type, the account index, the scope and the diversifier index; the seed with the account index recovers all of them. For 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 the same holds of 𝗇𝗄, 𝗊𝗌𝗄 and 𝗊𝗄, and, given 𝖺𝗄, of 𝗋𝗂𝗏𝗄, 𝗂𝗏𝗄, 𝖽𝗄, 𝗈𝗏𝗄 and every address; recovery needs 𝖺𝗄 in addition, and, to spend, the key material that signs under 𝖺𝗄, held collectively by the signers under FROST. In both cases the wallet must know the account’s value of 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄 or try both. The function is partial: it is undefined at an account index whose key is invalid (§2.6).

Proof.

Composition of Constructions 2.3 and 2.4 and Definition 2.7, which map the seed to 𝗌𝗄𝖺𝖼𝖼𝗍; of Construction 2.10, which maps 𝗌𝗄𝖺𝖼𝖼𝗍 and 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄, together with 𝖺𝗄ℙ when 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾, to (𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄); and of the Ironwood Guide’s constructions from (𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄) (§“Viewing keys” and §“Diversified addresses”). The keys of the internal scope are a function of 𝖿𝗏𝗄 (§2.5), and the composition only adds that function. ZIP 2005, “Changes to the Protocol Specification”, §4.2.3 “Orchard Key Components”, notes, and “Usage with FROST” state the same requirements for recovery. □

Construction 2.13 (Full viewing key fingerprint and tag).

For a full viewing key (𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄) of either branch,

𝖥𝖵𝖥𝖯(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄):=BLAKE2b-256( ZcashOrchardFVFP,
𝖨𝟤𝖫𝖤𝖮𝖲𝖯256(𝖺𝗄)∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256(𝗇𝗄)∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256(𝗋𝗂𝗏𝗄)),

over the 96-byte string shown, which is the raw encoding of an Orchard full viewing key (protocol specification, §“Orchard Raw Full Viewing Keys”). It MAY be used to identify the key uniquely; its uses rely on collision resistance, cited as for Construction 2.2; Lemma 2.24 models it as a random oracle. The tag is 𝖥𝖵𝖥𝖯[0..4), its first 4 bytes; it serves key lookup and MUST NOT be assumed unique, and nothing is claimed of it (ZIP 32, “Orchard Full Viewing Key Fingerprints and Tags”). In ZIP 32’s encoding of an extended spending key, a key names its parent by this tag, the master key’s parent tag being four zero bytes (ZIP 32, “Orchard extended spending keys”).

2.5 Internal keys: change and auto-shielding

With no change level, the separation between externally visible receipt and wallet-internal operations runs below the account. The internal operations are change and auto-shielding, the automatic transfer of received transparent funds to the most recent shielded pool (ZIP 315, “Terminology”; its rules in §11.3). The derivation applies to keys at the account level (ZIP 32, “Orchard internal key derivation”).

Construction 2.14 (Internal full viewing key).

For a full viewing key 𝖿𝗏𝗄=(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄) let K:=LE256⁢(𝗋𝗂𝗏𝗄), written 𝖨𝟤𝖫𝖤𝖡𝖲𝖯256⁢(𝗋𝗂𝗏𝗄) in ZIP 32, and

𝗋𝗂𝗏𝗄𝗂𝗇𝗍:=ToScalar⁢(𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽K⁢([𝟶⁢𝚡⁢𝟾𝟹]⁢‖𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝖺𝗄)‖⁢𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝗇𝗄)))∈𝔽p𝖵𝖾𝗌𝗍𝖺.

The internal full viewing key is 𝖿𝗏𝗄𝗂𝗇𝗍:=(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄𝗂𝗇𝗍). The internal keys are 𝗂𝗏𝗄𝗂𝗇𝗍:=𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝗂𝗏𝗄𝗂𝗇𝗍𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄) and (𝖽𝗄𝗂𝗇𝗍,𝗈𝗏𝗄𝗂𝗇𝗍), the two halves of the 𝟶⁢𝚡⁢𝟾𝟸 expansion keyed by LE256⁢(𝗋𝗂𝗏𝗄𝗂𝗇𝗍) over the same message. The input of the 𝟶⁢𝚡⁢𝟾𝟹 expansion has the key and message body of the 𝟶⁢𝚡⁢𝟾𝟸 expansion and another lead byte. The internal expanded spending key is (𝖺𝗌𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄𝗂𝗇𝗍); no 32-byte internal spending key exists (ZIP 32, “Orchard internal key derivation”; protocol specification, §“Orchard Key Components”).

Hence 𝖺𝗄𝗂𝗇𝗍=𝖺𝗄 and 𝗇𝗄𝗂𝗇𝗍=𝗇𝗄, as the protocol specification, §“Orchard Key Components”, notes: spend authorisation and nullifier derivation serve both scopes, and 𝗂𝗏𝗄, 𝖽𝗄 and 𝗈𝗏𝗄 are derived again from 𝗋𝗂𝗏𝗄𝗂𝗇𝗍. The construction does not force the keys of the two scopes to differ; their equality is an event of negligible probability (Proposition 2.17), not an excluded case. For Sapling, ZIP 32 keeps the spend authorising key and derives again the key that enters the proof and the nullifier, the outgoing viewing key and the diversifier key, so the two scopes share spend authority and differ in the key that enters the proof and the nullifier (ZIP 32, “Sapling internal key derivation”); this is cited, not constructed. Payments are sent from an account and a scope, not from an address: no outgoing viewing key per diversified address exists (ZIP 32, “Orchard diversifier and OVK derivation”; ZIP 316, “Usage of Outgoing Viewing Keys”).

Proposition 2.15 (Capability of a full viewing key).

From 𝖿𝗏𝗄 alone one computes, for both scopes, 𝗂𝗏𝗄, 𝖽𝗄, 𝗈𝗏𝗄 and the address at every diversifier index j∈{0,…,288−1}. For a key with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾, no efficient algorithm given 𝖿𝗏𝗄 outputs 𝖺𝗌𝗄, and no efficient algorithm given the keys of one account outputs the spending key of another account, except with negligible probability. Recovering the index and scope of a given address is stated with the index (§3.1).

Proof.

Computation: 𝖿𝗏𝗄𝗂𝗇𝗍 is a function of 𝖿𝗏𝗄 (Construction 2.14), and each address is a function of (𝖽𝗄,𝗂𝗏𝗄) and j (Ironwood Guide, §“Diversified addresses”, Construction “Diversified address”). No 𝖺𝗌𝗄: the Ironwood Guide, §“Key capabilities and scope”, Proposition “Capability separation”, part (a), under its Assumptions “Pseudorandomness of PRF expansion” and “Discrete logarithms on Pallas”, transferred to 𝗌𝗄𝖺𝖼𝖼𝗍 by Lemma 2.9. No other account: the spending key of another account lies at a distinct path, and only hardened derivation exists; by Lemma 2.5 the two keys are jointly indistinguishable from independent uniform strings, so an algorithm given every key of this account outputs the other key with probability at most 2−256 plus the advantage bound of that lemma. □

Assumption 2.16 (Joint hiding of the viewing keys of both scopes).

For keys with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾: for every (𝖺𝗄,𝗇𝗄)∈{1,…,p𝖯𝖺𝗅𝗅𝖺𝗌−1}×𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, given to the distinguisher, and 𝗋𝗂𝗏𝗄 uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺, the six keys (𝗂𝗏𝗄,𝖽𝗄,𝗈𝗏𝗄,𝗂𝗏𝗄𝗂𝗇𝗍,𝖽𝗄𝗂𝗇𝗍,𝗈𝗏𝗄𝗂𝗇𝗍), computed by the Ironwood Guide’s constructions and Construction 2.14, are computationally indistinguishable from

(𝖢𝗈𝗆𝗆𝗂𝗍r𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄),u1,u2,𝖢𝗈𝗆𝗆𝗂𝗍r′𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄),u3,u4),

where r and r′ are uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺 and u1,…,u4 are uniform 32-byte strings, all independent. It extends the Ironwood Guide’s Assumption “Joint hiding of the viewing keys” (§“Viewing keys”), which covers the external triple only, to the 𝟶⁢𝚡⁢𝟾𝟹 row, whose key LE256⁢(𝗋𝗂𝗏𝗄) is also the 𝖢𝗈𝗆𝗆𝗂𝗍𝗂𝗏𝗄 trapdoor of the external 𝗂𝗏𝗄 and so lies outside the hypothesis of the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (§“Pseudorandom functions and field reductions”) (Remark “Hiding of 𝗂𝗏𝗄 and the double use of 𝗋𝗂𝗏𝗄” (§“Viewing keys”)); the PRF assumption does not give it (protocol specification, §“Orchard Key Components”, note on 𝗋𝗂𝗏𝗄 as trapdoor and key). It is applied after Lemma 2.9, averaging over the key-generation distribution of (𝖺𝗄,𝗇𝗄).

Proposition 2.17 (Separation of scopes under trial decryption).

Let an account key have 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾, with external and internal incoming viewing keys outside {0,⊥}. An output honestly addressed to an internal-scope address of the account is accepted under the account’s external 𝗂𝗏𝗄 only with negligible probability, under the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas” (§“Sinsemilla: hash, commitment, and short forms”) and “GroupHash as a random oracle” (§“GroupHash, domain separation, and nothing-up-my-sleeve generators”), Assumption 2.16 and the hypotheses of Lemma 2.9. Consequently an external incoming viewing key reveals no change or auto-shielding output. Since 𝖿𝗏𝗄𝗂𝗇𝗍 is computable from 𝖿𝗏𝗄, a full viewing key reveals both scopes, and the boundary between the scopes lies at the incoming viewing tier.

Proof.

Acceptance under a key 𝗂𝗏𝗄 derives the transmission key again as [𝗂𝗏𝗄]⁢𝗀𝖽 from the decrypted diversifier and checks the note commitment of the derived note against 𝖼𝗆𝗑 (Ironwood Guide, §“Trial decryption and note acceptance”, Construction “Acceptance of an Ironwood-pool output”, check (iv); for an Orchard-pool output the check of the protocol specification, §“Decryption using an Incoming Viewing Key (Sapling and Orchard)”). The honest output commits to a note n with transmission key [𝗂𝗏𝗄𝗂𝗇𝗍]⁢𝗀𝖽. If the note n′ derived under 𝗂𝗏𝗄𝖾𝗑𝗍 differs from n, acceptance exhibits two distinct notes with one extracted commitment, which happens with negligible probability (Ironwood Guide, §“Note commitments”, Proposition “Hiding and binding of note commitments”, part (b)). If n′=n, then [𝗂𝗏𝗄𝖾𝗑𝗍]⁢𝗀𝖽=[𝗂𝗏𝗄𝗂𝗇𝗍]⁢𝗀𝖽; since 𝗀𝖽≠𝒪 in a group of prime order and both scalars lie in {1,…,p𝖯𝖺𝗅𝗅𝖺𝗌−1} with p𝖯𝖺𝗅𝗅𝖺𝗌<p𝖵𝖾𝗌𝗍𝖺, this forces 𝗂𝗏𝗄𝖾𝗑𝗍=𝗂𝗏𝗄𝗂𝗇𝗍 (Ironwood Guide, §“Viewing keys”). By Lemma 2.9 and Assumption 2.16 the pair is replaced by (𝖢𝗈𝗆𝗆𝗂𝗍r𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄),𝖢𝗈𝗆𝗆𝗂𝗍r′𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄)) with independent uniform r and r′, at the cost of the distinguishing advantage, since equality is efficiently decidable. By the Ironwood Guide’s Lemma “Distribution of 𝗂𝗏𝗄” (§“Viewing keys”), the second value equals any fixed value with probability at most 2/p𝖵𝖾𝗌𝗍𝖺, independently of the first, so the two are equal with probability at most 2/p𝖵𝖾𝗌𝗍𝖺. □

Construction 2.18 (Transparent outgoing viewing keys).

A P2PKH (pay-to-public-key-hash) output pays to the hash of one secp256k1 public key (Crypto Guide, §“The transparent layer’s schemes: ECDSA and BIP-340 over secp256k1”). P2PKH keys have no outgoing viewing key, yet auto-shielding outputs need one. For the BIP 32 account-level extended public key (𝖼,𝗉𝗄) of a transparent account, at path m/44′/𝑐𝑜𝑖𝑛⁢_⁢𝑡𝑦𝑝𝑒′/𝑎𝑐𝑐𝑜𝑢𝑛𝑡′ (BIP 44), let

I𝗈𝗏𝗄:=𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝖼⁢([𝟶⁢𝚡⁢𝙳⁢𝟶]∥𝗌𝖾𝗋P⁢(𝗉𝗄)),

with the chain code 𝖼 used as a 32-byte key and 𝗌𝖾𝗋P⁢(𝗉𝗄) the 33-byte compressed encoding of BIP 32; then 𝗈𝗏𝗄𝖾𝗑𝗍𝖾𝗋𝗇𝖺𝗅:=I𝗈𝗏𝗄[0..32) and 𝗈𝗏𝗄𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅:=I𝗈𝗏𝗄[32..64) (ZIP 316, “Deriving Internal Keys”). The external transparent incoming viewing key is the extended public key of the non-hardened child 0 of (𝖼,𝗉𝗄) and the internal one that of the non-hardened child 1 (ZIP 316, “Deriving a UIVK from a UFVK”; BIP 44), each obtained by BIP 32 public-to-public derivation, which is HMAC-SHA512 keyed by 𝖼 (BIP 32, “Public parent key → public child key”; Crypto Guide, §“PRFs from hash functions: length extension and keyed BLAKE2”).

Assumption 2.19 (Hiding of the transparent account key).

For an honestly generated account-level extended public key (𝖼,𝗉𝗄), the extended public keys of its non-hardened children 0 and 1 and the two halves of I𝗈𝗏𝗄 are jointly computationally indistinguishable from two independently generated extended public keys, each a uniform 32-byte chain code with the public key of a uniform secret key, and two independent uniform 32-byte strings. The chain code 𝖼 keys both HMAC-SHA512 in BIP 32 non-hardened derivation and 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽 in the 𝟶⁢𝚡⁢𝙳⁢𝟶 row, so this is not an instance of the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (§“Pseudorandom functions and field reductions”); it is assumed.

Proposition 2.20 (Capability separation of internal keys).

The following hold, where “derives” means outputs the key with non-negligible probability.

  1. (i)

    A holder of a full viewing key derives the external and internal incoming viewing keys and the external and internal outgoing viewing keys.

  2. (ii)

    A holder of the external incoming viewing key derives neither the internal incoming viewing key nor any outgoing viewing key.

  3. (iii)

    A holder of the external outgoing viewing key derives neither the internal outgoing viewing key nor any incoming viewing key.

For Orchard the statements hold for keys with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾 under Lemma 2.9 and Assumption 2.16; for Sapling they are the properties that ZIP 316, “Deriving Internal Keys”, states for the construction of ZIP 32, “Sapling internal key derivation”, and are cited, not proved; for transparent P2PKH keys under Assumption 2.19 (ZIP 316, “Deriving Internal Keys”).

Proof.

(i) Constructive: Construction 2.14 and the Ironwood Guide’s constructions; for transparent keys, Construction 2.18 from (𝖼,𝗉𝗄).

(ii) and (iii), Orchard: by Lemma 2.9 and Assumption 2.16 the six keys are replaced by the ideal distribution, at the cost of the distinguishing advantage, since success is decided by comparing the output with the key. In the ideal distribution every key not computed from the held one is independent of it: either a uniform 32-byte string, output with probability 2−256, or a 𝖢𝗈𝗆𝗆𝗂𝗍𝗂𝗏𝗄 value under an independent trapdoor, output with probability at most 2/p𝖵𝖾𝗌𝗍𝖺 (Ironwood Guide, §“Viewing keys”, Lemma “Distribution of 𝗂𝗏𝗄”). Transparent: the same argument in the ideal distribution of Assumption 2.19, where an independently generated extended public key has a uniform chain code, output with probability 2−256. Sapling: cited to ZIP 316, “Deriving Internal Keys”, which asserts them from the one-wayness of 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽 and 𝖢𝖱𝖧𝗂𝗏𝗄; not proved here. □

2.6 Valid account keys

Definition 2.21 (Valid account key).

For 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾, an account spending key 𝗌𝗄𝖺𝖼𝖼𝗍 is valid if and only if 𝖺𝗌𝗄≠0, 𝗂𝗏𝗄∉{0,⊥} and 𝗂𝗏𝗄𝗂𝗇𝗍∉{0,⊥}. The first two conditions are discard conditions of the Ironwood Guide, §“The spending key and the spend-side secrets”, Definition “Spending key and key generation”; the third is the specification’s condition on the internal key of Construction 2.14, which that Definition names without constructing (protocol specification, §“Orchard Key Components”; ZIP 32, “Orchard internal key derivation”). ZIP 2005 amends the derivation for 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 (“Changes to the Protocol Specification”, §4.2.3), for which this volume states no validity condition. Only keys a wallet uses need be valid; intermediate path nodes are never expanded into components.

Remark 2.22 (Derivation failure).

ZIP 32 notes that a child spending key yields an invalid external or internal full viewing key “with small probability” and prescribes no wallet behaviour (“Orchard child key derivation”). The specification’s instruction to discard the key and repeat with a new 𝗌𝗄 applies to a freshly random key, not to a fixed path, where nothing is drawn again: an account index whose key is invalid has no key. Class (Definition 1.1): the wallet’s handling of such an index is an open problem; Proposition 2.23 bounds its probability.

Proposition 2.23 (Probability of an invalid account key).

Model the Sinsemilla generators, the initial point Q:=Q⁢(z.cash:Orchard-CommitIvk-M) and the points S⁢(j) for 0≤j<210, as independent uniform points of the Pallas group, independent of every other quantity (Ironwood Guide, §“GroupHash, domain separation, and nothing-up-my-sleeve generators”, Assumption “GroupHash as a random oracle”). Let

ε:=3⁢⌈2512/p𝖵𝖾𝗌𝗍𝖺⌉2512+408p𝖵𝖾𝗌𝗍𝖺<412p𝖵𝖾𝗌𝗍𝖺=2−245.31.

For 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾 and a fixed account path, Pr⁢[𝗌𝗄𝖺𝖼𝖼𝗍⁢ is invalid]≤ε+δ, where δ is the sum of the advantages of efficient reductions, each deciding validity, against Lemma 2.5, the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” (§“Pseudorandom functions and field reductions”) (rows 𝟶⁢𝚡⁢𝟶𝟼, 𝟶⁢𝚡⁢𝟶𝟽 and 𝟶⁢𝚡⁢𝟶𝟾) and Assumption 2.16 (row 𝟶⁢𝚡⁢𝟾𝟹), plus the statistical distance of ToScalar from uniform, below 2−257 (Ironwood Guide, §“Pseudorandom functions and field reductions”). For the n accounts a wallet uses, Pr⁢[some key is invalid]≤n⁢ε+δn, where δn is the corresponding sum for the n paths jointly; the union runs over the keys used, not over path nodes. The bound averages over generators modelled as random and is not a frequency for the fixed deployed generators.

Proof.

Replace 𝗌𝗄𝖺𝖼𝖼𝗍 by a uniform string (Lemma 2.5); the 512-bit outputs of rows 𝟶⁢𝚡⁢𝟶𝟼, 𝟶⁢𝚡⁢𝟶𝟽 and 𝟶⁢𝚡⁢𝟶𝟾 by independent uniform strings (the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (§“Pseudorandom functions and field reductions”), first conclusion); 𝗋𝗂𝗏𝗄 by a uniform element of 𝔽p𝖵𝖾𝗌𝗍𝖺 (the reduction distance); and, on the event 𝖺𝗌𝗄≠0, the pair (𝗂𝗏𝗄,𝗂𝗏𝗄𝗂𝗇𝗍) by (𝖢𝗈𝗆𝗆𝗂𝗍r𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄),𝖢𝗈𝗆𝗆𝗂𝗍r′𝗂𝗏𝗄⁢(𝖺𝗄,𝗇𝗄)) with independent uniform r and r′ (Assumption 2.16). Each replacement changes the probability of invalidity by at most one term of δ, since validity is efficiently decidable. Then, by the union bound (Math Guide, §“The union bound and a birthday calculation”, Theorem “Union bound / Boole’s inequality”), the key is invalid only on one of the following events.

  1. (a)

    𝖺𝗌𝗄=0. The sign normalisation preserves 0, so this happens exactly when a uniform 512-bit integer is divisible by p𝖵𝖾𝗌𝗍𝖺, with probability ⌈2512/p𝖵𝖾𝗌𝗍𝖺⌉/2512 (Math Guide, §“Uniform sampling and the bias of modular reduction”).

  2. (b)

    The Sinsemilla hash point M^ of the message LE255⁢(𝖺𝗄)∥LE255⁢(𝗇𝗄) is ⊥. The message has 510 bits, 51 chunks of 10 bits, so the hash performs 102 incomplete additions, two per round, 𝖠𝖼𝖼i:=(𝖠𝖼𝖼i−1∔S⁢(mi))∔𝖠𝖼𝖼i−1 (protocol specification, §“Sinsemilla Hash Function”; Ironwood Guide, §“Sinsemilla: hash, commitment, and short forms”, Construction “Sinsemilla hash on Pallas”). An incomplete addition A∔B of points is exceptional exactly when A=𝒪, B=𝒪, A=B or A=−B. At the first exceptional addition every accumulator so far equals its formal value, an integer combination of Q and the S⁢(j), so one of four linear relations among the generators holds. Each relation is nontrivial: it either states that the single generator S⁢(mi) is 𝒪, or gives Q a coefficient 2t or 2t+1, non-zero modulo the odd prime p𝖵𝖾𝗌𝗍𝖺. The message depends only on (𝖺𝗌𝗄,𝗇𝗄) and G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁, which are independent of Q and the S⁢(j), so each relation holds with probability 1/p𝖵𝖾𝗌𝗍𝖺, and the 102 additions cost at most 408/p𝖵𝖾𝗌𝗍𝖺. Both scopes commit to the same message, so this event is counted once.

  3. (c)

    𝗂𝗏𝗄=0 with M^≠⊥. The addition of [r]⁢HD is complete, and 𝗂𝗏𝗄=0 exactly when M^+[r]⁢HD=𝒪 (Ironwood Guide, §“Fields, groups, and encodings”, Lemma “Extract vanishes only at the identity”), which, since HD≠𝒪, holds for a single value of r: probability 1/p𝖵𝖾𝗌𝗍𝖺≤⌈2512/p𝖵𝖾𝗌𝗍𝖺⌉/2512.

  4. (d)

    𝗂𝗏𝗄𝗂𝗇𝗍=0 with M^≠⊥: likewise, under the independent r′, with the same bound.

The sum is ε. Negligibility alone is the Ironwood Guide’s Lemma “Rejection in key generation” (§“Viewing keys”). For n accounts, apply the replacements to the n paths jointly and the union bound over the n keys; path nodes that are not account keys are never expanded into components and do not enter the union. □

2.7 The 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽 lead-byte registry

Domain separation of 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽 is per key: under one key, distinct lead bytes give jointly pseudorandom outputs (Ironwood Guide, §“Pseudorandom functions and field reductions”, Lemma “Independence of domain-separated expansions”), while expansions under different keys may reuse a byte. Byte conventions: the key that ZIP 32 writes 𝖨𝟤𝖫𝖤𝖡𝖲𝖯256⁢(𝗋𝗂𝗏𝗄) is LE256⁢(𝗋𝗂𝗏𝗄); the bytes of 𝖺𝗄 are 𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝖺𝗄) of the field element 𝖺𝗄=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(𝖺𝗄ℙ), which for the sign-normalised 𝖺𝗄ℙ equals the byte form 𝖫𝖤𝖡𝖲𝟤𝖮𝖲𝖯256 of its star encoding, bit 255 being 0 (Ironwood Guide, §“The spending key and the spend-side secrets”); the key 𝗇𝗄 enters as 𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝗇𝗄) (protocol specification, §“Orchard Key Components”).

Table 2 lists the expansions and personalisations that this volume constructs. The expansions of the key components and of notes are the rows of the Ironwood Guide’s Construction “Domain bytes of PRF expansion” (§“Pseudorandom functions and field reductions”) and are not restated. The list of expansion bytes that the protocol specification maintains, as amended by ZIP 2005, is §“Pseudo Random Functions” (ZIP 2005, “Changes to the Protocol Specification”, §4.1.2); bytes this volume does not use are not listed.

Byte Key Message Output Constructed in
𝟶⁢𝚡⁢𝟾𝟷 𝖼𝗉𝖺𝗋 𝗌𝗄𝗉𝖺𝗋∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯32⁢(i) (𝗌𝗄i,𝖼i) Constr. 2.4
𝟶⁢𝚡⁢𝟾𝟹 LE256⁢(𝗋𝗂𝗏𝗄) 𝖨𝟤𝖫𝖤𝖮𝖲𝖯256(𝖺𝗄)∥
𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝗇𝗄)
𝗋𝗂𝗏𝗄𝗂𝗇𝗍 (ToScalar) Constr. 2.14
𝟶⁢𝚡⁢𝟶⁢𝙲 𝗌𝗄 ε (empty) 𝗊𝗌𝗄 (𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾32) Constr. 2.10
𝟶⁢𝚡⁢𝟶⁢𝙳 𝗊𝗄 𝖨𝟤𝖫𝖤𝖮𝖲𝖯256(𝖺𝗄)∥
𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(𝗇𝗄)
𝗋𝗂𝗏𝗄 if 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝗍𝗋𝗎𝖾 (ToScalar) Constr. 2.10
𝟶⁢𝚡⁢𝙳⁢𝟶 transparent chain code 𝖼 𝗌𝖾𝗋P⁢(𝗉𝗄) 𝗈𝗏𝗄𝖾𝗑𝗍𝖾𝗋𝗇𝖺𝗅∥𝗈𝗏𝗄𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅 Constr. 2.18
Personalisation Function Output Constructed in
ZcashIP32Orchard BLAKE2b⁢-⁢512 of S (𝗌𝗄m,𝖼m) Constr. 2.3
Zcash_HD_Seed_FP BLAKE2b⁢-⁢256 of [length⁢(S)]∥S 𝖲𝖾𝖾𝖽𝖥𝖯⁢(S) Constr. 2.2
ZcashOrchardFVFP BLAKE2b⁢-⁢256 of the 96-byte encoding of 𝖿𝗏𝗄 𝖥𝖵𝖥𝖯 Constr. 2.13
Table 2: Domains of key derivation. Upper part: each expansion 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽key⁢(b∥message) that this volume constructs, with its lead byte b, key, message and output; the rows 𝟶⁢𝚡⁢𝟶⁢𝙲 and 𝟶⁢𝚡⁢𝟶⁢𝙳 are those of ZIP 2005. Lower part: the 16-byte BLAKE2b personalisations of key derivation, with the function, output and constructing environment of each.
Lemma 2.24 (Independence of the key-derivation domains).

Under the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” (§“Pseudorandom functions and field reductions”), with BLAKE2b under distinct personalisations modelled as independent random oracles, the expansions of rows 𝟶⁢𝚡⁢𝟾𝟷 and 𝟶⁢𝚡⁢𝟶⁢𝙲, whose keys (a chain code of the Orchard tree, and 𝗌𝗄𝖺𝖼𝖼𝗍) are pseudorandom by Lemma 2.5 and enter no function other than 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽, and the three personalised BLAKE2b functions of Table 2 are jointly indistinguishable from independent random functions. The lemma excludes the other rows, each outside the hypothesis of the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (§“Pseudorandom functions and field reductions”): the row 𝟶⁢𝚡⁢𝟾𝟹, whose key is also the 𝖢𝗈𝗆𝗆𝗂𝗍𝗂𝗏𝗄 trapdoor, is covered by Assumption 2.16; the row 𝟶⁢𝚡⁢𝙳⁢𝟶, whose key also keys HMAC-SHA512, by Assumption 2.19; the row 𝟶⁢𝚡⁢𝟶⁢𝙳, keyed by the BLAKE3 output 𝗊𝗄 of which nothing is assumed (Remark 2.11), carries no claim.

Proof.

For each key, the Ironwood Guide’s Lemma “Independence of domain-separated expansions” (§“Pseudorandom functions and field reductions”), applied after the hybrid of Lemma 2.5 has made the keys uniform; this is a reduction, as in Lemma 2.9, not the statistical-distance clause of that lemma. For the three personalisations, the Crypto Guide’s Proposition “Domain separation yields independent oracles” (§“Domain separation and personalisation”): they are pairwise distinct 16-byte strings, and the two BLAKE2b-256 uses and the BLAKE2b-512 use differ also in the output length, a parameter of BLAKE2b. The proof of Lemma 2.5 uses the same two citations directly. □