ZSA Guide Zcash Shielded Assets: asset identity, issuance, transfer, and burn 2 Asset identity 4 OrchardZSA Actions and Action Groups

3 Notes and note commitments

This section extends the Orchard note by one field, the Asset Base (§3.1); extends the note commitment by a case split whose native branch is the Orchard commitment (§3.2); states the derivations of the note’s randomness from its seed and what no live text fixes of them (§3.3); states the field set of the note plaintext (§3.4); and replaces the fixed value base of the net value commitment by the Asset Base (§3.5). It proves hiding and binding of both commitments within and across Assets. Every construction of the section is taken from ZIP 226, which is Draft; the Orchard objects it extends are those of the Ironwood Guide and are cited, not restated.

3.1 The OrchardZSA note

Definition 3.1 (OrchardZSA note).

An OrchardZSA note is a tuple

n=(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\psi,\mathsf{rcm})

of type

	$\displaystyle\mathsf{Note}^{\mathsf{OrchardZSA}}:={}$	$\displaystyle\{0,1\}^{88}\times\bigl{(}\mathcal{E}(\mathbb{F}_{p_{\mathsf{% Pallas}}})\setminus\{\mathcal{O}\}\bigr{)}\times\{0,\dots,2^{64}-1\}$
		$\displaystyle\times\mathcal{E}^{*}\times\mathbb{F}_{p_{\mathsf{Pallas}}}\times% \mathbb{F}_{p_{\mathsf{Pallas}}}\times\mathbb{F}_{p_{\mathsf{Vesta}}},$

with $\mathcal{E}^{*}=\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})\setminus\{% \mathcal{O}\}$ as in §2.3. It is the note of the Ironwood Guide’s Definition “Note” (§“Notes”) with exactly one added field, the Asset Base $\mathsf{AssetBase}\in\mathcal{E}^{*}$ of the note’s Asset: for a Custom Asset the point of Construction 2.10, for the Native Asset the point $V^{\mathsf{Orchard}}$ of Definition 2.15. The components $(d,\mathsf{pk_{d}},v,\rho,\psi,\mathsf{rcm})$ and their types, with $\mathsf{rcm}$ typed in $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , are those of the cited definition. ZIP 226 types the added field in $\mathbb{P}^{*}$ , a group element that is neither the identity nor $\bot$ (Table 1). The value $v$ counts units of the note’s Asset; the Ironwood Guide’s Definition “Unit of value” (the zatoshi) applies only when $\mathsf{AssetBase}=V^{\mathsf{Orchard}}$ (ZIP 226, “Note Structure and Commitment”; protocol specification, §“Shielded Pools and Notes”). Class: specified.

3.2 Note commitments

Definition 3.2 (OrchardZSA note commitment).

Let $n=(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\psi,\mathsf{rcm})$ be an OrchardZSA note, $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)$ , and

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

the $1086$ -bit Orchard message of the Ironwood Guide’s Definition “Note commitment”. Let

M^{\mathsf{ZSA}}(n):=M(n)\,\|\,\mathsf{AssetBase}^{\star},

where the $256$ -bit star encoding $\mathsf{AssetBase}^{\star}$ has the bytes $\mathsf{asset\_base}$ of Definition 2.14. The string $M^{\mathsf{ZSA}}(n)$ has the fixed length $1342$ : $135$ chunks of $10$ bits with padding $8$ , against $109$ chunks for $M(n)$ , within the chunk bound $c=253$ of the Ironwood Guide’s Construction “Sinsemilla hash on Pallas”. With the Orchard blinding base and the hash point

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

the OrchardZSA note commitment $\mathsf{cm}:=\mathsf{NoteCommit}^{\mathsf{OrchardZSA}}_{\mathsf{rcm}}(n)$ of $n$ is defined in two branches. In the native branch, $\mathsf{AssetBase}=V^{\mathsf{Orchard}}$ , it is

\mathsf{cm}:=\mathsf{NoteCommit}_{\mathsf{rcm}}(M(n)),

