The Zcash ArboretumThe Complete Arboretum PDF

4 OrchardZSA Actions and Action Groups

This section shows that the membership exemption of Orchard dummy notes is unsound once the value base of an Action is a witness, and defines the Split Inputs that replace dummy consumed notes for Custom Assets (§4.1); constructs the split nullifier and proves its independence from the nullifier of the copied note (§4.2); states the OrchardZSA Action statement as a delta on the Orchard one, with named conditions (§4.3); states the assumptions on its proof and proves that a Split Input requires the spend authority of the copied note (§4.4); and defines the Action Group (§4.5). The objects of the section are taken from ZIP 226 and ZIP 228, both Draft, with the rules of ZIP 227 that bound the number of Action Groups. The Orchard objects they modify are those of the Ironwood Guide and are cited, not restated.

4.1 Dummy notes and Split Inputs

By the Ironwood Guide’s Definition “Dummy notes” (§“Actions, bundles, and dummy notes”), an Action whose consumed side is unused consumes a dummy note of value 0: under a fresh key or, when 𝖾𝗇𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌=0 and the created note is real, at the expanded receiver of the created note and under the key from which that receiver derives. Condition A3 of that volume’s Definition “Orchard Action statement”, namely v𝗈𝗅𝖽⋅(𝑟𝑜𝑜𝑡−𝑟𝑡)=0 or some evaluation of 𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁 in the fold returns ⊥, exempts every consumed note of value 0 from membership (protocol specification, §“Dummy Notes (Orchard)” and §“Action Statement (Orchard)”). In the Orchard protocol the exemption is sound for value: condition A4 multiplies the value by the fixed generator V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 (Ironwood Guide, Definition “Net value commitment”), so a consumed note of value 0 contributes [0]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽=𝒪, whatever path it fails to prove. The per-Asset value commitment of Definition 3.8 multiplies by a witnessed Asset Base instead. The next proposition shows that the exemption, kept unchanged, then admits a balance violation.

Proposition 4.1 (Unsoundness of the dummy exemption under a witnessed base).

Let ℛ− be the relation obtained from the Ironwood Guide’s Definition “Orchard Action statement” by adding an auxiliary input A∈ℰ∗ and making three replacements: in A1 and A2, the commitment 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍 is replaced by 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠 of Definition 3.2 with Asset Base A for both notes; in A4, the net value commitment becomes

𝖼𝗏𝗇𝖾𝗍=[v𝗈𝗅𝖽−v𝗇𝖾𝗐]⁢A+[𝗋𝖼𝗏]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

