V Ironwood Guide: The Zcash Orchard protocol and its Ironwood pool 10 Note encryption 12 Security

11 Transactions and consensus rules

This section assembles the public data of an Action and of a bundle, states the transaction format that carries them, constructs the digest that both kinds of signature sign and proves in Proposition 11.10 which data the signatures fix, states the chain state and the rules of each pool, and gives the procedures of the sender and of the verifier, with a worked two-Action payment.

11.1 Action descriptions and bundles

The objects of this subsection are constructed in §4 to §10. The subsection fixes their encodings and their grouping; it redefines neither the Action nor the bundle (Definitions “Action” and “Bundle”, §4.4). As in §10.2, a star encoding $P^{\star}$ enters a byte string as the $32$ bytes $\mathsf{LEBS2OSP}_{256}(P^{\star})$ and is identified with them.

Definition 11.1 (Action description).

The Action description of an Action is the byte string

(\mathsf{cv}^{\mathsf{net}})^{\star}\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{nf})% \,\|\,\mathsf{rk}^{\star}\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{cmx})\,\|\,% \mathsf{epk}^{\star}\,\|\,C_{\mathsf{enc}}\,\|\,C_{\mathsf{out}}

of $5\cdot 32+580+80=820$ bytes, whose fields, in this order, are those of Table 6: the net value commitment of Definition 8.2, the nullifier of the consumed note (Definition 6.3), the randomised validating key of “Randomised validating keys” (§7.2), the extracted commitment of the created note (Definition 4.4), and the ephemeral public key and the two ciphertexts of “Encryption to the recipient” (§10.2) and “The outgoing ciphertext” (§10.3) (protocol specification, §“Action Descriptions” and §“Action Description Encoding and Consensus”).

Field	Type enforced on parsing	Encoding	Bytes	Constructed in
$\mathsf{cv}^{\mathsf{net}}$	$\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ , the identity admitted	$(\mathsf{cv}^{\mathsf{net}})^{\star}$	$32$	Definition 8.2
$\mathsf{nf}$	$\{0,\dots,p_{\mathsf{Pallas}}-1\}$	$\mathsf{I2LEOSP}_{256}(\mathsf{nf})$	$32$	Definition 6.3
$\mathsf{rk}$	$\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ ; the identity excluded by a separate rule	$\mathsf{rk}^{\star}$	$32$	§7.2
$\mathsf{cmx}$	$\{0,\dots,p_{\mathsf{Pallas}}-1\}$	$\mathsf{I2LEOSP}_{256}(\mathsf{cmx})$	$32$	Definition 4.4
$\mathsf{epk}$	$\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})\setminus\{\mathcal{O}\}$	$\mathsf{epk}^{\star}$	$32$	§10.2
$C_{\mathsf{enc}}$	$580$ -byte string	itself	$580$	§10.2
$C_{\mathsf{out}}$	$80$ -byte string	itself	$80$	§10.3
Action description			$820$

Table 6: The fields of an Action description, in the order of their encoding, with the type that parsing enforces and the byte length of the encoding.

Every field of an Action description must be the canonical encoding of its type (protocol specification, §“Action Descriptions”; for $\mathsf{cmx}$ also §“Action Description Encoding and Consensus”). Hence $\mathsf{nf}$ and $\mathsf{cmx}$ are integers below $p_{\mathsf{Pallas}}$ , and neither is checked to be the $x$ -coordinate of a Pallas point; $\mathsf{epk}$ is a non-identity point by its type; $\mathsf{rk}$ is a point, and the rule of “Randomised validating keys” (§7.2) excludes the identity; and $\mathsf{cv}^{\mathsf{net}}$ may be the identity. The Action’s spend-authorisation signature, of $64$ bytes (“The RedPallas signature scheme”, §7.1), and its proof are not part of the Action description. The bundle carries the signatures, one per Action, and one aggregate proof, whose per-Action instances are in the order of the Action descriptions (ZIP 229, “Consensus Rules”).

A bundle of one pool with $n\geq 1$ Actions publishes:

(i)

its $n$ Action descriptions;
(ii)

one anchor $\mathit{rt}$ (“Anchors”, §5.2), shared by all $n$ Actions: no Action description carries an anchor, and the transaction carries one anchor field for each pool with Actions, $\mathsf{anchorOrchard}$ and $\mathsf{anchorIronwood}$ ;
(iii)

one flags byte (“Bundle flags”, §9.1), whose bit $0$ is $\mathsf{enableSpends}$ and bit $1$ $\mathsf{enableOutputs}$ , and whose bit $2$ is $\mathsf{enableCrossAddress}$ in $\mathsf{flagsIronwood}$ and reserved and $0$ in $\mathsf{flagsOrchard}$ ;
(iv)

the balancing value $v^{\mathsf{balance}}$ of “The balancing value” (§8.2);
(v)

one aggregate proof over its $n$ Actions (“The Action circuit and the Halo 2 proof”, §9.3);
(vi)

$n$ spend-authorisation signatures, one per Action;
(vii)

one binding signature (“The binding signature”, §8.3).

The anchor and the flags are common to all Actions of the bundle and are encoded once (protocol specification, §“Action Transfers and their Descriptions” and §“Action Descriptions”, note). A transaction carries at most one bundle per pool, hence one binding signature for each pool with Actions (ZIP 229, “Transaction Format” and “Consensus Rules”). Figure 4 shows each public field with the checks that consume it.

A bundle that consumes $s$ real notes and creates $o$ real notes has $n\geq\max(s,o)$ Actions, since every Action consumes exactly one note and creates exactly one; its $n-s$ consumed sides and $n-o$ created sides without a real note carry dummy notes of value $0$ (Definition “Dummy notes”, §4.4; protocol specification, §“Dummy Notes (Orchard)”). When the consumed value exceeds the payment and the fee, the difference is change: an ordinary created note to an address of the sender, constructed as every other created note.

Refer to caption — Figure 4: The public data of one bundle and the checks that consume them. Rows are the fields: per Action $i$ , the net value commitment $\mathsf{cv}^{\mathsf{net}}$ , the nullifier $\mathsf{nf}$ , the randomised validating key $\mathsf{rk}$ , the extracted commitment $\mathsf{cmx}$ , the ephemeral key $\mathsf{epk}^{\star}$ and the ciphertexts $C_{\mathsf{enc}}$ and $C_{\mathsf{out}}$ of the Action description, and the spend-authorisation signature $\sigma_{i}$ ; per bundle, the flags byte, the balancing value $v^{\mathsf{balance}}$ , the anchor $\mathit{rt}$ , the aggregate proof $\pi$ and the binding signature. Each column ends in the check or derived key that consumes it. A dot joins a field to a column; a row that crosses a column without a dot is not joined to it. Blue rows are effecting data and amber rows authorising data (“Transaction digests and signatures”, §11.3). Every effecting field, the ciphertexts included, joins the signature digest $\mathsf{SigHash}$ , which feeds every spend-authorisation signature and the binding signature; the anchor and the proof do not join it (Proposition 11.10). The fields $\mathsf{nf}$ , $\mathsf{cmx}$ , $\mathsf{cv}^{\mathsf{net}}$ , $\mathsf{rk}$ , the flags and $\mathit{rt}$ are primary inputs of the Action proof; $\mathit{rt}$ also feeds the anchor rule, $\mathsf{nf}$ the nullifier-set rule, $\mathsf{rk}$ the spend-authorisation signature, and $\mathsf{cv}^{\mathsf{net}}$ and $v^{\mathsf{balance}}$ the binding validating key $\mathsf{bvk}$ .

11.2 The transaction format

The transaction formats in force are version $5$ , specified in ZIP 225, and version $6$ , specified in ZIP 229; a transaction of any other version, version $4$ included, is invalid (protocol specification, §“Transaction Consensus Rules”, as amended by ZIP 2003, “Specification”; ZIP 259, Abstract). Of the two Orchard-protocol bundles a version- $5$ transaction can carry only the Orchard-pool bundle; a transaction with Ironwood-pool Actions is of version $6$ (protocol specification, §“Action Descriptions”). The Orchard-pool rules of “Chain state and pool rules” (§11.4) apply to Orchard-pool Actions in both versions (ZIP 229, “Consensus Rules”). Sprout, Zcash’s first shielded protocol, spends its notes only through JoinSplit descriptions, its transfer descriptions, which only transaction versions $2$ to $4$ carry (protocol specification, §“Transaction Encoding and Consensus”); Sprout funds are therefore unspendable, and their value remains counted as issued, in the sense of the total issued supply defined in “Chain state and pool rules” (§11.4) (ZIP 2003, Abstract and “Interaction with the proposed Network Sustainability Mechanism”; ZIP 259, Abstract). This subsection describes version $6$ .

