The Zcash ArboretumZSA Guide PDF

5 Burn and the binding signature

This section defines the burn set and the OrchardZSA bundle that it completes (§5.1); constructs the binding validating key, which subtracts the burnt amounts Asset by Asset (§5.2); and proves that a verifying binding signature forces per-Asset balance whenever every witnessed Asset Base and every Asset Base of a burn pair is a group-hash output at a suitably distinct input (§5.3). The premise on the bases concerns a single bundle; it is discharged for valid chains in “Security” (§9). The constructions are taken from ZIP 226 and ZIP 227, both Draft. The Orchard binding signature that they extend is that of the Ironwood Guide, §“The binding signature”, and is cited, not restated.

5.1 Burn sets and OrchardZSA bundles

Definition 5.1 (Burn set).

Burn destroys a stated amount of a Custom Asset (Definition 1.5): it sends nothing to any address, lowers the amount of the Asset in circulation, and publishes the Asset Base and the amount, so that the destruction is publicly verifiable. A burn set 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇 is a finite set of pairs (𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,v) with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾∈ℰ∗ and v∈ℤ. The author of a transaction adds one pair for each Custom Asset that the transaction burns, v being the amount burnt. The constant

𝖬𝖠𝖷⁢_⁢𝖡𝖴𝖱𝖭⁢_⁢𝖵𝖠𝖫𝖴𝖤:=263−1=9 223 372 036 854 775 807

bounds the amount of one Custom Asset burnt in one transaction, so that every burnt amount is representable in a signed 64-bit balance field. A burn set is valid when it satisfies the following rules.

  1. (B1)

    For every pair, 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽: the Native Asset Base (Definition 2.15), of ZEC and of TAZ alike, is never burnt.

  2. (B2)

    For every pair, 0<v≤𝖬𝖠𝖷⁢_⁢𝖡𝖴𝖱𝖭⁢_⁢𝖵𝖠𝖫𝖴𝖤.

  3. (B3)

    Every Asset Base occurs in at most one pair. The burnt amount vB of a point B is therefore well defined: the v of the pair with 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=B, or 0 if there is none.

Rules (B1) to (B3) constrain the pairs only. Rule (B1) excludes the one point V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and no other, and no rule requires 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾 to be the Asset Base of an issued Asset. The state rule that a burn cannot exceed the amount of the Asset in circulation is ZIP 227’s; it is rule (T4) of Construction 7.3, in “State transition of a transaction” (§7.2) (ZIP 226, “Burn Mechanism”, “Additional Consensus Rules for the assetBurn set” and “Rationale for MAX_BURN_VALUE”; ZIP 227, “Specification: Consensus Rule Changes”). Class: specified; the carrier of the burn set is stated in “Transaction formats” (§8.1).

Definition 5.2 (OrchardZSA bundle).

The OrchardZSA bundle of a transaction consists of at most one Action Group (Definition 4.13), one burn set 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇 satisfying (B1) to (B3), one balancing value v𝖻𝖺𝗅𝖺𝗇𝖼𝖾 and one binding signature. It extends the Ironwood Guide’s Definition “Bundle” by the burn set; its anchor, flags and proof are those of the Action Group. ZIP 226 places one burn set in the transaction, and ZIP 227 limits the transaction to at most one Action Group, so the two readings coincide (ZIP 226, “Burn Mechanism”; ZIP 227, “Specification: Consensus Rule Changes”). Class: the structure is specified; its encoding, one burn set per Action Group in withdrawn ZIP 230, belongs to the carrier and is classified in Remark 8.1.

Remark 5.3 (No transparent pool for Custom Assets).

ZIPs 226 and 227 leave the transparent protocol unchanged and single-asset. Transparent inputs and outputs, and the Ironwood Guide’s transparent transaction value pool (Definition “Transparent transaction value pool”), carry the Native Asset only; Custom Assets have no transparent value pool and cannot be unshielded by a transfer. ZIP 226 conditions this on future consensus changes, which no ZIP specifies (ZIP 226, “Burn Mechanism”, note; “Rationale for Value Balance Verification”: “All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer”). Structurally, the binding validating key of the next subsection (Definition 5.4) has, besides the Actions’ net value commitments, only the balancing value at V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and one burn term per pair; a non-zero net amount of a Custom Asset in a bundle can therefore be absorbed only by a burn pair of that Asset. The computational statement is Proposition 5.6. Class: specified.