as in Definition 3.8; condition A3 and conditions A5 to A10 are unchanged, so a consumed note of value 0 is exempt from membership whatever A is. Then for every v∈{1,…,264−1} there is a bundle of two Actions whose witnesses satisfy ℛ−, with balancing value 0 and no burn, whose binding signature verifies, and which creates a ZEC note, of Asset Base V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, of value v while every consumed note has value 0:

  1. Action 1 witnesses A:=[−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, v𝗈𝗅𝖽=0 and v𝗇𝖾𝗐=v;

  2. Action 2 witnesses A:=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, a dummy consumed note and v𝗇𝖾𝗐=v.

More generally, a witnessed base A=∑i[ai]⁢Bi with known coefficients ai over Asset Bases Bi contributes ∑i[ai⁢v]⁢Bi for a committed value v, so a value committed on A cancels values committed on the Bi. This is the attack of ZIP 226, “Rationale for Split Notes”: without the enforcement “the prover could input a multiple (or linear combination) of an existing Asset Base, and thereby attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds”. Status (Definition 1.3): proved here; ZIP 226 states the attack in words only.

Proof.

The point [−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 is not 𝒪, since V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 has prime order p𝖵𝖾𝗌𝗍𝖺, so Action 1 is well typed. Both consumed notes have value 0, so A3 holds for both Actions without a path, and A8 holds for either value of 𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌; A9 holds with 𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌=1. The remaining conditions hold when the commitments, the nullifiers and 𝗋𝗄 are computed from the witness by their definitions, under a key of the prover; each consumed note is placed at the expanded receiver of the note its Action creates, so that A10 holds for either value of 𝖽𝗂𝗌𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌, as in the Ironwood Guide’s Remark “Meaning of A10”. The net value commitments are

𝖼𝗏1𝗇𝖾𝗍 =[0−v]⁢([−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽)+[𝗋𝖼𝗏1]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽=[v]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽+[𝗋𝖼𝗏1]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽,
𝖼𝗏2𝗇𝖾𝗍 =[0−v]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽+[𝗋𝖼𝗏2]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽.

With balancing value 0 and no burn, the Ironwood Guide’s Definition “Binding validating key” gives

𝖻𝗏𝗄=𝖼𝗏1𝗇𝖾𝗍+𝖼𝗏2𝗇𝖾𝗍=[𝗋𝖼𝗏1+𝗋𝖼𝗏2]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

whose discrete logarithm 𝖻𝗌𝗄=𝗋𝖼𝗏1+𝗋𝖼𝗏2 to the base R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 the prover knows, so that volume’s Construction “Binding signature” produces a valid signature. Action 2 creates a ZEC note of value v, and no consumed note carries value. For the general case, [w]⁢(∑i[ai]⁢Bi)=∑i[ai⁢w]⁢Bi for every integer w, by bilinearity of scalar multiplication, and the same computation applies. □

Definition 4.2 (Split Input and Split Action).

Let B∈ℰ∗ with B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽. A Split Input of Asset Base B is an OrchardZSA note n=(d,𝗉𝗄𝖽,v,B,ρ,ψ,𝗋𝖼𝗆) (Definition 3.1), whose extracted commitment

𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗆𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢(n))

(Definition 3.2) is a leaf of the note commitment tree under the anchor of the consuming Action, consumed by an Action that sets the witness bit 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀:=1 of the statement defined in “The OrchardZSA Action statement” (§4.3). A Split Input differs from a spend of n in two respects only: its value is replaced by 0 in the net value commitment, while the commitment still opens with the true value v; and the Action publishes the split nullifier of “Nullifiers of OrchardZSA notes” (§4.2) in place of the nullifier of n. A Split Action is an Action whose consumed note is a Split Input. ZIP 226 calls n “a previously issued input note (that is, a note that has previously been included in the Merkle tree)”; any leaf of Asset Base B qualifies, whether its note was created by an Action or by issuance (ZIP 226, “Terminology” and “Split Notes”). Class: specified.

Padding rule. In a bundle (Ironwood Guide, Definition “Bundle”) of OrchardZSA Actions, for each Custom Asset whose Asset Base B has fewer consumed notes than created notes, the sender gives each input-less Action of B a Split Input of B (ZIP 226, “Split Notes”). Actions of ZEC keep the dummy consumed notes of the Ironwood Guide’s Definition “Dummy notes”; Actions of Custom Assets take no dummy consumed note (ZIP 226, “Backward Compatibility”). Both regimes occur within one bundle of OrchardZSA Actions. That bundle is not the Orchard-pool bundle of a version-6 transaction: version 6 is the format of ZIP 229, which carries no ZSA fields (ZIP 229, “Non-requirements”). ZIP 226 enforces in the statement that every consumed note of a Custom Asset, split or not and of any value, is a leaf: “for Custom Assets we enforce that every input note to an OrchardZSA Action must be proven to exist in the set of note commitments” (“Rationale for Split Notes”). The condition is constructed in “The OrchardZSA Action statement” (§4.3), and Corollary 9.4, in “Security”, states what it yields for the Asset Base of the created note.

Remark 4.3 (Choice of the copied note).

ZIP 226, “Split Notes”, lets the sender copy one of three notes of Asset Base B:

  1. (1)

    another note of B consumed by a real spend in the same bundle, but not by this Split Input;

  2. (2)

    a different unspent note of B, which is not thereby spent;

  3. (3)

    an already spent note of B, the zeroed value preventing a second spend.

It states that “we do not care about whether the previously issued note copied to create a Split Input is owned by the sender, or whether it was nullified before”. Proposition 4.12, in “The OrchardZSA Action proof” (§4.4), states which of these choices are available to a sender who does not hold the spend authority of the copied note. Under Remark 1.7, if OrchardZSA notes are in the Orchard pool, which ZIP 258, “Consensus rules from NU6.3 activation”, restricts to Actions with 𝖾𝗇𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌=0, then a Split Action whose created note is at an expanded receiver other than that of the copied note violates the cross-address rule. ZIP 226 does not address this case.

4.2 Nullifiers of OrchardZSA notes

An OrchardZSA note consumed by a real spend, with 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0, has the Orchard nullifier of the Ironwood Guide’s Definition “Nullifier”:

𝗇𝖿=𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋𝗇𝗄⁢(ρ,ψ,𝖼𝗆)=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢([(𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ)+ψ)modp𝖯𝖺𝗅𝗅𝖺𝗌]⁢K𝖮𝗋𝖼𝗁𝖺𝗋𝖽+𝖼𝗆),

with 𝖼𝗆=𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗆𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢(n) of Definition 3.2 (ZIP 226, “Note Structure and Commitment”: “generated in the same manner as in the Orchard protocol”; protocol specification, §“Computing ρ values and Nullifiers”). It depends on the Asset Base only through 𝖼𝗆; for a note with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 it is the Orchard nullifier bit for bit. The extension of the Ironwood Guide’s Lemma “One nullifier per note” to OrchardZSA notes is Lemma 9.6, in “Security”.

A Split Action publishes one nullifier, which enters the nullifier set of its pool, and a nullifier must not repeat, either within a transaction or across the block chain (Ironwood Guide, §“Nullifier sets”; protocol specification, §“Nullifier Sets”). The copied note may be unspent, choice (2) of Remark 4.3, or spent in the same bundle, choice (1). Publishing its nullifier would, in the first case, make it unspendable and, in the second, repeat a nullifier within the transaction, which invalidates the transaction. The nullifier of a Split Input must therefore differ from that of the copied note. ZIP 226 states the purpose of the change as privacy: it is made “to prevent the identification of notes” (“Circuit Statement”).

Construction 4.4 (Split nullifier).

Let L𝖮𝗋𝖼𝗁𝖺𝗋𝖽:=𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁⁢(z.cash:Orchard,L), the input of the second row of Table 3. For a Split Input with nullifier deriving key 𝗇𝗄, element ρ𝗈𝗅𝖽 and commitment 𝖼𝗆𝗈𝗅𝖽, the sender draws 𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿 uniformly from 𝔹𝕐⁢[32] and sets

ψ𝗇𝖿:=ToBase⁢(𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿⁢([𝟶⁢𝚡⁢𝟶⁢𝙰]∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(ρ𝗈𝗅𝖽)))∈𝔽p𝖯𝖺𝗅𝗅𝖺𝗌.

The split nullifier is

𝗇𝖿𝗈𝗅𝖽:=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢([(𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ𝗈𝗅𝖽)+ψ𝗇𝖿)modp𝖯𝖺𝗅𝗅𝖺𝗌]⁢K𝖮𝗋𝖼𝗁𝖺𝗋𝖽+𝖼𝗆𝗈𝗅𝖽+L𝖮𝗋𝖼𝗁𝖺𝗋𝖽).

