V Ironwood Guide: The Zcash Orchard protocol and its Ironwood pool 3 Keys and addresses 5 The note commitment tree

4 Notes and note commitments

This section defines the note, its commitment and its extracted commitment, and proves their hiding and binding; it constructs the derivation of all randomness of a created note from one seed under the lead byte $\mathtt{0x03}$ , and defines the Action and the bundle as units of a transaction.

4.1 Notes

Definition 4.1 (Unit of value).

The zatoshi is the smallest unit of value; one ZEC, the unit of the native currency of Zcash, is $10^{8}$ zatoshi (protocol specification, §“Shielded Pools and Notes” and §“Mainnet and Testnet”). Every value in this volume, note values included, is an integer number of zatoshi.

Definition 4.2 (Note).

A note is a tuple $n=(\mathsf{addr},v,\rho,\psi,\mathsf{rcm})$ , where

•

the address $\mathsf{addr}=(d,\mathsf{pk_{d}})$ of the recipient, of the type constructed in §3.3: a diversifier $d\in\{0,1\}^{88}$ and a transmission key $\mathsf{pk_{d}}\in\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})\setminus\{% \mathcal{O}\}$ ;
•

the value $v\in\{0,\dots,2^{64}-1\}$ , in zatoshi;
•

the elements $\rho\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ and $\psi\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ ;
•

the commitment trapdoor $\mathsf{rcm}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$

(protocol specification, §“Shielded Pools and Notes”; the lengths $88$ and $64$ are those of §“Constants”). The specification types $\mathsf{rcm}$ as an integer in $\{0,\dots,2^{255}-1\}$ (§“Commitment”). This volume types it in $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , because every derivation of $\mathsf{rcm}$ yields a reduced value and $\mathsf{rcm}$ acts only as the scalar of $[\mathsf{rcm}]$ , which depends on $\mathsf{rcm}$ modulo $p_{\mathsf{Vesta}}$ alone; this typing makes the binding of Proposition 4.5 a statement about notes. For a created note, $\psi$ and $\mathsf{rcm}$ are derived from its note seed, for an Ironwood-pool note in §4.3, and $\rho$ is the nullifier of the note consumed in the same Action, a rule constructed in “Nullifier chaining” (§6.3).

A note is never published. A transaction that creates a note publishes its extracted note commitment $\mathsf{cmx}$ (Definition 4.4) and a ciphertext of its note plaintext for the recipient, constructed in “Encryption to the recipient” (§10.2) (protocol specification, §“Note Commitments” and §“Sending Notes (Orchard)”). Of the fields of a created note, only $\rho$ appears on chain in the clear: it equals the nullifier that the same Action publishes for its consumed note (“Nullifier chaining”, §6.3). This representation of value serves requirement R1 of §1.4; Propositions 4.5 and 4.8 state what the commitment hides.

Remark 4.3 (Roles of the fields).

The address and the value are the content of the note, its recipient and its amount; the trapdoor $\mathsf{rcm}$ randomises its commitment; the elements $\rho$ and $\psi$ , which also enter the commitment, are the note-specific inputs of its nullifier, constructed in “The nullifier” (§6.1).

4.2 Note commitments

Definition 4.4 (Note commitment).