5.2 The binding validating key

Definition 5.4 (Binding validating key of an OrchardZSA bundle).

Let an OrchardZSA bundle have n Actions with net value commitments 𝖼𝗏1𝗇𝖾𝗍,…,𝖼𝗏n𝗇𝖾𝗍 (Definition 3.8), trapdoors 𝗋𝖼𝗏1,…,𝗋𝖼𝗏n, balancing value v𝖻𝖺𝗅𝖺𝗇𝖼𝖾 and burn set 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇. The binding signing key is unchanged:

𝖻𝗌𝗄:=𝗋𝖼𝗏1+⋯+𝗋𝖼𝗏n∈𝔽p𝖵𝖾𝗌𝗍𝖺

(Ironwood Guide, Definition “Binding signing key”). The verifier computes, from public fields only, the binding validating key

𝖻𝗏𝗄:=(∑i=1n𝖼𝗏i𝗇𝖾𝗍)−[v𝖻𝖺𝗅𝖺𝗇𝖼𝖾]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽−∑(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,v)∈𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇[v]⁢𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,

where the subtracted points are the zero-trapdoor commitments

𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂𝗍0𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢(V𝖮𝗋𝖼𝗁𝖺𝗋𝖽,v𝖻𝖺𝗅𝖺𝗇𝖼𝖾)and𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂𝗍0𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠⁢(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,v),

each signed integer entering as its residue modulo p𝖵𝖾𝗌𝗍𝖺. Against the Ironwood Guide’s Definition “Binding validating key” two things are new: the bases of the Actions’ commitments vary, being the witnessed Asset Bases, and one burn term is subtracted per pair.

The balancing value keeps the meaning of the Ironwood Guide’s Definitions “Transparent transaction value pool” and “Balancing value”: the net flow of ZEC between the pool and the transparent transaction value pool, a signed integer in {−263,…,263−1}. It enters 𝖻𝗏𝗄 at V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 only. Its meaning rests on the key of ZIP 226; its encoding, the field valueBalanceOrchard of withdrawn ZIP 230, belongs to the carrier.

The binding signature is that of the Ironwood Guide’s Construction “Binding signature”, the binding-signature instance of RedPallas on the base R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 (Ironwood Guide, §“The RedPallas signature scheme”): the author signs 𝖲𝗂𝗀𝖧𝖺𝗌𝗁 with 𝖻𝗌𝗄, and the verifier MUST validate the signature on 𝖲𝗂𝗀𝖧𝖺𝗌𝗁 under 𝖻𝗏𝗄. Here 𝖲𝗂𝗀𝖧𝖺𝗌𝗁 is the signature digest of the transaction (Ironwood Guide, Definition “Signature digest”) as modified for OrchardZSA; the modifications and their class are stated in “Transaction digests and the signature message” (§8.2, Remark 8.3) (ZIP 226, “Value Balance Verification” and “Value Commitment”; protocol specification, §“Balance and Binding Signature (Orchard)”). Class: specified; the signed message is not.

For an honestly constructed bundle each 𝖼𝗏i𝗇𝖾𝗍 equals [vi′−vi𝗇𝖾𝗐]⁢𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i+[𝗋𝖼𝗏i]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽, by condition A4′ of Definition 4.6. By the additive homomorphism (Crypto Guide, §“The Pedersen commitment”, Theorem “Additive homomorphism”), the trapdoor terms sum to [𝖻𝗌𝗄]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽, and the value terms group by Asset Base. When the net values of each Custom Asset sum to its burnt amount and those of ZEC to v𝖻𝖺𝗅𝖺𝗇𝖼𝖾, every value term cancels, so 𝖻𝗏𝗄=[𝖻𝗌𝗄]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽, the pair (𝖻𝗌𝗄,𝖻𝗏𝗄) is a key pair of the instance, and the honest signature is accepted, as in the paragraph after the Ironwood Guide’s Construction “Binding signature”. In the notation of ZIP 226, with S𝖢𝖠 the indices of the Actions of Custom Assets, a correctly constructed bundle satisfies