Against the Ironwood Guide’s Definition “Nullifier” there are two changes: ψ𝗈𝗅𝖽 is replaced by the fresh ψ𝗇𝖿, and the fixed point L𝖮𝗋𝖼𝗁𝖺𝗋𝖽 is added before extraction. The derivation adds one row to that volume’s Construction “Domain bytes of PRF expansion”:

b Key κ Remainder t′ f Output Section
𝟶⁢𝚡⁢𝟶⁢𝙰 𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿 𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(ρ𝗈𝗅𝖽) ToBase ψ𝗇𝖿 §4.2

The key 𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿 is secret, uniform and used once. The byte 𝟶⁢𝚡⁢𝟶⁢𝙰 is reserved for this use by ZIP 2005’s amendment of §“Sending Notes (Orchard)” (ZIP 2005, “Changes to the Protocol Specification”; ZIP 226, “Split Notes”); the specification’s own list of expansion uses (§“Pseudo Random Functions”) does not record it, and ZIP 2005’s amendment of that list adds 𝟶⁢𝚡⁢𝟶⁢𝙰 and 𝟶⁢𝚡⁢𝟶⁢𝙱. It differs from the bytes 𝟶⁢𝚡⁢𝟶𝟺 of 𝖾𝗌𝗄, 𝟶⁢𝚡⁢𝟶𝟻 and 𝟶⁢𝚡⁢𝟶⁢𝙱 of 𝗋𝖼𝗆 and 𝟶⁢𝚡⁢𝟶𝟿 of ψ of the Orchard sending derivations (protocol specification, §“Sending Notes (Orchard)”; Definition 3.5). Class: specified, as a sender rule; Remark 4.8 states what the statement enforces.

Proposition 4.5 (Independence of split nullifiers).

Let n be an OrchardZSA note with commitment 𝖼𝗆≠⊥, elements ρ,ψ, and nullifier 𝗇𝖿 under 𝗇𝗄. For ψ′∈𝔽p𝖯𝖺𝗅𝗅𝖺𝗌 let 𝗇𝖿𝗌𝗉𝗅𝗂𝗍⁢(ψ′) be the split nullifier of a copy of n with ψ𝗇𝖿=ψ′.

  1. (i)

    Under the Ironwood Guide’s Assumptions “GroupHash as a random oracle” and “Discrete logarithms on Pallas”, no efficient algorithm outputs 𝗇𝗄, a note n with the opening of its commitment, and ψ′∈𝔽p𝖯𝖺𝗅𝗅𝖺𝗌 with 𝗇𝖿𝗌𝗉𝗅𝗂𝗍⁢(ψ′)=𝗇𝖿, except with negligible probability. This holds for every choice of ψ′, honest or not.

  2. (ii)

    Let 𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿 be uniform and used only for this derivation, and let K𝖮𝗋𝖼𝗁𝖺𝗋𝖽≠𝒪. To an adversary that knows n, 𝗇𝗄 and the full viewing key, the split nullifier is indistinguishable from 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(U) for U uniform on ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌), with advantage at most

    ϵ𝖾𝗑𝗉𝖺𝗇𝖽+ϵ𝖳𝗈𝖡𝖺𝗌𝖾+δ,

    where ϵ𝖾𝗑𝗉𝖺𝗇𝖽 bounds the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” for one query, ϵ𝖳𝗈𝖡𝖺𝗌𝖾≤p𝖯𝖺𝗅𝗅𝖺𝗌/2512<2−257 is the statistical distance of ToBase on a uniform 64-byte input from the uniform distribution on 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, and δ:=(p𝖵𝖾𝗌𝗍𝖺−p𝖯𝖺𝗅𝗅𝖺𝗌)/p𝖵𝖾𝗌𝗍𝖺 as in that volume’s Proposition “Nullifier unlinkability”.

Status (Definition 1.3): proved here for the specified construction. Part (ii) concerns honest senders, since the statement does not enforce the derivation (Remark 4.8).

Proof.

(i) Write

s:=(𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ)+ψ)modp𝖯𝖺𝗅𝗅𝖺𝗌,s′:=(𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ)+ψ′)modp𝖯𝖺𝗅𝗅𝖺𝗌,

