8 The transaction carrier

The carrier of a construction is the set of transaction fields that encode it together with the digests that commit to it (Definition 1.4).

Deferral of the encodings. ZIP 226, “OrchardZSA Transaction Structure”, states that the transaction format that carries OrchardZSA “is described in ZIP 230”, and defers to it the transaction structure and the note plaintexts. ZIP 227, “Issue Note”, “Issuance Action” and “Issuance Bundle”, defers to ZIP 230 the encodings of Issue Notes, of Issuance Actions and of the Issuance Bundle. ZIP 230, now titled “Withdrawn Version 6 Transaction Format”, has status Withdrawn (Definition 1.1): it “has been obsoleted by ZIP 229, and will not be deployed”, and transaction version $6$ “is now defined by ZIP 229” (ZIP 230, “Abstract”). The consensus rules of ZIP 227 nonetheless name fields that exist only in ZIP 230, the Action-Group count and the per-group expiry field of rule (T1) of Construction 7.3 (“State transition of a transaction”, §7.2), and require every Issue Note description to be “a valid field encoding as defined in ZIP 230” (ZIP 227, “Specification: Consensus Rule Changes”). A Draft consensus rule thus delegates to withdrawn text. ZIP 226, “Privacy Implications” and “Implications for Wallets”, still identifies OrchardZSA with version-$6$ transactions.

Version 6. Version $6$ is the transaction format of ZIP 229, “Version 6 Transaction Format” (Draft), which the active NU6.3 deploys (ZIP 258, Draft). It carries the Ironwood component beside the Orchard component and no bundle of OrchardZSA or of issuance (Ironwood Guide, §“The transaction format”, Construction “Version-6 transaction”). By ZIP 229, “Non-requirements”, the format “need not support ZSAs”. The withdrawn format and the format of ZIP 229 share the version number $6$ and are distinct and incompatible.

Version 7. ZIP 248, “Extensible Transaction Format” (Draft), defines transaction version $7$, whose version group identifier is not yet assigned and whose “Deployment” section is empty. Its bundle registry allocates no bundle to ZSA. OrchardZSA, proposed as a provisional variant of the Orchard bundle type (ZIP 226), and ZSA Issuance, with no bundle type (ZIP 227), appear only under “Potential Future Bundle Types”, kinds that “have no allocated $(\mathrm{𝖻𝗎𝗇𝖽𝗅𝖾𝖳𝗒𝗉𝖾},\mathrm{𝖻𝗎𝗇𝖽𝗅𝖾𝖵𝖺𝗋𝗂𝖺𝗇𝗍})$ pair”. ZIP 248 specifies no encoding and no digest for either (ZIP 248, “Terminology”, “Abstract”, “Potential Future Bundle Types” and “Deployment”).

Content and withdrawn design. The abstract content that the rules of this volume need is fixed earlier and does not depend on a carrier: the OrchardZSA bundle of Definition 5.2, with at most one Action Group, one burn set, the balancing value and the binding signature, and the Issuance Bundle of Definition 6.5. The withdrawn design of ZIP 230 encodes this content as follows; no part of it is a live layout.

1. (a)

   The burn set is encoded inside the Action Group as a list of $40$-byte entries, each the $32$-byte encoding $\mathrm{𝖺𝗌𝗌𝖾𝗍}\mathrm{\_}\mathrm{𝖻𝖺𝗌𝖾}$ of Definition 2.14 followed by the amount as an unsigned $64$-bit little-endian integer. ZIP 230 thus places one burn set in each Action Group, which under the limit of ZIP 227 of one Action Group per transaction is one burn set per transaction. Its field description of the amount, “non-zero, and less than $\mathrm{𝖬𝖠𝖷}\mathrm{\_}\mathrm{𝖡𝖴𝖱𝖭}\mathrm{\_}\mathrm{𝖵𝖠𝖫𝖴𝖤}$”, is superseded by rule (B2) of Definition 5.1, , which is ZIP 226’s (ZIP 230, “OrchardZSA Action Group Description” and “OrchardZSA Asset Burn Description”; ZIP 226, “Additional Consensus Rules for the assetBurn set”).