∑j∈S𝖢𝖠𝖼𝗏j𝗇𝖾𝗍−∑(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,v)∈𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇[v]⁢𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾=[∑j∈S𝖢𝖠𝗋𝖼𝗏j]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽

(ZIP 226, “Rationale for Value Balance Verification”). For a Split Action v′=0, so the value of the copied note never enters 𝖻𝗏𝗄: the commitment [0−v𝗇𝖾𝗐]⁢𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾+[𝗋𝖼𝗏]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 cancels against the value of the notes of the same Asset consumed by real spends in other Actions (ZIP 226, “Split Notes”).

The key 𝖻𝗏𝗄 is computed from the Actions’ commitments, the balancing value and the burn set, and of these only the burn set names an Asset, by publishing each burnt Asset Base with its amount. The hiding of the Actions’ Asset Bases is Theorem 9.11, in “Security”.

5.3 Per-Asset balance

Lemma 5.5 (Modular per-Asset balance is integer balance).

Let n≤62 500. For 1≤i≤n let vi′ and vi𝗇𝖾𝗐 be integers in {0,…,264−1} and 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i a point. Let 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇 satisfy (B2) and (B3), with burnt amounts vB, and let v𝖻𝖺𝗅𝖺𝗇𝖼𝖾 be an integer in {−263,…,263−1}. For a point B put

cB :=∑i:𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i=B(vi′−vi𝗇𝖾𝗐)−vB (B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽),
cV𝖮𝗋𝖼𝗁𝖺𝗋𝖽 :=∑i:𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽(vi′−vi𝗇𝖾𝗐)−v𝖻𝖺𝗅𝖺𝗇𝖼𝖾,

rule (B1) giving vV𝖮𝗋𝖼𝗁𝖺𝗋𝖽=0 for a valid burn set. If cB≡0(modp𝖵𝖾𝗌𝗍𝖺), then cB=0 as an integer.

The hypotheses hold for every OrchardZSA bundle of a valid block. Every Action carries its own 32-byte nullifier (Ironwood Guide, Definition “Action description”; protocol specification, §“Action Description Encoding and Consensus”), and a block, hence a transaction, holds at most 2 000 000 bytes (protocol specification, §“Block Header Encoding and Consensus”), so

n≤2 000 000/32=62 500<216

whatever the carrier. The values are 64-bit by Definition 3.1, with v′∈{0,v𝗈𝗅𝖽} by the notation of Definition 4.6; burnt amounts are bounded by (B2), and the balancing value by Definition 5.4. No carrier-specific bound on the number of Actions is needed. Status (Definition 1.3): proved here; conditional on no unspecified object.

Proof.

The argument is that of the Ironwood Guide’s Lemma “Modular balance is integer balance”. Each difference vi′−vi𝗇𝖾𝗐 has absolute value at most 264−1, and n≤216−1. For B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, rule (B2) gives 0≤vB≤263−1, so

|cB|≤(216−1)⁢(264−1)+(263−1)=1 208 916 596 242 592 319 864 832;

for V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, with |v𝖻𝖺𝗅𝖺𝗇𝖼𝖾|≤263,

|cV𝖮𝗋𝖼𝗁𝖺𝗋𝖽|≤(216−1)⁢(264−1)+263=1 208 916 596 242 592 319 864 833,

the upper end of the range in the protocol specification, §“Balance and Binding Signature (Orchard)”. Both bounds are below 280<2253≤(p𝖵𝖾𝗌𝗍𝖺−1)/2 (Ironwood Guide, §“Fields, groups, and encodings”; protocol specification, §“Pallas and Vesta”). The hypothesis makes cB a multiple of p𝖵𝖾𝗌𝗍𝖺, the order of the Pallas group, and the only such multiple of absolute value below p𝖵𝖾𝗌𝗍𝖺 is 0. □