and K:=K𝖮𝗋𝖼𝗁𝖺𝗋𝖽, L:=L𝖮𝗋𝖼𝗁𝖺𝗋𝖽. By the Ironwood Guide’s Lemma “Coordinate extraction identifies opposite points”, 𝗇𝖿𝗌𝗉𝗅𝗂𝗍⁢(ψ′)=𝗇𝖿 means [s′]⁢K+𝖼𝗆+L=±([s]⁢K+𝖼𝗆). With the sign +,

L+[s′−s]⁢K=𝒪;

with the sign −,

L+[s+s′]⁢K+[2]⁢𝖼𝗆=𝒪.

Given its opening, 𝖼𝗆≠⊥ is a known integer combination of the Sinsemilla generators of its domain and of its blinding base, by the unfolding of the Ironwood Guide’s Construction “Sinsemilla hash on Pallas” used in the proof of its Proposition “Collision resistance of the Sinsemilla instances”; in either branch of Definition 3.2 these generators are values of 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 at inputs other than (z.cash:Orchard,L) and (z.cash:Orchard,K). In both cases L has coefficient 1, and its input differs from every other input involved (Lemma 2.8), so the algorithm has output a non-trivial relation among values of 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 at distinct inputs, which the Ironwood Guide’s Lemma “Relations among fixed generators” excludes except with negligible probability. This is the role of the offset L, which ZIP 226 does not state: without it, ψ′=ψ reproduces 𝗇𝖿.

(ii) The hybrids follow the proof of the Ironwood Guide’s Proposition “Nullifier unlinkability”. First, 𝖯𝖱𝖥𝖾𝗑𝗉𝖺𝗇𝖽𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿, evaluated at the single input [𝟶⁢𝚡⁢𝟶⁢𝙰]∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(ρ), is replaced by a uniform 64-byte string, at cost ϵ𝖾𝗑𝗉𝖺𝗇𝖽: the key is used nowhere else, and the rest of the game is an efficient function of the answer and of (n,𝗇𝗄). Second, ToBase of that uniform string is replaced by a uniform ψ𝗇𝖿∈𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, at cost ϵ𝖳𝗈𝖡𝖺𝗌𝖾 (Math Guide, §“Uniform sampling and the bias of modular reduction”; Ironwood Guide, §“Pseudorandom functions and field reductions”). Translation by 𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ) is a bijection of 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, so s′ is then uniform on {0,…,p𝖯𝖺𝗅𝗅𝖺𝗌−1} and independent of 𝗇𝗄, ρ and all else. Third, s′, read in 𝔽p𝖵𝖾𝗌𝗍𝖺, is replaced by a uniform scalar u∈𝔽p𝖵𝖾𝗌𝗍𝖺, at cost δ, the statistical distance computed in the cited proposition. Since K≠𝒪 generates the group of prime order p𝖵𝖾𝗌𝗍𝖺, the point [u]⁢K+𝖼𝗆+L is then uniform on ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌) whatever 𝖼𝗆 and L are, and the split nullifier is 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ of a uniform point. □

In the model of the Ironwood Guide’s Assumption “GroupHash as a random oracle”, the event K𝖮𝗋𝖼𝗁𝖺𝗋𝖽=𝒪 excluded in part (ii) has probability 1/p𝖵𝖾𝗌𝗍𝖺.

4.3 The OrchardZSA Action statement

The statement is defined as a delta on the relation ℛ𝖠𝖼𝗍𝗂𝗈𝗇 of the Ironwood Guide’s Definition “Orchard Action statement”, itself a relation in the sense of the Crypto Guide’s Definition “Language, relation, witness” (§“Languages, relations, and witnesses”). Notation, types and conditions not named below are those of that definition; conditions A6 to A9 are cited by name and not restated.

Definition 4.6 (OrchardZSA Action statement).

Base. The seven components of the primary input of the Ironwood Guide’s Definition “Orchard Action statement” other than 𝖽𝗂𝗌𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌, and its conditions A1 to A9. The input 𝖽𝗂𝗌𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌 and condition A10 are omitted (Remark 4.7).

Primary input.

𝗉𝗎𝖻=(𝑟𝑡,𝖼𝗏𝗇𝖾𝗍,𝗇𝖿𝗈𝗅𝖽,𝗋𝗄,𝖼𝗆𝗑,𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌,𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌,𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠),

with the first seven components typed as in the cited definition and 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠∈{0,1}.

Auxiliary input. The auxiliary input 𝖺𝗎𝗑 of the cited definition, together with

𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾∈ℰ∗,𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍∈{0,1},𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀∈{0,1},ψ𝗇𝖿∈𝔽p𝖯𝖺𝗅𝗅𝖺𝗌.

Notation. Let v′:=0 if 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1 and v′:=v𝗈𝗅𝖽 otherwise. With M𝗈𝗅𝖽 and M𝗇𝖾𝗐 the 1086-bit messages of the cited definition, built from the witnessed diversified bases, write 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗆𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢(𝗀𝖽⋆,𝗉𝗄𝖽⋆,v,ρ,ψ,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾) for the commitment of Definition 3.2 with M⁢(n) replaced by the message built from these arguments: 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗆⁢(M) in the native branch, and 𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁𝖳𝗈𝖯𝗈𝗂𝗇𝗍⁢(z.cash:ZSA-NoteCommit-M,M∥𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾⋆)+[𝗋𝖼𝗆]⁢HD, or ⊥, in the custom branch. Let L𝖮𝗋𝖼𝗁𝖺𝗋𝖽 be as in Construction 4.4.

