The Zcash ArboretumZSA Guide PDF

9 Security

This section composes the propositions stated at their objects into the five requirements of Definition 1.8, as Table 2 names them: Theorem 9.5 discharges Z1 and Z2; Theorem 9.7, with Proposition 7.8, discharges Z3; Theorem 9.8 discharges Z4; and Theorem 9.11 discharges Z5. The model and the assumptions are fixed in §9.1, and the four theorems are proved in §9.2 to §9.5.

The conventions are those of the Ironwood Guide, §“Security”, cited, not restated. Efficient adversaries and negligible functions are those of the Crypto Guide, §“Adversaries and the security parameter”, and computational indistinguishability is that of its Definition “Perfect, statistical, and computational indistinguishability” (§“Distribution ensembles and indistinguishability”). Every reduction simulates the honest parties and the random oracles, which are independent of one another. Every result holds except with negligible probability, and every result that uses a property of key generation is claimed for keys generated as the Ironwood Guide, §“Security”, claims them, with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾.

9.1 Accepted transactions and assumptions

Definition 9.1 (Accepted OrchardZSA transactions and witnesses).

The definition extends the Ironwood Guide’s Definition “Pools, accepted Actions and witnesses” to OrchardZSA.

  1. (a)

    Pool. The pool is the pool that carries OrchardZSA notes, which Remark 1.7 leaves open. It has one note commitment tree, one nullifier set and one issuance state 𝗂𝗌𝗌𝗎𝖾𝖽⁢_⁢𝖺𝗌𝗌𝖾𝗍𝗌 (Definition 7.1); every statement below uses these.

  2. (b)

    Valid chain. An adversary outputs a valid chain: a sequence of blocks each of whose transactions passes Construction 7.10 against the tree, the nullifier set and the issuance state that the transactions before it produce, the tree being extended in the order of Definition 7.4 and the issuance state by Construction 7.3. An Action, an Action Group (Definition 4.13), an OrchardZSA bundle (Definition 5.2) or an Issuance Bundle (Definition 6.5) of a transaction of a valid chain is accepted.

  3. (c)

    Witnesses. The witness of an accepted OrchardZSA Action is the auxiliary input that the extractor of Assumption 4.9 outputs for the proof of its Action Group, the assumption being applied to each Action Group as the Ironwood Guide applies its knowledge-soundness assumption to each bundle (the paragraph after its Definition “Pools, accepted Actions and witnesses”). It contains 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾, 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍, 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀 and ψ𝗇𝖿 besides the Orchard witness, and satisfies Definition 4.6. The Action consumes the note

    (𝗀𝖽𝗈𝗅𝖽,𝗉𝗄𝖽𝗈𝗅𝖽,v𝗈𝗅𝖽,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,ρ𝗈𝗅𝖽,ψ𝗈𝗅𝖽,𝗋𝖼𝗆𝗈𝗅𝖽)

    of its witness, with value v′:=0 if 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1 and v′:=v𝗈𝗅𝖽 otherwise (the notation of A4′), and creates the note

    (𝗀𝖽𝗇𝖾𝗐,𝗉𝗄𝖽𝗇𝖾𝗐,v𝗇𝖾𝗐,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,ρ𝗇𝖾𝗐,ψ𝗇𝖾𝗐,𝗋𝖼𝗆𝗇𝖾𝗐),

    with ρ𝗇𝖾𝗐 the published nullifier. Notes are given by expanded receivers as in item (d) of the cited definition. An accepted Action with 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0 is a real spend of its consumed note; one with 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1 is a Split Action (Definition 4.2). The shared pool also admits Orchard-protocol Actions (ZIP 226, “Privacy Implications”); the witness of such an Action is that of the Ironwood Guide’s Assumption “Knowledge soundness of the Action proof”, and every such Action is a real spend.

  4. (d)

    Issue Notes. An Issue Note of an accepted Issuance Bundle is given by its published fields and the Asset Base that rule (I4) of Construction 7.3 derives. Its note commitment is the one that the validator computes by rule (I6), which presupposes a fixed deterministic derivation of 𝗋𝖼𝗆 (Remark 6.2, Definition 1.3).

  5. (e)

    Committed notes and openings. A committed note is a note whose extracted commitment is a leaf of the tree. An opening of a leaf is a note whose extracted commitment equals it.

  6. (f)

    Adversary. The adversary controls every party except the honest ones that it attacks. It may generate issuance keys, issue Assets under them with any descriptions, choose every field of its own transactions, copy any leaf as a Split Input, and obtain from each honest issuer the signed transactions that the issuer composes, in an order that it schedules.

(ZIP 226, “Specification”; ZIP 227, “Specification: Consensus Rule Changes”.)

By the union bound over the polynomially many Action Groups of a valid chain, every witness satisfies Definition 4.6, except with negligible probability. Conditions A1′, A2′, A3′ and A7 then hold in their unweakened forms, without the ⊥ case, except with negligible probability, by the Ironwood Guide’s Remark “⊥-weakened conditions” (§“The Action statement”) and, for the custom branch of A1′ and A2′, by Proposition 3.3(c), under the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas” and “GroupHash as a random oracle”. The results below include this event in their negligible terms.

Remark 9.2 (Standing assumptions).

The results of this section rest on the following assumptions, each stated in the text named.

  1. 1.
  2. 2.

    The Ironwood Guide’s Assumption “Collision resistance of BLAKE2b” (§“Transaction digests and signatures”), and Assumption 2.9 (“Asset Digests and Asset Bases”).

  3. 3.

    Assumption 6.8 (“Computation of ρ for Issue Notes”).

  4. 4.

    Assumption 2.3 (“Issuance keys and the issuer identifier”).

  5. 5.

    Assumptions 4.9 and 4.10 (“The OrchardZSA Action proof”), and the Ironwood Guide’s Assumption “Knowledge soundness of the Action proof” for Orchard-protocol Actions.

  6. 6.
  7. 7.
  8. 8.

    The hypothesis H-SIG, Assumption 6.13 (“Issuance authorisation”), in the form that Remark 8.2 states as the obligation on a digest.