2. (b)

   The flags byte of the Action Group assigns bit $2$ to $\mathrm{𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠}$, an assignment without live counterpart (“Action Groups”, §4.5).

3. (c)

   Each Action carries the public fields of an Orchard Action description; the Action Group carries, in Action order, one spend-authorisation signature per Action, and the aggregate proof. The byte lengths of an Action depend on a plaintext encoding that no current ZIP defines (“Action Groups”, §4.5).

The pool into which a carrier would place OrchardZSA notes is the subject of Remark 1.7.

The signed message. Every signature that OrchardZSA uses signs one message, $\mathrm{𝖲𝗂𝗀𝖧𝖺𝗌𝗁}$: the issuance authorisation signature, by rule (I3) of Definition 6.12, the spend-authorisation signature of each Action, and the binding signature of the bundle (Definition 5.4; ZIP 226, “Value Balance Verification”; Ironwood Guide, Definition “Signature digest”). ZIP 227 defines $\mathrm{𝖲𝗂𝗀𝖧𝖺𝗌𝗁}$ as the digest of the protocol specification, §“SIGHASH Transaction Hashing”, under $\mathrm{𝖲𝖨𝖦𝖧𝖠𝖲𝖧}\mathrm{\_}\mathrm{𝖠𝖫𝖫}$, “with the modifications described in ZIP 226”, and cites for them a ZIP 226 section “TxId Digest” that does not exist. ZIP 226, “Sighash modifications relative to ZIP 244”, and ZIP 227, “Modifications relative to ZIP 244”, defer those modifications to ZIP 246, “Digests for the Withdrawn Version 6 Transaction Format”, whose status is Withdrawn and whose digests “are now specified by ZIP 229” (ZIP 227, “Specification: Consensus Rule Changes”; ZIP 246, “Abstract”).

Withdrawn design of the transaction identifier. ZIP 246 extends the digest tree of ZIP 244 (Ironwood Guide, Definition “Transaction identifier”). Each node is the function $𝗁=\mathrm{𝖡𝖫𝖠𝖪𝖤𝟤𝖻}\text{-}\mathrm{𝟤𝟧𝟨}$ under a personalisation of its own, applied to the concatenation of fixed-length digests and field encodings; a node that ZIP 246 does not redefine keeps its definition in ZIP 244. The root has six children:

$$\mathrm{𝗍𝗑𝗂𝖽}:=𝗁(\text{ZcashTxHash\_}\parallel \beta ,d_{\mathrm{𝗁𝖽𝗋}}\parallel d_{\mathrm{𝗍𝗋}}\parallel d_{\mathrm{𝖲𝖺𝗉}}\parallel d_{\mathrm{𝖮𝗋𝖼}}\parallel d_{\mathrm{𝖨𝗌𝗌}}\parallel d_{\mathrm{𝗆𝖾𝗆𝗈}}),$$

with $\beta$ the encoding of the consensus branch identifier as in the Ironwood Guide. The header digest $d_{\mathrm{𝗁𝖽𝗋}}$, redefined with fields of ZIPs outside this volume, the transparent digest $d_{\mathrm{𝗍𝗋}}$ and the Sapling digest $d_{\mathrm{𝖲𝖺𝗉}}$ carry no ZSA content. The other three children do.