with $\mathsf{NoteCommit}$ the Orchard commitment of the cited definition. In the custom branch, $\mathsf{AssetBase}\neq V^{\mathsf{Orchard}}$ , it is

\mathsf{cm}:=\begin{cases}\hat{M}^{\mathsf{ZSA}}+[\mathsf{rcm}]\,H_{D}&\text{% if }\hat{M}^{\mathsf{ZSA}}\neq\bot,\\ \bot&\text{otherwise}.\end{cases}

In both branches $\mathsf{cm}\in\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})\cup\{\bot\}$ , and the extracted note commitment is $\mathsf{cmx}:=\mathsf{Extract}_{\mathbb{P}}^{\bot}(\mathsf{cm})\in\mathbb{F}_{% p_{\mathsf{Pallas}}}\cup\{\bot\}$ , as for Orchard. The custom branch is not the routed $\mathsf{SinsemillaCommit}$ of the Ironwood Guide’s Construction “Sinsemilla commitment and short commitment” for any domain: its hash domain is new, while its blinding base is Orchard’s. The hash base $Q(\texttt{z.cash:ZSA-NoteCommit-M})$ is a row of Table 3. The new domain hashes the single length $1342$ , as the Ironwood Guide’s Remark “Fixed length” requires of every domain (ZIP 226, “Note Structure and Commitment”; protocol specification, §“Sinsemilla commitments”). Class: specified.

In the native branch the Asset Base is not an input of the commitment. Hence the OrchardZSA commitment of a note with $\mathsf{AssetBase}=V^{\mathsf{Orchard}}$ equals, bit for bit, the Orchard commitment of its Orchard components; an Orchard note and a native OrchardZSA note with the same Orchard components have the same $\mathsf{cmx}$ ; and every leaf of the Orchard-pool note commitment tree created before OrchardZSA remains a valid opening target. Both branches output in $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})\cup\{\bot\}$ , so custom-branch commitments enter the same tree. Each statement is immediate from Definition 3.2 (ZIP 226, “Note Structure and Commitment” and “Rationale for Note Commitment”).

Proposition 3.3 (Hiding and binding of OrchardZSA note commitments).

(a)

Hiding with one output distribution. Let $\mathsf{rcm}$ be uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ and independent of the content. For every content $(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\psi)$ whose hash point in its branch is not $\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}$ depend neither on the content nor on the branch, and commitments to ZEC and to Custom Assets are identically distributed.
(b)

Binding. Under the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas” and “GroupHash as a random oracle”, no efficient algorithm outputs, except with negligible probability, OrchardZSA notes $n\neq n^{\prime}$ with $\mathsf{cmx}(n)=\mathsf{cmx}(n^{\prime})\neq\bot$ ; in particular none with $\mathsf{AssetBase}=V^{\mathsf{Orchard}}\neq\mathsf{AssetBase}^{\prime}$ , and none whose contents are equal except for the Asset Base.
(c)

Under the same assumptions, no efficient algorithm outputs, except with negligible probability, a custom-branch content with $\hat{M}^{\mathsf{ZSA}}=\bot$ .

Status (Definition 1.3): proved here for the specified construction; conditional on no unspecified object. Part (a) is stated for uniform $\mathsf{rcm}$ and does not cover a derived trapdoor, whose derivation is classified in Remark 3.6.

Proof.

Write

Q_{\mathsf{O}}:=Q(\texttt{z.cash:Orchard-NoteCommit-M}),\qquad Q_{\mathsf{Z}}:% =Q(\texttt{z.cash:ZSA-NoteCommit-M}).

The generators $Q_{\mathsf{O}}$ , $Q_{\mathsf{Z}}$ , $S(0),\dots,S(1023)$ and $H_{D}$ are values of $\mathsf{GroupHash}$ at pairwise distinct inputs, by Lemma 2.8 and the Ironwood Guide’s table of §“GroupHash, domain separation, and nothing-up-my-sleeve generators”.