Following Definition 1.3, three of them concern designed but unspecified objects: Assumptions 4.9 and 4.10, the circuit and its verifying key, and Assumption 6.13, the signed message. Each result below names which of these it is conditional on, and the results about Issue Notes add the fixed derivation of 𝗋𝖼𝗆. The Ironwood Guide’s results on its own statement, for example its Theorems “Balance” and “Privacy of an Action”, are not cited as proved for OrchardZSA; only their proof steps are reused, each cited at its use.

9.2 Asset Bases and balance of accepted bundles

Lemma 9.3 (Provenance of Asset Bases).

Under Assumption 4.9, the Ironwood Guide’s Assumptions “Knowledge soundness of the Action proof”, “GroupHash as a random oracle” and “Discrete logarithms on Pallas”, in every valid chain, except with negligible probability:

  1. (i)

    every leaf of the tree has at most one opening that an efficient algorithm finds;

  2. (ii)

    every leaf whose opening has 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 opens to a note whose Asset Base is

    𝖹𝖲𝖠𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗌𝖾⁢(𝖠𝗌𝗌𝖾𝗍𝖣𝗂𝗀𝖾𝗌𝗍(𝗂𝗌𝗌𝗎𝖾𝗋,𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁))

    (Construction 2.10) for the 𝗂𝗌𝗌𝗎𝖾𝗋 of an accepted Issuance Bundle and the 𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁 of one of its Issuance Actions, whose Issue Notes precede the leaf, or include it, in the order of Definition 7.4;

  3. (iii)

    every leaf appended by an Orchard-protocol Action, before or after OrchardZSA, opens only with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, and the empty leaf opens to nothing.

Status (Definition 1.3): proved here for the specified statement and rules; conditional on Assumption 4.9, which concerns the designed but unspecified circuit, and, for the leaves of Issue Notes, on a fixed derivation of 𝗋𝖼𝗆, any deterministic one.

Proof.

Every step is carried out by the efficient algorithm that runs the adversary with the extractors and inspects the chain; the chain has polynomially many leaves, and the union bound collects the negligible events.

Uniqueness of openings. By Proposition 3.3(b), no efficient algorithm outputs two distinct OrchardZSA notes with equal extracted commitments other than ⊥, within one branch of Definition 3.2 or across the two; the sign ambiguity of extraction is handled in its proof by the Ironwood Guide’s Lemma “Coordinate extraction identifies opposite points”. An Orchard note is the native-branch OrchardZSA note with the same components, by the case split of that definition. Hence (i), and an opening found in the native branch excludes one in the custom branch.

Induction. The claim is proved for the leaves in the order of Definition 7.4, the hypothesis being (ii) and (iii) for all earlier leaves. A position beyond the appended leaves holds 𝖴𝗇𝖼𝗈𝗆𝗆𝗂𝗍𝗍𝖾𝖽𝖮𝗋𝖼𝗁𝖺𝗋𝖽=2, which by the Ironwood Guide’s Lemma “Uncommitted leaves” is the extracted commitment of no note, since in both branches 𝖼𝗆𝗑 is ⊥ or the extraction of a point. Every appended leaf is of one of three kinds.

Orchard-protocol Action. The witness of the Action that appended the leaf creates a note whose commitment 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝖮𝗋𝖼𝗁𝖺𝗋𝖽, by the unweakened condition A2, extracts to the leaf. That commitment is the native branch of 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠 (Definition 3.2), so the leaf has an opening with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, and by (i) no other. This holds for leaves appended before OrchardZSA and after it.

OrchardZSA Action. Let the witness have 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=B. If B=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 there is nothing to show. Otherwise 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=0 by C1, so the first disjunct of A3′ fails, and the unweakened A3′ gives a valid path from 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(𝖼𝗆𝗈𝗅𝖽) to the anchor 𝑟𝑡 of the Action Group. By check (4) of Construction 7.10, the anchor is the root of the tree in the final treestate of an earlier block. By the Ironwood Guide’s Proposition “Membership soundness”, and since 𝖼𝗆𝗈𝗅𝖽≠⊥ by the unweakened A1′, the value 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(𝖼𝗆𝗈𝗅𝖽) is a leaf appended by an earlier transaction. By A1′, the consumed note, of Asset Base B, opens that leaf, and by (i) it is its opening. By the hypothesis, B is the Asset Base derived from the 𝗂𝗌𝗌𝗎𝖾𝗋 and an 𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁 of an earlier accepted Issuance Action whose Issue Notes precede that leaf. By A2′, the created note carries the same B and opens the new leaf, and by (i) it is its opening. The case covers Split Actions: A3′ demands the path for every consumed note with 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=0, whatever its value and 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀, and C3 forbids 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1 with 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=1.

Issue Note. Rule (I4) derives the Asset Base from the bundle’s 𝗂𝗌𝗌𝗎𝖾𝗋 and the action’s 𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁 by Construction 2.10; rule (I6) makes the validator compute the commitment from that base and the published fields (Remark 6.14), with the fixed derivation of 𝗋𝖼𝗆; its commitment is not ⊥ except with negligible probability, by Proposition 3.3(c), its Asset Base being a custom one (Proposition 2.13). The Issue Note therefore opens the leaf, and by (i) it is its opening; its Asset Base is the derived one, which differs from V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 except with negligible probability (Proposition 2.13), and its own Issuance Action includes the leaf. □

ZIP 226 states the conclusion in rationale: “This ensures that the value base points of all output notes of a transfer are actual outputs of a GroupHash, as they originate in the Issuance protocol which is publicly verified” (“Rationale for Split Notes”), and the output notes “receive an Asset Base that exists on the global state” (“Rationale for Asset Identifiers”). In Lemma 9.3, existence on the global state is realised by membership in the tree; the proof never consults 𝗂𝗌𝗌𝗎𝖾𝖽⁢_⁢𝖺𝗌𝗌𝖾𝗍𝗌 (ZIP 227, “Addition to the Note Commitment Tree”). Figure 3 draws the induction.