1. (a)

   The Orchard branch $d_{\mathrm{𝖮𝗋𝖼}}$ hashes one digest over the Action Groups and the balancing value. For each Action Group, the digest over the Action Groups commits to every Action’s nullifier $\mathrm{𝗇𝖿}$, note commitment $\mathrm{𝖼𝗆𝗑}$, ephemeral key $\mathrm{𝖾𝗉𝗄}$ and ciphertexts $C_{\mathrm{𝖾𝗇𝖼}}$ and $C_{\mathrm{𝗈𝗎𝗍}}$, value commitment ${\mathrm{𝖼𝗏}}^{\mathrm{𝗇𝖾𝗍}}$ and randomised validating key $\mathrm{𝗋𝗄}$, in Action order, and to the flags byte, the anchor, the per-group expiry field and a burn digest. The burn digest hashes every burn pair $(\mathrm{𝖺𝗌𝗌𝖾𝗍}\mathrm{\_}\mathrm{𝖻𝖺𝗌𝖾},v)$ in encoding order, and is the hash of the empty string when the burn set is empty. Without an Action Group the Orchard branch is the hash of the empty string; since the burn set is encoded inside the Action Group, a transaction then has no burn set. With at most one Action Group per transaction (ZIP 227), the digest over the Action Groups is one hash over the elements of that group.

2. (b)

   The issuance branch $d_{\mathrm{𝖨𝗌𝗌}}$ hashes the length-prefixed $\mathrm{𝗂𝗌𝗌𝗎𝖾𝗋}$ and an actions digest, which commits, per Issuance Action and in order, to $\mathrm{𝖺𝗌𝗌𝖾𝗍𝖣𝖾𝗌𝖼𝖧𝖺𝗌𝗁}$, to a notes digest over every Issue Note’s recipient, value, $\rho$ and $\mathrm{𝗋𝗌𝖾𝖾𝖽}$, and to $\mathrm{𝖿𝗅𝖺𝗀𝗌𝖨𝗌𝗌𝗎𝖺𝗇𝖼𝖾}$. ZIP 246 states empty cases for the issuance digest, “no issuance components”, and for the notes digest, and none for the actions digest.

3. (c)

   The memo branch $d_{\mathrm{𝗆𝖾𝗆𝗈}}$ hashes a nonce and a digest over memo chunks, and presupposes the memo bundles of ZIP 231.

The personalisation strings of the nodes below the root are not listed, since no proof or rule of this volume uses them (ZIP 246, “TxId Digest”, nodes T.4, T.4a, T.4a.vi, T.5, T.5a, T.5a.i and T.6; ZIP 244, “TxId Digest”).

Withdrawn design of the signature digest and the authorising-data digest. The signature digest has the same six children as the transaction identifier. Its Orchard, issuance and memo children are those of $\mathrm{𝗍𝗑𝗂𝖽}$, and its transparent child is specific to the input, as in ZIP 244 (Ironwood Guide, Definition “Signature digest”). ZIP 246 produces a signature digest for each transparent input, each Sapling input, each Action and each Issuance Action; all of these except those of transparent inputs equal the $\mathrm{𝖲𝖨𝖦𝖧𝖠𝖲𝖧}\mathrm{\_}\mathrm{𝖠𝖫𝖫}$ digest $\mathrm{𝖲𝗂𝗀𝖧𝖺𝗌𝗁}$, since no other child depends on the signer. The authorising-data digest (Ironwood Guide, Definition “Authorising-data digest; effecting and authorising data”) has transparent, Sapling, Orchard and issuance children. The Orchard child hashes, per Action Group, the proof and the spend-authorisation signatures, and then the binding signature; the issuance child hashes the encoding of $\mathrm{𝗂𝗌𝗌𝗎𝖾𝖠𝗎𝗍𝗁𝖲𝗂𝗀}$. Proofs and signatures enter this digest only. ZIP 246 marks this digest as not yet updated for the $\mathrm{𝗌𝗂𝗀𝗁𝖺𝗌𝗁𝖨𝗇𝖿𝗈}$ fields of its format (ZIP 246, “v0 Digests”). ZIP 246 states that the pair of the transaction identifier and the authorising-data digest commits to all data of the transaction (ZIP 246, “Signature Digest” and “Authorizing Data Commitment”, nodes A.3, A.3a and A.4; ZIP 244, “Signature Digest” and “Authorizing Data Commitment”).