Construction 11.2 (Version-6 transaction).

A version- $6$ transaction consists of the fields of the version- $5$ format up to and including the Orchard component (ZIP 225), followed by the Ironwood component. Its first five fields form the header:

(i)

$\mathsf{header}$ , whose bit $31$ , the $\mathsf{fOverwintered}$ flag, is set and whose bits $0$ to $30$ hold the version, $6$ ;
(ii)

$\mathsf{nVersionGroupId}$ , which must be $\mathtt{0xD884B698}$ ;
(iii)

$\mathsf{nConsensusBranchId}$ , which must equal the consensus branch identifier used by the signature digest of “Transaction digests and signatures” (§11.3), the identifier of the consensus branch under which the transaction is validated, where a consensus branch is a sequence of consecutive blocks under one consensus rule set whose first block is the genesis block or follows a block validated under older rules, and each network upgrade fixes for the branch that it begins a globally unique non-zero $32$ -bit consensus branch identifier (ZIP 200, Terminology and “Specification”);
(iv)

$\mathsf{lock\_time}$ , the transparent lock time, which no rule of this volume uses;
(v)

$\mathsf{nExpiryHeight}$ , the expiry height.

In version $6$ , bits $0$ and $1$ of $\mathsf{flagsOrchard}$ are named $\mathsf{enableSpends}$ and $\mathsf{enableOutputs}$ , as in $\mathsf{flagsIronwood}$ , and bits $2$ to $7$ of $\mathsf{flagsOrchard}$ are reserved and must be $0$ , in version $5$ and version $6$ alike (“Bundle flags”, §9.1). The Ironwood component has the structure of the Orchard component, with its own flags, balancing value, anchor, proof and signatures; both encode each Action as the $820$ -byte Action description of §11.1 (ZIP 229, “Transaction Format” and “Consensus Rules”; protocol specification, §“Transaction Consensus Rules”).

Definition 11.3 (Coinbase transaction).

A coinbase transaction is the first transaction of a block; it collects the block subsidy, the value newly issued in that block, and the fees of the block’s other transactions. Every block has exactly one (protocol specification, §“Coinbase Transactions”).

The field $\mathsf{nExpiryHeight}$ is $0$ , which disables expiry, or a block height. The expiry rule is: for a transaction other than a coinbase transaction, $\mathsf{nExpiryHeight}$ is at most $499\,999\,999$ , and such a transaction with $\mathsf{nExpiryHeight}\neq 0$ is invalid in every block of height greater than $\mathsf{nExpiryHeight}$ ; the $\mathsf{nExpiryHeight}$ of a coinbase transaction equals the height of its block (protocol specification, §“Transaction Consensus Rules”; ZIP 203, “Specification”; ZIP 229, “Transaction Format”). The sender’s choice of the expiry height is stated in “Construction of a transaction” (§11.5).

Definition 11.4 (Ironwood component).

Let $n$ be the number of Ironwood-pool Actions of a version- $6$ transaction. The Ironwood component is the sequence of the fields of Table 7, in that order. The fields after $\mathsf{nActionsIronwood}$ are present if and only if $n>0$ , and an absent $\mathsf{valueBalanceIronwood}$ is taken to be $0$ . A count and a proof length are encoded as compactSize, the variable-length integer encoding of Bitcoin (ZIP 229, “Transaction Format”).

Field	Bytes	Content
$\mathsf{nActionsIronwood}$	compactSize	the count $n$
$\mathsf{vActionsIronwood}$	$820\,n$	the $n$ Action descriptions of §11.1
$\mathsf{flagsIronwood}$	$1$	bit $0$ $\mathsf{enableSpends}$ , bit $1$ $\mathsf{enableOutputs}$ , bit $2$ $\mathsf{enableCrossAddress}$ , bits $3$ to $7$ reserved and $0$
$\mathsf{valueBalanceIronwood}$	$8$	the balancing value, signed $64$ -bit little-endian
$\mathsf{anchorIronwood}$	$32$	the anchor $\mathit{rt}$
$\mathsf{sizeProofsIronwood}$	compactSize	the proof length, $2720+2272\,n$
$\mathsf{proofsIronwood}$	$2720+2272\,n$	the aggregate proof
$\mathsf{vSpendAuthSigsIronwood}$	$64\,n$	one spend-authorisation signature per Action, in Action order
$\mathsf{bindingSigIronwood}$	$64$	the binding signature

Table 7: The Ironwood component of a version-

6

transaction with

n

Ironwood-pool Actions (ZIP 229, “Transaction Format”). The fields after the count are present if and only if

n>0

The consensus rules on the component are: $n<2^{16}$ ; if $n>0$ , at least one of $\mathsf{enableSpends}$ and $\mathsf{enableOutputs}$ of $\mathsf{flagsIronwood}$ is $1$ ; bits $3$ to $7$ of $\mathsf{flagsIronwood}$ are $0$ ; $\mathsf{valueBalanceIronwood}$ lies in $\{-\mathsf{MAX\_MONEY},\dots,\mathsf{MAX\_MONEY}\}$ , where $\mathsf{MAX\_MONEY}=2.1\cdot 10^{15}$ zatoshi is a protocol constant (protocol specification, §“Constants”); and $\mathsf{proofsIronwood}$ has exactly $2720+2272\,n$ bytes (ZIP 229, “Consensus Rules”; protocol specification, §“Transaction Consensus Rules” and §“Action Description Encoding and Consensus”). The flags byte differs from $\mathsf{flagsOrchard}$ only in bit $2$ , which is $\mathsf{enableCrossAddress}$ in $\mathsf{flagsIronwood}$ and reserved and $0$ in $\mathsf{flagsOrchard}$ (“Bundle flags”, §9.1). The proof length is the one that ZIP 229 fixes; the Halo 2 Guide, §“Halo 2’s specifics: parameters, generators from a hash, the deferred multi-scalar multiplication, and the proof bytes”, paragraph “The bytes”, describes what its constant and its per-Action term cover. For one Action the proof has $2720+2272=4992$ bytes.

11.3 Transaction digests and signatures

Write $\mathsf{h}(P,x):=\mathrm{BLAKE2b\text{-}256}(P,x)$ , unkeyed BLAKE2b with a $32$ -byte output, the $16$ -byte personalisation $P$ and the input $x$ (§10.2); the personalisation is mixed into the initialisation vector (Crypto Guide, §“Domain separation and personalisation”). For a byte string $C$ and $0\leq a\leq b\leq|C|$ , the string $C[a{:}b]$ consists of the bytes $a$ to $b-1$ of $C$ , counted from $0$ . Every field enters a digest in its encoding of Table 6 or Table 7, and $\beta$ denotes the $4$ -byte little-endian encoding of the consensus branch identifier.

Definition 11.5 (Transaction identifier).

The transaction identifier of a version- $6$ transaction is

\mathsf{txid}:=\mathsf{h}\bigl{(}\texttt{ZcashTxHash\_}\,\|\,\beta,\ d_{% \mathsf{hdr}}\,\|\,d_{\mathsf{tr}}\,\|\,d_{\mathsf{Sap}}\,\|\,d_{\mathsf{Orc}}% \,\|\,d_{\mathsf{Irw}}\bigr{)},

the Ironwood digest last, where:

(i)

the header digest $d_{\mathsf{hdr}}$ is $\mathsf{h}$ under ZTxIdHeadersHash of the $4$ -byte little-endian encodings of $\mathsf{header}$ , $\mathsf{nVersionGroupId}$ , $\mathsf{nConsensusBranchId}$ , $\mathsf{lock\_time}$ and $\mathsf{nExpiryHeight}$ ;
(ii)