Refer to caption
Figure 3: Provenance of Asset Bases in the tree, the induction of Lemma 9.3. One transaction T appends its leaves in the order of Definition 7.4: the outputs of its Actions, then its Issue Notes. Earlier leaves (grey) satisfy the induction hypothesis; a leaf appended by an Orchard-protocol Action opens only with V𝖮𝗋𝖼𝗁𝖺𝗋𝖽. An Action output of a Custom Asset B (blue) inherits B from an earlier leaf through A1′, A2′ and A3′; C1 confines the exemption from membership to ZEC (amber). The Asset Base B′ of an Issue Note (green) is derived by the validator from 𝗂𝗌𝗌𝗎𝖾𝗋 and 𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁 by (I4), and its commitment computed by (I6). The empty leaf 2 opens to no note.
Corollary 9.4 (Asset Bases of accepted Actions).

Under the assumptions of Lemma 9.3, in every valid chain, except with negligible probability, every Asset Base witnessed by an accepted OrchardZSA Action is V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 or 𝖹𝖲𝖠𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗌𝖾⁢(𝖠𝗌𝗌𝖾𝗍𝖣𝗂𝗀𝖾𝗌𝗍) of the Asset Identifier of an Issuance Action of an accepted Issuance Bundle of an earlier transaction. No transactor chooses an Asset Base: every Custom Asset Base in an accepted Action is one that a validator derived. Status (Definition 1.3): proved here; conditional on Assumption 4.9 and, through Lemma 9.3, on a fixed derivation of 𝗋𝖼𝗆 for Issue Notes.

Proof.

For a witness with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 there is nothing to show. The exemption of A3′ applies only to such consumed notes, since C1 makes 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=1 exactly when 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽. Otherwise, as in the proof of Lemma 9.3, A3′ and the Ironwood Guide’s Proposition “Membership soundness” make the consumed note an opening of a leaf of the treestate at the anchor, appended by an earlier transaction; A1′ fixes its Asset Base as the witnessed one; and Lemma 9.3(ii) applies to that leaf. The only place where an Asset Base not derived by a validator could enter an Action is a consumed note without a membership proof, which C1 and A3′ confine to V𝖮𝗋𝖼𝗁𝖺𝗋𝖽; Proposition 4.1 shows that the confinement is necessary (ZIP 226, “Circuit Statement”, “Asset Base Equality” and the modified Merkle path condition). □

Theorem 9.5 (No counterfeiting across Assets).

Assume Assumption 4.9, Assumption 2.9, and the Ironwood Guide’s Assumptions “Knowledge soundness of the Action proof”, “GroupHash as a random oracle”, “Discrete logarithms on Pallas” and “The RedPallas hash as a random oracle”; the collision resistance of the Sinsemilla instances used by that volume’s Proposition “Membership soundness” follows from “GroupHash as a random oracle” and “Discrete logarithms on Pallas”. In every valid chain, except with negligible probability, every accepted OrchardZSA bundle, with Actions i, burn set 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇 and balancing value v𝖻𝖺𝗅𝖺𝗇𝖼𝖾, satisfies the following, as equalities of integers, the values being read from the witnesses:

  1. (i)

    for every point B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

    ∑i:𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i=B(vi′−vi𝗇𝖾𝗐)=vB,

    where vB is the amount of the pair (B,vB)∈𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇, or 0 if there is none;

  2. (ii)

    ∑i:𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽(vi′−vi𝗇𝖾𝗐)=v𝖻𝖺𝗅𝖺𝗇𝖼𝖾;

  3. (iii)

    distinct Assets have distinct Asset Bases, and no Custom Asset has the Asset Base V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, so that (i) and (ii) hold per Asset.

Hence no accepted bundle creates value of one Asset from value of another Asset or from nothing (requirements Z1 and Z2). The statement concerns the accepted bundles of a valid chain, not single bundles: the Asset Bases of burn pairs are constrained only by rule (T4) of Construction 7.3 against the issuance state. Status (Definition 1.3): proved here for the specified constructions; conditional on Assumption 4.9, which concerns the designed but unspecified circuit, and on a fixed derivation of 𝗋𝖼𝗆 for Issue Notes, and not on Assumption 6.13. ZIP 226 argues the property in rationale only.

Proof.

Witnessed Asset Bases. By Corollary 9.4, each is V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 or

𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁⁢(z.cash:OrchardZSA,D)

for the Asset Digest D of an accepted Issuance Action.

Asset Bases of burn pairs. By rule (T4) every burn pair of an accepted transaction has an Asset Base in the domain of its input state, and by Lemma 7.7 every such Asset Base is 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁⁢(z.cash:OrchardZSA,D) for the Asset Digest D of an accepted Issuance Action. Rule (B1) alone does not give this.

Premise and balance. Every input (z.cash:OrchardZSA,D) differs from the inputs of V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 (Lemma 2.8). Each such input is computable from the chain, by searching its Issuance Actions for one whose derived Asset Base is the point. So the algorithm that runs the adversary with the extractors, and outputs the accepted bundles together with these inputs whenever it finds them, outputs bundles whose set 𝔅 meets the premise on the bases of §5.3; by the two preceding steps it fails to find an input only with negligible probability. Parts (a) and (b) of Proposition 5.6 then give (i) and (ii), the congruences modulo p𝖵𝖾𝗌𝗍𝖺 being lifted to integers by Lemma 5.5, whose hypotheses hold for every bundle of a valid block. A Split Action contributes v′=0 by A4′, so the value of a copied note never enters these sums. No other term of 𝖻𝗏𝗄 carries a Custom Asset (Remark 5.3).