The protocol specification’s argument in §“Balance and Binding Signature (Orchard)” bounds the number of Actions by 216−1 through a separate consensus rule, which it notes is redundant given the 2 MB transaction size limit; the lemma uses the block size itself.

Fix an OrchardZSA bundle as in Definition 5.4, and let 𝔅 be the set of points consisting of V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, the Asset Bases of the Actions and the Asset Bases of the burn pairs. An opening of 𝖼𝗏i𝗇𝖾𝗍 is a triple (Bi,ui,ri) of a point Bi∈𝔅, an integer ui and a scalar ri∈𝔽p𝖵𝖾𝗌𝗍𝖺 with

𝖼𝗏i𝗇𝖾𝗍=[uimodp𝖵𝖾𝗌𝗍𝖺]⁢Bi+[ri]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽.

For openings, cB is defined for B∈𝔅 as in Lemma 5.5, with Bi in place of 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i and ui in place of vi′−vi𝗇𝖾𝗐. The set 𝔅 meets the premise on the bases when every B∈𝔅 other than V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 is given with an input xB of 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 such that B=𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁⁢(xB) and xB differs from the inputs (z.cash:Orchard-cv,v) of V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and (z.cash:Orchard-cv,r) of R𝖮𝗋𝖼𝗁𝖺𝗋𝖽. As in the Ironwood Guide, a binding signature under a point X is a signature valid under X in the binding-signature instance of RedPallas.

Proposition 5.6 (Per-Asset balance and key knowledge).

For the bundle fixed above:

  1. (i)

    Identity. If 𝖼𝗏i𝗇𝖾𝗍=[vi′−vi𝗇𝖾𝗐]⁢𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i+[𝗋𝖼𝗏i]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 for every i, and 𝖻𝗌𝗄:=∑i𝗋𝖼𝗏i, then

    𝖻𝗏𝗄−[𝖻𝗌𝗄]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽=∑B∈𝔅[cB]⁢B;

    hence cB≡0(modp𝖵𝖾𝗌𝗍𝖺) for every B∈𝔅 implies 𝖻𝗏𝗄=[𝖻𝗌𝗄]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽.

  2. (ii)

    Knowledge. Given openings of every 𝖼𝗏i𝗇𝖾𝗍 and b∈𝔽p𝖵𝖾𝗌𝗍𝖺 with 𝖻𝗏𝗄=[b]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

    ∑B∈𝔅[cB]⁢B+[∑i=1nri−b]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽=𝒪.

    If 𝔅 meets the premise on the bases and some cB is non-zero modulo p𝖵𝖾𝗌𝗍𝖺, this is a non-trivial relation among values of 𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁 at distinct inputs.

Consequently, under the Ironwood Guide’s Assumptions “Discrete logarithms on Pallas”, “GroupHash as a random oracle” and “The RedPallas hash as a random oracle”, an efficient party that outputs a bundle whose set 𝔅 meets the premise on the bases, openings of every net value commitment and a binding signature under the resulting 𝖻𝗏𝗄 on a message of its choice satisfies cB≡0(modp𝖵𝖾𝗌𝗍𝖺) for every B∈𝔅, and knows b=∑iri, except with negligible probability. The statement holds for every message and does not depend on the signed message.

Under Assumption 4.9 in addition, let an efficient adversary output OrchardZSA bundles of valid blocks, hence with at most 62 500 Actions each, whose Action proofs and binding signatures verify and whose witnessed and burn-pair Asset Bases meet the premise on the bases. Then, except with negligible probability, as integers:

  1. (a)

    for every Asset Base B≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, ∑i:𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i=B(vi′−vi𝗇𝖾𝗐)=vB, which is 0 when B is not burnt;

  2. (b)

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

  3. (c)

    no burn pair has an Asset Base that no Action witnesses;

  4. (d)

    the signer knows the trapdoor sum ∑i𝗋𝖼𝗏i.