the transparent digest $d_{\mathsf{tr}}$ and the Sapling digest $d_{\mathsf{Sap}}$ are those of ZIP 244, “T.2: transparent_digest” and “T.3: sapling_digest”, the latter with the version- $6$ node of ZIP 229; they cover the transparent inputs and outputs and the Sapling component, the component of Zcash’s second shielded protocol;

(iii)

for $n\geq 1$ Ironwood-pool Actions, with the fields of Action $i$ indexed by $i$ , the Ironwood digest is

	$\displaystyle d_{\mathsf{Irw}}$	$\displaystyle:=\mathsf{h}\bigl{(}\texttt{ZTxIdIronwd\_H\_v6},\ d_{\mathsf{C}}% \,\\|\,d_{\mathsf{M}}\,\\|\,d_{\mathsf{N}}\,\\|\,\mathsf{flagsIronwood}\,\\|\,% \mathsf{valueBalanceIronwood}\bigr{)},$
	$\displaystyle d_{\mathsf{X}}$	$\displaystyle:=\mathsf{h}\bigl{(}P_{\mathsf{X}},\ r^{\mathsf{X}}_{1}\,\\|\,% \cdots\,\\|\,r^{\mathsf{X}}_{n}\bigr{)}\qquad(\mathsf{X}\in\{\mathsf{C},\mathsf% {M},\mathsf{N}\}),$

with the compact, memo and non-compact records and personalisations

$\displaystyle r^{\mathsf{C}}_{i}$	$\displaystyle:=\mathsf{nf}_{i}\,\\|\,\mathsf{cmx}_{i}\,\\|\,\mathsf{epk}_{i}^{% \star}\,\\|\,C_{\mathsf{enc},i}[0{:}52],$	$\displaystyle P_{\mathsf{C}}$	$\displaystyle:=\texttt{ZTxIdIrnActCH\_v6},$
$\displaystyle r^{\mathsf{M}}_{i}$	$\displaystyle:=C_{\mathsf{enc},i}[52{:}564],$	$\displaystyle P_{\mathsf{M}}$	$\displaystyle:=\texttt{ZTxIdIrnActMH\_v6},$
$\displaystyle r^{\mathsf{N}}_{i}$	$\displaystyle:=(\mathsf{cv}^{\mathsf{net}}_{i})^{\star}\,\\|\,\mathsf{rk}_{i}^{% \star}\,\\|\,C_{\mathsf{enc},i}[564{:}580]\,\\|\,C_{\mathsf{out},i},$	$\displaystyle P_{\mathsf{N}}$	$\displaystyle:=\texttt{ZTxIdIrnActNH\_v6};$

for $n=0$ it is $d_{\mathsf{Irw}}:=\mathsf{h}(\texttt{ZTxIdIronwd\_H\_v6},\varepsilon)$ ;

(iv)

the Orchard digest $d_{\mathsf{Orc}}$ has the same structure over the Orchard-pool Actions, with $\mathsf{flagsOrchard}$ and $\mathsf{valueBalanceOrchard}$ , under the personalisation ZTxIdOrchardH_v6, with the Action digests personalised

$P_{\mathsf{C}}=\texttt{ZTxIdOrcActCHash},\quad P_{\mathsf{M}}=\texttt{% ZTxIdOrcActMHash},\quad P_{\mathsf{N}}=\texttt{ZTxIdOrcActNHash};$

without Orchard-pool Actions it is $\mathsf{h}(\texttt{ZTxIdOrchardH\_v6},\varepsilon)$ .

(ZIP 244, “Digests”, “txid_digest”, “T.1: header_digest” and “T.4: orchard_digest”; ZIP 229, “Ironwood component digest”, “Anchor commitment (version 6)” and “Summary of the resulting digest structure”.)

The ciphertext $C_{\mathsf{enc}}$ is the ChaCha20 encryption of the $564$ -byte note plaintext, byte for byte, followed by the $16$ -byte tag (Crypto Guide, §“The ChaCha20-Poly1305 AEAD”, Construction “ChaCha20-Poly1305”; “The note plaintext”, §10.1). The offsets therefore split it into the encryption of the $52$ -byte prefix of the plaintext, the lead byte, $d$ , $v$ and $\mathsf{rseed}$ ( $1+11+8+32=52$ ), the encryption of the $512$ -byte memo, ending at $52+512=564$ , and the tag. The empty Ironwood digest differs from the empty Orchard digest, since the two personalisations differ. Neither pool digest contains the anchor.

Definition 11.6 (Authorising-data digest; effecting and authorising data).

The authorising-data digest of a version- $6$ transaction is

\mathsf{auth}:=\mathsf{h}\bigl{(}\texttt{ZTxAuthHash\_}\,\|\,\beta,\ a_{% \mathsf{tr}}\,\|\,a_{\mathsf{Sap}}\,\|\,a_{\mathsf{Orc}}\,\|\,a_{\mathsf{Irw}}% \bigr{)},

where $a_{\mathsf{tr}}$ is the transparent scripts digest and $a_{\mathsf{Sap}}$ the Sapling authorising-data digest (ZIP 244, “Authorizing Data Commitment”; ZIP 229), and, for $n\geq 1$ Ironwood-pool Actions,

	$\displaystyle a_{\mathsf{Irw}}:=\mathsf{h}\bigl{(}\texttt{ZTxAuthIrnwdH\_v6},\$	$\displaystyle\mathsf{proofsIronwood}\,\\|\,\mathsf{vSpendAuthSigsIronwood}$
		$\displaystyle\,\\|\,\mathsf{bindingSigIronwood}\,\\|\,\mathsf{anchorIronwood}% \bigr{)},$

and $a_{\mathsf{Irw}}:=\mathsf{h}(\texttt{ZTxAuthIrnwdH\_v6},\varepsilon)$ for $n=0$ ; the Orchard digest $a_{\mathsf{Orc}}$ has the same structure under ZTxAuthOrchaH_v6. Each Orchard-protocol anchor is committed if and only if its component has Actions. The effecting data of a transaction are the data under the transaction identifier digest; its authorising data are the proofs, the signatures, the anchors and the transparent scripts, the data under the authorising-data digest (ZIP 229, “Ironwood component digest” and “Anchor commitment (version 6)”; ZIP 244, “Authorizing Data Commitment”).

ZIP 244, “Authorizing Data Commitment”, describes the pair of the transaction identifier and the authorising-data digest as a commitment to all data of the transaction. In version $6$ the anchors are authorising data so that a transaction can be signed before its anchor is chosen and its proofs are computed; replacing a bundle’s anchor and proof together does not change the transaction identifier (ZIP 229, Motivation and “Anchor commitment (version 6)”). Below the two roots, a node whose directly hashed input differs between versions $5$ and $6$ has a version- $6$ personalisation of its own; the roots keep theirs and hash one more child in version $6$ . The nodes that omit or include an anchor in version $6$ are personalised ZTxIdSSpendNH_v6, ZTxAuthSapliH_v6, ZTxIdOrchardH_v6 and ZTxAuthOrchaH_v6 (ZIP 229, “Ironwood component digest” and “Anchor commitment (version 6)”).

Definition 11.7 (Signature digest).

The signature digest of a transaction is its digest not associated with a transparent input, under the hash type $\mathsf{SIGHASH\_ALL}$ , which covers all transparent inputs and outputs:

\mathsf{SigHash}:=\mathsf{h}\bigl{(}\texttt{ZcashTxHash\_}\,\|\,\beta,\ d_{% \mathsf{hdr}}\,\|\,s_{\mathsf{tr}}\,\|\,d_{\mathsf{Sap}}\,\|\,d_{\mathsf{Orc}}% \,\|\,d_{\mathsf{Irw}}\bigr{)},

whose header and shielded children are those of $\mathsf{txid}$ and whose child $s_{\mathsf{tr}}$ is the transparent signature digest of ZIP 244, “S.2: transparent_sig_digest”. For a coinbase transaction and for a transaction without transparent inputs, $s_{\mathsf{tr}}=d_{\mathsf{tr}}$ , so $\mathsf{SigHash}=\mathsf{txid}$ ; otherwise $s_{\mathsf{tr}}$ commits in addition to the values and scripts of the coins that the transparent inputs spend. The digest $\mathsf{SigHash}$ is the message of every spend-authorisation signature and of each pool’s binding signature, the message left as a parameter in “The RedPallas signature scheme” (§7.1) (ZIP 244, “Signature Digest”; ZIP 229, “Transaction Identifiers, Auth Digests, and Signature Digests”; protocol specification, §“Action Descriptions” and §“Balance and Binding Signature (Orchard)”).