Part (iii). Claims 2 and 3 of Proposition 2.13: distinct Asset Identifiers have distinct Asset Bases, and no Asset Base of a Custom Asset equals V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, except with negligible probability, under Assumption 2.9 and the Ironwood Guide’s Assumption “GroupHash as a random oracle”. □

Each premise of the proof is necessary. For witnessed Asset Bases, Proposition 4.1 creates ZEC from a witnessed base [−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 when the exemption of A3′ is not confined to ZEC. For burn pairs, the example after Proposition 5.6 creates 2⁢v units of an issued Asset B with the pair ([−2]⁢B,v), which rules (B1) to (B3) admit and rule (T4) rejects. ZIP 226, “Rationale for Split Notes”, “Value Balance Verification” and “Additional Consensus Rules for the assetBurn set”, gives the argument informally; the proof here does not change the class of that rationale, and ZIP 227, “Specification: Consensus Rule Changes”, supplies rule (T4).

9.3 Circulating supply

Lemma 9.6 (One consumption per OrchardZSA note).

Under Assumption 4.9, Assumption 6.8, and the Ironwood Guide’s Assumptions “Knowledge soundness of the Action proof”, “GroupHash as a random oracle” and “Discrete logarithms on Pallas”, in every valid chain, except with negligible probability:

  1. (a)

    the openings of the leaves of the tree have pairwise distinct elements ρ, and are therefore pairwise distinct notes;

  2. (b)

    every committed note is consumed by at most one accepted real spend;

  3. (c)

    a Split Action contributes v′=0 and publishes a nullifier that is not the nullifier of its copied note.

Status (Definition 1.3): proved here; conditional on Assumption 4.9, which concerns the designed but unspecified circuit, and, for the leaves of Issue Notes, on a fixed derivation of 𝗋𝖼𝗆, any deterministic one.

Proof.

By Lemma 9.3(i), the opening of a leaf appended by an Action is the note that the Action’s witness creates, and the opening of a leaf appended by issuance is the Issue Note.

(a) Three cases cover every pair of leaves.

Two Action outputs. The note created by an accepted Action, of either protocol, has ρ equal to that Action’s published nullifier (A2′ with ρ𝗇𝖾𝗐:=𝗇𝖿𝗈𝗅𝖽, or A2), and the published nullifiers, real and split, are pairwise distinct by the nullifier-set rule, check (5) of Construction 7.10.

Two Issue Notes. Their elements ρ are pairwise distinct by Proposition 6.9, under Assumption 6.8.

An Action output and an Issue Note. It suffices that no accepted Action publishes a nullifier equal to the ρ of an Issue Note of the chain, in whichever order the two occur; Proposition 6.9 covers only the Action outputs fixed before the issued value. Let an efficient algorithm 𝒜′, running the adversary with the extractors, find such a pair with probability ϵ. The published nullifier is 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(Q), where by A5′ (or A5)

Q=[s]⁢K𝖮𝗋𝖼𝗁𝖺𝗋𝖽+𝖼𝗆𝗈𝗅𝖽orQ=[s]⁢K𝖮𝗋𝖼𝗁𝖺𝗋𝖽+𝖼𝗆𝗈𝗅𝖽+L𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

the second for a split nullifier, with s computed from the witness. By the unweakened A1′ (or A1), 𝖼𝗆𝗈𝗅𝖽≠⊥ is, by the unfolding of the Ironwood Guide’s Construction “Sinsemilla hash on Pallas” used in the proof of Proposition 4.5(i), an integer combination of values of 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 with coefficients computable from the witness; so is Q. A reduction to the Ironwood Guide’s Assumption “Discrete logarithms on Pallas” receives a challenge Y to a base G, programs every value of 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 as [a]⁢G for a fresh uniform scalar a, as in the proof of that volume’s Lemma “Relations among fixed generators”, chooses uniformly one of the at most q queries to the oracle of personalisation Zcash_ExpandSeed, and answers it with a uniform 64-byte string u conditioned on ToBase⁢(u)=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(Y+[b]⁢G), for a uniform scalar b. If 𝒜′ succeeds at that query, then 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(Q)=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(Y+[b]⁢G), so Q=±(Y+[b]⁢G) by the Ironwood Guide’s Lemma “Coordinate extraction identifies opposite points”; with Q=[c]⁢G for the computed c, the reduction outputs ±c−b, the discrete logarithm of Y. The programmed answer differs from a uniform one in that its reduction is the x-coordinate of a point, up to the statistical distance of ToBase from uniform, below 2−257 (Proposition 4.5); success requires the issued ρ to be such a coordinate in any case, and, given that it is one, the two distributions of ρ are within negligible statistical distance. The reduction therefore succeeds with probability at least ϵ/q less a negligible term, and ϵ is negligible.

Notes with distinct ρ are distinct.

(b) The steps of the proof of the Ironwood Guide’s Lemma “One nullifier per note” apply, with A1′ in place of A1 and A5′ with 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0, which sets ψ𝗇𝖿=ψ𝗈𝗅𝖽 and publishes 𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋𝗇𝗄⁢(ρ𝗈𝗅𝖽,ψ𝗈𝗅𝖽,𝖼𝗆𝗈𝗅𝖽), in place of A5; A7 is unchanged. Two real spends, of either protocol, whose consumed notes have the same extracted commitment consume the same note, by Proposition 3.3(b), with the same 𝗇𝗄, by the Ironwood Guide’s Proposition “Binding of 𝗂𝗏𝗄 to (𝖺𝗄,𝗇𝗄)”, and publish the same nullifier. The nullifier-set rule rejects a repeated nullifier within a transaction and across the chain.

(c) The value v′=0 is the notation of A4′ for 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1. The nullifier is the split nullifier of A5′, and by Proposition 4.5(i), which holds for every ψ𝗇𝖿, including one that the adversary chooses, it is not the nullifier of the copied note, except with negligible probability. A split nullifier that equals the nullifier of some other note only prevents the later spend of that note; it creates no value, and the note is not thereby consumed in the sense of Definition 9.1(c). (ZIP 226, “Split Notes”; ZIP 227, “Computation of ρ”; protocol specification, §“Nullifier Sets”.) □

Theorem 9.7 (Supply integrity).

Under the assumptions of Theorem 9.5 and Lemma 9.6, for every valid chain, every point B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and every state of the chain after a transaction, except with negligible probability,

∑nv⁢(n)=𝗂𝗌𝗌𝗎𝖾𝖽⁢_⁢𝖺𝗌𝗌𝖾𝗍𝗌⁢(B).𝖻𝖺𝗅𝖺𝗇𝖼𝖾,

the sum being over the committed notes n with Asset Base B that no accepted real spend has consumed, and v⁢(n) being the value of n. By Proposition 7.9, the right-hand side is the amount of B issued less the amount burnt. Consequently the amount of B in circulation is never negative and is at most 𝖬𝖠𝖷⁢_⁢𝖨𝖲𝖲𝖴𝖤=264−1, and it is constant or falling once B is finalised (Proposition 7.8). The invariant holds per branch, since the issuance state is a function of the branch (Remark 7.2). Status (Definition 1.3): proved here for the specified constructions; conditional on Assumption 4.9, which concerns the designed but unspecified circuit, and on a fixed derivation of 𝗋𝖼𝗆 for Issue Notes, any deterministic one. ZIP 227 argues the property in rationale only.

Proof.

Induction over the transactions of the chain. Write UB for the left-hand side.

Base. Before the first transaction of the OrchardZSA activation block the issuance state is the empty map (Definition 7.1), whose balances read 0, and every leaf was appended by an Orchard-protocol Action, so by Lemma 9.3(iii) no committed note has a Custom Asset Base: UB=0.

Step. Let T be a transaction of the chain, B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, and let the claim hold before T. The leaves that T appends open uniquely (Lemma 9.3(i)) to notes distinct from the openings of all other leaves (Lemma 9.6(a)), and each is unconsumed when appended.

Orchard-protocol Actions of T. They create native notes only (Lemma 9.3(iii)). A note that such an Action consumes is a native note; by Lemma 9.3(i) it is not the opening of a leaf of Asset Base B. They leave UB unchanged.

The Action Group of T and its burn set. Let RB be its real spends witnessing B, and AB all its Actions witnessing B. A note of Asset Base B consumed by an Action of T is consumed by an Action witnessing B, by A1′. The consumed notes of RB are committed, by A3′ with C1 and the Ironwood Guide’s Proposition “Membership soundness”, as in the proof of Lemma 9.3; and they were unconsumed before T and are pairwise distinct, by Lemma 9.6(b). Split Actions are not real spends and remove no note from UB; each contributes v′=0 (Definition 9.1(c), Lemma 9.6(c)). Every Action of AB creates one note of Asset Base B whose leaf T appends (Definition 7.4). Hence UB changes by

∑i∈ABvi𝗇𝖾𝗐−∑i∈RBvi𝗈𝗅𝖽=−∑i∈AB(vi′−vi𝗇𝖾𝗐)=−vB,

the first equality because vi′=vi𝗈𝗅𝖽 on RB and vi′=0 on AB∖RB, and the second by Theorem 9.5(i), whose premise on burn-pair bases rests on (T4) and Lemma 7.7. Rule (T4) lowers the balance of B by the same vB. No transparent term carries B (Remark 5.3).

The Issuance Bundle of T. Each Issue Note of Asset Base B, that is of an Issuance Action whose derived base is B by (I4), enters the tree after the Action outputs (Definition 7.4) with its public value and unconsumed, and no Action of T consumes it: a consumed note of T opens a leaf of an earlier block, and by Lemma 9.6(a) that opening is not the Issue Note. Rule (I6) raises the balance of B by exactly that value; a reference note adds 0 to both sides. Issuance Actions of other Asset Bases write other entries.

Both sides therefore change equally, and the claim holds after T. The bounds follow from UB≥0 and Proposition 7.9, and the behaviour after finalisation from Proposition 7.8. □

The theorem, not the issuance state, excludes counterfeit value. ZIP 227, “Rationale for Global Issuance State”, keeps the state along the lines of ZIP 209 (“Specification”), and ZIP 227, “Global Issuance State” and “Management of the Global Issuance State”, maintain it. The state detects counterfeit value directly only when a burn exceeds the recorded balance, by rule (T4). A bundle that created unbacked value of B and did not burn it would pass every check on the map; Theorem 9.5 excludes such a bundle, and Theorem 9.7 inherits the exclusion.

9.4 Authority over issuance

Theorem 9.8 (Issuance authority).

Let an honest issuer generate 𝗂𝗌𝗄 as in Definition 2.1 and Assumption 2.3 and publish 𝗂𝗌𝗌𝗎𝖾𝗋=𝗂𝗄⁢_⁢𝖾𝗇𝖼𝗈𝖽𝗂𝗇𝗀 (Definition 2.4), and let the adversary of Definition 9.1 obtain the transactions that the issuer signs. An Asset of the honest issuer is an Asset whose Asset Identifier has that 𝗂𝗌𝗌𝗎𝖾𝗋. Under Assumption 2.3, Assumption 6.13, Assumption 2.9 and the Ironwood Guide’s Assumptions “Collision resistance of BLAKE2b” and “GroupHash as a random oracle”, in every valid chain that the adversary outputs, except with negligible probability:

  1. (i)

    every accepted Issuance Action whose Asset Base is that of an Asset of the honest issuer, and which raises its balance by rule (I6), sets its finalisation bit by rule (I7) or creates its entry with the reference note by rule (I5), belongs to a transaction whose Issuance Bundle has the effecting data, and whose transaction has the burn set and the nullifier 𝗇𝖿0,0, of a transaction that the honest issuer signed;

  2. (ii)

    the Issuance Bundle of each signed transaction is accepted at most once.

Hence only the holder of 𝗂𝗌𝗄 issues or finalises the issuer’s Assets (requirement Z4). Status (Definition 1.3): proved here for the specified rules; conditional on Assumption 6.13, which concerns the designed but unspecified signed message.

Proof.

Reduction. Let an accepted Issuance Action change the entry at an Asset Base B of an Asset of the honest issuer, with Asset Identifier (𝗂𝗌𝗌𝗎𝖾𝗋h,h). Rule (I4) derives B from the bundle’s 𝗂𝗌𝗌𝗎𝖾𝗋 and the action’s 𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁. If (𝗂𝗌𝗌𝗎𝖾𝗋,𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁)≠(𝗂𝗌𝗌𝗎𝖾𝗋h,h), two distinct Asset Identifiers have the Asset Base B, which claim 2 of Proposition 2.13 excludes, under Assumption 2.9 and the Ironwood Guide’s Assumption “GroupHash as a random oracle”, except with negligible probability. So the bundle’s 𝗂𝗌𝗌𝗎𝖾𝗋 is the honest 𝗂𝗄⁢_⁢𝖾𝗇𝖼𝗈𝖽𝗂𝗇𝗀. Rules (I2) and (I3) then require a signature valid under the honest 𝗂𝗄 on the transaction’s 𝖲𝗂𝗀𝖧𝖺𝗌𝗁.

If the honest issuer made no signature on that digest, the reduction, which answers the honest issuer’s signing through the signing oracle of the EUF-CMA experiment, outputs the digest and the signature of the chain, a forgery against Assumption 2.3. If it made one, on a transaction Th, then the two transactions have equal 𝖲𝗂𝗀𝖧𝖺𝗌𝗁, and Assumption 6.13, which for the withdrawn digest rests on the Ironwood Guide’s Assumption “Collision resistance of BLAKE2b” (Remark 8.2), makes their Issuance Bundles’ effecting data equal (𝗂𝗌𝗌𝗎𝖾𝗋 and, per Issuance Action, 𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁, 𝖿𝗂𝗇𝖺𝗅𝗂𝗓𝖾 and every field of every Issue Note), and their burn sets and nullifiers 𝗇𝖿0,0 equal. Every change of the entry, the finalisation bit included, is therefore one that the issuer authorised; this is (i).

Part (ii) is Proposition 6.16, by rule (I1) and the nullifier set on 𝗇𝖿0,0. Burns of the issuer’s Assets by note holders are outside the claim: rule (T4) only lowers the balance (ZIP 227, “Specification: Consensus Rule Changes” and “Issuance Authorization Signature Scheme”). □

Remark 9.9 (Issuance key compromise).

No rotation of issuance keys exists, and 𝗂𝗌𝗌𝗎𝖾𝗋 is the encoding 𝗂𝗄⁢_⁢𝖾𝗇𝖼𝗈𝖽𝗂𝗇𝗀 of the key; ZIP 227 notes that this equality “might not hold in future when key rotation is specified for issuance key pairs” (“Issuer Identifier”). The Asset Identifier of an Asset, and hence its Asset Base, stays bound to the key under which it was issued. On compromise of 𝗂𝗌𝗄, ZIP 227 recommends, without a requirement keyword, setting 𝖿𝗂𝗇𝖺𝗅𝗂𝗓𝖾=1 for every Asset issued with that key, changing to a new issuance authorising key, hence a new 𝗂𝗌𝗌𝗎𝖾𝗋, and issuing new Assets, each with a new Asset Identifier (“Issuance Key Compromise”). By rule (I4), finalisation bounds only the future issuance of the finalised Asset. It does not undo issuance by the attacker before the finalising transaction is accepted. An attacker that holds 𝗂𝗌𝗄 can issue up to 𝖬𝖠𝖷⁢_⁢𝖨𝖲𝖲𝖴𝖤 less the recorded balance of each unfinalised Asset, can finalise first, and can issue Assets under new descriptions, which no finalisation prevents; by consensus these are indistinguishable from the issuer’s own, and ZIP 227 treats their presentation only as a matter of display (“Security and Privacy Considerations”, “Displaying Asset Identifier information to users”). Theorem 9.8 assumes the secrecy of 𝗂𝗌𝗄 and says nothing after its compromise. Key rotation has no design in any text. The specified protocol needs it for no result of this volume, so its absence is a stated limitation, not an open problem in the sense of Definition 1.2 (ZIP 227, “Issuance Keys”).

9.5 Hiding of the Asset type

The Ironwood Guide’s Theorem “Privacy of an Action” is confined to Ironwood-pool bundles by precondition (P2) of its Definition “Public leakage and privacy preconditions”. It is not cited as proved here; the definition below has the form of that definition.

Definition 9.10 (Public leakage of an OrchardZSA bundle).

The public leakage of an OrchardZSA bundle is its number of Actions, its anchor, its flags 𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌, 𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌 and 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠, its balancing value, and its burn set, which publishes each burnt Asset Base and amount. The rest of the transaction is public as well, including any Issuance Bundle with every field of its Issue Notes (Remark 6.6) and the carrier that holds the bundle. The public fields are, per Action, 𝖼𝗏𝗇𝖾𝗍, 𝗇𝖿, 𝗋𝗄, 𝖼𝗆𝗑, 𝖾𝗉𝗄, C𝖾𝗇𝖼, C𝗈𝗎𝗍 and the spend-authorisation signature, and, per bundle, the proof and the binding signature. The private inputs are, per Action, its witness (Definition 4.6, with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾, 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍, 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀 and ψ𝗇𝖿), the plaintext of its created note (Definition 3.7), the outgoing viewing key under which its C𝗈𝗎𝗍 is formed, or ⊥, and whether its consumed side is a real note, a Split Input or a dummy. The privacy preconditions are:

  1. (Q1)

    every key involved is generated as in (P1) of the cited definition, except the all-zero spending key of a reference note copied as a Split Input, which is public (Definition 6.10);

  2. (Q2)

    honest construction: each created note has a fresh uniform 𝗋𝗌𝖾𝖾𝖽, and its 𝗋𝖼𝗆 is derived from 𝗋𝗌𝖾𝖾𝖽 by the designed 𝖣𝖾𝗋𝗂𝗏𝖾⁢_⁢𝗋𝖼𝗆 under an assigned lead byte (Remark 3.6); 𝗋𝖼𝗏 is uniform; α is drawn by 𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆; each Split Input has a fresh uniform 𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿 (Construction 4.4); dummy consumed notes occur only for ZEC and are formed as in the protocol specification, §“Dummy Notes (Orchard)”; each Split Input copies a leaf with the Action’s Asset Base whose recipient key is a key of (Q1) held by the sender, or the reference note; consumed notes are padded per Asset by the padding rule after Definition 4.2; each real consumed note is a note of a key of (Q1) that the sender accepted by the Ironwood Guide’s §“Trial decryption and note acceptance”; and the plaintext encoding has a length independent of the Asset;

  3. (Q3)

    authentication paths are computed from public data (the Ironwood Guide’s Lemma “Authentication paths from public data”);

  4. (Q4)

    the adversary holds no viewing key of a key of (Q1).

Within these preconditions the adversary may choose the consumed notes, the recipients, the Assets and the values, and may know the contents of the consumed notes (ZIP 226, “Burn Mechanism”, “Split Notes” and “Backward Compatibility”; protocol specification, §“Dummy Notes (Orchard)”).

Theorem 9.11 (Privacy of the Asset type).

Assume (Q1) to (Q4) of Definition 9.10, and let two sequences of private inputs of one OrchardZSA bundle have equal public leakage, both satisfy Definition 4.6 with the common anchor and flags, and each balance per Asset against the common burn set and balancing value. Assume Assumption 4.10 and the Ironwood Guide’s Assumptions “Pseudorandomness of PRF expansion”, “Joint hiding of the viewing keys”, “Poseidon is a PRF”, “DDH on Pallas”, “GroupHash as a random oracle”, “The note-encryption hashes as random oracles”, “Confidentiality and integrity of ChaCha20-Poly1305”, “The RedPallas hash as a random oracle” and “Discrete logarithms on Pallas”. Then the public fields of the two bundles are computationally indistinguishable.

Precisely, every efficient adversary has negligible advantage in the experiment of the Ironwood Guide’s Theorem “Privacy of an Action”, with the following changes: the leaves that the adversary outputs are those of the tree of Definition 9.1(a); it outputs in addition the common burn set and the flag 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠; and a specification gives, per Action, its Asset Base, a consumed side that is a dummy (for V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 only), a note of a key of (Q1) whose extracted commitment is a leaf, or a Split Input as in (Q2), and a created side as in that experiment. Each specification balances per Asset, the consumed notes of one key have pairwise distinct ρ, and the construction of (Q2) yields witnesses of Definition 4.6.

In particular a bundle reveals, beyond its leakage, neither which Assets its Actions move, nor how many distinct Assets, nor their values, nor which consumed sides are real, split or dummies; Remark 9.12 states what the leakage itself reveals (requirement Z5). Status (Definition 1.3): proved here; conditional on Assumption 4.10, which concerns the designed but unspecified circuit, on the unassigned lead byte for the uniformity of 𝗋𝖼𝗆, and on the open plaintext encoding. ZIP 226 argues the property in rationale only (“Overview”, “Privacy Implications”).

Proof.

For each of the two specifications, the hybrids H0 to H10 below change the probability that the adversary outputs 1 by a negligible amount (Crypto Guide, §“The hybrid argument”, Lemma “Hybrid lemma”; each hybrid is reached in polynomially many steps, one key or one Action at a time), and the two hybrids H10 are identically distributed. Every reduction runs the experiment with the adversary and samples every value that its hop does not concern. The keys involved are those of (Q1), the keys of the dummy consumed notes and the keys of dummy created notes.

Hybrid H0 is the real bundle.

Hybrid H1 (proof). The aggregate proof is the output of the simulator of Assumption 4.10 on the primary inputs, which are public, 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠 included; the witnesses satisfy Definition 4.6 by hypothesis. The cost is the statistical distance of that assumption. From H1 on, a witness enters the game only through the public fields computed from it.

Hybrid H2 (keys). Each key of (Q1) and each dummy key is replaced as in game G2 of the proof of the Ironwood Guide’s Theorem “Privacy of an Action” (its Lemmas “Rejection in key generation” and “Independence of domain-separated expansions”, and Assumption “Joint hiding of the viewing keys”), so that 𝖺𝗌𝗄, 𝗇𝗄, 𝗂𝗏𝗄, 𝖽𝗄 and 𝗈𝗏𝗄 of each key are independent and 𝖽𝗄 and 𝗈𝗏𝗄 uniform. The public all-zero key is left unchanged.

Hybrid H3 (randomisers). Each randomiser αi is replaced by a uniform scalar, as in game G4 of that proof (Ironwood Guide, Lemma “Distance of GenRandom from uniform”, and Assumption “The RedPallas hash as a random oracle”). Then 𝗋𝗌𝗄i=𝖺𝗌𝗄+αi is uniform and independent of 𝖺𝗌𝗄, the public 𝖺𝗌𝗄 of the all-zero key included, and each 𝗋𝗄i is a uniform point independent of 𝖺𝗄.

Hybrid H4 (signatures). Every spend-authorisation signature and the binding signature are replaced by simulated signatures under 𝗋𝗄i and 𝖻𝗏𝗄, programming the RedPallas hash, by the Crypto Guide’s Lemma “Signature simulation” (§“Security in the random oracle model and the forking lemma”). Its simulator applies to RedPallas, a Schnorr signature whose challenge is the RedPallas hash of the nonce commitment, the validating key and the message (Ironwood Guide, Construction “RedPallas”); the costs are the abort probability of the lemma and the statistical distance of the reduced hash output from a uniform scalar. No signing key enters the game from H4 on: neither 𝗋𝗌𝗄i nor 𝖻𝗌𝗄.

Hybrid H5 (value commitments). After H4, each trapdoor 𝗋𝖼𝗏i enters the game only through 𝖼𝗏i𝗇𝖾𝗍. Each 𝖼𝗏i𝗇𝖾𝗍 is replaced by an independent uniform point, by perfect hiding for every Asset Base (Lemma 3.9(i)); the key 𝖻𝗏𝗄 is computed from these points, the public burn set and the balancing value by Definition 5.4. The hop is perfect.

Hybrid H6 (split nullifiers). Each split nullifier is replaced by the x-coordinate of a uniform point, by Proposition 4.5(ii), at cost ϵ𝖾𝗑𝗉𝖺𝗇𝖽+ϵ𝖳𝗈𝖡𝖺𝗌𝖾+δ each. That proposition holds against an adversary that knows the copied note and 𝗇𝗄, so the reduction samples every key itself; it holds in particular for the public key of a reference note, and for a copied note that the same bundle spends.

Hybrid H7 (nullifiers of consumed notes). For each key that consumes a real or dummy note, 𝗇𝗄 enters the game after H6 only through the nullifiers of those notes, 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢([𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ)+ψ]⁢K𝖮𝗋𝖼𝗁𝖺𝗋𝖽+𝖼𝗆𝗈𝗅𝖽), where 𝖼𝗆𝗈𝗅𝖽 depends on the Asset Base. As in hybrids H4 and H5 of the proof of the Ironwood Guide’s Proposition “Nullifier unlinkability” and in game G5, the PRF is replaced by a random function (Assumption “Poseidon is a PRF”) and each multiplier of K𝖮𝗋𝖼𝗁𝖺𝗋𝖽 by a uniform scalar, so each nullifier is the x-coordinate of a uniform point whatever 𝖼𝗆𝗈𝗅𝖽 is. The real consumed notes of one key have pairwise distinct ρ by the definition of the experiment, which in a valid chain holds by Lemma 9.6(a), and a dummy consumed note has a key of its own.