Relation. The relation ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠 is the set of pairs (𝗉𝗎𝖻,𝖺𝗎𝗑) of the types above that satisfy the following conditions.

  1. A1′.

    Old note commitment integrity:

    𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗆𝗈𝗅𝖽𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢((𝗀𝖽𝗈𝗅𝖽)⋆,(𝗉𝗄𝖽𝗈𝗅𝖽)⋆,v𝗈𝗅𝖽,ρ𝗈𝗅𝖽,ψ𝗈𝗅𝖽,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾)
    ∈{𝖼𝗆𝗈𝗅𝖽,⊥}.
  2. A2′.

    New note commitment integrity:

    𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⊥⁢(𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗆𝗇𝖾𝗐𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢((𝗀𝖽𝗇𝖾𝗐)⋆,(𝗉𝗄𝖽𝗇𝖾𝗐)⋆,v𝗇𝖾𝗐,ρ𝗇𝖾𝗐,ψ𝗇𝖾𝗐,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾))
    ∈{𝖼𝗆𝗑,⊥},

    with ρ𝗇𝖾𝗐:=𝗇𝖿𝗈𝗅𝖽 and the same 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 as in A1′.

  3. C1.

    Native indicator: 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=1 if and only if 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽.

  4. C2.

    Pause: if 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠=0, then 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=1.

  5. A3′.

    Merkle path validity: (v𝗈𝗅𝖽=0 and 𝗂𝗌_𝗇𝖺𝗍𝗂𝗏𝖾_𝖺𝗌𝗌𝖾𝗍=1), or 𝑟𝑜𝑜𝑡=𝑟𝑡, or some evaluation of 𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁 in the fold returns ⊥; the value 𝑟𝑜𝑜𝑡, the fold and the encoding bits 𝖼 are those of A3.

  6. A4′.

    Value commitment integrity:

    𝖼𝗏𝗇𝖾𝗍 =𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝗋𝖼𝗏𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,v′−v𝗇𝖾𝗐)
    =[v′−v𝗇𝖾𝗐]⁢𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾+[𝗋𝖼𝗏]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

    a variable-base multiplication by the witnessed 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 (Definition 3.8).

  7. C3.

    Split only for Custom Assets: if 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1, then 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=0.

  8. A5′.

    Nullifier integrity: if 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0, then ψ𝗇𝖿=ψ𝗈𝗅𝖽 and

    𝗇𝖿𝗈𝗅𝖽=𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋𝗇𝗄⁢(ρ𝗈𝗅𝖽,ψ𝗈𝗅𝖽,𝖼𝗆𝗈𝗅𝖽);

    if 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1, then

    𝗇𝖿𝗈𝗅𝖽=𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ( [(𝖯𝖱𝖥𝗇𝗄𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽⁢(ρ𝗈𝗅𝖽)+ψ𝗇𝖿)modp𝖯𝖺𝗅𝗅𝖺𝗌]⁢K𝖮𝗋𝖼𝗁𝖺𝗋𝖽
    +𝖼𝗆𝗈𝗅𝖽+L𝖮𝗋𝖼𝗁𝖺𝗋𝖽),

    the split nullifier of Construction 4.4.

  9. A6, A7.

    Spend authority and diversified address integrity: unchanged and unconditional; no factor of 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀 relaxes them.

  10. A8, A9.

    Enable spend flag and enable output flag: unchanged; A8 reads v𝗈𝗅𝖽, not v′, and A9 reads v𝗇𝖾𝗐.

(ZIP 226, “Circuit Statement”, paragraphs “Asset Base Equality”, “The enableZSA Flag”, “Value Commitment Correctness” and “Asset Identifier Consistency for Split Actions”; ZIP 226, “Split Notes” and “Note Structure and Commitment”; protocol specification, §“Action Statement (Orchard)”.) Class: specified at statement level; its status is stated in Remark 4.7.

The following consequences are read off Definition 4.6, Definition 3.2 and Definition 2.15.

One witness. Conditions A1′, A2′ and A4′ use the single witnessed 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾, so the consumed and the created note of an Action have one Asset Base, and its net value commitment is on that base.

Native branch. By C1 and the case split of Definition 3.2, an Action with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0 satisfies A1′, A2′, A4′ and A5′ exactly when ψ𝗇𝖿=ψ𝗈𝗅𝖽 and it satisfies the Orchard A1, A2, A4 and A5.

Pause. With 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠=0, C2 and C1 force 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, and C3 then forces 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0, so the relation admits only Orchard Actions.