Proposition 8.10, which holds for every message, applies to the binding signature on $\mathsf{SigHash}$ .

Remark 11.8 (Version 5).

In version $5$ the root of the transaction identifier has four children, the header, transparent, Sapling and Orchard digests, under the same root personalisation. The Orchard digest, under ZTxIdOrchardHash, hashes

d_{\mathsf{C}}\,\|\,d_{\mathsf{M}}\,\|\,d_{\mathsf{N}}\,\|\,\mathsf{% flagsOrchard}\,\|\,\mathsf{valueBalanceOrchard}\,\|\,\mathsf{anchorOrchard},

with the Action digests of version $6$ , and the Orchard authorising-data digest, under ZTxAuthOrchaHash, covers the proofs and the signatures only. In version $5$ the Orchard anchor is therefore effecting data and fixed by the signatures; the proofs are authorising data in both versions. A version- $5$ transaction carries Orchard-pool Actions only (ZIP 244, “txid_digest”, “T.4: orchard_digest” and “A.3: orchard_auth_digest”).

Figure 5 draws both trees. The binding of the signatures needs one further assumption, stated at its first use.

Assumption 11.9 (Collision resistance of BLAKE2b).

No efficient algorithm outputs, except with negligible probability, two distinct pairs $(P,x)$ and $(P^{\prime},x^{\prime})$ , each of a $16$ -byte personalisation and an input string, with $\mathsf{h}(P,x)=\mathsf{h}(P^{\prime},x^{\prime})$ . The notion is the Crypto Guide’s Definition “Collision resistance” (§“Security notions: preimage, second-preimage, and collision resistance”), read for the unkeyed deployment as that volume’s Remark “Convention: keyed definitions, unkeyed deployments” (§“Hash functions and the random oracle model”, §“Syntax”) prescribes; the personalisation is mixed into the initialisation vector (§“Domain separation and personalisation”), so the pair $(P,x)$ is the hashed input. It is used by Proposition 11.10 and by the consensus-branch binding below.

Proposition 11.10 (Bundle binding).

Let $T$ be a version- $6$ transaction, and for a bundle of $T$ , of either pool, let $\mathsf{rk}_{1},\dots,\mathsf{rk}_{n}$ be the randomised validating keys of its Actions, $\mathsf{rk}_{i}=[\mathsf{rsk}_{i}]\,G^{\mathsf{SpendAuth}}$ with $\mathsf{rsk}_{i}=\mathsf{ask}_{i}+\alpha_{i}$ as in “Randomised validating keys” (§7.2), where $\mathsf{ask}_{i}$ is the spend authorising key of the spending key that authorises Action $i$ . Assume:

(H)

each $\mathsf{ask}_{i}$ is uniform on the non-zero scalars $a$ for which $[a]\,G^{\mathsf{SpendAuth}}$ has even $y$ -coordinate (§3.1), and every value of the experiment other than a signature by the holder of $\mathsf{ask}_{i}$ is computed from $\mathsf{ak}^{\mathbb{P}}_{i}=[\mathsf{ask}_{i}]\,G^{\mathsf{SpendAuth}}$ and from values drawn independently of $\mathsf{ask}_{i}$ ;
(S)

the holder of $\mathsf{ask}_{i}$ signs under $\mathsf{rsk}_{i}$ only $\mathsf{SigHash}(T)$ , and signs any other message only under $\mathsf{ask}_{i}+\alpha$ for a fresh randomiser $\alpha$ drawn by $\mathsf{GenRandom}$ .

An adversary receives $T$ and all other public data, and obtains on request, for messages of its choice, signatures of the key holders under fresh randomisers as in (S); it receives no $\mathsf{ask}_{i}$ and no $\mathsf{rsk}_{i}$ . Under Assumptions 11.9, 2.22 and 7.3, the probability that it outputs an accepted transaction $T^{\prime}$ that contains an Action description with validating key $\mathsf{rk}_{i}$ for some $i$ and whose effecting data differ from those of $T$ is negligible.

The signatures thus fix the effecting data: every Action’s $\mathsf{nf}$ , $\mathsf{cmx}$ , $\mathsf{cv}^{\mathsf{net}}$ , $\mathsf{rk}$ , $\mathsf{epk}$ , $C_{\mathsf{enc}}$ and $C_{\mathsf{out}}$ , the number and order of the Actions, each bundle’s flags and balancing value, the header, with the consensus branch identifier and the expiry height, and the transparent data. They fix neither the anchor nor the proof of a bundle: for a pair $(\mathit{rt}^{\prime},\pi^{\prime})$ such that $\pi^{\prime}$ verifies on the primary inputs formed with $\mathit{rt}^{\prime}$ , replacing $(\mathit{rt},\pi)$ by $(\mathit{rt}^{\prime},\pi^{\prime})$ changes neither the transaction identifier nor any signed message, so every signature remains valid, and $\pi^{\prime}$ binds $\mathit{rt}^{\prime}$ as a primary input (Definition 9.2).

Proof.

Let $E$ be the event that the adversary outputs such a $T^{\prime}$ . On $E$ , let $i$ be the least index for which $T^{\prime}$ contains an Action description with key $\mathsf{rk}_{i}$ , and let $\sigma^{\prime}$ be the spend-authorisation signature that $T^{\prime}$ carries for it. Since $T^{\prime}$ is accepted, $\sigma^{\prime}$ is valid under $\mathsf{rk}_{i}$ on $m^{\prime}:=\mathsf{SigHash}(T^{\prime})$ (“Randomised validating keys”, §7.2). Let $m:=\mathsf{SigHash}(T)$ , and split $E$ into $E_{=}$ , where $m^{\prime}=m$ , and $E_{\neq}$ , where $m^{\prime}\neq m$ .

Case $E_{=}$ : a collision. The digest $\mathsf{SigHash}$ is computed by the tree of its definition from the effecting data and, when the transaction has transparent inputs, from the values and scripts of the coins that they spend. Each node hashes a string from which its children and its fields are recovered uniquely: its input consists of fixed-length fields and digests, of concatenations of fixed-length per-Action records whose number the length determines, or, for transparent outputs, of records whose variable-length script carries its length; the two nodes that share a personalisation, the transparent digest and the transparent signature digest, hash strings of different lengths (ZIP 244, “TxId Digest” and “Signature Digest”). Compare the trees of $T$ and $T^{\prime}$ from the root, whose outputs are equal. At a node with equal outputs, either the two (personalisation, input) pairs differ, a collision of $\mathsf{h}$ , or they agree, and then the node’s children have equal outputs and its fields are equal. The effecting data of $T$ and $T^{\prime}$ differ, so some field, or some number of records, differs, and descending along the nodes that cover it ends in a collision. An algorithm that runs the experiment, which it can since it samples every key, and performs this descent outputs a collision with probability $\mathrm{Pr}[E_{=}]$ , which is negligible by Assumption 11.9.