Current text. The version-$6$ digests of ZIP 229 have header, transparent, Sapling, Orchard and Ironwood children and no issuance, burn or memo-bundle data (no counterpart of the branch $d_{\mathrm{𝗆𝖾𝗆𝗈}}$ of ZIP 246); their Orchard child carries Orchard-pool Actions, which have no Asset Bases (Ironwood Guide, §“Transaction digests and signatures”; ZIP 229, “Transaction Identifiers, Auth Digests, and Signature Digests” and “Summary of the resulting digest structure”). ZIP 248 lets each bundle type define its own versions of the signature digest, carried with each signature as $\mathrm{𝗌𝗂𝗀𝗁𝖺𝗌𝗁𝖨𝗇𝖿𝗈}$, and defines none for a ZSA bundle (ZIP 248, “Sighash Versioning” and “Potential Future Bundle Types”). No current text specifies a digest that commits to OrchardZSA or issuance data.

The conventional fee. The transaction fee is the value remaining in the transparent transaction value pool, and ZIP 317, “Fee calculation”, specifies the conventional fee

	$$\mathrm{𝑚𝑎𝑟𝑔𝑖𝑛𝑎𝑙}\mathrm{\_}\mathrm{𝑓𝑒𝑒}\cdot \max (\mathrm{𝑔𝑟𝑎𝑐𝑒}\mathrm{\_}\mathrm{𝑎𝑐𝑡𝑖𝑜𝑛𝑠},\mathrm{𝑙𝑜𝑔𝑖𝑐𝑎𝑙}\mathrm{\_}\mathrm{𝑎𝑐𝑡𝑖𝑜𝑛𝑠})\text{ zatoshi},$$
	$$\mathrm{𝑚𝑎𝑟𝑔𝑖𝑛𝑎𝑙}\mathrm{\_}\mathrm{𝑓𝑒𝑒}=5000,\mathrm{𝑔𝑟𝑎𝑐𝑒}\mathrm{\_}\mathrm{𝑎𝑐𝑡𝑖𝑜𝑛𝑠}=2,$$

where $\mathrm{𝑙𝑜𝑔𝑖𝑐𝑎𝑙}\mathrm{\_}\mathrm{𝑎𝑐𝑡𝑖𝑜𝑛𝑠}$ is a sum of contributions per component, fixed by the applicable revision of ZIP 317. The fee and the formula are those of the Ironwood Guide, §“The balancing value”, and are cited, not re-derived. Paying the conventional fee is not a consensus requirement: “It is not a consensus requirement that fees follow this formula; however, wallets SHOULD create transactions that pay this fee” (ZIP 317, “Fee calculation”).

Fees in ZEC. Fees are paid in ZEC only. The balancing value is an amount of ZEC and enters the binding validating key at the base $V^{\mathrm{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}$ only (Definition 5.4), and a Custom Asset has no transparent value pool (Remark 5.3), so no Custom Asset reaches the pool whose remainder is the fee. ZIP 227 records the alternative, a fee denominated in the Custom Asset, as not adopted, since for shielded transactions any design that lifts value from the transaction leaks information about it (ZIP 226, “Value Balance Verification”; ZIP 227, “Rationale for paying fees in ZEC”).

Missing ZSA terms. ZIP 227, “Changes to ZIP 317”, states that the conventional fee in ZEC is altered for the Issuance Actions of a transaction and for Custom Assets newly created in the global issuance state, and refers to ZIP 317, “Fee calculation”. No revision of ZIP 317 has such a term; Revision 0 is Active and Revisions 1 and 2 are Draft. The Change History of ZIP 317 records “Removed the ZSA issuance and asset-creation fee contributions (ZIP 227)”. ZIP 226, “Transaction Fees”, links a ZIP 227 section “OrchardZSA Fee Calculation” that does not exist. Both references dangle. The removed design had one contribution per Issue Note and one per newly created Custom Asset; their values are not quoted (ZIP 317, “Revisions”, “Fee calculation” and “Change History”).