Hybrid H8 (outgoing ciphertexts). Each C𝗈𝗎𝗍 is replaced by the encryption of a fixed string under an independent uniform key, as in game G3 (Ironwood Guide, Proposition “Confidentiality of the outgoing ciphertext”).

Hybrid H9 (ephemeral keys and note ciphertexts). For each created note, 𝖾𝗉𝗄 is replaced by a uniform non-identity point and C𝖾𝗇𝖼 by the encryption of a fixed plaintext of the common length, keeping every note commitment, by steps (1) to (4) of the proof of the Ironwood Guide’s Proposition “Confidentiality and key privacy of note encryption”, as in game G6. The common length is the hypothesis of (Q2) on the plaintext encoding.

After H9, the seed 𝗋𝗌𝖾𝖾𝖽 of each created note enters the game only through ψ and 𝗋𝖼𝗆, that is through 𝖼𝗆. With 𝗋𝖼𝗆 a PRF-expansion output of 𝗋𝗌𝖾𝖾𝖽 under an assigned lead byte, as for either derivation of Definition 3.5, the argument of the proof of the Ironwood Guide’s Proposition “Hiding under the derived trapdoor” places 𝗋𝖼𝗆 within negligible distance of a uniform scalar independent of the rest of the game.

Hybrid H10 (note commitments). Each 𝖼𝗆𝗑 is replaced by the x-coordinate of a uniform point, by hiding with one output distribution for both branches (Proposition 3.3(a)), as in game G7.