Case $E_{\neq}$ : a forgery. An algorithm $\mathcal{B}$ plays the adversary of Proposition 7.12. It receives $Y=[x]\,G^{\mathsf{SpendAuth}}$ for $x$ uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , with access to $\mathsf{H}$ and to the signing oracle, and draws $i^{*}$ uniformly from $\{1,\dots,n\}$ . If $Y=\mathcal{O}$ or $Y$ has odd $y$ -coordinate, it stops; otherwise, an event of probability $(p_{\mathsf{Vesta}}-1)/(2p_{\mathsf{Vesta}})$ , the point $Y$ has the distribution that (H) gives to $\mathsf{ak}^{\mathbb{P}}_{i^{*}}$ , and $\mathcal{B}$ sets $\mathsf{ak}^{\mathbb{P}}_{i^{*}}:=Y$ . It computes every other value of the experiment as (H) permits, in particular the proof of $T$ , whose witness (Definition 9.2) contains $\mathsf{ak}^{\mathbb{P}}$ and $\alpha$ but not $\mathsf{ask}$ ; it draws every randomiser by $\mathsf{GenRandom}$ itself; it obtains each signature by the holder of $\mathsf{ask}_{i^{*}}$ , on $m$ and on the adversary’s requests, as the oracle’s answer on the pair $(\alpha,M)$ ; and it produces the other signatures with keys it holds. The adversary’s view is then that of the experiment. On $E_{\neq}$ with $i=i^{*}$ , $\mathcal{B}$ outputs $(\mathsf{rk}_{i^{*}},m^{\prime},\sigma^{\prime})$ with the randomiser $\alpha_{i^{*}}$ , of its own choice, as part (ii) of Proposition 7.12 admits. The oracle answered under the key $\mathsf{rk}_{i^{*}}$ only on $m$ , except when a randomiser drawn for a request equals $\alpha_{i^{*}}$ , which has negligible probability by the lemma on the distance of $\mathsf{GenRandom}$ from uniform (§7.2); outside that event the output is a forgery. The index $i^{*}$ is independent of the adversary’s view, so $\mathcal{B}$ forges with probability at least

\frac{p_{\mathsf{Vesta}}-1}{2p_{\mathsf{Vesta}}}\cdot\frac{\mathrm{Pr}[E_{\neq% }]}{n}

less a negligible term, where $n<2^{16}$ . By Proposition 7.12(ii), under Assumptions 2.22 and 7.3, $\mathrm{Pr}[E_{\neq}]$ is negligible.

Anchor and proof. By the definitions above, the anchor and the proof of each bundle are inputs of the authorising-data digest and of no node of $\mathsf{txid}$ or $\mathsf{SigHash}$ . Replacing them changes neither, and every signature, whose message is $\mathsf{SigHash}$ , remains valid. The verifier checks the bundle’s proof against the primary inputs formed with the bundle’s anchor field (protocol specification, §“Action Descriptions”), now $\mathit{rt}^{\prime}$ , so the modified bundle is accepted only if $\pi^{\prime}$ verifies for $\mathit{rt}^{\prime}$ , and the anchor rule then applies to $\mathit{rt}^{\prime}$ . □

Remark 11.11 (Hypothesis (H) for honest keys).

For keys generated with $\mathsf{use\_qsk}=\mathsf{false}$ from uniform spending keys, hypothesis (H) holds up to a negligible change in the probability of every efficiently decidable event, in particular of the event of Proposition 11.10, which an algorithm holding the keys decides by verifying $T^{\prime}$ and comparing its effecting data with those of $T$ . By Lemma 2.15 (Assumption 2.12) the triple $(\mathsf{ask},\mathsf{nk},\mathsf{r_{ivk}})$ is indistinguishable from independent uniform elements; the sign normalisation of “The spending key and the spend-side secrets” (§3.1) maps a uniform non-zero $\mathsf{ask}$ to the uniform distribution on the set of (H); and rejection, by Lemma “Rejection in key generation” (§3.2), costs a negligible term under Assumptions 2.12, 2.22 and 2.8. A dummy spend uses such a key (Definition “Dummy notes”, §4.4).

Remark 11.12 (Consensus-branch binding).

The consensus branch identifier enters $\mathsf{SigHash}$ twice, in the root personalisation and in the header digest, and a consensus rule requires $\mathsf{nConsensusBranchId}$ to equal the identifier of the consensus branch under which the transaction is validated (protocol specification, §“Transaction Consensus Rules”; ZIP 244, “txid_digest” and “T.1: header_digest”). Under any other branch a signed transaction $T$ either fails that rule or carries another $\mathsf{nConsensusBranchId}$ , hence other effecting data, and Proposition 11.10 excludes valid signatures on such a transaction that keeps an Action of $T$ , except with negligible probability. A signed transaction is therefore valid under one consensus branch only and cannot be carried across the activation of a network upgrade (ZIP 259, “Backward compatibility”). That the anchors and the proofs are authorising data does not affect this binding, since the header is effecting data.

11.4 Chain state and pool rules

The Orchard pool and the Ironwood pool each have their own chain state: a note commitment tree (“The Merkle hash and the tree”, §5.1) with its anchors (“Anchors”, §5.2), a nullifier set (“Nullifier sets”, §6.2) and a chain value pool balance, defined below. An Action is checked only against the state of its own pool (ZIP 229, Terminology and Rationale, “Separate state”; protocol specification, §“Nullifier Sets” and §“Note Commitment Trees”).

Definition 11.13 (Chain value pool balances).

The Ironwood chain value pool balance of a block chain is the negation of the sum of the $\mathsf{valueBalanceIronwood}$ fields of all its transactions, and the Orchard chain value pool balance the negation of the sum of their $\mathsf{valueBalanceOrchard}$ fields, an absent field counting as $0$ . The total issued supply is the sum of the balances of all chain value pools of the protocol specification, §“Chain Value Pool Balances”, the transparent pool and the other shielded pools included, computed without overflow (ZIP 209, Terminology and “Specification”).

The consensus rules on the balances are: a block that would make the chain value pool balance of any pool negative is invalid, and a block that would make the total issued supply exceed $\mathsf{MAX\_MONEY}$ (§11.2) is invalid (ZIP 209, “Specification”; protocol specification, §“Chain Value Pool Balances”).

Remark 11.14 (Outflow bound).

Fix a pool $P$ and write each of its balancing values as $v=v^{+}-v^{-}$ with $v^{+}:=\max(v,0)$ and $v^{-}:=\max(-v,0)$ . The chain value pool balance of $P$ is $\sum v^{-}-\sum v^{+}$ , summed over the transactions of the chain, so the rule that it is non-negative at every block states that at every block the net value that has left $P$ through positive balancing values, $\sum v^{+}$ , is at most the net value that entered it through negative ones, $\sum v^{-}$ . Value created inside $P$ by a failure of soundness can therefore leave $P$ only up to the value recorded as having entered it (ZIP 209, “Specification”).

The following Orchard-pool rules apply to every transaction, whatever its version (ZIP 258, “Consensus rules from NU6.3 activation”; ZIP 229, “Consensus Rules”).

(i)

Cross-address transfers are disabled for every Orchard-pool Action: bits $2$ to $7$ of $\mathsf{flagsOrchard}$ are $0$ , so every Orchard-pool Action has $\mathsf{enableCrossAddress}=0$ and primary input $\mathsf{disableCrossAddress}=1$ (“Bundle flags”, §9.1), and the verifying key that consensus selects for every Action enforces condition A10 of Definition 9.2. The meaning of A10 and its pool-level effect are those stated at A10 in “The Action statement” (§9.2).
(ii)

For every transaction, $\mathsf{valueBalanceOrchard}\geq 0$ : net value may leave the Orchard pool and never enter it, so the Orchard chain value pool balance never increases.

Of the two Orchard-protocol pools, therefore, only the Ironwood pool accepts net inflow: a shielding transaction, one whose transparent inputs fund a negative balancing value, can place that negative balancing value, among the Orchard-protocol pools, only in its Ironwood component (ZIP 258, same section; protocol specification, §“Shielded Pools and Notes”).

The coinbase transaction of “The transaction format” (§11.2) is subject to the following rules on the shielded path (protocol specification, §“Transaction Consensus Rules”; ZIP 229, “Consensus Rules”; ZIP 258, “Consensus rules from NU6.3 activation”).

(iii)

A coinbase transaction has no Orchard-pool Actions.
(iv)

The bit $\mathsf{enableSpends}$ is $0$ in $\mathsf{flagsOrchard}$ of a coinbase transaction of version $5$ or $6$ and in $\mathsf{flagsIronwood}$ of a coinbase transaction of version $6$ . By condition A8 of Definition 9.2, under Assumption 9.11, every Action of a coinbase transaction has, except with negligible probability, an extracted witness with $v^{\mathsf{old}}=0$ : a coinbase transaction consumes no note of non-zero value. The rule concerns coinbase transactions only; every other transaction may spend Ironwood-pool notes.
(v)

Every Ironwood-pool output of a coinbase transaction must decrypt to a note plaintext by the recovery with $\mathsf{ovk}$ of “The outgoing ciphertext” (§10.3) under the all-zero outgoing viewing key, the string of $32$ zero bytes, so its plaintext is public and its lead byte is $\mathtt{0x03}$ , the only lead byte that recovery accepts (ZIP 213, “Specification”; ZIP 258, “Changes to the Protocol Specification”).