Here 𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i, vi′, vi𝗇𝖾𝗐 and 𝗋𝖼𝗏i are read from the extracted witnesses. Status (Definition 1.3): proved here for the specified 𝖻𝗏𝗄; conditional on Assumption 4.9, which concerns the designed but unspecified circuit, and not on Assumption 6.13. The premise on the bases is discharged for every accepted bundle of a valid chain only in “Security”, in Theorem 9.5: for witnessed bases by Corollary 9.4, for burn-pair bases by rule (T4) of Construction 7.3 and Lemma 7.7. ZIP 226 argues per-Asset balance in rationale only (“Rationale for Value Balance Verification”), and that argument stays designed but unspecified.

Proof.

(i) Expand each 𝖼𝗏i𝗇𝖾𝗍 and apply the additive homomorphism (Crypto Guide, §“The Pedersen commitment”, Theorem “Additive homomorphism”):

∑i=1n𝖼𝗏i𝗇𝖾𝗍=∑B∈𝔅[∑i:𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i=B(vi′−vi𝗇𝖾𝗐)]⁢B+[𝖻𝗌𝗄]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽.

By (B3) each Asset Base of a burn pair occurs in exactly one subtracted term [vB]⁢B, and by (B1) none of them is V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, whose only subtracted term is [v𝖻𝖺𝗅𝖺𝗇𝖼𝖾]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽. Subtracting these terms as in Definition 5.4 and grouping by base gives the identity. If every cB vanishes modulo p𝖵𝖾𝗌𝗍𝖺, the right-hand side is 𝒪.

(ii) With the openings in place of the honest values, the same grouping gives 𝖻𝗏𝗄=∑B[cB]⁢B+[∑iri]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽; equating with [b]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 gives the relation. Its coefficients are scalars modulo p𝖵𝖾𝗌𝗍𝖺. Under the premise, the base V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 is the value at its input, and each other B∈𝔅 at xB. The points of 𝔅 are pairwise distinct, so the chosen inputs are pairwise distinct, one per point; two distinct inputs with one value would themselves be a relation of the same kind. The inputs differ from that of R𝖮𝗋𝖼𝗁𝖺𝗋𝖽, by the premise and since the inputs of V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 differ in the message. A non-zero cB makes the relation non-trivial.

Consequence. Let an efficient party 𝒜 output, with probability ϵ, a bundle meeting the premise, openings, a message and a binding signature on it under the resulting 𝖻𝗏𝗄, with some cB non-zero modulo p𝖵𝖾𝗌𝗍𝖺; the event is efficiently decidable from the output. The value b is extracted exactly as in the proof of the Ironwood Guide’s Proposition “Balance and key knowledge”: if 𝖻𝗏𝗄=𝒪, then b:=0; otherwise special soundness with forking in the random-oracle model for the RedPallas hash yields b with 𝖻𝗏𝗄=[b]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 (Crypto Guide, §“Binding signatures as a proof of knowledge of a discrete logarithm”, Theorem “The binding signature is a proof of knowledge of logP⁡B”). Key prefixing places 𝖻𝗏𝗄 in the critical query, so the openings and the bases of the first run satisfy the hypothesis of part (ii) for it. Part (ii) then outputs 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; so ϵ is negligible. In the model of that volume’s Assumption “GroupHash as a random oracle” the inputs xB may equally be read from the queries of 𝒜: a point that equals the value at an input 𝒜 never queried occurs with probability at most 1/p𝖵𝖾𝗌𝗍𝖺 for each point. For Asset Bases of Custom Assets, Lemma 2.8 places every input under z.cash:OrchardZSA apart from those of V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 and R𝖮𝗋𝖼𝗁𝖺𝗋𝖽. When every cB vanishes, the relation reduces to [∑iri−b]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽=𝒪, and R𝖮𝗋𝖼𝗁𝖺𝗋𝖽 has prime order p𝖵𝖾𝗌𝗍𝖺, so b=∑iri.