Membership. Since 0≤v𝗈𝗅𝖽<264<p𝖯𝖺𝗅𝗅𝖺𝗌, the first disjunct of A3′ holds only for a consumed ZEC note of value 0. Every consumed note of a Custom Asset, split or not and of any value, satisfies 𝑟𝑜𝑜𝑡=𝑟𝑡 or the ⊥ clause. The ⊥ clause gives no escape: for witnesses extracted under Assumption 4.9, the argument of the Ironwood Guide’s Remark “⊥-weakened conditions”, by that volume’s Proposition “Collision resistance of the Sinsemilla instances” (iii) under its Assumptions “Discrete logarithms on Pallas” and “GroupHash as a random oracle”, excludes it except with negligible probability; the same holds for the ⊥ cases of A1′ and A2′ in both branches of 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠, by Proposition 3.3(c) for the custom branch.

Split Actions. By A4′ the copied value never enters 𝖼𝗏𝗇𝖾𝗍. By A8, which reads v𝗈𝗅𝖽, a Split Action that copies a note of non-zero value requires 𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌=1, while one that copies a note of value 0 does not.

These consequences are direct from the cited definitions and from the Ironwood Guide’s Remark “⊥-weakened conditions”, with Assumption 4.9 in place of that volume’s knowledge-soundness assumption (ZIP 226, “Circuit Statement” and “Overview”). Table 5 pairs each condition with the Orchard condition it replaces and its ZIP 226 paragraph; Figure 1 draws the new witnesses and the conditions that read them.

Condition Replaces ZIP 226, “Circuit Statement”, paragraph
A1′ A1 “Asset Base Equality”
A2′ A2 “Asset Base Equality”
C1 none “Asset Base Equality” (the witness 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍)
C2 none “The enableZSA Flag”
A3′ A3 “Asset Identifier Consistency for Split Actions” (Merkle Path Validity)
A4′ A4 “Value Commitment Correctness”; “Asset Identifier Consistency for Split Actions” (v′)
C3 none “Asset Identifier Consistency for Split Actions”
A5′ A5 “Asset Identifier Consistency for Split Actions” (Nullifier Integrity), with “Split Notes” for the formula and “Note Structure and Commitment” for 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=0
A6 to A9 themselves none (unchanged)
A10 omitted none (Remark 4.7)
Table 5: Conditions of the OrchardZSA Action statement of Definition 4.6: each condition, the condition of the Ironwood Guide’s Definition “Orchard Action statement” that it replaces, and the paragraph of ZIP 226, “Circuit Statement”, that states it.
Refer to caption
Figure 1: The witnessed Asset Base in the OrchardZSA Action statement of Definition 4.6. The four new witnesses are on the left, the new primary input 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠 on the right, and the conditions that read them in the centre, each tagged with the Orchard condition it replaces or as new. One witness 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 enters A1′, A2′ and A4′, which forces equal Asset Bases of the consumed and the created note and a value commitment on that base; through C1 and A3′, only a consumed ZEC note of value 0 escapes membership.
Remark 4.7 (Status of the OrchardZSA Action statement).

The delta is specified at statement level (ZIP 226, Draft, “Circuit Statement”). ZIP 226 states it against the specification’s statement with seven primary inputs and conditions A1 to A9. The current Orchard statement has the eighth primary input 𝖽𝗂𝗌𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌 and condition A10 (Ironwood Guide, Definition “Orchard Action statement” and Remark “Status”; protocol specification, §“Action Descriptions”; ZIP 258, “Consensus rules from NU6.3 activation”), which ZIP 226 never mentions. The composition of the delta with A10 is therefore an open problem (Definition 1.2). The statement uses 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠, which ZIP 226 never lists as a primary input. The encoded instance of the current Orchard statement has ten elements, the nine that encode its first seven primary inputs and 𝖽𝗂𝗌𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌 (Ironwood Guide, §“The Action statement”); no live text places 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠 in it, so its position is an open problem. ZIP 226 defers “All modifications in the Circuit” to an unversioned document outside the ZIPs, “Modifications to the Orchard circuit for the OrchardZSA Protocol”; no ZIP fixes a complete OrchardZSA circuit, which is designed but unspecified. The reading of A8 on v𝗈𝗅𝖽 is specified by the delta, which leaves A8 unchanged; only its confirmation in that circuit document is designed but unspecified, and Table 7 records it.

Remark 4.8 (What the OrchardZSA statement does not check).

Items (i) to (iii) of the Ironwood Guide’s Remark “What the statement does not check” carry over. In addition:

  1. (iv)

    The witness ψ𝗇𝖿 is constrained only through A5′ to the published nullifier. For 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1 only the equality ψ𝗇𝖿=ψ𝗈𝗅𝖽 is switched off, and no condition derives ψ𝗇𝖿 from a seed. The derivation of Construction 4.4 is therefore a sender rule whose formula is specified and which nothing enforces: 𝗋𝗌𝖾𝖾𝖽⁢_⁢𝗇𝖿 is transmitted nowhere, and no text proposes an enforcement. Proposition 4.5(i) holds for every ψ𝗇𝖿; part (ii) holds for senders that follow the rule.

  2. (v)

    The derivations of 𝗋𝖼𝗆 and ψ from 𝗋𝗌𝖾𝖾𝖽 are unchecked, as for Orchard.

  3. (vi)

    The witnessed 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 is checked only against the consumed leaf, through A1′ and A3′, and never against a record of issued Assets. Lemma 9.3, in “Security”, concerns the leaves.

  4. (vii)

    The statement does not check that the prover owns the copied note of a Split Input beyond A6 and A7; this is the subject of Proposition 4.12.