Rule (v) is the only check by consensus of the lead byte of an Orchard-protocol output. Every Ironwood-pool output uses the note format of lead byte $\mathtt{0x03}$ (“The note seed”, §4.3), and the Action statement does not check the derivation of $\mathsf{rcm}$ (Definition 9.2, Remark “What the statement does not check”); for every other output the lead byte is encrypted and the recipient enforces it, decryption returning $\bot$ when the byte is not allowed for the pool (“Trial decryption and note acceptance”, §10.4; protocol specification, §“Decryption using an Incoming Viewing Key (Sapling and Orchard)”).

The rules of ZIP 218, “Shielded pool action limits”, bound per block the number of Orchard-pool Actions and a shielded budget that counts them together with the descriptions of the other shielded protocols; they do not mention Ironwood-pool Actions, which a version- $6$ transaction counts in the separate field $\mathsf{nActionsIronwood}$ (ZIP 229, “Transaction Format”). These are block-level rules, outside the Action statement.

11.5 Construction of a transaction

The following procedure extends the single spend of the Crypto Guide’s Example “An Orchard shielded spend” (§“A shielded spend, end to end”) to a bundle with signatures and balance. Its steps follow the order of the preceding sections.

Construction 11.15 (Ironwood-pool bundle).

The input is the sender’s keys; the Ironwood-pool notes to consume, with their leaf positions; each recipient’s address, which its holder derives from an incoming viewing key (“Diversified addresses”, §3.3) and hands to the sender; the amounts; and the fee. The sender performs the following steps.

(1)

Pairing. For $s$ consumed and $o$ created notes it forms $n\geq\max(s,o)$ Actions (§11.1). A dummy consumed note comes from a fresh uniformly random spending key, with value $0$ , a uniform $\mathsf{rseed}$ , $\rho=\mathsf{Extract}_{\mathbb{P}}$ of a uniform Pallas point and an arbitrary authentication path; a dummy created note has value $0$ and a random address (Definition “Dummy notes”, §4.4).
(2)

Anchor. It takes as $\mathit{rt}$ the root of the Ironwood tree’s final treestate at a recent block, at the depth that “Anchors” (§5.2) recommends, and computes the authentication path of each real consumed note from public data (Lemma 5.15).
(3)

Created notes. For each Action it computes $\mathsf{nf}^{\mathsf{old}}$ of the consumed note by Definition 6.3, sets $\rho^{\mathsf{new}}:=\mathsf{nf}^{\mathsf{old}}$ (“Nullifier chaining”, §6.3), draws a fresh uniform $32$ -byte $\mathsf{rseed}$ , derives $\mathsf{esk}$ , $\psi^{\mathsf{new}}$ and $\mathsf{rcm}^{\mathsf{new}}$ under lead byte $\mathtt{0x03}$ as in “The note seed” (§4.3), redrawing $\mathsf{rseed}$ when $\mathsf{esk}=0$ or $\mathsf{cmx}=\bot$ , and computes $\mathsf{cm}^{\mathsf{new}}$ by Definition 4.4 and $\mathsf{cmx}:=\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\mathsf{new}})$ .
(4)

Value commitments. For each Action it draws $\mathsf{rcv}$ uniformly from $\mathbb{F}_{p_{\mathsf{Vesta}}}$ and sets $\mathsf{cv}^{\mathsf{net}}:=[v^{\mathsf{old}}-v^{\mathsf{new}}]\,V^{\mathsf{% Orchard}}+[\mathsf{rcv}]\,R^{\mathsf{Orchard}}$ (Definition 8.2).
(5)

Randomised keys. For each Action it draws $\alpha$ by $\mathsf{GenRandom}$ and sets $\mathsf{rsk}:=\mathsf{ask}+\alpha$ and $\mathsf{rk}:=\mathsf{ak}^{\mathbb{P}}+[\alpha]\,G^{\mathsf{SpendAuth}}$ (“Randomised validating keys”, §7.2), with $\mathsf{ask}$ and $\mathsf{ak}^{\mathbb{P}}$ of the consumed note’s spending key, the dummy key for a dummy spend.
(6)

Flags and balance. It sets $\mathsf{enableSpends}=\mathsf{enableOutputs}=1$ , and $\mathsf{enableCrossAddress}=1$ whenever some Action’s created note pays an expanded receiver other than that of its consumed note (condition A10 of Definition 9.2); it sets $v^{\mathsf{balance}}:=\sum(v^{\mathsf{old}}-v^{\mathsf{new}})$ over the Actions, and chooses the created values so that the fee is the value left in the transparent transaction value pool (“The balancing value”, §8.2).

(7)

Proof. It computes one Halo 2 proof over the $n$ instances

(\mathit{rt},\mathsf{cv}^{\mathsf{net}},\mathsf{nf}^{\mathsf{old}},\mathsf{rk}% ,\mathsf{cmx},\mathsf{enableSpends},\mathsf{enableOutputs},1-\mathsf{% enableCrossAddress})

with the witnesses of Definition 9.2 (“The Action circuit and the Halo 2 proof”, §9.3). By Assumption 9.11 a prover of an accepted proof knows, for each Action, a witness satisfying A1 to A10; under Assumption 9.14 the proof reveals nothing beyond the instances.

(8)

Encryption. For each Action it computes $\mathsf{epk}:=[\mathsf{esk}]\,\mathsf{g_{d}}$ , $C_{\mathsf{enc}}$ and $C_{\mathsf{out}}$ as in “Encryption to the recipient” (§10.2) and “The outgoing ciphertext” (§10.3).
(9)

Header. It sets the version to $6$ , $\mathsf{nConsensusBranchId}$ to the identifier of the consensus branch in force, and $\mathsf{nExpiryHeight}$ (§11.2).
(10)

Digest. It computes $\mathsf{SigHash}$ (“Transaction digests and signatures”, §11.3).
(11)

Spend authorisation. For each Action it computes the spend-authorisation signature under $\mathsf{rsk}$ on $\mathsf{SigHash}$ .
(12)

Binding signature. It sets $\mathsf{bsk}:=\sum\mathsf{rcv}\bmod p_{\mathsf{Vesta}}$ and $\mathsf{bvk}:=\sum\mathsf{cv}^{\mathsf{net}}-[v^{\mathsf{balance}}]\,V^{% \mathsf{Orchard}}$ , checks $\mathsf{bvk}=[\mathsf{bsk}]\,R^{\mathsf{Orchard}}$ , which the protocol specification recommends to the signer, and computes the binding signature under $\mathsf{bsk}$ on $\mathsf{SigHash}$ (“The binding signature”, §8.3).

(Protocol specification, §“Sending Notes (Orchard)”, §“Dummy Notes (Orchard)”, §“Spend Authorization Signature (Sapling and Orchard)” and §“Balance and Binding Signature (Orchard)”.)

Steps (10) to (12) depend on neither $\mathit{rt}$ nor the proof, which are authorising data, so signing can precede proving (ZIP 229, Motivation).

The sender sets $\mathsf{nExpiryHeight}$ . ZIP 218, “Default expiry delta”, recommends to node implementations that create transactions a default expiry height $120$ blocks above the current height (ZIP 203, “Specification”), which at the $25$ -second target spacing stated in “Anchors” (§5.2) is $120\times 25=3000$ seconds, $50$ minutes. The consensus rule is the expiry rule of “The transaction format” (§11.2).

Example 11.16 (A two-Action payment).

The example is numeric only in amounts, fees, value differences, the balancing value, sizes and counts, each the output of a script; every curve point, field element, hash, ciphertext and signature is named and its derivation shown, not evaluated. The subscripts $\mathsf{S}$ , $\mathsf{R}$ and $\mathsf{D}$ mark the sender’s key, the recipient’s key and the dummy spending key.