In H10 every public field is a uniform value independent of the specification, a simulated proof or signature on public values, or a function of the leakage of Definition 9.10: the value commitments, nullifiers and extracted commitments are uniform, each 𝖾𝗉𝗄 is a uniform non-identity point, the ciphertexts encrypt fixed strings under fresh keys, each 𝗋𝗄i is uniform, and 𝖻𝗏𝗄 is a function of these and of the common burn set and balancing value. The two hybrids H10 are therefore identically distributed, and the advantage is at most the sum of the costs for both specifications, which is negligible. □

Remark 9.12 (Limits of Asset-type privacy).
  1. (a)

    Leakage. Each burn publishes its Asset Base and amount, “the amount and identifier of the Asset being burnt” (ZIP 226, “Rationale for Value Balance Verification”). The flag 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠=0 shows that a bundle moves ZEC only (C2). The balancing value is an amount of ZEC. Issuance is public (Remark 6.6), although a later spend of an Issue Note is unlinkable to it (Proposition 6.4), except for a reference note.

  2. (b)

    Action count. Every Action has one Asset Base (A1′, A2′), consumes at most one real note and creates one note. A bundle whose Actions move k Assets, Asset j with ij real consumed notes and oj created notes, therefore has at least ∑j=1kmax⁡(ij,oj)≥k Actions, and the public number of Actions bounds k. Theorem 9.11 hides the Assets only among bundles with equal Action counts.

  3. (c)

    Order. ZIP 226 fixes no Action order. Theorem 9.11 holds for every order against an adversary bound by (Q4); it claims nothing against a recipient, which by (e) is outside its scope.

  4. (d)

    Anonymity set. ZIP 226, “Privacy Implications”, separates Orchard and OrchardZSA note commitments by transaction version, version 5 for Orchard and version 6 for OrchardZSA (Remark 3.4); no current format assigns these versions so (Remark 8.1). The anonymity set of an Action is the set of OrchardZSA Actions of whatever carrier is specified, and an Orchard-protocol bundle reveals that its notes are ZEC. The pool that carries OrchardZSA notes is the open problem of Remark 1.7.

  5. (e)

    Non-claims. The theorem claims nothing against a holder of a viewing key of a key involved; nothing for the copied note of a Split Input beyond the unlinkability of its split nullifier; and nothing about timing, network metadata or information outside the transaction.

(ZIP 226, “Privacy Implications”, “Rationale for Value Balance Verification” and “Asset Base Equality”.)