(a) In both branches $\mathsf{cm}=\hat{M}+[\mathsf{rcm}]\,H_{D}$ , with the same blinding base $H_{D}\neq\mathcal{O}$ and a point $\hat{M}$ fixed by the content. The proof of the Ironwood Guide’s Lemma “Hiding and binding of SinsemillaCommit” (i) uses only these two facts, the first established for $H_{D}$ before that volume’s Proposition “Hiding and binding of note commitments”; so $\mathsf{cm}$ is uniform, whatever the content and the branch. The value $\mathsf{cmx}$ is a fixed function of $\mathsf{cm}$ .

(b) Step 1. The map from a content to its branch and message is injective except on a diversifier collision: the branch is fixed by whether $\mathsf{AssetBase}=V^{\mathsf{Orchard}}$ ; in the native branch the Asset Base is determined, and the message $M(n)$ determines the Orchard components; in the custom branch the message $M^{\mathsf{ZSA}}(n)$ determines them and, by the injectivity of the star encoding, the Asset Base. A diversifier collision is excluded as in Step 1 of the proof of the Ironwood Guide’s Proposition “Hiding and binding of note commitments” (b). Outside that event, $n\neq n^{\prime}$ gives distinct branches, or one branch with distinct messages, or one branch and one message with $\mathsf{rcm}\neq\mathsf{rcm}^{\prime}$ .

Step 2. Let $\mathsf{cmx}(n)=\mathsf{cmx}(n^{\prime})\neq\bot$ . Both commitments are points, and by the Ironwood Guide’s Lemma “Coordinate extraction identifies opposite points”, $\mathsf{cm}^{\prime}=\pm\mathsf{cm}$ ; both hash points are not $\bot$ . Three cases remain.

Both native. The Orchard components differ, since the Asset Bases agree, and the Ironwood Guide’s Proposition “Hiding and binding of note commitments” (b) applies.

Both custom. The three steps of the Ironwood Guide’s Proposition “Collision resistance of the Sinsemilla instances” hold for the message length $l=1342$ and $n=135$ chunks. Since $2^{135}\leq 2^{c}\leq(p_{\mathsf{Vesta}}-1)/2$ , every difference $\chi_{j}(m)-\chi_{j}(m^{\prime})$ of the unfolding in its proof has absolute value below $p_{\mathsf{Vesta}}$ , so $\chi$ is injective, and the coefficient $2^{136}$ on $Q_{\mathsf{Z}}$ in the opposite case is non-zero modulo $p_{\mathsf{Vesta}}$ . Equal points on distinct messages, or opposite points, therefore give a non-trivial relation among $Q_{\mathsf{Z}}$ , the $S(j)$ and $H_{D}$ . Equal messages with $\mathsf{rcm}\neq\mathsf{rcm}^{\prime}$ and equal points give $[\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}}$ ; opposite points on equal messages are the opposite case above.

Across branches. Let $n$ be native and $n^{\prime}$ custom, with pieces $m$ and $m^{\prime}$ of $M(n)$ and $M^{\mathsf{ZSA}}(n^{\prime})$ . Unfolding both hash points gives

[2^{109}]\,Q_{\mathsf{O}}\mp[2^{135}]\,Q_{\mathsf{Z}}+\textstyle\sum_{j}[\chi_% {j}(m)\mp\chi_{j}(m^{\prime})]\,S(j)+[\mathsf{rcm}\mp\mathsf{rcm}^{\prime}]\,H% _{D}=\mathcal{O}.

The coefficient $2^{109}$ on $Q_{\mathsf{O}}$ is non-zero modulo $p_{\mathsf{Vesta}}$ .

In each case the relation is non-trivial among values of $\mathsf{GroupHash}$ at distinct inputs, which the Ironwood Guide’s Lemma “Relations among fixed generators” excludes except with negligible probability. The first particular case of (b) is the case across branches; the second is either that case or the case of two custom notes with distinct messages.

(c) Step (2) of the proof of the cited proposition applies to the domain of $Q_{\mathsf{Z}}$ : an operand $\mathcal{O}$ arises only if $Q_{\mathsf{Z}}$ or some $S(j)$ is $\mathcal{O}$ , itself a non-trivial relation, and an exceptional case at step $i$ yields a relation with coefficient $\alpha\,2^{i-1}$ on $Q_{\mathsf{Z}}$ , where $\alpha\in\{-1,1,2\}$ and $0<|\alpha\,2^{i-1}|\leq 2^{135}<p_{\mathsf{Vesta}}$ . The same lemma excludes both. □

