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 .
The definition extends the Ironwood Guide’s Definition “Pools, accepted Actions and witnesses” to OrchardZSA.
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.
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
of its witness, with value if and otherwise (the notation of A4′), and creates the note
with the published nullifier. Notes are given by expanded receivers as in item (d) of the cited definition. An accepted Action with is a real spend of its consumed note; one with 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.
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).
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.
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.
The results of this section rest on the following assumptions, each stated in the text named.
The Ironwood Guide’s Assumption “Collision resistance of BLAKE2b” (§“Transaction digests and signatures”), and Assumption 2.9 (“Asset Digests and Asset Bases”).
Assumption 6.8 (“Computation of for Issue Notes”).
Assumption 2.3 (“Issuance keys and the issuer identifier”).
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.
The Ironwood Guide’s Assumption “The RedPallas hash as a random oracle” (§“The RedPallas signature scheme”).
The assumptions of the Ironwood Guide’s Proposition “Confidentiality and key privacy of note encryption” (§“Encryption to the recipient”), and its Assumptions “Poseidon is a PRF” (§“The nullifier”), “Pseudorandomness of PRF expansion” (§“Pseudorandom functions and field reductions”) and “Joint hiding of the viewing keys” (§“Viewing keys”).
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.
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:
every leaf of the tree has at most one opening that an efficient algorithm finds;
every leaf appended by an Orchard-protocol Action, before or after OrchardZSA, opens only with , 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.
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 , 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 , and by (i) no other. This holds for leaves appended before OrchardZSA and after it.
OrchardZSA Action. Let the witness have . If there is nothing to show. Otherwise 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 , opens that leaf, and by (i) it is its opening. By the hypothesis, 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 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 , whatever its value and , and C3 forbids with .
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 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.
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 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.
For a witness with there is nothing to show. The exemption of A3′ applies only to such consumed notes, since C1 makes exactly when . 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 ; Proposition 4.1 shows that the confinement is necessary (ZIP 226, “Circuit Statement”, “Asset Base Equality” and the modified Merkle path condition). □
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 , burn set and balancing value , satisfies the following, as equalities of integers, the values being read from the witnesses:
for every point ,
where is the amount of the pair , or if there is none;
;
distinct Assets have distinct Asset Bases, and no Custom Asset has the Asset Base , 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.
Witnessed Asset Bases. By Corollary 9.4, each is or
for the Asset Digest 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 for the Asset Digest of an accepted Issuance Action. Rule (B1) alone does not give this.
Premise and balance. Every input differs from the inputs of and (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 being lifted to integers by Lemma 5.5, whose hypotheses hold for every bundle of a valid block. A Split Action contributes 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 , 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 when the exemption of A3′ is not confined to ZEC. For burn pairs, the example after Proposition 5.6 creates units of an issued Asset with the pair , 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).
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:
the openings of the leaves of the tree have pairwise distinct elements , and are therefore pairwise distinct notes;
every committed note is consumed by at most one accepted real spend;
a Split Action contributes 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.
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.
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 , where by A5′ (or A5)
the second for a split nullifier, with 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 . A reduction to the Ironwood Guide’s Assumption “Discrete logarithms on Pallas” receives a challenge to a base , programs every value of as for a fresh uniform scalar , as in the proof of that volume’s Lemma “Relations among fixed generators”, chooses uniformly one of the at most queries to the oracle of personalisation Zcash_ExpandSeed, and answers it with a uniform -byte string conditioned on , for a uniform scalar . If succeeds at that query, then , so by the Ironwood Guide’s Lemma “Coordinate extraction identifies opposite points”; with for the computed , the reduction outputs , the discrete logarithm of . The programmed answer differs from a uniform one in that its reduction is the -coordinate of a point, up to the statistical distance of from uniform, below (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 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 , 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 is the notation of A4′ for . 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”.) □
Under the assumptions of Theorem 9.5 and Lemma 9.6, for every valid chain, every point and every state of the chain after a transaction, except with negligible probability,
the sum being over the committed notes with Asset Base that no accepted real spend has consumed, and being the value of . By Proposition 7.9, the right-hand side is the amount of issued less the amount burnt. Consequently the amount of in circulation is never negative and is at most , and it is constant or falling once 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.
Induction over the transactions of the chain. Write 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 , and every leaf was appended by an Orchard-protocol Action, so by Lemma 9.3(iii) no committed note has a Custom Asset Base: .
Step. Let be a transaction of the chain, , and let the claim hold before . The leaves that 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 . 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 . They leave unchanged.
The Action Group of and its burn set. Let be its real spends witnessing , and all its Actions witnessing . A note of Asset Base consumed by an Action of is consumed by an Action witnessing , by A1′. The consumed notes of 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 and are pairwise distinct, by Lemma 9.6(b). Split Actions are not real spends and remove no note from ; each contributes (Definition 9.1(c), Lemma 9.6(c)). Every Action of creates one note of Asset Base whose leaf appends (Definition 7.4). Hence changes by
the first equality because on and on , 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 by the same . No transparent term carries (Remark 5.3).
The Issuance Bundle of . Each Issue Note of Asset Base , that is of an Issuance Action whose derived base is by (I4), enters the tree after the Action outputs (Definition 7.4) with its public value and unconsumed, and no Action of consumes it: a consumed note of 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 by exactly that value; a reference note adds to both sides. Issuance Actions of other Asset Bases write other entries.
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 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.
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:
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 , of a transaction that the honest issuer signed;
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.
Reduction. Let an accepted Issuance Action change the entry at an Asset Base of an Asset of the honest issuer, with Asset Identifier . Rule (I4) derives from the bundle’s and the action’s . If , two distinct Asset Identifiers have the Asset Base , 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 , 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 equal. Every change of the entry, the finalisation bit included, is therefore one that the issuer authorised; this is (i).
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 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”).
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.
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, , , , , , , 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 is formed, or , and whether its consumed side is a real note, a Split Input or a dummy. The privacy preconditions are:
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);
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;
authentication paths are computed from public data (the Ironwood Guide’s Lemma “Authentication paths from public data”);
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)”).
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 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”).
For each of the two specifications, the hybrids to below change the probability that the adversary outputs 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 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 is the real bundle.
Hybrid (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 on, a witness enters the game only through the public fields computed from it.
Hybrid (keys). Each key of (Q1) and each dummy key is replaced as in game 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 (randomisers). Each randomiser is replaced by a uniform scalar, as in game of that proof (Ironwood Guide, Lemma “Distance of GenRandom from uniform”, and Assumption “The RedPallas hash as a random oracle”). Then is uniform and independent of , the public of the all-zero key included, and each is a uniform point independent of .
Hybrid (signatures). Every spend-authorisation signature and the binding signature are replaced by simulated signatures under 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 on: neither nor .
Hybrid (value commitments). After , each trapdoor enters the game only through . Each 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 (split nullifiers). Each split nullifier is replaced by the -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 (nullifiers of consumed notes). For each key that consumes a real or dummy note, enters the game after only through the nullifiers of those notes, , where depends on the Asset Base. As in hybrids and of the proof of the Ironwood Guide’s Proposition “Nullifier unlinkability” and in game , the PRF is replaced by a random function (Assumption “Poseidon is a PRF”) and each multiplier of by a uniform scalar, so each nullifier is the -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 (outgoing ciphertexts). Each is replaced by the encryption of a fixed string under an independent uniform key, as in game (Ironwood Guide, Proposition “Confidentiality of the outgoing ciphertext”).
Hybrid (ephemeral keys and note ciphertexts). For each created note, is replaced by a uniform non-identity point and 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 . The common length is the hypothesis of (Q2) on the plaintext encoding.
After , 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 (note commitments). Each is replaced by the -coordinate of a uniform point, by hiding with one output distribution for both branches (Proposition 3.3(a)), as in game .
In 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 is uniform, and is a function of these and of the common burn set and balancing value. The two hybrids are therefore identically distributed, and the advantage is at most the sum of the costs for both specifications, which is negligible. □
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 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.
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 Assets, Asset with real consumed notes and created notes, therefore has at least Actions, and the public number of Actions bounds . Theorem 9.11 hides the Assets only among bundles with equal Action counts.
Anonymity set. ZIP 226, “Privacy Implications”, separates Orchard and OrchardZSA note commitments by transaction version, version for Orchard and version 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.
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”.)