(ZIP 226, “Split Notes” and “Circuit Statement”.)

4.4 The OrchardZSA Action proof

The Ironwood Guide’s Assumptions “Knowledge soundness of the Action proof” and “Zero knowledge of the Action proof” name the relation ℛ𝖠𝖼𝗍𝗂𝗈𝗇 and its verifying key. The corresponding assumptions for ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠 are stated here in the same form; the OrchardZSA verifying key denotes the verifying key of a circuit for ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠, which no ZIP names.

Assumption 4.9 (Knowledge soundness of the OrchardZSA Action proof).

Let the hash of the Fiat–Shamir transform be modelled as a random oracle. For every efficient adversary that outputs primary inputs 𝗉𝗎𝖻1,…,𝗉𝗎𝖻n and an aggregate proof π, there is an efficient extractor, with access to the adversary and to its random-oracle queries, that outputs auxiliary inputs 𝖺𝗎𝗑1,…,𝖺𝗎𝗑n such that the probability of the event

π is accepted for (𝗉𝗎𝖻1,…,𝗉𝗎𝖻n) under the OrchardZSA verifying key
and ⁢(𝗉𝗎𝖻i,𝖺𝗎𝗑i)∉ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠⁢ for some ⁢i

is negligible. This is the knowledge-soundness clause of the Crypto Guide’s Definition “SNARK” (§“SNARKs: succinct non-interactive arguments of knowledge”) for the relation of Definition 4.6, for a Halo 2 proof (Halo 2 Guide, §“The Halo 2 proof system” and §“A rigorous treatment of knowledge soundness”), the primary input bound to the proof as in the Halo 2 Guide, §“Instance columns and binding the public statement”. It includes that every satisfying assignment of the circuit yields a witness of ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠; in particular, the multiplication of A4′ is by the witnessed 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 and nothing else. No ZIP names the circuit or the verifying key: the assumption concerns a designed but unspecified object.

Assumption 4.10 (Zero knowledge of the OrchardZSA Action proof).

Let the hash of the Fiat–Shamir transform be modelled as a programmable random oracle. There is an efficient simulator that, given only 𝗉𝗎𝖻1,…,𝗉𝗎𝖻n and programming the random oracle, outputs an aggregate proof statistically indistinguishable from an honest proof under the OrchardZSA verifying key, for any 𝖺𝗎𝗑1,…,𝖺𝗎𝗑n with (𝗉𝗎𝖻i,𝖺𝗎𝗑i)∈ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠 for every i, against every distinguisher that makes polynomially many random-oracle queries. This is zero knowledge of statistical grade in the non-interactive, random-oracle form of the Crypto Guide’s Definition “Zero knowledge” (§“The simulation paradigm and zero knowledge”), for a Halo 2 proof (Halo 2 Guide, §“Zero knowledge: hiding the witness in Halo 2”). It concerns the same designed but unspecified circuit and key.

Remark 4.11 (Circuit, verifying key and proof length).

The statement is specified at delta level (ZIP 226). Its arithmetisation exists only in the document outside the ZIPs named in Remark 4.7, so the circuit and its verifying key are designed but unspecified, and Assumptions 4.9 and 4.10 are the only hypotheses through which later results depend on them. Condition A4′ is sound only if the circuit multiplies by the witnessed 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 and nothing else. The Orchard variable-base scalar multiplication was corrected at NU6.2 because it left the base under-constrained (ZIP 257, “NU6.2 deployment”). ZIP 226, which turns the value base into a witness (“Value Commitment Correctness”), does not mention the correction, which any OrchardZSA circuit must carry. ZIP 257 made the Orchard proof length 2720+2272⁢n bytes, for n Actions, a consensus rule (“Canonical Orchard Action proof length”). No ZIP fixes an OrchardZSA proof length, which the circuit determines and which no live text contradicts: it is designed but unspecified, as the circuit and the verifying key are.

Proposition 4.12 (Ownership of Split Inputs).

Consider the Ironwood Guide’s Definition “Spend-authority experiment” with ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠 in place of ℛ𝖠𝖼𝗍𝗂𝗈𝗇: a key generated with 𝗎𝗌𝖾⁢_⁢𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾, the adversary holding its full viewing key but not 𝖺𝗌𝗄. Under Assumption 4.9 and the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas”, “GroupHash as a random oracle”, “The RedPallas hash as a random oracle” and “Pseudorandomness of PRF expansion”, no efficient adversary outputs, except with negligible probability, a block chain with an accepted Split Action whose witness copies a leaf that is a note of the key, and whose spend-authorisation signature is valid under its 𝗋𝗄 on a signature digest for which it made no signing query with that 𝗋𝗄. Consequently the sentence of ZIP 226, “Split Notes”, “we do not care about whether the previously issued note copied to create a Split Input is owned by the sender, or whether it was nullified before” holds for spentness and not for ownership: a sender can use choices (2) and (3) of Remark 4.3 only with the spend authority of the copied note, except for a note whose key is public, such as a reference note (Proposition 6.11). Status (Definition 1.3): proved here from specified conditions; conditional on Assumption 4.9, which concerns the designed but unspecified circuit.