For a note $n=((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ let $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)$ (§3.3) and

M(n):=\mathsf{g_{d}}^{\star}\,\|\,\mathsf{pk_{d}}^{\star}\,\|\,\mathrm{LE}_{64% }(v)\,\|\,\mathrm{LE}_{255}(\rho)\,\|\,\mathrm{LE}_{255}(\psi),

with $\rho$ and $\psi$ read as integers in $\{0,\dots,p_{\mathsf{Pallas}}-1\}$ ; the string $M(n)$ has the fixed length $1086$ of Table 4. With $D:=\texttt{z.cash:Orchard-NoteCommit}$ , the note commitment of $n$ is

\mathsf{cm}:=\mathsf{NoteCommit}_{\mathsf{rcm}}(M(n)):=\mathsf{% SinsemillaCommit}_{\mathsf{rcm}}(D,M(n))\in\mathcal{E}(\mathbb{F}_{p_{\mathsf{% Pallas}}})\cup\{\bot\}.

By the routing of §2.4, with the hash point and the blinding base

	$\displaystyle\hat{M}$	$\displaystyle:=\mathsf{SinsemillaHashToPoint}(\texttt{z.cash:Orchard-% NoteCommit-M},\,M(n)),$
	$\displaystyle H_{D}$	$\displaystyle:=\mathsf{GroupHash}(\texttt{z.cash:Orchard-NoteCommit-r},\,% \varepsilon),$

the commitment is $\mathsf{cm}=\hat{M}+[\mathsf{rcm}]\,H_{D}$ if $\hat{M}\neq\bot$ , and $\mathsf{cm}=\bot$ otherwise. The extracted note commitment is $\mathsf{cmx}:=\mathsf{Extract}_{\mathbb{P}}^{\bot}(\mathsf{cm})\in\mathbb{F}_{% p_{\mathsf{Pallas}}}\cup\{\bot\}$ (§2.1). The specification’s $\mathsf{NoteCommit}$ takes the five encoded fields as separate arguments, in the order of their encodings in $M(n)$ (protocol specification, §“Sinsemilla commitments”, §“Sending Notes (Orchard)” and §“Coordinate Extractor for Pallas”).

A sender never publishes $\bot$ : it redraws the note seed (step (vi) of the derivation of §4.3). The extracted commitment $\mathsf{cmx}$ is the value an Action publishes for its created note, and the leaf of that note in the pool’s note commitment tree of “The Merkle hash and the tree” (§5.1), whose nodes are elements of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ .

The blinding base $H_{D}$ is not $\mathcal{O}$ : the protocol specification, §“Sinsemilla commitments”, states that $\mathsf{SinsemillaCommit}$ is perfectly hiding for a uniform trapdoor, for every domain, which holds only for a blinding base other than $\mathcal{O}$ (as for $\mathsf{Commit}^{\mathsf{ivk}}$ , §3.2).

Proposition 4.5 (Hiding and binding of note commitments).

(a)

Perfect hiding. Let $\mathsf{rcm}$ be uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ . For every note content $(d,\mathsf{pk_{d}},v,\rho,\psi)$ whose message $M(n)$ has hash point $\hat{M}\neq\bot$ , the commitment $\mathsf{cm}$ is uniform on $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ . Hence the distributions of $\mathsf{cm}$ and of $\mathsf{cmx}$ do not depend on $(\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi)$ , and $\mathsf{NoteCommit}$ is perfectly hiding on messages without a $\bot$ output, in the sense of the Crypto Guide’s Definition “Hiding game and hiding” (§“Hiding and binding”).
(b)

Binding of the extracted commitment. Under Assumptions 2.22 and 2.8, no efficient algorithm outputs, except with negligible probability, two notes $n\neq n^{\prime}$ with $\mathsf{cmx}(n)=\mathsf{cmx}(n^{\prime})\neq\bot$ . In particular two distinct notes share no note commitment other than $\bot$ . With Proposition 2.24(iii), which excludes messages with output $\bot$ , part (b) gives computational binding in the sense of the Crypto Guide’s Definition “Binding game and binding” (same section), with the note content as the message and $\mathsf{rcm}$ as the randomness, stated for notes and for the extracted value.

Proposition 4.8 states hiding for the trapdoor that a sender derives.

Proof.

(a) This is Lemma 2.26(i) for the domain $D$ and the message length $1086$ , whose hypothesis $H_{D}\neq\mathcal{O}$ holds by the paragraph above; the value $\mathsf{cmx}$ is a fixed function of $\mathsf{cm}$ . Equal distributions for every pair of contents without a $\bot$ output are perfect hiding by the Crypto Guide’s Proposition “Distributional characterisation of hiding” (§“Hiding and binding”).

(b) Step 1 reduces distinct notes to distinct openings. The map $(\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi)\mapsto M(n)$ is injective: the string $M(n)$ concatenates fields of fixed lengths; the star encoding is injective (§2.1); the encoding $\mathrm{LE}_{64}$ is injective on $\{0,\dots,2^{64}-1\}$ ; and the encoding $\mathrm{LE}_{255}$ is injective on the representatives of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , since $p_{\mathsf{Pallas}}<2^{255}$ (§2.1). The map $n\mapsto(M(n),\mathsf{rcm})$ is therefore injective except on pairs of notes with $d\neq d^{\prime}$ and $\mathsf{DiversifyHash}(d)=\mathsf{DiversifyHash}(d^{\prime})$ . Let $T$ and $T^{\prime}$ be the values of $\mathsf{GroupHash}$ at $(\texttt{z.cash:Orchard-gd},\mathsf{LEBS2OSP}_{88}(d))$ and at the corresponding input for $d^{\prime}$ , distinct inputs because $\mathsf{LEBS2OSP}_{88}$ is injective. If $T,T^{\prime}\neq\mathcal{O}$ , equal diversified bases give $T-T^{\prime}=\mathcal{O}$ ; otherwise $T=\mathcal{O}$ or $T^{\prime}=\mathcal{O}$ . Each is a non-trivial relation among values of $\mathsf{GroupHash}$ on distinct inputs, which the lemma on relations among fixed generators (§2.4) excludes except with negligible probability.

Step 2 treats distinct openings. Let $\mathsf{cmx}(n)=\mathsf{cmx}(n^{\prime})\neq\bot$ . The lifting $\mathsf{Extract}_{\mathbb{P}}^{\bot}$ maps only $\bot$ to $\bot$ , so $\mathsf{cm}$ and $\mathsf{cm}^{\prime}$ are points, and by Lemma 2.4 $\mathsf{cm}^{\prime}=\mathsf{cm}$ or $\mathsf{cm}^{\prime}=-\mathsf{cm}$ . The pairs $(M(n),\mathsf{rcm})$ and $(M(n^{\prime}),\mathsf{rcm}^{\prime})$ are openings of the instance $\mathsf{NoteCommit}$ in $\{0,1\}^{1086}\times\mathbb{F}_{p_{\mathsf{Vesta}}}$ . By Proposition 2.24(ii), outputs with $\mathsf{cm}^{\prime}=-\mathsf{cm}$ , or with $\mathsf{cm}^{\prime}=\mathsf{cm}$ and $M(n)\neq M(n^{\prime})$ , have negligible probability (in the opposite case the relation in its proof has coefficient $2^{109+1}$ on the hash base, for a message of $109$ chunks). In the remaining case $\mathsf{cm}^{\prime}=\mathsf{cm}$ and $M(n)=M(n^{\prime})$ , and outside the event of Step 1 the openings differ, so $\mathsf{rcm}\neq\mathsf{rcm}^{\prime}$ in $\mathbb{F}_{p_{\mathsf{Vesta}}}$ ; then $[\mathsf{rcm}-\mathsf{rcm}^{\prime}]\,H_{D}=\mathcal{O}$ , impossible for $H_{D}\neq\mathcal{O}$ in a group of prime order $p_{\mathsf{Vesta}}$ . A note commitment other than $\bot$ shared by $n\neq n^{\prime}$ gives equal extracted commitments other than $\bot$ , which proves the particular case. □

4.3 The note seed: Ironwood derivations (lead byte $\mathtt{0x03}$ )

Definition 4.6 (Note seed and lead byte).

A created note reaches its recipient as a note plaintext, the byte string constructed in “The note plaintext” (§10.1) that the sender encrypts. Its first byte, the lead byte, names the format of the plaintext and selects the derivation of the note’s randomness. The sender draws one note seed $\mathsf{rseed}$ , a uniform $32$ -byte string, the key type of $\mathsf{PRFexpand}$ (§2.3), which the plaintext carries. The values $\psi$ and $\mathsf{rcm}$ of the note and the ephemeral secret key $\mathsf{esk}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$ of “Encryption to the recipient” (§10.2) are all derived from it (protocol specification, §“Note Plaintexts and Memo Fields” and §“Sending Notes (Orchard)”).

Construction 4.7 (Derivations under lead byte $\mathtt{0x03}$ ).

The input is an address $(d,\mathsf{pk_{d}})$ , a value $v\in\{0,\dots,2^{64}-1\}$ and $\rho\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ . Let $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)$ and $\underline{\rho}:=\mathsf{I2LEOSP}_{256}(\rho)$ . For a point $P=(x,y)$ the $32$ -byte string $\mathsf{LEBS2OSP}_{256}(P^{\star})$ equals $\mathsf{I2LEOSP}_{256}(x+2^{255}(y\bmod 2))$ (§2.1). The sender

