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.
A wallet seed is a byte string with , where is its length in bytes (MUST). The method that generates MUST give it at least bits of entropy; the requirement extends to any mnemonic or input randomness from which is obtained (ZIP 32, “Specification: Wallet seeds”). Every key of every account of the wallet is derived from : the account spending key in §2.3, and what recovery needs beyond in §2.4.
Every key of every account is a deterministic function of , 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”).
For a wallet seed , the seed fingerprint is
unkeyed BLAKE2b with a -byte output and the -byte personalisation shown, over the single length byte of followed by ; the length fits one byte because . 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 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.
ZIP 32 instantiates its hardened-only derivation for Orchard with the master-key domain ZcashIP32Orchard, a -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 -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 . 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 write .
For a parent extended spending key and an index : if , derivation fails; otherwise
a -byte string, and . Here is the -byte little-endian encoding of , and 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.
Assume the following.
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 that is modelled as a random oracle.
The seed has min-entropy at least bits, the reading of the entropy requirement of Definition 2.1 that the lemma uses.
The Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” (§“Pseudorandom functions and field reductions”) holds.
Let be a fixed finite set of distinct nodes of the Orchard derivation tree rooted at , each reached by Construction 2.4 along hardened indices, and let be the subtree spanned by the paths from the root to the nodes of . Then the spending keys of the nodes of , the chain codes of those nodes of that are not a proper ancestor of another node of , and are jointly computationally indistinguishable from independent uniform -byte strings. For an adversary making random-oracle queries, the distinguishing advantage is at most plus one PRF advantage for each node of whose chain code keys a derivation in ; there are at most as many such nodes as has edges.
A hybrid argument (Crypto Guide, §“The hybrid argument”, Lemma “Hybrid lemma”). Game is the real experiment. Game answers every oracle query whose input is determined by (the master query of Construction 2.3, the input of and the inputs of the other modelled derivations) by fresh uniform strings, independent of . The two games differ only if the adversary itself queries such an input. In Game its view is independent of until that happens, so each of its queries does so with probability at most by hypothesis (ii), and the games differ by at most . In Game the pair and are independent uniform strings.
Then visit the nodes of that have a child in , each parent before its children. At such a node the chain code is, by the earlier hops, a uniform string that is used only as a key and is not released, because is a proper ancestor of a node of . The hop replaces by a uniformly random function. The children of in have distinct indices, hence distinct inputs , so their -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 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. □
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 -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.
For a wallet seed , a coin type and an account index ,
the path . The purpose index is , following BIP 43; the coin type is the SLIP 44 value, on Mainnet and on Testnet, every test network sharing the value ; accounts are numbered sequentially from , 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 , MUST support generating the default payment address, at diversifier index , 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 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.
Let be the bytes , on Mainnet (coin type ), account . The pairs along the path, in hexadecimal, are:
| Node | Value | |
|---|---|---|
| 7eee3c1017870990a3dd6891b82f80be8976c1e7dc20d60817a5e88e8b2cd4b8 | ||
| ab8b7a00509ef20e469b5292b61d474b7cffcb1657924cda720250ae40526677 | ||
| 93af0a87c2e4704d8825e145557c6a5d4dcbc9016170e276a2080a2dc9eb0f87 | ||
| 6e1e808d410d6d1f84e62e67c8b60e80e5ee4de5021d575c0433a625d609c45c | ||
| 149fcee594a2a03de277ab919f22611d0ef6aa8e8e9a0bef32f01a0bcb0e8c4c | ||
| 07d13fdeccd21da16b467f8e785edc32f74ceeb541bede0394647f10fdb7114f | ||
| 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”.
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
(§“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.
Let be a result of the Ironwood Guide about a key generated with , stated as a bound on the probability of a win event in a game 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 . Let be with at a fixed account path, the adversary also receiving and the spending keys at a fixed finite set of other account paths, and let be the event that passes the discard conditions of that Definition (made exact in §2.6). Let be the adversary of that samples those extra inputs as independent uniform -byte strings, answers the random-oracle queries of by lazy sampling, and runs . Then
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 . Every key-side result of the Ironwood Guide therefore holds for up to this loss.
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 and are decided efficiently by the challenger. A distinguisher for Lemma 2.5 receives either the real values (, the other spending keys and ) or independent uniform strings, runs the challenger and on them, and outputs exactly on ; a second distinguisher outputs exactly on . Write and for the real values, and , for the uniform ones. Then and , with . 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 . Hence
using and . □
The flag is chosen at key generation. For a spending key , in both branches
If : , , and are those of the Ironwood Guide, and .
If : a spend validating key with even -coordinate, that is, with bit of its star encoding equal to , is an input, obtained by a method outside this construction, for example a directly generated with , or FROST distributed key generation. Then
where keeps the first 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.
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.
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).
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. □
For a full viewing key of either branch,
over the -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 , its first 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”).
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”).
For a full viewing key let , written in ZIP 32, and
The internal full viewing key is . The internal keys are and , the two halves of the expansion keyed by 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 -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”).
From alone one computes, for both scopes, , , and the address at every diversifier index . 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).
Computation: is a function of (Construction 2.14), and each address is a function of and (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 plus the advantage bound of that lemma. □
For keys with : for every , given to the distinguisher, and uniform on , the six keys , computed by the Ironwood Guide’s constructions and Construction 2.14, are computationally indistinguishable from
where and are uniform on and are uniform -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 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 .
Let an account key have , with external and internal incoming viewing keys outside . 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.
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 with transmission key . If the note derived under differs from , 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 , then ; since in a group of prime order and both scalars lie in with , this forces (Ironwood Guide, §“Viewing keys”). By Lemma 2.9 and Assumption 2.16 the pair is replaced by with independent uniform and , 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 , independently of the first, so the two are equal with probability at most . □
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 (BIP 44), let
with the chain code used as a -byte key and the -byte compressed encoding of BIP 32; then and (ZIP 316, “Deriving Internal Keys”). The external transparent incoming viewing key is the extended public key of the non-hardened child of and the internal one that of the non-hardened child (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”).
For an honestly generated account-level extended public key , the extended public keys of its non-hardened children and and the two halves of are jointly computationally indistinguishable from two independently generated extended public keys, each a uniform -byte chain code with the public key of a uniform secret key, and two independent uniform -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.
The following hold, where “derives” means outputs the key with non-negligible probability.
A holder of a full viewing key derives the external and internal incoming viewing keys and the external and internal outgoing viewing keys.
A holder of the external incoming viewing key derives neither the internal incoming viewing key nor any outgoing viewing key.
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”).
(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 -byte string, output with probability , or a value under an independent trapdoor, output with probability at most (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 . Sapling: cited to ZIP 316, “Deriving Internal Keys”, which asserts them from the one-wayness of and ; not proved here. □
For , an account spending key is valid if and only if , and . 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.
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.
Model the Sinsemilla generators, the initial point and the points for , 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
For and a fixed account path, , 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 from uniform, below (Ironwood Guide, §“Pseudorandom functions and field reductions”). For the accounts a wallet uses, , where is the corresponding sum for the 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.
Replace by a uniform string (Lemma 2.5); the -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 (the reduction distance); and, on the event , the pair by with independent uniform and (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.
. The sign normalisation preserves , so this happens exactly when a uniform -bit integer is divisible by , with probability (Math Guide, §“Uniform sampling and the bias of modular reduction”).
The Sinsemilla hash point of the message is . The message has bits, chunks of bits, so the hash performs incomplete additions, two per round, (protocol specification, §“Sinsemilla Hash Function”; Ironwood Guide, §“Sinsemilla: hash, commitment, and short forms”, Construction “Sinsemilla hash on Pallas”). An incomplete addition of points is exceptional exactly when , , or . At the first exceptional addition every accumulator so far equals its formal value, an integer combination of and the , so one of four linear relations among the generators holds. Each relation is nontrivial: it either states that the single generator is , or gives a coefficient or , non-zero modulo the odd prime . The message depends only on and , which are independent of and the , so each relation holds with probability , and the additions cost at most . Both scopes commit to the same message, so this event is counted once.
with . The addition of is complete, and exactly when (Ironwood Guide, §“Fields, groups, and encodings”, Lemma “Extract vanishes only at the identity”), which, since , holds for a single value of : probability .
with : likewise, under the independent , with the same bound.
The sum is . Negligibility alone is the Ironwood Guide’s Lemma “Rejection in key generation” (§“Viewing keys”). For accounts, apply the replacements to the paths jointly and the union bound over the keys; path nodes that are not account keys are never expanded into components and do not enter the union. □
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 is ; the bytes of are of the field element , which for the sign-normalised equals the byte form of its star encoding, bit being (Ironwood Guide, §“The spending key and the spend-side secrets”); the key enters as (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 |
| Constr. 2.4 | ||||
|
|
() | Constr. 2.14 | ||
| (empty) | () | Constr. 2.10 | ||
|
|
if () | Constr. 2.10 | ||
| transparent chain code | Constr. 2.18 | |||
| Personalisation | Function | Output | Constructed in | |
| ZcashIP32Orchard | of | Constr. 2.3 | ||
| Zcash_HD_Seed_FP | of | Constr. 2.2 | ||
| ZcashOrchardFVFP | of the -byte encoding of | Constr. 2.13 | ||
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.
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 -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. □