ZIP 226 argues the property in rationale only, attributing it to the Sinsemilla hash function (“by definition of the Sinsemilla hash function”, “Rationale for Note Commitment”; see also “Privacy Implications”). The unblinded hash is deterministic and hides nothing; the hiding comes from the term $[\mathsf{rcm}]\,H_{D}$ . The plaintext equivalence of Orchard and native OrchardZSA notes, which is withdrawn ZIP 230 text, is not used.

Remark 3.4 (Contextual distinguishability of commitments).

Commitments are hidden only as group elements. ZIP 226, “Privacy Implications”, states that Orchard note commitments are distinguishable from OrchardZSA note commitments by context, since the two protocols are carried by different transaction versions (in its text, version $5$ for Orchard and version $6$ for OrchardZSA), whether or not both are active. No current format assigns OrchardZSA a version: version $6$ is the format of ZIP 229, “Transaction Format”, which carries Orchard-pool and Ironwood-pool Actions and no ZSA. ZIP 248, “Potential Future Bundle Types”, lists OrchardZSA provisionally as variant $2$ of bundle type $3$ , the Orchard bundle type, whose public variant identifier would likewise separate the two. Within one OrchardZSA bundle, commitments to ZEC and to Custom Assets are identically distributed under a uniform trapdoor (Proposition 3.3(a)); the derived trapdoor, undefined in live text, is not covered (Remark 3.6). The carrier is treated in “The transaction carrier” (§8).

3.3 The note seed and the lead byte

ZIP 226, “Abstract”, is defined relative to the protocol with ZIP 2005 applied, and reads $\mathsf{H}^{\mathsf{rcm}}$ , $\mathsf{H}^{\psi}$ and the recoverable plaintexts as ZIP 2005 defines them; it calls ZIP 2005 “Orchard Quantum Recoverability”. ZIP 2005 is now “Ironwood Quantum Recoverability” (Proposed). It is active with NU6.3 and merged into the protocol specification (ZIP 258, “ZIP 2005 activation”; ZIP 2005, “Specification Updates”), and it applies its recoverable plaintext format, lead byte $\mathtt{0x03}$ , only to Ironwood-pool notes (ZIP 229, “Transaction Format”), while ZIP 226 places OrchardZSA notes in the Orchard pool (Remark 1.7). The two premises no longer coincide. Two constructions depend on them: the lead byte, here, and the seed of split nullifiers, at “Nullifiers of OrchardZSA notes” (§4.2). The derivations of ZIP 2005 are constructed in the Ironwood Guide, §“The note seed: Ironwood derivations (lead byte $\mathtt{0x03}$ )”, and are cited, not restated.

Definition 3.5 (Seed derivations of an OrchardZSA note).

Let an OrchardZSA note be created with recipient $(d,\mathsf{pk_{d}})$ , value $v$ , element $\rho\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ , note seed $\mathsf{rseed}$ uniform on the $32$ -byte strings, and lead byte $\mathsf{leadByte}$ . Let $\underline{\rho}:=\mathsf{I2LEOSP}_{256}(\rho)$ and $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)$ . Then

	$\displaystyle\psi$	$\displaystyle:=\mathrm{ToBase}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x09}]\,\\|\,\underline{\rho})\bigr{)},$
	$\displaystyle\mathsf{rcm}$	$\displaystyle:=\mathsf{Derive\_rcm}_{\mathsf{rseed}}(\mathsf{leadByte},\mathsf% {g_{d}}^{\star},\mathsf{pk_{d}}^{\star},v,\underline{\rho},\psi),$

where $\psi$ does not depend on the lead byte, and $\mathsf{Derive\_rcm}$ is defined only for two lead bytes:

\mathsf{Derive\_rcm}_{\mathsf{rseed}}(\mathsf{leadByte},\dots):=\begin{cases}% \mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([\mathtt{0x05}]\,% \|\,\underline{\rho})\bigr{)}&\text{if }\mathsf{leadByte}=\mathtt{0x02},\\ \text{the }\mathsf{pre\_rcm}\text{ derivation}&\text{if }\mathsf{leadByte}=% \mathtt{0x03},\end{cases}

the latter being that of the Ironwood Guide’s Construction “Derivations under lead byte $\mathtt{0x03}$ ”. Neither input list contains $\mathsf{AssetBase}$ . ZIP 226, “Note Structure and Commitment”, requires $\mathsf{leadByte}$ to be the placeholder $\{\{\mathsf{ZSALEADBYTE}\}\}$ whenever §“Sending Notes (Orchard)” or §“Dummy Notes (Orchard)” of the protocol specification is invoked, directly or indirectly, for an OrchardZSA note. That rule speaks of “the computation of $\rho$ and $\psi$ ”; under the amended specification the lead byte enters only $\mathsf{Derive\_rcm}$ . The specification admits lead byte $\mathtt{0x02}$ in the Orchard pool and $\mathtt{0x03}$ in the Ironwood pool only (protocol specification, §“Note Plaintexts and Memo Fields”), and ZIP 2005, “Usage with other proposals requiring note plaintext format changes”, requires such proposals to use a new lead byte value or values. Classes: the derivation of $\psi$ is specified; the derivation of $\mathsf{rcm}$ and the value of the lead byte are classified in Remark 3.6.

Remark 3.6 (Unassigned lead byte).

Each part carries one class of Definition 1.2.

(i)

The derivation of $\psi$ is specified.
(ii)

The derivation of $\mathsf{rcm}$ is designed but unspecified. A complete design existed: ZIP 226 fixed $\mathtt{0x03}$ with $\mathsf{H}^{\mathsf{rcm}}$ before $\mathtt{0x03}$ passed to ZIP 2005, and the design needs only a lead byte.
(iii)

The value of the lead byte is an open problem. The removed design’s $\mathtt{0x03}$ is the Ironwood lead byte in live text, a design that conflicts with live text; the placeholders $\{\{\mathsf{ZSALEADBYTE}\}\}$ (ZIP 226), $\{\{\mathsf{LEADBYTE}\}\}$ (withdrawn ZIP 230) and $\{\{\mathsf{MBLEADBYTE}\}\}$ (ZIP 231, “Note plaintext lead byte assignment”) are unassigned.

Until the byte is assigned, the $\mathsf{rcm}$ of an OrchardZSA note is undefined in live text, and the Ironwood Guide’s Proposition “Hiding under the derived trapdoor” does not transfer. The OrchardZSA Action statement, like the Orchard one, does not check the derivation (Ironwood Guide, Remark “What the statement does not check” (ii)), so for the outputs of a transfer the gap binds only sender and recipient. Its consequence for validators is stated at “Issue Notes” (§6.1).

3.4 The note plaintext

Definition 3.7 (OrchardZSA note plaintext).

The OrchardZSA note plaintext of a created OrchardZSA note carries the fields $(\mathsf{leadByte},d,v,\mathsf{rseed},\mathsf{memo})$ of the Ironwood Guide’s Definition “Note plaintext” and, in addition, the $32$ -byte string $\mathsf{asset\_base}$ of Definition 2.14 (ZIP 226, “Note Structure and Commitment”). The recipient needs $\mathsf{asset\_base}$ to recompute $\mathsf{cmx}$ by Definition 3.2 and to spend the note. Given an encoding of fixed length and an assigned lead byte, the Ironwood Guide’s Constructions “Encryption to the recipient” and “Trial decryption” apply unchanged. Its acceptance checks (§“Trial decryption and note acceptance”) apply with the lead-byte check and the derivation of $\mathsf{rcm}$ replaced by those of that lead byte (Remark 3.6), $\mathsf{asset\_base}$ required to decode to a point of $\mathcal{E}^{*}$ , and the recomputed commitment that of Definition 3.2. Classes: the field set is specified; the encoding is an open problem.