(i)

checks that $\mathsf{pk_{d}}\neq\mathcal{O}$ ;
(ii)

draws $\mathsf{rseed}$ uniformly from the $32$ -byte strings;
(iii)

derives $\mathsf{esk}:=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x04}]\,\|\,\underline{\rho})\bigr{)}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$ , and returns to (ii) if $\mathsf{esk}=0$ ;
(iv)

derives $\psi:=\mathrm{ToBase}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([\mathtt{0x09% }]\,\|\,\underline{\rho})\bigr{)}\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ ;

(v)

derives $\mathsf{rcm}:=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}(% \mathsf{pre\_rcm})\bigr{)}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$ , where

	$\displaystyle\mathsf{pre\_rcm}:=[\mathtt{0x0B}]$	$\displaystyle\,\\|\,\mathsf{LEBS2OSP}_{256}(\mathsf{g_{d}}^{\star})\,\\|\,% \mathsf{LEBS2OSP}_{256}(\mathsf{pk_{d}}^{\star})$
		$\displaystyle\,\\|\,\mathsf{I2LEOSP}_{64}(v)\,\\|\,\underline{\rho}\,\\|\,\mathsf% {I2LEOSP}_{256}(\psi),$

a string of $1+32+32+8+32+32=137$ bytes;

(vi)

