diff --git a/protocol/key_components_orchard.png b/protocol/key_components_orchard.png new file mode 100644 index 00000000..6637be6a Binary files /dev/null and b/protocol/key_components_orchard.png differ diff --git a/protocol/key_components_orchard.svg b/protocol/key_components_orchard.svg new file mode 100644 index 00000000..13be0e91 --- /dev/null +++ b/protocol/key_components_orchard.svg @@ -0,0 +1,1949 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + ivk + + + + + + ovk + + + + + a + pk + pk + enc + + Incomingviewing key + Paying key + + + + a + sk + + + Spending key + + + + + Shielded payment address + Receivingkey + + + a + pk + enc + sk + + + + + + + + + + + + Transmissionkey + Diversifier + + + + + Shielded payment address + + + d + pk + d + + + + + + ivk + + + + + ak + nk + + + + + + + Fullviewing key + + Incomingviewing key + + + nsk + ak + + + + sk + + Spending key + + + ask + nsk + + + + + + + Proof author-izing key + + + + + + + Expandedspending key + + + + + + + ovk + + + + + + + Transmissionkey + Transmissionkey + Diversifier + + + + + Shielded payment address + + + d + pk + d + + + + + + + + + Fullviewing key + + Incomingviewing key + + Orchard + + + + ovk + + + + + ask + + + + sk + + Spending key + + Outgoingviewing key + + + ak + nk + rivk + + + Outgoingviewing key + Sapling + Sprout + + + + + + + + + + + + + + + diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 300686d8..759f8fc7 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -818,7 +818,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\actionDescription}{\term{Action description}} \newcommand{\actionDescriptions}{\terms{Action description}} \newcommand{\actionTransfer}{\term{Action transfer}} -\newcommand{\actionTransfers}{\terms{Action transfers}} +\newcommand{\actionTransfers}{\terms{Action transfer}} \newcommand{\actionCircuit}{\term{Action circuit}} \newcommand{\actionStatement}{\term{Action statement}} \newcommand{\actionStatements}{\terms{Action statement}} @@ -1421,7 +1421,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\PRFnf}[1]{\PRF{#1}{\nf}} \newcommand{\PRFsn}[1]{\PRF{#1}{sn}} \newcommand{\PRFpk}[1]{\PRF{#1}{pk}} -\newcommand{\PRFrho}[1]{\PRF{#1}{\NoteAddressRand}} +\newcommand{\PRFrho}[1]{\PRF{#1}{\NoteUniqueRand}} \newcommand{\PRFnfSapling}[1]{\PRF{#1}{nf\kern-0.01em Sapling}} \newcommand{\PRFnfOrchard}[1]{\PRF{#1}{nf\kern-0.01em Orchard}} \newcommand{\PRFOutputLengthSprout}{\mathsf{\ell_{PRF\notsprout{Sprout}}}} @@ -1542,12 +1542,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\NoteCommitRandNew}[1]{\NoteCommitRand^\mathsf{new}_{#1}} \newcommand{\NoteCommitRandOrSeedBytes}{\notcanopy{\NoteCommitRand}\canopy{\NoteSeedBytes}} \newcommand{\NoteCommitRandBytesOrSeedBytes}{\notcanopy{\NoteCommitRandBytes}\canopy{\NoteSeedBytes}} -\newcommand{\NoteAddressRand}{\mathsf{\uprho}} -\newcommand{\NoteAddressRandRepr}{{\NoteAddressRand\Repr}} -\newcommand{\NoteAddressRandOld}[1]{\NoteAddressRand^\mathsf{old}_{#1}} -\newcommand{\NoteAddressRandNew}[1]{\NoteAddressRand^\mathsf{new}_{#1}} -\newcommand{\NoteAddressPreRand}{\mathsf{\upvarphi}} -\newcommand{\NoteAddressPreRandLength}{\mathsf{\ell_{\NoteAddressPreRand}}} +\newcommand{\NoteUniqueRand}{\mathsf{\uprho}} +\newcommand{\NoteUniqueRandRepr}{{\NoteUniqueRand\Repr}} +\newcommand{\NoteUniqueRandOld}[1]{\NoteUniqueRand^\mathsf{old}_{#1}} +\newcommand{\NoteUniqueRandNew}[1]{\NoteUniqueRand^\mathsf{new}_{#1}} +\newcommand{\NoteUniquePreRand}{\mathsf{\upvarphi}} +\newcommand{\NoteUniquePreRandLength}{\mathsf{\ell_{\NoteUniquePreRand}}} +\newcommand{\NoteNullifierRand}{\mathsf{\uppsi}} \newcommand{\NoteCommitS}{\mathsf{s}} \newcommand{\CommitIvkRand}{\mathsf{rivk}} \newcommand{\cv}{\mathsf{cv}} @@ -1563,6 +1564,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\nf}{\mathsf{nf}} \newcommand{\nfOld}[1]{\nf^\mathsf{old}_{#1}} \newcommand{\nfOldRepr}[1]{{\MakeRepr{\nf}{\mathsf{old}}}_{#1}} +\newcommand{\enableSpend}{\mathsf{enableSpend}} +\newcommand{\enableOutput}{\mathsf{enableOutput}} \newcommand{\Memo}{\mathsf{memo}} \newcommand{\MemoByteLength}{512} \newcommand{\MemoType}{\byteseq{\MemoByteLength}} @@ -2503,7 +2506,10 @@ For each \shieldedInput, \begin{itemize} \item \saplingonward{there is a revealed \valueCommitment to the same value as - the input \note;} + the input \note;\orchard{\footnotewithlabel{orchardvaluecommitments}{\orchard{For + \Orchard, each Action reveals a single \valueCommitment to the net value + spent by the Action, rather than one \valueCommitment for the input \note + and one for the output \note.}}}} \item if the value is nonzero, some revealed \noteCommitment exists for this \note; \item the prover knew the \authProvingKey of the \note; \item the \nullifier and \noteCommitment are computed correctly. @@ -2513,7 +2519,7 @@ and for each \shieldedOutput, \begin{itemize} \item \saplingonward{there is a revealed \valueCommitment to the same value as - the output \note;} + the output \note;\orchard{\footnoteref{orchardvaluecommitments}}} \item the \noteCommitment is computed correctly; \item it is infeasible to cause the \nullifier of the output \note to collide with the \nullifier of any other \note. @@ -2779,7 +2785,7 @@ The following integer constants will be instantiated in \crossref{constants}: $\ValueLength$, $\MerkleHashLength{Sprout}$,\sapling{ $\MerkleHashLength{Sapling}$,}\orchard{ $\MerkleHashLength{Orchard}$,} $\hSigLength$, $\PRFOutputLengthSprout$,\sapling{ $\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,} $\NoteCommitRandLength$, \changed{$\RandomSeedLength$,} $\AuthPrivateLength$, - \changed{$\NoteAddressPreRandLength$,}\sapling{ $\SpendingKeyLength$, $\DiversifierLength$, + \changed{$\NoteUniquePreRandLength$,}\sapling{ $\SpendingKeyLength$, $\DiversifierLength$, $\InViewingKeyLength{Sapling}$,\orchard{ $\InViewingKeyLength{Orchard}$,} $\OutViewingKeyLength$, $\ScalarLength{Sapling}$,\orchard{ $\ScalarLength{Orchard}$,}} $\MAXMONEY$,\blossom{ $\BlossomActivationHeight$,}\canopy{ $\CanopyActivationHeight$, $\ZIPTwoOneTwoGracePeriod$} @@ -2819,7 +2825,8 @@ abstractions. \begin{center} \sprout{\includegraphics[scale=.7]{key_components}} -\sapling{\includegraphics[scale=.5]{key_components_sapling}} +\sapling{\notorchard{\includegraphics[scale=.5]{key_components_sapling}}} +\orchard{\includegraphics[scale=.39]{key_components_orchard}} \end{center} \sproutspecific{ @@ -2836,7 +2843,7 @@ From these components we can derive an \authProvingKey $(\AuthSignPublic, \AuthP a \fullViewingKey $(\AuthSignPublic, \NullifierKey, \OutViewingKey)$, an \incomingViewingKey $\InViewingKey$, and a set of \diversifiedPaymentAddresses $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$, -as described in \crossref{saplingkeycomponents}. +as described in \crossref{saplingkeycomponents}.} The consensus protocol does not depend on how an \expandedSpendingKey is constructed. Two methods of doing so are defined: @@ -2850,6 +2857,14 @@ Two methods of doing so are defined: \end{enumerate} } %saplingonward +\orchardonward{ +An \Orchard \spendingKey $\SpendingKey$ is used to derive a \authSigningKey $\AuthSignPrivate$, +and a \fullViewingKey $(\AuthProvePrivate, \NullifierKey, \CommitIvkRand)$. From the \fullViewingKey +we can also derive an \incomingViewingKey $\InViewingKey$, an \outgoingViewingKey $\OutViewingKey$, and +a set of \diversifiedPaymentAddresses $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$, +as described in \crossref{orchardkeycomponents}. +} %orchardonward + \vspace{-2ex} \nnote{In \zcashd, all \SaplingAndOrchard{} keys and addresses are derived according to \cite{ZIP-32}.} } %saplingonward @@ -2881,8 +2896,8 @@ relevant \transactions. \vspace{-1ex} \pnote{ -It is conventional in cryptography to refer to the key used to encrypt -a message in an asymmetric encryption scheme as the ``\defining{\publicKey}''. +It is conventional in cryptography to call the key used to encrypt +a message in an asymmetric encryption scheme a ``\defining{\publicKey}''. However, the \publicKey used as \defining{the \transmissionKey component of an address ($\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$})} need not be publically distributed; it has the same distribution as the \paymentAddress itself. @@ -2900,7 +2915,7 @@ in order to exploit a hypothetical weakness in that cryptosystem. \sprout{ A \defining{\note} (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, -\NoteAddressRand, \NoteCommitRand)}$. It represents that a value $\Value$ is +\NoteUniqueRand, \NoteCommitRand)}$. It represents that a value $\Value$ is spendable by the recipient who holds the \spendingKey $\AuthPrivate$ corresponding to $\AuthPublic$, as described in the previous section. } %sprout @@ -2932,14 +2947,14 @@ Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}. \vspace{2ex} \introlist A \SproutOrNothing{} \note is a tuple $\changed{(\AuthPublic, -\Value, \NoteAddressRand, \NoteCommitRand)}$, where: +\Value, \NoteUniqueRand, \NoteCommitRand)}$, where: \begin{itemize} \item $\AuthPublic \typecolon \PRFOutputSprout$ is the \defining{\payingKey} of the recipient's \paymentAddress; \item $\Value \typecolon \range{0}{\MAXMONEY}$ is an integer representing the value of the \note in \zatoshi (\defining{$1$ \ZEC = $10^8$ \zatoshi}); - \item $\NoteAddressRand \typecolon \PRFOutputSprout$ + \item $\NoteUniqueRand \typecolon \PRFOutputSprout$ is used as input to $\PRFnf{\AuthPrivate}$ to derive the \nullifier of the \note; \item $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Sprout}$ @@ -2981,7 +2996,7 @@ Let $\NoteType{Sapling}$ be the type of a \Sapling{} \note, i.e. \vspace{1ex} \introlist An \Orchard{} \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, -\Value, \NoteCommitRand, \todo{...})$, where: +\Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$, where: \begin{itemize} \item $\Diversifier \typecolon \DiversifierType$ is the \diversifier of the recipient's \paymentAddress; @@ -2989,16 +3004,20 @@ An \Orchard{} \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, is the \diversifiedTransmissionKey of the recipient's \paymentAddress; \item $\Value \typecolon \range{0}{\MAXMONEY}$ is an integer representing the value of the \note in \zatoshi; + \item $\NoteUniqueRand \typecolon \GF{\ParamP{r}}$ + is used as input to $\PRFnfOrchard{\NullifierKey}$ as part of deriving + the \nullifier of the \note; + \item $\NoteNullifierRand \typecolon \GF{\ParamP{r}}$ + is additional randomness used in deriving the \nullifier; \item $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Orchard}$ is a random \commitmentTrapdoor as defined in \crossref{abstractcommit}. - \item \todo{other fields} \end{itemize} \introlist Let $\NoteType{Orchard}$ be the type of an \Orchard{} \note, i.e. \begin{formulae} \item $\NoteType{Orchard} := \DiversifierType \times \KAPublic{Orchard} \times \range{0}{\MAXMONEY} - \times \NoteCommitTrapdoor{Orchard} \times \todo{...}$. + \times \GF{\ParamP{r}} \times \GF{\ParamP{r}} \times \NoteCommitTrapdoor{Orchard}$. \end{formulae} } %orchard @@ -3012,11 +3031,11 @@ on the \blockChain. \vspace{2ex} \introlist A \SproutOrNothing{} \defining{\noteCommitment} on a \note -$\NoteTuple{} = \changed{(\AuthPublic, \Value, \NoteAddressRand, \NoteCommitRand)}$ is computed as +$\NoteTuple{} = \changed{(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)}$ is computed as \begin{formulae} \item $\NoteCommitment{Sprout}(\NoteTuple{}) = - \NoteCommit{Sprout}{\NoteCommitRand}(\AuthPublic, \Value, \NoteAddressRand)$, + \NoteCommit{Sprout}{\NoteCommitRand}(\AuthPublic, \Value, \NoteUniqueRand)$, \end{formulae} \vspace{-1.5ex} where $\NoteCommit{Sprout}{}$ is instantiated in \crossref{concretesproutnotecommit}. @@ -3043,14 +3062,14 @@ $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRa where $\NoteCommitAlg{Sapling}$ is instantiated in \crossref{concretewindowedcommit}. Notice that the above definition of a \Sapling{} \note does not have a -$\NoteAddressRand$ field. There is in fact a $\NoteAddressRand$ value associated +$\NoteUniqueRand$ field. There is in fact a $\NoteUniqueRand$ value associated with each \Sapling{} \note, but this can only be computed once its position in the \noteCommitmentTree is known (see \crossref{transactions} and \crossref{merkletree}). We refer to the combination of a \note and its \notePosition $\NotePosition$, as a \positionedNote. For a \positionedNote, we can compute the value -$\NoteAddressRand$ as described in \crossref{commitmentsandnullifiers}. +$\NoteUniqueRand$ as described in \crossref{commitmentsandnullifiers}. } %sapling \orchard{ @@ -3059,49 +3078,48 @@ $\NoteAddressRand$ as described in \crossref{commitmentsandnullifiers}. Let $\DiversifyHash{Orchard}$ be as defined in \crossref{concretediversifyhash}. An \Orchard{} \defining{\noteCommitment} on a \note -$\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand, \todo{...})$ -is computed as +$\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand, +\NoteNullifierRand, \NoteCommitRand)$ is computed as \begin{formulae} \item $\DiversifiedTransmitBase := \DiversifyHash{Orchard}(\Diversifier)$ \vspace{-1ex} - \item $\NoteCommitment{Orchard}(\NoteTuple{}) := \begin{cases} - \bot, &\caseif \DiversifiedTransmitBase = \bot \\ - \NoteCommit{Orchard}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase}, - \reprJ\Of{\DiversifiedTransmitPublic}, - \Value), &\caseotherwise. - \end{cases}$ + \item $\NoteCommitment{Orchard}(\NoteTuple{}) := + \NoteCommit{Orchard}{\NoteCommitRand}(\reprPstar\Of{\DiversifiedTransmitBase}, + \reprPstar\Of{\DiversifiedTransmitPublic}, + \Value, \NoteUniqueRand, \NoteNullifierRand)$. \end{formulae} \vspace{-1.5ex} where $\NoteCommitAlg{Orchard}$ is instantiated in \crossref{concretesinsemillacommit}. Unlike in \Sapling, the definition of an \Orchard{} \note includes the -$\NoteAddressRand$ field; the \note's position in the \noteCommitmentTree does +$\NoteUniqueRand$ field; the \note's position in the \noteCommitmentTree does not need to be known in order to compute this value. } %orchard The \nullifier of a \note is denoted $\nf$. \vspace{2ex} -A \nullifier for a \Sprout \note is derived from the $\NoteAddressRand$ value and +A \nullifier for a \Sprout \note is derived from the $\NoteUniqueRand$ value and the recipient's \spendingKey $\AuthPrivate$. \sapling{ -A \nullifier for a \Sapling \note is derived from the $\NoteAddressRand$ value and +A \nullifier for a \Sapling \note is derived from the $\NoteUniqueRand$ value and the recipient's \nullifierDerivingKey $\NullifierKey$. } \orchard{ -A \nullifier for an \Orchard \note is derived from the $\NoteAddressRand$ value, -the recipient's \nullifierDerivingKey $\NullifierKey$, and the \noteCommitment}. +A \nullifier for an \Orchard \note is derived from the $\NoteUniqueRand$ and +$\NoteNullifierRand$ values, the recipient's \nullifierDerivingKey $\NullifierKey$, +and the \noteCommitment. } The \nullifier computation uses a \pseudoRandomFunction (see \crossref{abstractprfs}), as described in \crossref{commitmentsandnullifiers}. A \note is spent by proving knowledge of -$(\NoteAddressRand, \AuthPrivate)$\sapling{ or $(\NoteAddressRand, \AuthSignPublic, -\AuthProvePrivate)$}\orchard{ or $(\NoteAddressRand, \AuthSignPublic, \NullifierKey)$} +$(\NoteUniqueRand, \AuthPrivate)$\sapling{ or $(\NoteUniqueRand, \AuthSignPublic, +\AuthProvePrivate)$}\orchard{ or $(\NoteUniqueRand, \AuthSignPublic, \NullifierKey)$} in zero knowledge while publically disclosing its \nullifier $\nf$, allowing $\nf$ to be used to prevent double-spending. \sapling{For \SaplingAndOrchard, a \spendAuthSignature is also required, in order to demonstrate knowledge of @@ -3122,7 +3140,7 @@ Each \SproutOrNothing{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) c \vspace{-1ex} \begin{formulae} \item $(\changed{\NotePlaintextLeadByte \typecolon \byte,\ } - \Value \typecolon \ValueType, \NoteAddressRand \typecolon \PRFOutputSprout, + \Value \typecolon \ValueType, \NoteUniqueRand \typecolon \PRFOutputSprout, \NoteCommitRand \typecolon \NoteCommitTrapdoor{Sprout}\changed{, \Memo \typecolon \MemoType})$. \end{formulae} @@ -3201,7 +3219,8 @@ The remaining value in the \transparentTxValuePool{} \MUST be nonnegative. \sprout{To each \transaction there is associated an initial \defining{\treestate}. A \treestate consists of:} \notsprout{To each \transaction there are associated initial \defining{\treestates} -for \Sprout\sapling{ and for \Sapling}. \sapling{Each} \treestate consists of:} +for \Sprout\sapling{ and for \Sapling}\orchard{ and for \Orchard}. \sapling{Each} +\treestate consists of:} \begin{itemize} \item a \noteCommitmentTree (\crossref{merkletree}); @@ -3213,14 +3232,14 @@ Validation state associated with \transparent inputs and outputs, such as the UT used in essentially the same way as in \Bitcoin. An \defining{\anchor} is a Merkle tree root of a \noteCommitmentTree\sapling{ (either the -\Sprout tree or the \Sapling tree)}. It uniquely identifies a \noteCommitmentTree -state given the assumed security properties of the Merkle tree's +\Sprout tree or the \Sapling tree\orchard{ or the \Orchard tree})}. It uniquely identifies +a \noteCommitmentTree state given the assumed security properties of the Merkle tree's \hashFunction. Since the \nullifierSet is always updated together with the \noteCommitmentTree, this also identifies a particular state of the associated \nullifierSet. \introlist -In a given \blockChain, \sapling{for each of \Sprout and \Sapling,} +In a given \blockChain, \sapling{for each of \Sprout and \SaplingAndOrchard,} \treestates are chained as follows: \begin{itemize} @@ -3235,7 +3254,8 @@ In a given \blockChain, \sapling{for each of \Sprout and \Sapling,} \changed{\joinSplitDescriptions also have interstitial input and output \treestates\notsprout{ for \Sprout}, explained in the following section.} -\sapling{There is no equivalent of interstitial \treestates for \Sapling.} +\sapling{There is no equivalent of interstitial \treestates for \Sapling\orchard{ or +for \Orchard}.} \lsubsection{JoinSplit Transfers and Descriptions}{joinsplit} @@ -3376,7 +3396,7 @@ each other, potentially increasing opportunities for precomputation. The fields of an \actionDescription are essentially a merger of the fields of a \spendDescription and an \outputDescription, but with only a single \valueCommitment -and a signle \zkSNARKProof. +and a single \zkSNARKProof. \vspace{-1ex} \nnote{ @@ -3403,8 +3423,8 @@ the same \transaction. \vspace{-2ex} \defining{A \noteCommitmentTree is an \incrementalMerkleTree} of fixed depth used to store -\noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers} produce. -Just as the \defining{\utxoSet} (UTXO set) used in \Bitcoin, +\noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers}\orchard{ or \actionTransfers} +produce. Just as the \defining{\utxoSet} (UTXO set) used in \Bitcoin, it is used to express the existence of value and the capability to spend it. However, unlike the UTXO set, it is \emph{not} the job of this tree to protect against double-spending, as it is append-only. @@ -3412,16 +3432,17 @@ against double-spending, as it is append-only. A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate (\crossref{transactions}). -Each \defining{\merkleNode} in the \incrementalMerkleTree is associated with a -\defining{\merkleHash} of size $\MerkleHashLength{Sprout}$ \sapling{ or $\MerkleHashLength{Sapling}$} bits. -The \defining{\merkleLayer} numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has -$2^h$ \merkleNodes with \defining{\merkleIndices} $0$ to $2^h-1$ inclusive. -The \defining{\merkleHash} associated with the \merkleNode at \merkleIndex $i$ in \merkleLayer $h$ -is denoted $\MerkleNode{h}{i}$. +Each \defining{\merkleNode} in the \incrementalMerkleTree is associated with +a \defining{\merkleHash} of size $\MerkleHashLength{Sprout}$\sapling{ or +$\MerkleHashLength{Sapling}$}\orchard{ or $\MerkleHashLength{Orchard}$} bits. +The \defining{\merkleLayer} numbered $h$, counting from \merkleLayer $0$ at the +\merkleRoot, has $2^h$ \merkleNodes with \defining{\merkleIndices} $0$ to $2^h-1$ +inclusive. The \defining{\merkleHash} associated with the \merkleNode at +\merkleIndex $i$ in \merkleLayer $h$ is denoted $\MerkleNode{h}{i}$. The \merkleIndex of a \notesCommitment at the leafmost layer -($\MerkleDepth{Sprout}OrSapling$) is called its \defining{\notePosition}. - +($\MerkleDepth{Sprout}$\sapling{ or $\MerkleDepth{Sapling}$}\orchard{ or $\MerkleDepth{Orchard}$}) +is called its \defining{\notePosition}. \lsubsection{Nullifier Sets}{nullifierset} @@ -3556,8 +3577,8 @@ keys for the \note being spent. It is instantiated in \crossref{concretecrhivk}. $\MixingPedersenHash \typecolon \GroupJ \times \range{0}{\ParamJ{r}-1} \rightarrow \GroupJ$ is a \hashFunction used in \crossref{commitmentsandnullifiers} -to derive the unique $\NoteAddressRand$ value for a \Sapling{} \note. It is also used -in the \spendStatement to confirm use of the correct $\NoteAddressRand$ value as an +to derive the unique $\NoteUniqueRand$ value for a \Sapling{} \note. It is also used +in the \spendStatement to confirm use of the correct $\NoteUniqueRand$ value as an input to \nullifier derivation. It is instantiated in \crossref{concretemixinghash}. $\DiversifyHash{Sapling} \typecolon \DiversifierType \rightarrow \SubgroupJstar$ is a \hashFunction @@ -3579,7 +3600,7 @@ from a \diversifier in \crossref{orchardkeycomponents}. $\PRF{x}{}$ is a \defining{\pseudoRandomFunction} keyed by $x$. -Let $\AuthPrivateLength$, \changed{$\NoteAddressPreRandLength$,} $\hSigLength$, +Let $\AuthPrivateLength$, \changed{$\NoteUniquePreRandLength$,} $\hSigLength$, $\PRFOutputLengthSprout$, \sapling{$\SpendingKeyLength$, $\OutViewingKeyLength$, $\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,} $\NOld$, and $\NNew$ be as defined in \crossref{constants}. @@ -3599,7 +3620,7 @@ Let $\Sym$ be as defined in \crossref{concretesym}. $\PRFaddr{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \byte $& &$\rightarrow \PRFOutputSprout $\\ $\PRFnf{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \PRFOutputSprout $& &$\rightarrow \PRFOutputSprout $\\ $\PRFpk{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \setofOld $&$\times\; \hSigType $&$\rightarrow \PRFOutputSprout $\\ -$\setchanged\PRFrho{} $&$\setchanged\typecolon\; \bitseq{\NoteAddressPreRandLength} $&$\setchanged\times\; \setofNew $&$\setchanged\times\; \hSigType $&$\setchanged\rightarrow \PRFOutputSprout $ +$\setchanged\PRFrho{} $&$\setchanged\typecolon\; \bitseq{\NoteUniquePreRandLength} $&$\setchanged\times\; \setofNew $&$\setchanged\times\; \hSigType $&$\setchanged\rightarrow \PRFOutputSprout $ \end{tabular} These are used in \crossref{joinsplitstatement}; $\PRFaddr{}$ is also used to @@ -4902,7 +4923,7 @@ Let $\JoinSplitSig$ be as specified in \crossref{abstractsig}. Let $\NoteCommitAlg{Sprout}$ be as specified in \crossref{abstractcommit}. -Let $\RandomSeedLength and \NoteAddressPreRandLength$ be as specified in \crossref{constants}. +Let $\RandomSeedLength and \NoteUniquePreRandLength$ be as specified in \crossref{constants}. Sending a \transaction containing \joinSplitDescriptions involves first generating a new $\JoinSplitSig$ key pair: @@ -4916,18 +4937,18 @@ generating a new $\JoinSplitSig$ key pair: For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at random on $\bitseq{\RandomSeedLength}$, and selects the input \notes. At this point there is sufficient information to compute $\hSig$, -as described in the previous section. \changed{The sender also chooses $\NoteAddressPreRand$ -uniformly at random on $\bitseq{\NoteAddressPreRandLength}$.} +as described in the previous section. \changed{The sender also chooses $\NoteUniquePreRand$ +uniformly at random on $\bitseq{\NoteUniquePreRandLength}$.} Then it creates each output \note with index $i \typecolon \setofNew$: \begin{itemize} \item Choose uniformly random $\NoteCommitRand_i \leftarrowR \NoteCommitGenTrapdoor{Sprout}()$. \changed{ - \item Compute $\NoteAddressRand_i = \PRFrho{\NoteAddressPreRand}(i, \hSig)$. + \item Compute $\NoteUniqueRand_i = \PRFrho{\NoteUniquePreRand}(i, \hSig)$. } \item Compute $\cm_i = - \NoteCommit{Sprout}{\NoteCommitRand_i}(\AuthPublicSub{i}, \Value_i, \NoteAddressRand_i)$. - \item Let $\NotePlaintext{i} = (\changed{\hexint{00},\ } \Value_i, \NoteAddressRand_i, \NoteCommitRand_i\changed{, \Memo_i})$. + \NoteCommit{Sprout}{\NoteCommitRand_i}(\AuthPublicSub{i}, \Value_i, \NoteUniqueRand_i)$. + \item Let $\NotePlaintext{i} = (\changed{\hexint{00},\ } \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i\changed{, \Memo_i})$. \end{itemize} $\NotePlaintext{\allNew}$ are then encrypted to the recipient \transmissionKeys @@ -5105,9 +5126,9 @@ is constructed as follows: \item Generate a new uniformly random \spendingKey $\AuthPrivateOld{i} \leftarrowR \bitseq{\AuthPrivateLength}$ and derive its \payingKey $\AuthPublicOld{i}$. \item \vspace{-0.5ex} Set $\vOld{i} = 0$. - \item Choose uniformly random $\NoteAddressRandOld{i} \leftarrowR \PRFOutputSprout$ + \item Choose uniformly random $\NoteUniqueRandOld{i} \leftarrowR \PRFOutputSprout$ and $\NoteCommitRandOld{i} \leftarrowR \NoteCommitGenTrapdoor{Sprout}()$. - \item Compute $\nfOld{i} = \PRFnf{\AuthPrivateOld{i}}(\NoteAddressRandOld{i})$. + \item Compute $\nfOld{i} = \PRFnf{\AuthPrivateOld{i}}(\NoteUniqueRandOld{i})$. \item Let $\TreePath{i}$ be a \dummy \merklePath for the \auxiliaryInput to the \joinSplitStatement (this will not be checked). \item When generating the \joinSplitProof\!\!, set $\EnforceMerklePath{i}$ to $0$. @@ -5153,11 +5174,11 @@ A \dummy{} \Sapling input \note is constructed as follows: and $\AuthProvePrivate \leftarrowR \GF{\ParamJ{r}}$. \item Compute $\NullifierKey = \scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}$ and $\NullifierKeyRepr = \reprJ\Of{\NullifierKey}$\,. - \item Compute $\NoteAddressRand{} = \cmOld{} + \item Compute $\NoteUniqueRand{} = \cmOld{} = \NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase}, \reprJ\Of{\DiversifiedTransmitPublic}, \vOld{})$. - \item Compute $\nfOld{} = \PRFnfSapling{\NullifierKeyRepr}(\reprJ(\NoteAddressRand))$. + \item Compute $\nfOld{} = \PRFnfSapling{\NullifierKeyRepr}(\reprJ(\NoteUniqueRand))$. \item Construct a \dummy \merklePath $\TreePath{}$ for use in the \auxiliaryInput to the \spendStatement (this will not be checked, because $\vOld{} = 0$). \end{itemize} @@ -5839,17 +5860,17 @@ would have added a \nullifier to the \nullifierSet that already exists in the se (see \crossref{nullifierset}). \vspace{2ex} -\sprout{Each}\notsprout{In \Sprout, each} \note has a $\NoteAddressRand$ component. +\sprout{Each}\notsprout{In \Sprout, each} \note has a $\NoteUniqueRand$ component. \sapling{ \vspace{2ex} \introlist -In \Sapling, each \defining{\positionedNote} has an associated $\NoteAddressRand$ value which +In \Sapling, each \defining{\positionedNote} has an associated $\NoteUniqueRand$ value which is computed from its \noteCommitment $\cm$ and \notePosition $\NotePosition$ as follows: \begin{formulae} - \item $\NoteAddressRand := \MixingPedersenHash(\cm, \NotePosition)$. + \item $\NoteUniqueRand := \MixingPedersenHash(\cm, \NotePosition)$. \end{formulae} $\MixingPedersenHash$ is defined in \crossref{concretemixinghash}. @@ -5860,14 +5881,14 @@ Let $\PRFnf{}{}$\sapling{ and $\PRFnfSapling{}{}$} be as instantiated in \crossr \vspace{2ex} \sprout{The \nullifier of a \note}\notsprout{For a \Sprout{} \note, the \nullifier} -is derived as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$, where $\AuthPrivate$ is the +is derived as $\PRFnf{\AuthPrivate}(\NoteUniqueRand)$, where $\AuthPrivate$ is the \spendingKey associated with the \note. \vspace{2ex} \sapling{ For a \Sapling{} \note, the \nullifier is derived as -$\PRFnfSapling{\NullifierKeyRepr}(\NoteAddressRandRepr)$, where $\NullifierKeyRepr$ -is a representation of the \nullifierDerivingKey associated with the \note and $\NoteAddressRandRepr = \reprJ(\NoteAddressRand)$. +$\PRFnfSapling{\NullifierKeyRepr}(\NoteUniqueRandRepr)$, where $\NullifierKeyRepr$ +is a representation of the \nullifierDerivingKey associated with the \note and $\NoteUniqueRandRepr = \reprJ(\NoteUniqueRand)$. } %sapling @@ -5879,7 +5900,7 @@ is a representation of the \nullifierDerivingKey associated with the \note and $ \vspace{-2ex} Let $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$, $\MerkleDepth{Sprout}$, $\ValueLength$, -$\AuthPrivateLength$, $\NoteAddressPreRandLength$, $\hSigLength$, $\NOld$, $\NNew$ be as defined in \crossref{constants}. +$\AuthPrivateLength$, $\NoteUniquePreRandLength$, $\hSigLength$, $\NOld$, $\NNew$ be as defined in \crossref{constants}. \vspace{-1ex} Let $\PRFaddr{}$, $\PRFnf{}$, $\PRFpk{}$, \changed{and $\PRFrho{}$} be as defined in \crossref{abstractprfs}. @@ -5909,7 +5930,7 @@ the prover knows an \auxiliaryInput: \hparen\nOld{\allOld} \typecolon \typeexp{\NoteType{Sprout}}{\NOld},\\ \hparen\AuthPrivateOld{\allOld} \typecolon \typeexp{\bitseq{\AuthPrivateLength}}{\NOld},\\ \hparen\nNew{\allNew} \typecolon \typeexp{\NoteType{Sprout}}{\NNew}\changed{,}\vspace{0.8ex}\\ - \hparen\changed{\NoteAddressPreRand \typecolon \bitseq{\NoteAddressPreRandLength},}\vspace{-0.5ex}\\ + \hparen\changed{\NoteUniquePreRand \typecolon \bitseq{\NoteUniquePreRandLength},}\vspace{-0.5ex}\\ \hparen\changed{\EnforceMerklePath{\allOld} \typecolon \bitseq{\NOld}}\cparen$, \end{formulae} \vspace{-2ex} @@ -5917,9 +5938,9 @@ where: \vspace{-0.5ex} \begin{formulae} \item for each $i \in \setofOld$: $\nOld{i} = (\AuthPublicOld{i}, -\vOld{i}, \NoteAddressRandOld{i}, \NoteCommitRandOld{i})$; +\vOld{i}, \NoteUniqueRandOld{i}, \NoteCommitRandOld{i})$; \item for each $i \in \setofNew$: $\nNew{i} = (\AuthPublicNew{i}, -\vNew{i}, \NoteAddressRandNew{i}, \NoteCommitRandNew{i})$ +\vNew{i}, \NoteUniqueRandNew{i}, \NoteCommitRandNew{i})$ \end{formulae} \vspace{-1ex} such that the following conditions hold: @@ -5940,7 +5961,7 @@ $\changed{\vpubOld\; +} \ssum{i=1}{\NOld} \vOld{i} = \vpubNew + \ssum{i=1}{\NNew \snarkcondition{Nullifier integrity}{sproutnullifierintegrity} for each $i \in \setofOld$: -$\nfOld{i} = \PRFnf{\AuthPrivateOld{i}}(\NoteAddressRandOld{i})$. +$\nfOld{i} = \PRFnf{\AuthPrivateOld{i}}(\NoteUniqueRandOld{i})$. \snarkcondition{Spend authority}{sproutspendauthority} for each $i \in \setofOld$: @@ -5950,9 +5971,9 @@ $\AuthPublicOld{i} = \changed{\PRFaddr{\AuthPrivateOld{i}}(0)}$. for each $i \in \setofOld$: $\h{i} = \PRFpk{\AuthPrivateOld{i}}(i, \hSig)$. -\changed{\snarkcondition{Uniqueness of $\NoteAddressRandNew{i}$}{sproutuniquerho} +\changed{\snarkcondition{Uniqueness of $\NoteUniqueRandNew{i}$}{sproutuniquerho} for each $i \in \setofNew$: -$\NoteAddressRandNew{i} = \PRFrho{\NoteAddressPreRand}(i, \hSig)$.} +$\NoteUniqueRandNew{i} = \PRFrho{\NoteUniquePreRand}(i, \hSig)$.} \snarkcondition{Note commitment integrity}{sproutcommitmentintegrity} for each $i \in \setofNew$: $\cmNew{i} = \NoteCommitment{Sprout}(\nNew{i})$. @@ -6035,12 +6056,12 @@ are not of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} and $\scalarmult{\ParamJ{h}}{\AuthSignPublic} \neq \ZeroJ$. \snarkcondition{Nullifier integrity}{spendnullifierintegrity} -$\nfOld{} = \PRFnfSapling{\NullifierKeyRepr}(\NoteAddressRandRepr)$ where +$\nfOld{} = \PRFnfSapling{\NullifierKeyRepr}(\NoteUniqueRandRepr)$ where \vspace{-1ex} \begin{formulae} \item $\NullifierKeyRepr = \reprJ\Of{\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}}$ \vspace{-1ex} - \item $\NoteAddressRandRepr = \reprJ\big(\MixingPedersenHash(\cmOld{}, \NotePosition)\kern-0.12em\big)$. + \item $\NoteUniqueRandRepr = \reprJ\big(\MixingPedersenHash(\cmOld{}, \NotePosition)\kern-0.12em\big)$. \end{formulae} \snarkcondition{Spend authority}{spendauthority} @@ -6171,7 +6192,9 @@ A valid instance of a \defining{\actionStatement}, $\ProofAction$, assures that \hparen\nfOld{} \typecolon \PRFOutputNfOrchard,\\ \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard},\\ \hparen\cmX \typecolon \MerkleHash{Orchard},\\ - \hparen\EphemeralPublic \typecolon \GroupPstar\cparen$, + \hparen\EphemeralPublic \typecolon \GroupPstar,\\ + \hparen\enableSpend \typecolon \bit,\\ + \hparen\enableOutput \typecolon \bit\cparen$, \end{formulae} \vspace{-2ex} @@ -6217,7 +6240,7 @@ $\DiversifiedTransmitBaseOld$ and $\DiversifiedTransmitBaseNew$ and $\AuthSignPu \todo{express this in the type} \snarkcondition{Nullifier integrity}{actionnullifierintegrity} -$\nfOld{} = \scalarmult{(\PRFnfOrchard{\NullifierKeyRepr}(\NoteAddressRandRepr) + \uppsi) \bmod \ParamP{q}}{\NullifierBaseOrchard} + \cmOld{}$. +$\nfOld{} = \scalarmult{(\PRFnfOrchard{\NullifierKeyRepr}(\NoteUniqueRandRepr) + \uppsi) \bmod \ParamP{q}}{\NullifierBaseOrchard} + \cmOld{}$. \snarkcondition{Spend authority}{actionspendauthority} $\AuthSignRandomizedPublic = \SpendAuthSigRandomizePublic(\AuthSignRandomizer, \AuthSignPublic)$. @@ -6243,6 +6266,12 @@ where $\DiversifiedTransmitBaseNewRepr = \reprJ\Of{\DiversifiedTransmitBaseNew}$ \snarkcondition{Ephemeral public key integrity}{actionepkintegrity} $\EphemeralPublic = \scalarmult{\EphemeralPrivate}{\DiversifiedTransmitBaseNew}$. +\snarkcondition{Enable spend flag}{actionenablespend} +$\vOld{} = 0$ or $\enableSpend = 1$. + +\snarkcondition{Enable output flag}{actionenableoutput} +$\vNew{} = 0$ or $\enableOutput = 1$. + For details of the form and encoding of \actionStatement proofs, see \crossref{halo2}. \begin{pnotes} @@ -6270,7 +6299,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h \sprout{The}\notsprout{In \Sprout, the} secrets that need to be transmitted to a recipient of funds in order for them to later spend, are $\Value$, -$\NoteAddressRand$, and $\NoteCommitRand$. +$\NoteUniqueRand$, and $\NoteCommitRand$. \changed{A \memo (\crossref{noteptconcept}) is also transmitted.} To transmit these secrets securely to a recipient @@ -6373,17 +6402,17 @@ is defined as follows: \item if $\TransmitPlaintext{i} = \bot$, return $\bot$ \item extract $\NotePlaintext{i} = (\NotePlaintextLeadByte_i \typecolon \byte, \Value_i \typecolon \ValueType, -\NoteAddressRand_i \typecolon \PRFOutputSprout, +\NoteUniqueRand_i \typecolon \PRFOutputSprout, \NoteCommitRand_i \typecolon \NoteCommitTrapdoor{Sprout}, \Memo_i \typecolon \MemoType)$ from $\TransmitPlaintext{i}$ - \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}((\AuthPublic, \Value_i, \NoteAddressRand_i, + \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}((\AuthPublic, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i)) \neq \cm_i$, return $\bot$, else return $\NotePlaintext{i}$. \end{formulae} } To test whether a \note is unspent in a particular \blockChain also requires the \spendingKey $\AuthPrivate$; the coin is unspent if and only if -$\nf = \PRFnf{\AuthPrivate}(\NoteAddressRand)$ is not in the \nullifierSet +$\nf = \PRFnf{\AuthPrivate}(\NoteUniqueRand)$ is not in the \nullifierSet for that \blockChain. \vspace{0.5ex} @@ -6565,11 +6594,11 @@ from $\TransmitPlaintext{}$ $\NotePlaintextLeadByte \neq \hexint{01}$) in the comparison against $\reprJ\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$}. \item Normally only \noteCiphertextsSapling of \transactions in \blocks need to be decrypted. In that case, - any received \Sapling{} \note is necessarily a \positionedNote, and so its $\NoteAddressRand$ + any received \Sapling{} \note is necessarily a \positionedNote, and so its $\NoteUniqueRand$ value can immediately be calculated as described in \crossref{commitmentsandnullifiers}. To test whether a \Sapling{} \note is unspent in a particular \blockChain also requires the \nullifierDerivingKey $\NullifierKeyRepr$; the coin is unspent if and only if - $\nf = \PRFnfSapling{\NullifierKeyRepr}\big(\reprJ(\NoteAddressRand)\kern-0.15em\big)$ is + $\nf = \PRFnfSapling{\NullifierKeyRepr}\big(\reprJ(\NoteUniqueRand)\kern-0.15em\big)$ is not in the \nullifierSet for that \blockChain. \item A \note can change from being unspent to spent as a node's view of the \bestValidBlockChain is extended by new \transactions. Also, \blockChainReorganizations can cause a node to switch to @@ -6577,7 +6606,7 @@ from $\TransmitPlaintext{}$ \item A client \MAY attempt to decrypt a \noteCiphertextSapling of a \transaction in the \mempool\canopy{, using the next \blockHeight for $\BlockHeight$}. However, in that case it \MUSTNOT assume that the \transaction will be mined and \MUST treat the decrypted information as provisional. It - will not be able to calculate the $\NoteAddressRand$ value. + will not be able to calculate the $\NoteUniqueRand$ value. \end{pnotes} } %sapling @@ -6651,7 +6680,7 @@ from $\TransmitPlaintext{}$ \vspace{-0.5ex} \item $\DiversifiedTransmitPublicRepr$ can also be non-canonical. The decoded point $\DiversifiedTransmitPublic$ is \emph{not} checked to be in the subgroup $\SubgroupJ$. - \item The comments in \crossref{saplingdecryptivk} concerning calculation of $\NoteAddressRand$, detection + \item The comments in \crossref{saplingdecryptivk} concerning calculation of $\NoteUniqueRand$, detection of spent \notes, and decryption of \noteCiphertextsSapling for \transactions in the \mempool also apply to \notes decrypted by this procedure. \end{pnotes} @@ -6882,7 +6911,7 @@ Define: \item $\NoteCommitRandLength \typecolon \Nat := \changed{256}$ \item $\changed{\RandomSeedLength \typecolon \Nat := 256}$ \item $\AuthPrivateLength \typecolon \Nat := \changed{252}$ - \item $\changed{\NoteAddressPreRandLength \typecolon \Nat := 252}$ + \item $\changed{\NoteUniquePreRandLength \typecolon \Nat := 252}$ \sapling{ \item $\SpendingKeyLength \typecolon \Nat := 256$ \item $\DiversifierLength \typecolon \Nat := 88$ @@ -7543,7 +7572,7 @@ so there are no solutions for $\varv$ (contradiction). \sapling{ \lsubsubsubsection{Mixing Pedersen Hash Function}{concretemixinghash} -A mixing \xPedersenHash is used to compute $\NoteAddressRand$ from +A mixing \xPedersenHash is used to compute $\NoteUniqueRand$ from $\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as input a \xPedersenCommitment $P$, and hashes it with another input $x$. @@ -7767,7 +7796,7 @@ described in \crossref{abstractprfs}, are all instantiated using \shaCompress: \sbitbox{18}{$1$} & \sbitbox{18}{$0$} & \sbitbox{224}{$252$-bit $\AuthPrivate$} & - \sbitbox{256}{$256$-bit $\NoteAddressRand$} + \sbitbox{256}{$256$-bit $\NoteUniqueRand$} \end{bytefield} \end{lrbox} @@ -7792,7 +7821,7 @@ described in \crossref{abstractprfs}, are all instantiated using \shaCompress: \sbitbox{18}{\iminusone} & \sbitbox{18}{$1$} & \sbitbox{18}{$0$} & - \sbitbox{224}{$252$-bit $\NoteAddressPreRand$} & + \sbitbox{224}{$252$-bit $\NoteUniquePreRand$} & \sbitbox{256}{$256$-bit $\hSig$} \end{bytefield} \end{lrbox} @@ -7801,9 +7830,9 @@ described in \crossref{abstractprfs}, are all instantiated using \shaCompress: \begin{equation*} \begin{aligned} \setchanged \PRFaddr{x}(t) &\setchanged := \SHACompressBox{\addrbox} \\ -\PRFnf{\AuthPrivate}(\NoteAddressRand) &:= \SHACompressBox{\nfbox} \\ +\PRFnf{\AuthPrivate}(\NoteUniqueRand) &:= \SHACompressBox{\nfbox} \\ \PRFpk{\AuthPrivate}(i, \hSig) &:= \SHACompressBox{\pkbox} \\ -\setchanged \PRFrho{\NoteAddressPreRand}(i, \hSig) &\setchanged := \SHACompressBox{\rhobox} +\setchanged \PRFrho{\NoteUniquePreRand}(i, \hSig) &\setchanged := \SHACompressBox{\rhobox} \end{aligned} \end{equation*} @@ -7811,7 +7840,7 @@ described in \crossref{abstractprfs}, are all instantiated using \shaCompress: \begin{securityrequirements} \item \shaCompress must be \collisionResistant\!. \item \shaCompress must be a \xPRF when keyed by the bits - corresponding to $x$, $\AuthPrivate$ or $\NoteAddressPreRand$ + corresponding to $x$, $\AuthPrivate$ or $\NoteUniquePreRand$ in the above diagrams, with input in the remaining bits. \end{securityrequirements} @@ -7849,7 +7878,7 @@ be necessary.}) \setsapling \begin{bytefield}[bitwidth=0.038em]{512} \sbitbox{256}{$\LEBStoOSPOf{256}{\NullifierKeyRepr}$} & - \sbitbox{256}{$\LEBStoOSPOf{256}{\NoteAddressRandRepr}$} + \sbitbox{256}{$\LEBStoOSPOf{256}{\NoteUniqueRandRepr}$} \end{bytefield} \end{lrbox} @@ -7900,7 +7929,7 @@ $\PRFnfSapling{}$ is used to derive the \nullifier for a \Sapling{} \note. It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \crossref{concreteblake2}: \begin{formulae} - \item $\PRFnfSapling{\NullifierKeyRepr}(\NoteAddressRandRepr) := \BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$. + \item $\PRFnfSapling{\NullifierKeyRepr}(\NoteUniqueRandRepr) := \BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$. \end{formulae} \vspace{-2ex} @@ -7908,7 +7937,7 @@ It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \cross $\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a \collisionResistant \xPRF for output range $\byteseq{32}$ when keyed by the bits corresponding to $\NullifierKeyRepr$, with input in the bits corresponding to -$\NoteAddressRandRepr$. Note that +$\NoteUniqueRandRepr$. Note that {$\NullifierKeyRepr$}{$\typecolon$}{$\SubgroupReprJ$} % {$...$} hack needed for reasonable spacing is a representation of a point in the $\ParamJ{r}$-order subgroup of the \jubjubCurve, and therefore is not uniformly distributed on $\ReprJ$. @@ -8481,7 +8510,7 @@ $\ValueCommitRandBase{Orchard}$}. \sbitbox{28}{$0$} & \sbitbox{256}{$256$-bit $\AuthPublic$} & \sbitbox{140}{$64$-bit $\Value$} & - \sbitbox{256}{$256$-bit $\NoteAddressRand$} & + \sbitbox{256}{$256$-bit $\NoteUniqueRand$} & \sbitbox{256}{$256$-bit $\NoteCommitRand$} \end{bytefield} \end{lrbox} @@ -8491,7 +8520,7 @@ The commitment scheme $\NoteCommit{Sprout}{}$ specified in \crossref{abstractcom instantiated using \shaHash as follows: \begin{formulae}[leftmargin=1em] - \item $\NoteCommit{Sprout}{\NoteCommitRand}(\AuthPublic, \Value, \NoteAddressRand) := \SHAFullBox{\cmbox}$ + \item $\NoteCommit{Sprout}{\NoteCommitRand}(\AuthPublic, \Value, \NoteUniqueRand) := \SHAFullBox{\cmbox}$ \item $\NoteCommitGenTrapdoor{Sprout}()$ generates the uniform distribution on $\NoteCommitTrapdoor{Sprout}$. \end{formulae} @@ -9612,7 +9641,7 @@ respective \transmissionKeys $\TransmitPublicNew{\allNew}$. Each \notsprout{\Sprout} \notePlaintext (denoted $\NotePlaintext{}$) consists of: \begin{formulae} \item $(\changed{\NotePlaintextLeadByte \typecolon \byte,\ } - \Value \typecolon \ValueType, \NoteAddressRand \typecolon \PRFOutputSprout, + \Value \typecolon \ValueType, \NoteUniqueRand \typecolon \PRFOutputSprout, \NoteCommitRand \typecolon \NoteCommitOutput{Sprout}\changed{, \Memo \typecolon \MemoType})$ \end{formulae} @@ -9660,7 +9689,7 @@ The encoding of a \SproutOrNothing{} \notePlaintext consists of: \changed{ \sbitbox{220}{$8$-bit $\NotePlaintextLeadByte$} &}\sbitbox{180}{$64$-bit $\Value$} & - \sbitbox{256}{$256$-bit $\NoteAddressRand$} & + \sbitbox{256}{$256$-bit $\NoteUniqueRand$} & \sbitbox{256}{\changed{$256$}-bit $\NoteCommitRand$} & \changed{\sbitbox{800}{$\Memo$ ($\MemoByteLength$ bytes)}} \end{bytefield} @@ -9672,7 +9701,7 @@ The encoding of a \SproutOrNothing{} \notePlaintext consists of: encoding of a \SproutOrNothing{} \notePlaintext. } \item $8$ bytes specifying $\Value$. - \item $32$ bytes specifying $\NoteAddressRand$. + \item $32$ bytes specifying $\NoteUniqueRand$. \item \changed{32} bytes specifying $\NoteCommitRand$. \changed{ \item $\MemoByteLength$ bytes specifying $\Memo$. @@ -10341,13 +10370,13 @@ $\versionField \geq 4$ and $\nShieldedSpend + \nShieldedOutput > 0$. \preoverwinteritem{The \fOverwintered{} flag \MUSTNOT be set\sprout{ in the protocol version described by this document}.} \overwinteronwarditem{The \fOverwintered{} flag \MUST be set.} \overwinteronwarditem{The \versionGroupID{} \MUST be recognized.} - \overwinteronlyitem{The \transactionVersionNumber{} \MUST be $3$ and the \versionGroupID{} \MUST + \overwinteronlyitem{The \transactionVersionNumber{} \MUST be $3$, and the \versionGroupID{} \MUST be $\hexint{03C48270}$.} - \saplingonwarditem{The \transactionVersionNumber{} \MUST be $4$ and the \versionGroupID{} \MUST - be $\hexint{892F2085}$.} + \saplingonwarditem{\;The\, \transactionVersionNumber\, \MUST\, be\, $4$,\; and\, the\, \versionGroupID\, + \MUST\, be\, $\hexint{892F2085}$.} \orchardonwarditem{The \transactionVersionNumber{} \MUST be $4$ or $5$. If the \transactionVersionNumber{} is $4$ then the \versionGroupID{} \MUST be $\hexint{892F2085}$. - If the \transactionVersionNumber{} is $5$ then the \versionGroupID{} \MUST be \todo{}}. + If the \transactionVersionNumber{} is $5$ then the \versionGroupID{} \MUST be $\hexint{26A7270A}$.} \presaplingitem{The encoded size of the \transaction{} \MUST be less than or equal to $100000$ bytes.} \presaplingitem{If $\versionField = 1$ or $\nJoinSplit = 0$, then both \txInCount{} and \txOutCount{} \MUST be nonzero.\!} @@ -11586,14 +11615,14 @@ outputs are still possible. \lsubsection{Faerie Gold attack and fix}{faeriegold} When a \shielded \note is created in \Zerocash, the creator is -supposed to choose a new $\NoteAddressRand$ value at random. +supposed to choose a new $\NoteUniqueRand$ value at random. The \nullifier of the \note is derived from its \spendingKey -($\AuthPrivate$) and $\NoteAddressRand$. The \noteCommitment +($\AuthPrivate$) and $\NoteUniqueRand$. The \noteCommitment is derived from the recipient address component $\AuthPublic$, the value $\Value$, and the \commitmentTrapdoor $\NoteCommitRand$, -as well as $\NoteAddressRand$. However nothing prevents creating +as well as $\NoteUniqueRand$. However nothing prevents creating multiple \notes with different $\Value$ and $\NoteCommitRand$ -(hence different \noteCommitments) but the same $\NoteAddressRand$. +(hence different \noteCommitments) but the same $\NoteUniqueRand$. An adversary can use this to mislead a \note recipient, by sending two \notes both of which are verified as valid by $\Receive$ (as @@ -11634,7 +11663,7 @@ but doing so is outside the scope of this specification. Here we only describe how \Zcash addresses the immediate attack. It would be possible to address the attack by requiring that a -recipient remember all of the $\NoteAddressRand$ values for all +recipient remember all of the $\NoteUniqueRand$ values for all \notes they have ever received, and reject duplicates (as proposed in \cite{GGM2016}). However, this requirement would interfere with the intended \Zcash feature that a holder of a \spendingKey @@ -11644,7 +11673,7 @@ of their funds, even if they have forgotten everything but the \sproutspecific{ Instead, \Zcash enforces that an adversary must choose distinct values -for each $\NoteAddressRand$, by making use of the fact that all of the +for each $\NoteUniqueRand$, by making use of the fact that all of the \nullifiers in \joinSplitDescriptions that appear in a \validBlockChain must be distinct. This is true regardless of whether the \nullifiers corresponded to real or \dummy \notes (see \crossref{sproutdummynotes}). @@ -11659,27 +11688,27 @@ adversary.) } \sproutspecific{ -The $\NoteAddressRand$ value for each output \note is then derived from -a random private seed $\NoteAddressPreRand$ and $\hSig$ using -$\PRFrho{\NoteAddressPreRand}$. The correct construction of -$\NoteAddressRand$ for each output \note is enforced by +The $\NoteUniqueRand$ value for each output \note is then derived from +a random private seed $\NoteUniquePreRand$ and $\hSig$ using +$\PRFrho{\NoteUniquePreRand}$. The correct construction of +$\NoteUniqueRand$ for each output \note is enforced by \crossref{sproutuniquerho} in the \joinSplitStatement. } \sproutspecific{ Now even if the creator of a \joinSplitDescription does not choose -$\NoteAddressPreRand$ randomly, uniqueness of \nullifiers and +$\NoteUniquePreRand$ randomly, uniqueness of \nullifiers and \collisionResistance of both $\hSigCRH$ and $\PRFrho{}$ will ensure -that the derived $\NoteAddressRand$ values are unique, at least for +that the derived $\NoteUniqueRand$ values are unique, at least for any two \joinSplitDescriptions that get into a \validBlockChain. This is sufficient to prevent the Faerie Gold attack. } A variation on the attack attempts to cause the \nullifier of a sent -\note to be repeated, without repeating $\NoteAddressRand$. +\note to be repeated, without repeating $\NoteUniqueRand$. However, since the \nullifier is computed as -$\PRFnf{\AuthPrivate}(\NoteAddressRand)$\sapling{ (or -$\PRFnfSapling{\NullifierKey}(\NoteAddressRandRepr)$ for \Sapling)}, +$\PRFnf{\AuthPrivate}(\NoteUniqueRand)$\sapling{ (or +$\PRFnfSapling{\NullifierKey}(\NoteUniqueRandRepr)$ for \Sapling)}, this is only possible if the adversary finds a collision across both inputs on $\PRFnf{}$\sapling{ (or $\PRFnfSapling{}$)}, which is assumed to be infeasible --- see \crossref{abstractprfs}. @@ -11698,7 +11727,7 @@ on the value. adversary sees a victim's \transaction, and is able to publish another \transaction that is mined first and blocks the victim's \transaction. This attack would be possible if the public value(s) used to -enforce uniqueness of $\NoteAddressRand$ could be chosen arbitrarily +enforce uniqueness of $\NoteUniqueRand$ could be chosen arbitrarily by the \transaction creator: the victim's \transaction, rather than the adversary's, would be considered to be repeating these values. In the chosen solution that uses \nullifiers for these public values, @@ -11709,16 +11738,16 @@ who does not know these keys. } \saplingonward{ -In \Sapling, uniqueness of $\NoteAddressRand$ is ensured by making it +In \Sapling, uniqueness of $\NoteUniqueRand$ is ensured by making it dependent on the position of the \noteCommitment in the \Sapling{} \noteCommitmentTree. Specifically, -$\NoteAddressRand = \cm + \scalarmult{\NotePosition}{\NotePositionBaseSapling}$, +$\NoteUniqueRand = \cm + \scalarmult{\NotePosition}{\NotePositionBaseSapling}$, where $\NotePositionBaseSapling$ is a generator independent of the generators -used in $\NoteCommitAlg{Sapling}$. Therefore, $\NoteAddressRand$ commits uniquely +used in $\NoteCommitAlg{Sapling}$. Therefore, $\NoteUniqueRand$ commits uniquely to the \note and its position, and this commitment is \collisionResistant by the same argument used to prove \collisionResistance of \xPedersenHashes. Note that it is possible for two distinct \Sapling{} \positionedNotes (having -different $\NoteAddressRand$ values and \nullifiers, but different +different $\NoteUniqueRand$ values and \nullifiers, but different \notePositions) to have the same \noteCommitment, but this causes no security problem. Roadblock attacks are not possible because a given \notePosition does not repeat for outputs of different \transactions in the same \blockChain. @@ -11730,14 +11759,14 @@ does not repeat for outputs of different \transactions in the same \blockChain. The \Zerocash security proof requires that the composition of $\Commit{\NoteCommitRand}$ and $\Commit{\NoteCommitS}$ is a computationally binding commitment to its inputs $\AuthPublic$, -$\Value$, and $\NoteAddressRand$. However, the instantiation of +$\Value$, and $\NoteUniqueRand$. However, the instantiation of $\Commit{\NoteCommitRand}$ and $\Commit{\NoteCommitS}$ in section 5.1 of the paper did not meet the definition of a binding commitment at a $128$-bit security level. Specifically, the internal -hash of $\AuthPublic$ and $\NoteAddressRand$ is truncated to $128$ bits +hash of $\AuthPublic$ and $\NoteUniqueRand$ is truncated to $128$ bits (motivated by providing statistical hiding security). This allows an attacker, with a work factor on the order of $2^{64}$, to find distinct -pairs $(\AuthPublic, \NoteAddressRand)$ and $(\AuthPublic\!', \NoteAddressRand')$ +pairs $(\AuthPublic, \NoteUniqueRand)$ and $(\AuthPublic\!', \NoteUniqueRand')$ with colliding outputs of the truncated hash, and therefore the same \noteCommitment. This would have allowed such an attacker to break the Balance property by double-spending \notes, potentially creating arbitrary @@ -11787,7 +11816,7 @@ The format of inputs to the \xPRFs instantiated in \crossref{concreteprfs} has changed relative to \Zerocash. There is also a requirement for another \xPRF, $\PRFrho{}$, which must be domain-separated from the others. -In the \Zerocash protocol, $\NoteAddressRandOld{i}$ is truncated from $256$ +In the \Zerocash protocol, $\NoteUniqueRandOld{i}$ is truncated from $256$ to $254$ bits in the input to $\PRFsn{}$ (which corresponds to $\PRFnf{}$ in \Zcash). Also, $\hSig$ is truncated from $256$ to $253$ bits in the input to $\PRFpk{}$. These truncations are not taken into account in the security proofs. @@ -11800,13 +11829,13 @@ In more detail: \begin{itemize} \item In the argument relating $\mathbf{H}$ and $\Game_2$, it is stated that in $\Game_2$, - ``for each $i \in \setof{1, 2}, \mathsf{sn}_i := \PRFsn{\AuthPrivate}(\NoteAddressRand)$ - for a random (and not previously used) $\NoteAddressRand$''. It is also + ``for each $i \in \setof{1, 2}, \mathsf{sn}_i := \PRFsn{\AuthPrivate}(\NoteUniqueRand)$ + for a random (and not previously used) $\NoteUniqueRand$''. It is also argued that ``the calls to $\PRFsn{\AuthPrivate}$ are each by definition unique''. - The latter assertion depends on the fact that $\NoteAddressRand$ + The latter assertion depends on the fact that $\NoteUniqueRand$ is ``not previously used''. However, the argument is incorrect because the truncated input to $\PRFsn{\AuthPrivate}$, i.e. - $[\NoteAddressRand]_{254}$, may repeat even if $\NoteAddressRand$ does not. + $[\NoteUniqueRand]_{254}$, may repeat even if $\NoteUniqueRand$ does not. \item In the same argument, it is stated that ``with overwhelming probability, $\hSig$ is unique''. In fact what is required to be unique is the truncated input to $\PRFpk{}$, i.e.\ $[\hSig]_{253} = [\CRH(\pksig)]_{253}$. @@ -11815,15 +11844,15 @@ In more detail: for this is presented. \end{itemize} -Note that $\NoteAddressRand$ is truncated in the input to $\PRFsn{}$ +Note that $\NoteUniqueRand$ is truncated in the input to $\PRFsn{}$ but not in the input to $\Commit{\NoteCommitRand}$, which further complicates the analysis. As further evidence that it is essential for the proofs to explicitly take any such truncations into account, consider a slightly modified protocol in which -$\NoteAddressRand$ is truncated in the input to $\Commit{\NoteCommitRand}$ +$\NoteUniqueRand$ is truncated in the input to $\Commit{\NoteCommitRand}$ but not in the input to $\PRFsn{}$. In that case, it would be possible to -violate balance by creating two \notes for which $\NoteAddressRand$ differs +violate balance by creating two \notes for which $\NoteUniqueRand$ differs only in the truncated bits. These \notes would have the same \noteCommitment but different \nullifiers, so it would be possible to spend the same value twice. @@ -11836,7 +11865,7 @@ $\hSigCRH$ and $\PRFrho{}$ (instantiated using $\BlakeTwob{256}$ and does not follow from \collisionResistance of the original hash, even if the truncation is only by one bit. This motivated avoiding truncation along any path from the inputs to the computation of $\hSig$ to the uses of -$\NoteAddressRand$. +$\NoteUniqueRand$. } \sproutspecific{ @@ -11844,7 +11873,7 @@ Since the \xPRFs are instantiated using \shaCompress which has an input block size of $512$ bits (of which $256$ bits are used for the \xPRF input and $4$ bits are used for domain separation), it was necessary to reduce the size of the PRF key to $252$ bits. The key is set to $\AuthPrivate$ in the case of -$\PRFaddr{}$, $\PRFnf{}$, and $\PRFpk{}$, and to $\NoteAddressPreRand$ (which +$\PRFaddr{}$, $\PRFnf{}$, and $\PRFpk{}$, and to $\NoteUniquePreRand$ (which does not exist in \Zerocash) for $\PRFrho{}$, and so those values have been reduced to $252$ bits. This is preferable to requiring reasoning about truncation, and $252$ bits is quite sufficient for security of these cryptovalues. @@ -11965,7 +11994,7 @@ the proof of the Balance property. Suppose that an adversary finds a collision on $\PRFaddr{}$ such that $\AuthPrivateSup{1}$ and $\AuthPrivateSup{2}$ are distinct \spendingKeys for the same $\AuthPublic$. Because the \noteCommitment is to $\AuthPublic$, -but the \nullifier is computed from $\AuthPrivate$ (and $\NoteAddressRand$), +but the \nullifier is computed from $\AuthPrivate$ (and $\NoteUniqueRand$), the adversary is able to double-spend the note, once with each $\AuthPrivate$. This is not detected because each Spend reveals a different \nullifier. The \joinSplitStatements are still valid because they can only @@ -11980,16 +12009,16 @@ For the ``$\Adversary$ violates Condition I'' case, the proof says: \item[``(i)] If $\cmOld{1} = \cmOld{2}$, then the fact that $\snOld{1} \neq \snOld{2}$ implies that the witness $a$ contains two distinct openings of $\cmOld{1}$ (the first opening contains - $(\AuthPrivateOldX{1}, \NoteAddressRandOld{1})$, while the second - opening contains $(\AuthPrivateOldX{2}, \NoteAddressRandOld{2})$). + $(\AuthPrivateOldX{1}, \NoteUniqueRandOld{1})$, while the second + opening contains $(\AuthPrivateOldX{2}, \NoteUniqueRandOld{2})$). This violates the binding property of the commitment scheme $\CommitAlg$." \end{itemize} In fact the openings do not contain $\AuthPrivateOld{i}$; they contain $\AuthEmphPublicOld{i}$. (In \SproutOrZcash $\cmOld{i}$ opens directly to -$(\AuthEmphPublicOld{i}, \ValueOld{i}, \NoteAddressRandOld{i})$, and +$(\AuthEmphPublicOld{i}, \ValueOld{i}, \NoteUniqueRandOld{i})$, and in \Zerocash it opens to $(\ValueOld{i}, -\Commit{\NoteCommitS}(\AuthEmphPublicOld{i}, \NoteAddressRandOld{i})$.) +\Commit{\NoteCommitS}(\AuthEmphPublicOld{i}, \NoteUniqueRandOld{i})$.) A similar error occurs in the argument for the ``$\Adversary$ violates Condition II'' case. @@ -12009,9 +12038,9 @@ distinct openings of the \noteCommitment when Condition I or II is violated. \begin{itemize} \item The paper defines a \note as $((\AuthPublic, \TransmitPublic), \Value, - \NoteAddressRand, \NoteCommitRand, \NoteCommitS, \cm)$, whereas this + \NoteUniqueRand, \NoteCommitRand, \NoteCommitS, \cm)$, whereas this specification defines \sprout{it}\notsprout{a \Sprout{} \note} as - $(\AuthPublic, \Value, \NoteAddressRand, \NoteCommitRand)$. + $(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$. The instantiation of $\Commit{\NoteCommitS}$ in section 5.1 of the paper did not actually use $\NoteCommitS$, and neither does the new instantiation of $\NoteCommit{Sprout}{}$ in \SproutOrZcash. $\TransmitPublic$ is also @@ -12976,7 +13005,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. of commitments being binding on $\ValueCommitType{Sapling}$. \item Fix the loss of tightness in the use of $\PRFnfSapling{}$ by specifying the keyspace more precisely. - \item Correct type ambiguities for $\NoteAddressRand$. + \item Correct type ambiguities for $\NoteUniqueRand$. \item Specify the representation of $i$ in group $\GroupG{2}$ of \BLSPairing. } %sapling \end{itemize} @@ -13288,8 +13317,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Explain a variation on the Faerie Gold attack and why it is prevented. \item Generalize the description of the InternalH attack to include finding - collisions on $(\AuthPublic, \NoteAddressRand)$ rather than just on - $\NoteAddressRand$. + collisions on $(\AuthPublic, \NoteUniqueRand)$ rather than just on + $\NoteUniqueRand$. \item Rename $\mathsf{enforce}_i$ to $\EnforceMerklePath{i}$. \end{itemize} @@ -14582,7 +14611,7 @@ In particular, \introlist \lsubsubsubsection{Mixing Pedersen hash}{cctmixinghash} -A mixing \xPedersenHash is used to compute $\NoteAddressRand$ from +A mixing \xPedersenHash is used to compute $\NoteUniqueRand$ from $\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as input a \xPedersenCommitment $P$, and hashes it with another input $x$. @@ -14906,14 +14935,14 @@ However, so $\cvOld{}$, $\cmOld{}$, $\AuthSignRandomizedPublic$, and $\DiversifiedTransmitPublic$ do not need to be explicitly checked to be on the curve. -In addition, $\NullifierKeyRepr$ and $\NoteAddressRandRepr$ used in +In addition, $\NullifierKeyRepr$ and $\NoteUniqueRandRepr$ used in \textbf{Nullifier integrity} are compressed representations of \jubjubCurve points. \todo{explain why these are implemented as \crossref{ccteddecompressvalidate} even though the statement spec doesn't explicitly say to do validation.} Therefore we have $\DiversifiedTransmitBase$, $\AuthSignPublic$, $\NullifierKey$, -and $\NoteAddressRand$ that need to be constrained to valid \jubjubCurve points as +and $\NoteUniqueRand$ that need to be constrained to valid \jubjubCurve points as described in \crossref{ccteddecompressvalidate}. \introsection @@ -15004,14 +15033,14 @@ Check & Implements & \heading{Cost} & Reference \\ inputize $\rt$ & & ? & \\ \hline - $\NoteAddressRand = \MixingPedersenHash(\cmOld{}, \NotePosition)$ + $\NoteUniqueRand = \MixingPedersenHash(\cmOld{}, \NotePosition)$ & \snarkref{Nullifier integrity}{spendnullifierintegrity} & 98 & \shortcrossref{cctmixinghash} \\ \cline{1-1}\cline{3-4} - $\NoteAddressRandRepr = \reprJ\Of{\NoteAddressRand}$ - \small\todo{spec doesn't say to validate $\NoteAddressRand$ since it's calculated} + $\NoteUniqueRandRepr = \reprJ\Of{\NoteUniqueRand}$ + \small\todo{spec doesn't say to validate $\NoteUniqueRand$ since it's calculated} & & 392 & \shortcrossref{ccteddecompressvalidate} \\ \cline{1-1}\cline{3-4} - $\nfOld{} = \PRFnfSapling{\NullifierKeyRepr}(\NoteAddressRandRepr)$ + $\nfOld{} = \PRFnfSapling{\NullifierKeyRepr}(\NoteUniqueRandRepr)$ & & 21006 & \shortcrossref{cctblake2s} \\ \hline \raggedright pack $\nfOld{\barerange{0}{253}}$ and $\nfOld{\barerange{254}{255}}$ into two $\GF{\ParamS{r}}$ inputs