ZIP 226 delegates the encoding to ZIP 230, which is Withdrawn. Its layout

\mathsf{leadByte}\,\|\,d\,\|\,v\,\|\,\mathsf{rseed}\,\|\,\mathsf{asset\_base}% \,\|\,\mathsf{K}^{\mathsf{memo}}

presupposes the memo key $\mathsf{K}^{\mathsf{memo}}$ of ZIP 231, which is now defined only for version- $7$ transactions (ZIP 231, “Specification”), and a lead byte that live text assigns otherwise (Remark 3.6). No current ZIP defines an OrchardZSA plaintext encoding. The statement of withdrawn ZIP 230 that Orchard and native OrchardZSA notes need not be distinguished in plaintexts carries no weight; the commitment half of that statement follows from Definition 3.2.

3.5 The per-Asset value commitment

Definition 3.8 (Per-Asset value commitment).

Let an Action (Ironwood Guide, Definition “Action”) consume an OrchardZSA note of value $v^{\mathsf{old}}$ and create an OrchardZSA note of value $v^{\mathsf{new}}$ , both with Asset Base $\mathsf{AssetBase}\in\mathcal{E}^{*}$ . Its net value is the integer

v^{\mathsf{net}}:=v^{\mathsf{old}}-v^{\mathsf{new}}\in\{-2^{64}+1,\dots,2^{64}% -1\}.

For $\mathsf{rcv}$ drawn by the Ironwood Guide’s Construction “Value-commitment trapdoor”, its per-Asset value commitment is

\mathsf{cv}^{\mathsf{net}}:=\mathsf{ValueCommit}^{\mathsf{OrchardZSA}}_{% \mathsf{rcv}}(\mathsf{AssetBase},v^{\mathsf{net}}):=[v^{\mathsf{net}}\bmod p_{% \mathsf{Vesta}}]\,\mathsf{AssetBase}+[\mathsf{rcv}]\,R^{\mathsf{Orchard}},

with $R^{\mathsf{Orchard}}$ and the reading of $v^{\mathsf{net}}$ modulo $p_{\mathsf{Vesta}}$ as in the Ironwood Guide’s Definition “Net value commitment”. For $\mathsf{AssetBase}=V^{\mathsf{Orchard}}$ it equals $\mathsf{ValueCommit}^{\mathsf{Orchard}}_{\mathsf{rcv}}(v^{\mathsf{net}})$ . The only change against Orchard is that the fixed-base multiplication by $V^{\mathsf{Orchard}}$ becomes a variable-base multiplication by the Action’s Asset Base; the randomness term is unchanged. The condition that controls the base is stated in “The OrchardZSA Action statement” (§4.3) (ZIP 226, “Value Commitment”; protocol specification, §“Homomorphic Pedersen commitments (Sapling and Orchard)”). Class: specified.

Lemma 3.9 (Hiding and binding of per-Asset value commitments).

(i)

Perfect hiding. For every $B\in\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ and every integer $v$ , with $\mathsf{rcv}$ uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ and independent of $(B,v)$ , the point $[v\bmod p_{\mathsf{Vesta}}]\,B+[\mathsf{rcv}]\,R^{\mathsf{Orchard}}$ is uniform on $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ .
(ii)

Binding across bases. Call a base admissible if it is given as the value of $\mathsf{GroupHash}$ at the input $(\texttt{z.cash:Orchard-cv},\texttt{v})$ or at $(\texttt{z.cash:OrchardZSA},D)$ for a byte string $D$ . Under the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas” and “GroupHash as a random oracle”, no efficient algorithm outputs, except with negligible probability, two families $((B_{i},v_{i}))_{i}$ and $((B^{\prime}_{j},v^{\prime}_{j}))_{j}$ of polynomial size, of admissible bases with integers, and trapdoors $\mathsf{rcv},\mathsf{rcv}^{\prime}$ , with

$\textstyle\sum_{i}[v_{i}]\,B_{i}+[\mathsf{rcv}]\,R^{\mathsf{Orchard}}=\sum_{j}% [v^{\prime}_{j}]\,B^{\prime}_{j}+[\mathsf{rcv}^{\prime}]\,R^{\mathsf{Orchard}}$