Amounts. The sender holds one Ironwood-pool note $n^{\mathsf{old}}_{1}$ of $7$ ZEC, $700\,000\,000$ zatoshi, and pays $5$ ZEC, $500\,000\,000$ zatoshi, to a recipient’s address $\mathsf{addr}_{\mathsf{R}}$ . One real consumed note and two created notes need $\max(1,2)=2$ Actions, hence two logical actions, and the conventional fee of “The balancing value” (§8.2) is $5000\cdot\max(2,2)=10\,000$ zatoshi. The change is $700\,000\,000-500\,000\,000-10\,000=199\,990\,000$ zatoshi. The following table pairs the notes into Actions.

	Action $1$	Action $2$
consumed note	$n^{\mathsf{old}}_{1}$ , the sender’s	$n^{\mathsf{old}}_{2}$ , a dummy
spending key	the sender’s: $\mathsf{ask}_{\mathsf{S}}$ , $\mathsf{ak}^{\mathbb{P}}_{\mathsf{S}}$ , $\mathsf{nk}_{\mathsf{S}}$	the dummy key: $\mathsf{ask}_{\mathsf{D}}$ , $\mathsf{ak}^{\mathbb{P}}_{\mathsf{D}}$ , $\mathsf{nk}_{\mathsf{D}}$
$v^{\mathsf{old}}_{i}$	$700\,000\,000$	$0$
created note	$n^{\mathsf{new}}_{1}$ to $\mathsf{addr}_{\mathsf{R}}$	$n^{\mathsf{new}}_{2}$ , the change, to $\mathsf{addr}_{\mathsf{S}}$
$v^{\mathsf{new}}_{i}$	$500\,000\,000$	$199\,990\,000$
$v^{\mathsf{old}}_{i}-v^{\mathsf{new}}_{i}$	$200\,000\,000$	$-199\,990\,000$

The net values sum to $\mathsf{valueBalanceIronwood}=200\,000\,000+(-199\,990\,000)=10\,000$ zatoshi, the fee. The transaction has no transparent inputs or outputs, so the fee is the whole value remaining in its transparent transaction value pool.