Proof.

The proof is a reduction to the proof of the Ironwood Guide’s Theorem “Spend authority”. By Assumption 4.9 the extractor yields, for the accepted Split Action, a witness of ℛ𝖠𝖼𝗍𝗂𝗈𝗇𝖹𝖲𝖠 with 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀=1. By C3, 𝗂𝗌⁢_⁢𝗇𝖺𝗍𝗂𝗏𝖾⁢_⁢𝖺𝗌𝗌𝖾𝗍=0, so A3′ gives 𝑟𝑜𝑜𝑡=𝑟𝑡 outside its ⊥ case, which is excluded as in the consequences of Definition 4.6; with the anchor rule, the Ironwood Guide’s Proposition “Membership soundness” makes 𝖤𝗑𝗍𝗋𝖺𝖼𝗍ℙ⁢(𝖼𝗆𝗈𝗅𝖽) a leaf. Condition A1′ with Proposition 3.3(b) makes the witnessed consumed note the note of that leaf, so its witnessed expanded receiver (𝗀𝖽𝗈𝗅𝖽,𝗉𝗄𝖽𝗈𝗅𝖽) is the receiver of the leaf’s note, a note of the key; the witness therefore consumes a note of the key in the sense of the experiment. Conditions A6 and A7, unchanged and unconditional, then bind 𝗋𝗄 to a randomisation of ±𝖺𝗄ℙ of that key, by the Ironwood Guide’s Proposition “Binding of 𝗂𝗏𝗄 to (𝖺𝗄,𝗇𝗄)” and Lemma “Coordinate extraction identifies opposite points”, and a valid signature under 𝗋𝗄 without a matching signing query contradicts that volume’s Proposition “Unforgeability under re-randomisation”, exactly as in steps (1) to (5) of the proof of Theorem “Spend authority”. Neither 𝗌𝗉𝗅𝗂𝗍⁢_⁢𝖿𝗅𝖺𝗀 nor v′ enters A6 or A7, the only conditions that proof uses; A1′ and membership serve here only to identify the witnessed receiver with that of the copied leaf’s note, so the steps apply unchanged.

For spentness: by A4′ the copied value is not committed, and by Proposition 4.5(i) the copied note’s nullifier is not published, except with negligible probability. Choice (1) of Remark 4.3 copies a note that the same bundle spends, so its sender holds that note’s spend authority in any case. □

4.5 Action Groups

Definition 4.13 (Action Group).

An Action Group is a non-empty finite sequence of OrchardZSA Actions together with one anchor 𝑟𝑡, the flags 𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌, 𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌 and 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠 in {0,1}, and one aggregate proof for the relation of Definition 4.6 at the primary inputs

(𝑟𝑡,𝖼𝗏i𝗇𝖾𝗍,𝗇𝖿i,𝗋𝗄i,𝖼𝗆𝗑i,𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌,𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌,𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠)

of its Actions i. Each Action carries the public fields (𝖼𝗏𝗇𝖾𝗍,𝗇𝖿,𝗋𝗄,𝖼𝗆𝗑,𝖾𝗉𝗄,C𝖾𝗇𝖼,C𝗈𝗎𝗍) of an Orchard Action description (Ironwood Guide, Definition “Action description”) and its own spend-authorisation signature under 𝗋𝗄. The term is that of ZIP 228, “Terminology”: Actions that share the tuple (𝑟𝑡,𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌,𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌,𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠,𝗇𝖠𝖦𝖤𝗑𝗉𝗂𝗋𝗒𝖧𝖾𝗂𝗀𝗁𝗍). ZIP 227, “Specification: Consensus Rule Changes”, requires 𝗇𝖠𝖦𝖤𝗑𝗉𝗂𝗋𝗒𝖧𝖾𝗂𝗀𝗁𝗍=0 and at most one Action Group per transaction, so the fifth component is constant and is omitted. The nullifier 𝗇𝖿0,0 of the first Action of the Action Group is the value that issuance uses (ZIP 227, “Computation of ρ”). The Action Group has no burn set; the remaining components of a transaction’s bundle are defined in “Burn sets and OrchardZSA bundles” (§5.1). Class: specified.

The structure is specified by ZIPs 226 to 228, all Draft. Its encoding exists only in ZIP 230, which is Withdrawn; the layout that ZIP 230 calls version 6 is not the version 6 of ZIP 229, which has no Action Groups (ZIP 229, “Transaction Format”). The byte lengths of the note ciphertext and of an Action depend on a plaintext encoding that no current ZIP defines (Definition 3.7). The flag 𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠 has no flag bit in any current format. ZIP 230 assigns it bit 2 of the Orchard flags byte, which ZIP 229, “Consensus Rules”, reserves as 0 in version 6 and which is 𝖾𝗇𝖺𝖻𝗅𝖾𝖢𝗋𝗈𝗌𝗌𝖠𝖽𝖽𝗋𝖾𝗌𝗌 in the Ironwood flags byte (Ironwood Guide, §“Bundle flags”; ZIP 258, “Consensus rules from NU6.3 activation”). The design conflicts with live text, so the flag bit is an open problem (Definition 1.2).