computes $\mathsf{cmx}$ of the note $n:=((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ by Definition 4.4, and returns to (ii) if $\mathsf{cmx}=\bot$ .

The output is the note $n$ , its seed $\mathsf{rseed}$ and $\mathsf{esk}$ (protocol specification, §“Sending Notes (Orchard)”; ZIP 2005, “Changes to the Protocol Specification”, §4.7.3).

The order is forced: the string $\mathsf{pre\_rcm}$ contains $\psi$ , so $\mathsf{rcm}$ is derived after $\psi$ . The strings $\mathsf{g_{d}}^{\star}$ and $\mathsf{pk_{d}}^{\star}$ in $\mathsf{pre\_rcm}$ are those of the message $M(n)$ , packed into bytes, so $\mathsf{rcm}$ is a function of $\mathsf{rseed}$ and of every committed field $(\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi)$ . The leading bytes $\mathtt{0x04}$ , $\mathtt{0x09}$ and $\mathtt{0x0B}$ are rows of Table 3.

An Ironwood-pool note has the type of Definition “Note” (§4.1) and is committed by the same $\mathsf{NoteCommit}$ (Definition 4.4). Every note created by an Ironwood-pool Action, a dummy created note included, has a plaintext with lead byte $\mathtt{0x03}$ and the derivations above; no note created by an Orchard-pool Action does. This is the only note-level distinction between the two pools (ZIP 229, “Transaction Format”; ZIP 258, “ZIP 2005 activation”).

Proposition 4.8 (Hiding under the derived trapdoor).

An adversary chooses two tuples $(d^{(i)},\mathsf{pk_{d}}^{(i)},v^{(i)},\rho^{(i)})$ , $i\in\{0,1\}$ , of the input type of the construction above, with $\mathsf{pk_{d}}^{(i)}\neq\mathcal{O}$ . The challenger draws a uniform bit $b$ , runs steps (ii) to (vi) of the construction on tuple $b$ , and returns $(\mathsf{cm}_{b},\mathsf{esk}_{b})$ , the note commitment of the note it computes and its $\mathsf{esk}$ ; the adversary receives no other function of $\mathsf{rseed}$ (the ciphertext that carries $\mathsf{rseed}$ is treated in Theorem 12.12). It outputs a bit $b^{\prime}$ . Let the number $\epsilon_{\mathsf{PRF}}$ bound the advantage against Assumption 2.12 of each algorithm built from the adversary in the proof, each of which queries $\mathsf{PRFexpand}_{\mathsf{rseed}}$ on three inputs with pairwise distinct leading bytes; let $\delta<2^{-257}$ bound the distance of $\mathrm{ToScalar}$ from uniform (§2.3); and let $\epsilon_{\bot}$ be the largest, over $i$ , of the sum of two probabilities that one pass through steps (ii) to (vi) on tuple $i$ returns to step (ii), one with $\mathsf{PRFexpand}_{\mathsf{rseed}}$ as specified and one with its three outputs replaced by independent uniform strings. Then

\bigl{|}\mathrm{Pr}[b^{\prime}=1\mid b=0]-\mathrm{Pr}[b^{\prime}=1\mid b=1]% \bigr{|}\leq 2\,(\epsilon_{\mathsf{PRF}}+\delta+\epsilon_{\bot}),

and $\epsilon_{\mathsf{PRF}}$ and $\epsilon_{\bot}$ are negligible under Assumptions 2.12, 2.22 and 2.8. The same bound holds with $\mathsf{cmx}_{b}$ in place of $\mathsf{cm}_{b}$ .

Proof.

Fix the adversary’s tuples. One pass through steps (ii) to (vi) with a fresh $\mathsf{rseed}$ is a trial; its output is $(\mathsf{cm},\mathsf{esk})$ , and it is accepted, event $A$ , when $\mathsf{esk}\neq 0$ and $\hat{M}\neq\bot$ , since $\mathsf{cmx}=\bot$ exactly when $\hat{M}=\bot$ . Trials are independent and identically distributed, and the challenger returns the output of the first accepted one; so its answer $X_{i}$ on tuple $i$ is distributed as the output $Y_{i}$ of one trial conditioned on $A$ . For a random variable $Y$ and an event $A$ with $\mathrm{Pr}[\neg A]=p<1$ , the statistical distance between $Y$ and $Y$ conditioned on $A$ is at most $p$ : for every set $S$ ,

\mathrm{Pr}[Y\in S]-\mathrm{Pr}[Y\in S\mid A]=\mathrm{Pr}[Y\in S,\,\neg A]-% \mathrm{Pr}[Y\in S,\,A]\,\frac{p}{1-p},

and both terms lie in $[0,p]$ .

Hybrid 1 replaces the outputs of $\mathsf{PRFexpand}_{\mathsf{rseed}}$ on $[\mathtt{0x04}]\,\|\,\underline{\rho}$ , $[\mathtt{0x09}]\,\|\,\underline{\rho}$ and $\mathsf{pre\_rcm}$ by independent uniform $u_{1},u_{2},u_{3}\in\{0,1\}^{512}$ , so that $\mathsf{esk}=\mathrm{ToScalar}(u_{1})$ , $\psi=\mathrm{ToBase}(u_{2})$ and $\mathsf{rcm}=\mathrm{ToScalar}(u_{3})$ . The three inputs have distinct leading bytes, the input $\mathsf{pre\_rcm}$ is chosen after the answer that determines $\psi$ , and $\mathsf{rseed}$ is used only as a key of $\mathsf{PRFexpand}$ . By Lemma 2.15 (Assumption 2.12), the probability that any efficient test outputs $1$ on the trial’s output changes by at most $\epsilon_{\mathsf{PRF}}$ . Hybrid 2 replaces $\mathsf{rcm}$ by a uniform element of $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , independent of all else, at statistical cost $\delta$ . The event $A$ does not involve $\mathsf{rcm}$ , so its probability is the same in both hybrids.

In Hybrid 2 the values $\mathsf{esk}$ and $\psi$ are independent, $A$ is the intersection of an event on $\mathsf{esk}$ and an event on $\psi$ , and $\mathsf{rcm}$ is uniform and independent of both. Conditioned on $A$ , therefore, $\hat{M}\neq\bot$ and $\mathsf{cm}=\hat{M}+[\mathsf{rcm}]\,H_{D}$ is uniform on $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ by Proposition 4.5(a), independently of $\mathsf{esk}$ , and $\mathsf{esk}$ is distributed as $\mathrm{ToScalar}(u_{1})$ conditioned on being non-zero. This distribution $W$ does not depend on $i$ .

For each $i$ , the adversary’s output probability on $X_{i}$ differs from that on $W$ by at most the rejection probability of a trial as specified ( $X_{i}$ against $Y_{i}$ ), plus $\epsilon_{\mathsf{PRF}}+\delta$ ( $Y_{i}$ against its form in Hybrid 2), plus the rejection probability in Hybrid 2, which equals that with uniform strings (the unconditioned form in Hybrid 2 against $W$ ). The two rejection probabilities sum to at most $\epsilon_{\bot}$ . Adding the bounds for $i=0$ and $i=1$ gives the stated bound. For $\mathsf{cmx}_{b}$ , an adversary against $\mathsf{cmx}_{b}$ is one against $\mathsf{cm}_{b}$ that first applies the fixed map $\mathsf{Extract}_{\mathbb{P}}^{\bot}$ .

Negligibility. With uniform strings, $\mathsf{esk}=0$ has probability at most $1/p_{\mathsf{Vesta}}+\delta$ . The event $\hat{M}=\bot$ has the probability with which an efficient algorithm finds a message of hash point $\bot$ : the algorithm that runs the adversary’s choice of tuples, draws $u_{2}$ , and outputs $M(n)$ for tuple $i$ with $\psi=\mathrm{ToBase}(u_{2})$ . That probability is negligible by Proposition 2.24(iii) under Assumptions 2.22 and 2.8. Rejection is efficiently decidable from the three outputs of $\mathsf{PRFexpand}_{\mathsf{rseed}}$ , so the rejection probability as specified exceeds that with uniform strings by at most $\epsilon_{\mathsf{PRF}}$ , negligible under Assumption 2.12. □

Remark 4.9 (Purpose of the hashed trapdoor).

Because $\mathsf{rcm}$ is a hash of $\mathsf{rseed}$ and of every committed field, Ironwood-pool notes are recoverable in the sense of ZIP 2005. That ZIP proposes, with details subject to change, a Recovery Protocol for recovering Ironwood-pool funds if the Orchard protocol must be disabled because discrete logarithms become computable; a recovery protocol whose statement recomputes $\mathsf{rcm}$ by this derivation can bind a note even against an adversary able to compute discrete logarithms (ZIP 2005, Abstract; Rationale, “Proposed Recovery Protocol” and “Repairing note commitments”). Against such an adversary $\mathsf{NoteCommit}$ alone is not binding: the discrete-logarithm relations between its bases give a linear equation over $\mathbb{F}_{p_{\mathsf{Vesta}}}$ with several solutions, hence two distinct notes that open one commitment (ZIP 2005, Rationale, “Attacks against binding of note commitments”). What the deployed protocol checks of the derivation is stated with the Action statement, defined in “The Action statement” (§9.2).

The specification defines, for each pool, the set $\mathsf{allowedLeadBytes}^{\mathit{pool}}$ of lead bytes allowed in a note plaintext of that pool. For every transaction that contains Actions of the pool, the set is $\{\mathtt{0x03}\}$ for the Ironwood pool and $\{\mathtt{0x02}\}$ for the Orchard pool (protocol specification, §“Note Plaintexts and Memo Fields”; ZIP 2005, “Changes to the Protocol Specification”, §3.2.1; ZIP 258, “ZIP 2005 activation”). The lead byte travels encrypted, and each decrypting party enforces the rule: decryption with an incoming viewing key, by the recipient, and decryption with an outgoing viewing key, by its holder, both return $\bot$ when the lead byte is not allowed (§“Decryption using an Incoming Viewing Key (Sapling and Orchard)” and §“Decryption using an Outgoing Viewing Key (Sapling and Orchard)”). For an Ironwood-pool output this is check (i) of the acceptance procedure of “Trial decryption and note acceptance” (§10.4). The one consensus check of the lead byte is stated in “Chain state and pool rules” (§11.4).

4.4 Actions, bundles, and dummy notes

Definition 4.10 (Action).

An Action of a pool consumes one note $n^{\mathsf{old}}$ and creates one note $n^{\mathsf{new}}$ of that pool; it is the specification’s Action transfer, and every Action has both sides (protocol specification, §“Action Transfers and their Descriptions”). Its public data carry the extracted commitment $\mathsf{cmx}$ of the created note (Definition 4.4), the nullifier of the consumed note (“The nullifier”, §6.1), a randomised validating key with a spend-authorisation signature (“Randomised validating keys”, §7.2), a net value commitment (“Value commitments”, §8.1), and the ciphertexts of “Encryption to the recipient” (§10.2). “Action descriptions and bundles” (§11.1) assembles them and redefines neither the Action nor the bundle. The relation that each Action must satisfy is the Action statement, defined in “The Action statement” (§9.2).

Definition 4.11 (Dummy notes).

Every Action has one consumed and one created note, so that its public fields are the same whether a side is real or not; a side that a payment does not use carries a dummy note, a note of value $0$ . A dummy consumed note is built as follows (protocol specification, §“Dummy Notes (Orchard)”; ZIP 2005, “Changes to the Protocol Specification”, §4.8.3):

(i)

draw a fresh spending key as in §3.1, and derive its key components and an address $(d,\mathsf{pk_{d}})$ (§3.2, §3.3);
(ii)

set $v:=0$ , draw $\mathsf{rseed}$ uniformly, and set $\rho:=\mathsf{Extract}_{\mathbb{P}}(P)$ for a uniform point $P$ of $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ ;
(iii)

derive $\psi$ and $\mathsf{rcm}$ under the lead byte chosen as for a created note of the pool (ZIP 2005, “Changes to the Protocol Specification”, §4.8.3); in the Ironwood pool the lead byte is $\mathtt{0x03}$ and the derivations are steps (iv) and (v) of §4.3;
(iv)

compute $\mathsf{cm}$ by Definition 4.4, and repeat from the draw of $\mathsf{rseed}$ with a fresh seed if $\mathsf{cm}=\bot$ .

Its nullifier is computed as for any note (“The nullifier”, §6.1). For step (iii) the two sources differ: the specification’s section chooses the lead byte with the pool fixed to the Orchard pool, which gives $\mathtt{0x02}$ also in the Ironwood pool, whereas ZIP 2005, §4.8.3, makes the choice identical for dummy and non-dummy notes. The volume follows the ZIP. No condition of the Action statement checks the derivation of $\mathsf{rcm}^{\mathsf{old}}$ (Definition 9.2, Remark “What the statement does not check”).

A dummy created note is a created note of value $0$ , built as any created note; in the Ironwood pool it therefore carries lead byte $\mathtt{0x03}$ . Its address depends on the flag $\mathsf{enableCrossAddress}$ of the bundle (“Bundle flags”, §9.1).

•

When $\mathsf{enableCrossAddress}=1$ , the dummy created note goes to a random address (protocol specification, §“Dummy Notes (Orchard)”).
•

When $\mathsf{enableCrossAddress}=0$ , as in every Orchard-pool bundle, condition A10 of Definition 9.2 places the note that an Action creates at the expanded receiver, defined in “Bundle flags”, of the note that the same Action consumes. A dummy created note then goes to the expanded receiver of that consumed note, real or dummy. In the Orchard pool, beside a real consumed note, the sender fills the component $C_{\mathsf{enc}}$ of the note ciphertext of the dummy created note (“Encryption to the recipient”, §10.2) with random bytes, not with an encryption of its plaintext (ZIP 326, “Fabricated same-address outputs and randomized note ciphertexts”). A dummy consumed note beside a real created note lies at the expanded receiver of that created note: in place of step (i) it takes the created note’s address and the key components of the key from which that address derives, and the Action’s spend-authorisation signature requires that key’s $\mathsf{ask}$ (Remark “Meaning of A10”, §9.2). A fresh key as in step (i) remains admissible when both sides of the Action are dummies at its address.

That the public data do not reveal which sides of an Action are real is part of Theorem 12.12 (§12.4).

Definition 4.12 (Bundle).

The bundle of a pool in a transaction, which ZIP 229 calls the pool’s component, is the sequence of that pool’s Actions in the transaction together with the bundle-level data that later sections attach: one anchor (“Anchors”, §5.2), one balancing value (“The balancing value”, §8.2), one binding signature (“The binding signature”, §8.3), the flags (“Bundle flags”, §9.1) and one proof for all its Actions (“The Action circuit and the Halo 2 proof”, §9.3). A transaction carries at most one bundle per pool (ZIP 229, “Transaction Format”).