Bundles. The adversary outputs polynomially many bundles, and the union bound reduces the claim to one of them, as in the proof of the Ironwood Guide’s Theorem “Balance”. The algorithm that runs the adversary with the extractor of Assumption 4.9 outputs, for that bundle, the triples (𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾i,vi′−vi𝗇𝖾𝗐,𝗋𝖼𝗏i) read from the witnesses; by A4′ of Definition 4.6 each is an opening of 𝖼𝗏i𝗇𝖾𝗍, except with the negligible probability that a witness fails the relation. The bundle’s binding signature verifies on 𝖲𝗂𝗀𝖧𝖺𝗌𝗁 under 𝖻𝗏𝗄, so the algorithm is a party of the consequence, and every cB vanishes modulo p𝖵𝖾𝗌𝗍𝖺 and b=∑i𝗋𝖼𝗏i, which is (d). The hypotheses of Lemma 5.5 hold for the witnesses, the bundle being in a valid block, and the lemma lifts each congruence to an equality of integers, which is (a) and (b). A burn pair of base B that no Action witnesses has cB=−vB, with 0<vB<p𝖵𝖾𝗌𝗍𝖺 by (B2), so cB≢0; this is (c). □

The premise on the bases cannot be dropped, for witnessed bases or for the bases of burn pairs. For witnessed bases this is Proposition 4.1. For burn pairs, let B be the Asset Base of an issued Asset and 0<v≤𝖬𝖠𝖷⁢_⁢𝖡𝖴𝖱𝖭⁢_⁢𝖵𝖠𝖫𝖴𝖤. Split Actions of base B contribute v′=0, so Actions of base B whose net values sum to −2⁢v create 2⁢v units of B from nothing. The pair ([−2]⁢B,v) satisfies (B2) and (B3), and (B1) unless [−2]⁢B=V𝖮𝗋𝖼𝗁𝖺𝗋𝖽, a relation that Lemma “Relations among fixed generators” of the Ironwood Guide excludes except with negligible probability. With balancing value 0 and t:=∑i𝗋𝖼𝗏i, Definitions 3.8 and 5.4 give

𝖻𝗏𝗄=[−2⁢v]⁢B+[t]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽−[v]⁢([−2]⁢B)=[t]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽,

whose discrete logarithm the author knows, so the binding signature verifies. Likewise, with balancing value 0, ZEC Actions whose net values sum to −v and the pair ([−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽,v) give

𝖻𝗏𝗄=[−v]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽+[t]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽−[v]⁢([−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽)=[t]⁢R𝖮𝗋𝖼𝗁𝖺𝗋𝖽:

an amount of v zatoshi of ZEC appears from nothing, and (B1) does not exclude the pair, since [−1]⁢V𝖮𝗋𝖼𝗁𝖺𝗋𝖽≠V𝖮𝗋𝖼𝗁𝖺𝗋𝖽 in a group of odd order. Rule (B1) excludes only V𝖮𝗋𝖼𝗁𝖺𝗋𝖽; the premise on burn-pair bases is discharged by the issuance state, through rule (T4) of Construction 7.3 and Lemma 7.7, not by the burn rules (ZIP 226, “Rationale for Split Notes”, on inputs that are a multiple or linear combination of an existing Asset Base; ZIP 226, “Additional Consensus Rules for the assetBurn set”).

Remark 5.7 (Homomorphism across Asset Bases).

ZIP 226, “Rationale for Value Balance Verification”, states that the relation between 𝖻𝗏𝗄 and 𝖻𝗌𝗄 holds “if and only if”, per Custom Asset, the net values sum to the burnt amount (0 if absent) and, for ZEC, to the balancing value, and that the commitments “add up homomorphically only with respect to the same value base point”. Neither is a literal statement about the Pallas group. The group is cyclic of prime order p𝖵𝖾𝗌𝗍𝖺 (protocol specification, §“Pallas and Vesta”), so any two non-identity bases satisfy B′=[λ]⁢B for some λ; commitments to distinct bases add homomorphically as group elements; and ∑B[cB]⁢B=𝒪 has non-zero solutions (cB). The “if” direction is part (i) of Proposition 5.6. The “only if” direction holds computationally, for group-hash bases and an efficient signer, as part (ii) and its consequence prove, and then as integers by Lemma 5.5. The argument of the ZIP is rationale and keeps its class (Definition 1.3).