Public fields. The recipient derives $\mathsf{addr}_{\mathsf{R}}=(d_{\mathsf{R}},\mathsf{pk_{d}}{}_{,\mathsf{R}})$ from its incoming viewing key (“Diversified addresses”, §3.3) and gives it to the sender; $\mathsf{addr}_{\mathsf{S}}$ is an address of the sender’s own key. Write $(\mathsf{g_{d}}{}_{,1},\mathsf{pk_{d}}{}_{,1})$ and $(\mathsf{g_{d}}{}_{,2},\mathsf{pk_{d}}{}_{,2})$ for the expanded receivers of $\mathsf{addr}_{\mathsf{R}}$ and $\mathsf{addr}_{\mathsf{S}}$ , and $\mathsf{nk}_{1}:=\mathsf{nk}_{\mathsf{S}}$ , $\mathsf{nk}_{2}:=\mathsf{nk}_{\mathsf{D}}$ . For $i=1,2$ the sender computes, from the consumed note’s fields $(\rho^{\mathsf{old}}_{i},\psi^{\mathsf{old}}_{i},\mathsf{cm}^{\mathsf{old}}_{i})$ ,

	$\displaystyle\mathsf{nf}^{\mathsf{old}}_{i}$	$\displaystyle:=\mathsf{DeriveNullifier}_{\mathsf{nk}_{i}}(\rho^{\mathsf{old}}_% {i},\psi^{\mathsf{old}}_{i},\mathsf{cm}^{\mathsf{old}}_{i})$	$\displaystyle\text{(Definition~{}\href{V5.S6.html#Thmtheorem3}{6.3})},$
	$\displaystyle\rho^{\mathsf{new}}_{i}$	$\displaystyle:=\mathsf{nf}^{\mathsf{old}}_{i}$	$\displaystyle\text{(\S\href{V5.S6.html#SS3}{6.3})},$

draws a uniform $\mathsf{rseed}_{i}$ , derives $\mathsf{esk}_{i}$ , $\psi^{\mathsf{new}}_{i}$ and $\mathsf{rcm}^{\mathsf{new}}_{i}$ from $\mathsf{rseed}_{i}$ under lead byte $\mathtt{0x03}$ (“The note seed”, §4.3), and sets

	$\displaystyle\mathsf{cm}^{\mathsf{new}}_{i}$	$\displaystyle:=\mathsf{NoteCommit}_{\mathsf{rcm}^{\mathsf{new}}_{i}}\bigl{(}% \mathsf{g_{d}}{}_{,i}^{\star}\,\\|\,\mathsf{pk_{d}}{}_{,i}^{\star}\,\\|\,\mathrm% {LE}_{64}(v^{\mathsf{new}}_{i})\,\\|\,\mathrm{LE}_{255}(\rho^{\mathsf{new}}_{i}% )\,\\|\,\mathrm{LE}_{255}(\psi^{\mathsf{new}}_{i})\bigr{)},$
	$\displaystyle\mathsf{cmx}_{i}$	$\displaystyle:=\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\mathsf{new}}_{i})$

(Definition 4.4). With $\mathsf{rcv}_{i}$ uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ and $\alpha_{i}$ drawn by $\mathsf{GenRandom}$ ,

	$\displaystyle\mathsf{cv}^{\mathsf{net}}_{1}$	$\displaystyle:=[200\,000\,000]\,V^{\mathsf{Orchard}}+[\mathsf{rcv}_{1}]\,R^{% \mathsf{Orchard}},$	$\displaystyle\mathsf{rk}_{1}$	$\displaystyle:=\mathsf{ak}^{\mathbb{P}}_{\mathsf{S}}+[\alpha_{1}]\,G^{\mathsf{% SpendAuth}},$
	$\displaystyle\mathsf{cv}^{\mathsf{net}}_{2}$	$\displaystyle:=[-199\,990\,000]\,V^{\mathsf{Orchard}}+[\mathsf{rcv}_{2}]\,R^{% \mathsf{Orchard}},$	$\displaystyle\mathsf{rk}_{2}$	$\displaystyle:=\mathsf{ak}^{\mathbb{P}}_{\mathsf{D}}+[\alpha_{2}]\,G^{\mathsf{% SpendAuth}},$

the negative difference read in $\mathbb{F}_{p_{\mathsf{Vesta}}}$ (Definition 8.2; “Randomised validating keys”, §7.2). The anchor $\mathit{rt}$ is the anchor of a recent Ironwood-pool block, with the authentication path of $\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\mathsf{old}}_{1})$ ; the path of the dummy is arbitrary, since A3 exempts $v^{\mathsf{old}}_{2}=0$ . The flags are $\mathsf{enableSpends}=\mathsf{enableOutputs}=\mathsf{enableCrossAddress}=1$ , because both created notes pay expanded receivers other than those of their Actions’ consumed notes (A10). One proof $\pi$ covers the instances $(\mathit{rt},\mathsf{cv}^{\mathsf{net}}_{i},\mathsf{nf}^{\mathsf{old}}_{i},% \mathsf{rk}_{i},\mathsf{cmx}_{i},1,1,0)$ for $i=1,2$ . Finally $\mathsf{epk}_{i}:=[\mathsf{esk}_{i}]\,\mathsf{g_{d}}{}_{,i}$ , $C_{\mathsf{enc},i}$ encrypts the plaintext of $n^{\mathsf{new}}_{i}$ to its receiver, and $C_{\mathsf{out},i}$ is formed under the sender’s $\mathsf{ovk}$ (“Encryption to the recipient”, §10.2; “The outgoing ciphertext”, §10.3).

Signatures, balance and size. The transaction has no transparent inputs, so $\mathsf{SigHash}$ equals its transaction identifier (“Transaction digests and signatures”, §11.3). The spend-authorisation signatures are $\sigma_{1}$ under $\mathsf{rsk}_{1}=\mathsf{ask}_{\mathsf{S}}+\alpha_{1}$ and $\sigma_{2}$ under $\mathsf{rsk}_{2}=\mathsf{ask}_{\mathsf{D}}+\alpha_{2}$ , both on $\mathsf{SigHash}$ . The binding signing key is $\mathsf{bsk}:=\mathsf{rcv}_{1}+\mathsf{rcv}_{2}\bmod p_{\mathsf{Vesta}}$ , and

	$\displaystyle\mathsf{bvk}$	$\displaystyle=\mathsf{cv}^{\mathsf{net}}_{1}+\mathsf{cv}^{\mathsf{net}}_{2}-[1% 0\,000]\,V^{\mathsf{Orchard}}$
		$\displaystyle=[200\,000\,000-199\,990\,000-10\,000]\,V^{\mathsf{Orchard}}+[% \mathsf{bsk}]\,R^{\mathsf{Orchard}}=[\mathsf{bsk}]\,R^{\mathsf{Orchard}};$

$\mathsf{bindingSigIronwood}$ is the binding signature under $\mathsf{bsk}$ on $\mathsf{SigHash}$ . By Table 7 the Ironwood component has

1+2\cdot 820+1+8+32+3+(2720+2272\cdot 2)+2\cdot 64+64=9141

bytes: the count, the Action descriptions, the flags, the balancing value, the anchor, the proof length, the proof of $7264$ bytes, the spend-authorisation signatures and the binding signature.

The two views. The verifier receives only the public data: for each $i$ the Action description $(\mathsf{cv}^{\mathsf{net}}_{i},\mathsf{nf}^{\mathsf{old}}_{i},\mathsf{rk}_{i}% ,\mathsf{cmx}_{i},\mathsf{epk}_{i},C_{\mathsf{enc},i},C_{\mathsf{out},i})$ and $\sigma_{i}$ , and $\mathit{rt}$ , the flags byte with bits $0$ , $1$ and $2$ set, $\mathsf{valueBalanceIronwood}=10\,000$ , $\pi$ and $\mathsf{bindingSigIronwood}$ . It runs the procedure of “Verification of a transaction” (§11.6). What these data reveal is the subject of Theorem 12.12 in “Privacy” (§12.4). The recipient trial-decrypts every output with its incoming viewing key. On output $1$ it recovers the plaintext $(\mathtt{0x03},d_{\mathsf{R}},500\,000\,000,\mathsf{rseed}_{1},\mathsf{memo})$ , re-derives the note with $\rho=\mathsf{nf}^{\mathsf{old}}_{1}$ of the same Action, checks $\mathsf{epk}_{1}$ and $\mathsf{cmx}_{1}$ , and records the leaf position of $\mathsf{cmx}_{1}$ (“Trial decryption and note acceptance”, §10.4); the sender recovers the change note of output $2$ in the same way. Either note is later consumed by the procedure of this subsection.

11.6 Verification of a transaction

Each step of the following procedure is tagged with the requirements whose soundness part it serves and with the conditions of Definition 9.2 that it completes, in the pairing of the requirement map, Table 5.

Construction 11.17 (Verification).

Given the chain state of each pool, a transaction $T$ in a block is accepted, as far as its Orchard-protocol components are concerned, if and only if the following checks pass.

(1)

Parsing. The version of $T$ is $5$ or $6$ , with the version group identifier of its version, and $\mathsf{nConsensusBranchId}$ equals the identifier of the consensus branch in force. Every field of every Action description is the canonical encoding of its type (Table 6): $\mathsf{cv}^{\mathsf{net}}$ and $\mathsf{rk}$ are points, $\mathsf{epk}$ is a non-identity point, and $\mathsf{nf}$ and $\mathsf{cmx}$ are integers below $p_{\mathsf{Pallas}}$ ; $\mathsf{rk}\neq\mathcal{O}$ ; every signature encoding is canonical as RedPallas validation requires (§7.1); and each component satisfies the rules of “The transaction format” (§11.2) on its count, its reserved flag bits, its flags, the range of its balancing value and the length of its proof. The transaction $T$ has a transparent input, a Spend description in its Sapling component or an Orchard-protocol bundle with $\mathsf{enableSpends}=1$ , and it has a transparent output, an Output description in its Sapling component or an Orchard-protocol bundle with $\mathsf{enableOutputs}=1$ , where Spend and Output descriptions are the Sapling component’s descriptions of a consumed and of a created note.

(2)

Proof. For each pool with Actions, the aggregate proof verifies under the post-NU6.3 verifying key of “The Action circuit and the Halo 2 proof” (§9.3) on the per-Action primary inputs

(\mathit{rt},\mathsf{cv}^{\mathsf{net}},\mathsf{nf},\mathsf{rk},\mathsf{cmx},% \mathsf{enableSpends},\mathsf{enableOutputs},1-\mathsf{enableCrossAddress}),

with $\mathit{rt}$ and the flags read from the bundle. [R1 to R5, through A1 to A10.]

(3)

Anchor rule. Each bundle’s $\mathit{rt}$ is the root of its pool’s final treestate at an earlier block of the chain (“Anchors”, §5.2). [R2, with A3.]
(4)

Nullifier rule. No nullifier repeats within $T$ or across the transactions of the chain; the nullifiers of each pool are checked against that pool’s nullifier set (“Nullifier sets”, §6.2). [R3, with A5.]
(5)

Spend authorisation. Each Action’s spend-authorisation signature is valid under its $\mathsf{rk}$ on $\mathsf{SigHash}$ (“Randomised validating keys”, §7.2). [R5, with A6 and A7.]
(6)

Balance. For each pool with Actions, the verifier computes $\mathsf{bvk}:=\sum\mathsf{cv}^{\mathsf{net}}-[v^{\mathsf{balance}}]\,V^{% \mathsf{Orchard}}$ over the pool’s Actions and checks the binding signature under $\mathsf{bvk}$ on $\mathsf{SigHash}$ (“The binding signature”, §8.3; Crypto Guide, §“Binding signatures as a proof of knowledge of a discrete logarithm”); and the fee, the value remaining in the transparent transaction value pool, is non-negative (“The balancing value”, §8.2), a coinbase transaction satisfying instead the coinbase rule of the protocol specification, §“Transaction Consensus Rules”, which balances its outputs against the block subsidy and the fees of the block’s other transactions. [R4, with A4.]
(7)

Pool rules. The rules of “Chain state and pool rules” (§11.4), the expiry rule of “The transaction format” (§11.2) and the capacity rule of each pool’s note commitment tree (“The Merkle hash and the tree”, §5.1) hold.

(Protocol specification, §“Transaction Consensus Rules”, §“Action Descriptions”, §“Action Description Encoding and Consensus”, §“RedDSA, RedJubjub, and RedPallas”, §“Action Transfers and their Descriptions”, §“Nullifier Sets”, §“Note Commitment Trees”, §“Balance and Binding Signature (Orchard)” and §“Transactions and Treestates”; ZIP 229, “Consensus Rules”; ZIP 2003, “Specification”; ZIP 259, Abstract.) These are the consensus checks on the Orchard-protocol components of $T$ ; the remaining rules of §“Transaction Consensus Rules” concern its other components.

Remark 11.18 (Division of the checks).

Under Assumption 9.11 the proof yields, for each Action, a witness that satisfies Definition 9.2 for its primary input. Whether $\mathit{rt}$ is a root that the chain recorded and whether $\mathsf{nf}$ is new are facts about the chain’s history, which no proof over one Action’s data attests; the verifier checks them against its state, in steps (3) and (4). Beyond the parsing of step (1), the fee rule of step (6) and the rules of step (7), validity is thus the conjunction of one proof per bundle, two kinds of signature and these two checks against chain state; apart from the coinbase rule (v) of §11.4, no step decrypts or inspects a note.

Construction 11.19 (State update).

On accepting a block, for each pool: every nullifier of the pool’s Actions enters the pool’s nullifier set, so that a later Action that publishes the same nullifier fails step (4); every $\mathsf{cmx}$ is appended to the pool’s note commitment tree, in the order of the transactions and, within a transaction, of the Actions, so that the note’s holder can later prove membership against an anchor whose tree contains it; and the chain value pool balance of the pool decreases by each transaction’s balancing value (protocol specification, §“Nullifier Sets”, §“Transactions and Treestates” and §“Chain Value Pool Balances”).

The verifier holds no viewing key and decrypts no Orchard-protocol ciphertext, except for the decryption of Ironwood-pool coinbase outputs under the all-zero outgoing viewing key that “Chain state and pool rules” (§11.4) requires, whose plaintexts are public by that rule (protocol specification, §“Transaction Consensus Rules”; ZIP 213, “Specification”). Its input is the transaction’s public data and the chain state; what those data reveal about the private inputs is the subject of Theorem 12.12 in “Privacy” (§12.4).