while the base-value vectors differ: for some group-hash input $x$ , the sum of the $v_{i}$ at bases with input $x$ and the sum of the $v^{\prime}_{j}$ at bases with input $x$ differ modulo $p_{\mathsf{Vesta}}$ . For one pair each, $(B,v)$ and $(B^{\prime},v^{\prime})$ with inputs $x$ and $x^{\prime}$ , equal commitments force $x=x^{\prime}$ , hence $B=B^{\prime}$ , and $v\equiv v^{\prime}$ , or else $v\equiv v^{\prime}\equiv 0\pmod{p_{\mathsf{Vesta}}}$ .
(iii)

Binding fails for arbitrary bases. For $B\neq\mathcal{O}$ , $v\not\equiv 0$ and $v^{\prime}\not\equiv 0,v\pmod{p_{\mathsf{Vesta}}}$ , the point $B^{\prime}:=[v\,v^{\prime-1}]\,B$ satisfies $B^{\prime}\notin\{\mathcal{O},B\}$ and $[v]\,B=[v^{\prime}]\,B^{\prime}$ , so the two openings $(B,v)$ and $(B^{\prime},v^{\prime})$ share every trapdoor and every commitment. Hence the Action statement must control the base.

Status (Definition 1.3): proved here; conditional on no unspecified object.

Proof.

(i) The proof of the Ironwood Guide’s Lemma “Hiding and binding of net value commitments” (i) uses only $R^{\mathsf{Orchard}}\neq\mathcal{O}$ and the prime order $p_{\mathsf{Vesta}}$ of the group, not the value base: $[\mathsf{rcv}]\,R^{\mathsf{Orchard}}$ is uniform, and so is its translate by the fixed point $[v\bmod p_{\mathsf{Vesta}}]\,B$ .

(ii) Let $P_{x}$ denote the value of $\mathsf{GroupHash}$ at input $x$ , and $c_{x}$ the difference, modulo $p_{\mathsf{Vesta}}$ , of the two sums of values at input $x$ . Grouping both sides by input, a double opening gives

\textstyle\sum_{x}[c_{x}]\,P_{x}+[\mathsf{rcv}-\mathsf{rcv}^{\prime}]\,R^{% \mathsf{Orchard}}=\mathcal{O}

with some $c_{x}\neq 0$ , the relation of the proof of the Crypto Guide’s Theorem “Properties of the vector commitment” (§“Pedersen vector commitments”). The inputs $x$ are pairwise distinct by construction, and distinct from the input $(\texttt{z.cash:Orchard-cv},\texttt{r})$ of $R^{\mathsf{Orchard}}$ : the input of $V^{\mathsf{Orchard}}$ differs from it in the message, and every input under z.cash:OrchardZSA differs from both by Lemma 2.8. The relation is therefore non-trivial among values of $\mathsf{GroupHash}$ at distinct inputs, and the Ironwood Guide’s Lemma “Relations among fixed generators” excludes it except with negligible probability. For one pair each, $x\neq x^{\prime}$ gives $c_{x}=v$ and $c_{x^{\prime}}=-v^{\prime}$ , non-trivial unless $v\equiv v^{\prime}\equiv 0$ ; and $x=x^{\prime}$ gives $c_{x}=v-v^{\prime}$ , non-trivial unless $v\equiv v^{\prime}$ .

(iii) Direct computation: $[v^{\prime}]\,B^{\prime}=[v^{\prime}v\,v^{\prime-1}]\,B=[v]\,B$ ; the scalar $v\,v^{\prime-1}$ is neither $0$ nor $1$ modulo $p_{\mathsf{Vesta}}$ , and $B$ generates the group of prime order $p_{\mathsf{Vesta}}$ , so $B^{\prime}\neq\mathcal{O}$ and $B^{\prime}\neq B$ . □

ZIP 226, “Rationale for Value Commitment”, states the change of value base without a binding argument; Lemma 3.9 supplies it for bases of the admissible form, and part (iii) shows that the form cannot be dropped.