zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Other fixes to the Orchard specification, including generation of dummy notes and output notes. 

fixes #465

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-03-26 18:18:25 +00:00
parent aa86282e16
commit 2f246ce24d
1 changed files with 121 additions and 83 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

204
protocol/protocol.tex
View File

@ -1611,6 +1611,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\NoteCommitRandOrSeedBytes}{\notcanopy{\NoteCommitRand}\canopy{\NoteSeedBytes}} \newcommand{\NoteCommitRandOrSeedBytes}{\notcanopy{\NoteCommitRand}\canopy{\NoteSeedBytes}}
\newcommand{\NoteCommitRandBytesOrSeedBytes}{\notcanopy{\NoteCommitRandBytes}\canopy{\NoteSeedBytes}} \newcommand{\NoteCommitRandBytesOrSeedBytes}{\notcanopy{\NoteCommitRandBytes}\canopy{\NoteSeedBytes}}
\newcommand{\NoteUniqueRand}{\mathsf{\uprho}} \newcommand{\NoteUniqueRand}{\mathsf{\uprho}}
\newcommand{\NoteUniqueRandPoint}{\NoteUniqueRand^{\GroupP}}
\newcommand{\NoteUniqueRandRepr}{{\NoteUniqueRand\Repr}} \newcommand{\NoteUniqueRandRepr}{{\NoteUniqueRand\Repr}}
\newcommand{\NoteUniqueRandOld}[1]{\NoteUniqueRand^\mathsf{old}_{#1}} \newcommand{\NoteUniqueRandOld}[1]{\NoteUniqueRand^\mathsf{old}_{#1}}
\newcommand{\NoteUniqueRandNew}[1]{\NoteUniqueRand^\mathsf{new}_{#1}} \newcommand{\NoteUniqueRandNew}[1]{\NoteUniqueRand^\mathsf{new}_{#1}}
@ -4330,7 +4331,7 @@ A \defining{\representedGroup} $\GroupG{}$ consists of:
\item a bit-length parameter $\ellG{} \typecolon \Nat$; \item a bit-length parameter $\ellG{} \typecolon \Nat$;
\item a representation function \smash{$\reprG{} \typecolon \GroupG{} \rightarrow \bitseq{\ellG{}}$} \item a representation function \smash{$\reprG{} \typecolon \GroupG{} \rightarrow \bitseq{\ellG{}}$}
and an abstraction function \smash{$\abstG{} \typecolon \bitseq{\ellG{}} \rightarrow \maybe{\GroupG{}}$}, and an abstraction function \smash{$\abstG{} \typecolon \bitseq{\ellG{}} \rightarrow \maybe{\GroupG{}}$},
such that $\abstG{}$ is the left inverse of $\reprG{}$, i.e. for all $P \in \GroupG{}$, such that $\abstG{}$ is a left inverse of $\reprG{}$, i.e. for all $P \in \GroupG{}$,
$\abstG{}\big(\reprG{}(P)\kern-0.1em\big) = P$. $\abstG{}\big(\reprG{}(P)\kern-0.1em\big) = P$.
\end{itemize} \end{itemize}
@ -4727,7 +4728,8 @@ For each \spendingKey, there is also a \defining{\defaultDiversifiedPaymentAddre
with a ``random-looking'' \diversifier. This allows an implementation that does not expose with a ``random-looking'' \diversifier. This allows an implementation that does not expose
diversified addresses as a user-visible feature, to use a default address that diversified addresses as a user-visible feature, to use a default address that
cannot be distinguished (without knowledge of the \spendingKey) from one with a random cannot be distinguished (without knowledge of the \spendingKey) from one with a random
\diversifier as above. \diversifier as above. Note however that the \zcashd wallet picks \diversifiers as in
\cite{ZIP-32}, rather than using this procedure.
\introlist \introlist
Let $\first \typecolon (\byte \rightarrow \maybe{T}) \rightarrow \maybe{T}$ Let $\first \typecolon (\byte \rightarrow \maybe{T}) \rightarrow \maybe{T}$
@ -4787,8 +4789,6 @@ if this happens, discard the key and repeat with a different $\SpendingKey$.
{\reprJ\big(\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}} \typecolon \SubgroupReprJ\big)$ {\reprJ\big(\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}} \typecolon \SubgroupReprJ\big)$
is bijective, the distribution of $\reprJ\Of{\NullifierKey}$ will be computationally is bijective, the distribution of $\reprJ\Of{\NullifierKey}$ will be computationally
indistinguishable from uniform on $\SubgroupReprJ$ (the keyspace of $\PRFnf{Sapling}{}$). indistinguishable from uniform on $\SubgroupReprJ$ (the keyspace of $\PRFnf{Sapling}{}$).
\item The \zcashd wallet picks \diversifiers as in \cite{ZIP-32}, rather than using the default
\diversifier specified above.
\end{nnotes} \end{nnotes}
\vspace{-2ex} \vspace{-2ex}
} %sapling } %sapling
@ -4893,26 +4893,27 @@ The resulting \diversifiedPaymentAddress is
$(\Diversifier \typecolon \DiversifierType, \DiversifiedTransmitPublic \typecolon \KAPublic{Orchard})$. $(\Diversifier \typecolon \DiversifierType, \DiversifiedTransmitPublic \typecolon \KAPublic{Orchard})$.
\vspace{1ex} \vspace{1ex}
For each \spendingKey, there is also a \defining{\defaultDiversifiedPaymentAddress} The \diversifiedPaymentAddress with \diversifierIndex $0$ is called the \defining{\defaultDiversifiedPaymentAddress}.
with a ``random-looking'' \diversifier, which is derived as specified in \cite{ZIP-32}.
\vspace{1ex} \vspace{1ex}
\begin{pnotes} \begin{pnotes}
\item The protocol does not prevent using the \diversifier $\Diversifier$ to produce \item The protocol does not prevent using the \diversifier $\Diversifier$ to produce
\quotedtermnoindex{vanity} addresses that start with a meaningful string when \quotedtermnoindex{vanity} addresses that start with or contain meaningful
encoded in \Bech (see \crossref{orchardpaymentaddrencoding}). strings when encoded in \Bechm (see \crossref{unifiedpaymentaddrencoding}).
Users and writers of software that generates addresses should be aware that Users and writers of software that generates addresses should be aware that
this provides weaker privacy properties than a randomly chosen \diversifier, this provides weaker privacy properties than a randomly chosen \diversifier,
since a vanity address can obviously be distinguished, and might leak more since a vanity address can obviously be distinguished, and might leak more
information than intended as to who created it. information than intended as to who created it.
\item Similarly, address generators \MAY encode information in the \diversifier \item Address generators \MAY encode information in the \diversifierIndex
that can be recovered by the recipient of a payment to determine which that can be recovered by the recipient of a payment, given the \diversifierKey.
\diversifiedPaymentAddress was used. It is \RECOMMENDED that such \diversifiers
be randomly chosen unique values used to index into a database, rather than
directly encoding the needed data.
\end{pnotes} \end{pnotes}
\todo{Security analysis of the uses of $\ToScalar{Orchard}$ and $\ToBase{Orchard}$.} \vspace{-2ex}
\nnote{
The uses of $\ToScalar{Orchard}$ and $\ToBase{Orchard}$ produce output that is
uniform on $\GF{\ParamP{r}}$ and $\GF{\ParamP{q}}$ respectively when applied to random
input, by a similar argument to that used in \crossref{saplingkeycomponents}.
} %nnote
} %nufive } %nufive
@ -5337,19 +5338,17 @@ with one or more \outputDescriptions.
Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as specified in \crossref{abstractcommit}. Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as specified in \crossref{abstractcommit}.
\vspace{-0.5ex} \vspace{-0.25ex}
Let $\KA{Sapling}$ be as specified in \crossref{abstractkeyagreement}. Let $\KA{Sapling}$ be as specified in \crossref{abstractkeyagreement}.
\vspace{-0.5ex} \vspace{-0.25ex}
Let $\DiversifyHash{Sapling}$ be as specified in \crossref{abstracthashes}. Let $\DiversifyHash{Sapling}$ be as specified in \crossref{abstracthashes}.
\vspace{-0.5ex} \vspace{-0.25ex}
Let $\ToScalar{Sapling}$ be as specified in \crossref{saplingkeycomponents}. Let $\ToScalar{Sapling}$ be as specified in \crossref{saplingkeycomponents}.
Let $\reprJ$ and $\ParamJ{r}$ be as defined in \crossref{jubjub}. Let $\reprJ$ and $\ParamJ{r}$ be as defined in \crossref{jubjub}.
Let $\ItoLEOSP{}$ be as defined in \crossref{endian}.
\vspace{1ex} \vspace{1ex}
\introlist \introlist
Let $\OutViewingKey$ be a \Sapling \outgoingViewingKey that is intended to be able to decrypt Let $\OutViewingKey$ be a \Sapling \outgoingViewingKey that is intended to be able to decrypt
@ -5430,57 +5429,67 @@ The encoded \transaction is submitted to the peer-to-peer network.
\nufive{ \nufive{
\vspace{-1ex}
\introlist \introlist
\lsubsubsection{Sending Notes (\OrchardText)}{orchardsend} \lsubsubsection{Sending Notes (\OrchardText)}{orchardsend}
\vspace{-1ex}
In order to send \Orchard \shielded value, the sender constructs a \transaction In order to send \Orchard \shielded value, the sender constructs a \transaction
with one or more \actionDescriptions. This section describes how to produce the with one or more \actionDescriptions. This section describes how to produce the
output-related fields of an \actionDescription. output-related fields of an \actionDescription.
\vspace{1ex} \vspace{0.5ex}
Let $\ValueCommitAlg{Orchard}$ and $\NoteCommitAlg{Orchard}$ be as specified in \crossref{abstractcommit}. Let $\ValueCommitAlg{Orchard}$ and $\NoteCommitAlg{Orchard}$ be as specified in \crossref{abstractcommit}.
\vspace{-0.25ex}
Let $\PRFexpand{}$ be as specified in \crossref{abstractprfs}. Let $\PRFexpand{}$ be as specified in \crossref{abstractprfs}.
\vspace{-0.25ex}
Let $\KA{Orchard}$ be as specified in \crossref{abstractkeyagreement}. Let $\KA{Orchard}$ be as specified in \crossref{abstractkeyagreement}.
\vspace{-0.25ex}
Let $\DiversifyHash{Orchard}$ be as specified in \crossref{abstracthashes}. Let $\DiversifyHash{Orchard}$ be as specified in \crossref{abstracthashes}.
\vspace{-0.25ex}
Let $\ToScalar{Orchard}$ and $\ToBase{Orchard}$ be as specified in \crossref{orchardkeycomponents}. Let $\ToScalar{Orchard}$ and $\ToBase{Orchard}$ be as specified in \crossref{orchardkeycomponents}.
\vspace{-0.25ex}
Let $\reprP$ and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. Let $\reprP$ and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}.
Let $\ItoLEOSP{}$ be as defined in \crossref{endian}. Let $\ExtractPbot$ be as defined in \crossref{concreteextractorpallas}.
\vspace{1ex} \vspace{0.5ex}
Let $\OutViewingKey$ be an \Orchard \outgoingViewingKey that is intended to be able to decrypt Let $\OutViewingKey$ be an \Orchard \outgoingViewingKey that is intended to be able to decrypt
this payment. The considerations for choosing \outgoingViewingKeys are as described for \Sapling this payment. The considerations for choosing \outgoingViewingKeys are as described for \Sapling
in \crossref{saplingsend}. in \crossref{saplingsend}.
Let $\NotePlaintextLeadByte$ be the \notePlaintextLeadByte, which \MUST be $\hexint{02}$. Let $\NotePlaintextLeadByte$ be the \notePlaintextLeadByte, which \MUST be $\hexint{02}$.
\introlist \vspace{0.5ex}
For each \actionDescription, the sender selects a value $\Value \typecolon \range{0}{\MAXMONEY}$ For each \actionDescription, the sender selects a value $\Value \typecolon \range{0}{\MAXMONEY}$
and a destination \Orchard \shieldedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, and a destination \Orchard \shieldedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, and
and then performs the following steps: performs the following steps:
\begin{algorithm} \begin{algorithm}
\vspace{-0.25ex}
\item Check that $\DiversifiedTransmitPublic$ is of type $\KAPublic{Orchard}$, i.e.\ it \item Check that $\DiversifiedTransmitPublic$ is of type $\KAPublic{Orchard}$, i.e.\ it
\MUST be a valid \swCurve point on the \pallasCurve (as defined in \crossref{pallasandvesta}). \MUST be a valid \swCurve point on the \pallasCurve (as defined in \crossref{pallasandvesta}).
\item Calculate $\DiversifiedTransmitBase = \DiversifyHash{Orchard}(\Diversifier)$. \item Calculate $\DiversifiedTransmitBase = \DiversifyHash{Orchard}(\Diversifier)$.
\item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Orchard}()$.
\vspace{-0.25ex} \vspace{-0.25ex}
\item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Orchard}()$.
\item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$. \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$.
\item Derive $\EphemeralPrivate = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$. \item Derive $\EphemeralPrivate = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$.
\item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$. \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$.
\item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$. \item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$.
\item Let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. \item Let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription.
\item Let $\cv = \ValueCommit{Orchard}{\ValueCommitRand}(\Value)$. \item Let $\cvNet{}$ be the \valueCommitment to the value of the input \note minus the value $\Value$
\item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, of the output \note for this \actionTransfer, using $\ValueCommitRand$, as described in \crossref{orchardbalance}.
\reprP\Of{\DiversifiedTransmitPublic}, \vspace{-0.25ex}
\Value, \NoteUniqueRand, \NoteNullifierRand)$. \item Let $\cmX = \ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase},
\vspace{0.25ex} \reprP\Of{\DiversifiedTransmitPublic},
\item If $\cm = \bot$, return $\bot$. \Value, \NoteUniqueRand, \NoteNullifierRand)\kern-0.1em\big)$.
\vspace{0.2ex}
\item If $\cmX = \bot$, return $\bot$.
\item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteSeedBytes, \Memo)$. \item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteSeedBytes, \Memo)$.
\vspace{0.25ex} \vspace{0.25ex}
\item Encrypt $\NotePlaintext{}$ to the recipient \item Encrypt $\NotePlaintext{}$ to the recipient
@ -5488,11 +5497,12 @@ and then performs the following steps:
\diversifiedBase $\DiversifiedTransmitBase$, and to the \diversifiedBase $\DiversifiedTransmitBase$, and to the
\outgoingViewingKey $\OutViewingKey$, giving the \noteCiphertextOrchard \outgoingViewingKey $\OutViewingKey$, giving the \noteCiphertextOrchard
$(\EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext)$. $(\EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext)$.
This procedure is described in \crossref{saplingandorchardencrypt}; it also uses This procedure is described in \crossref{saplingandorchardencrypt}; it uses
$\cvField$ and $\cmxField$ to derive $\OutCipherKey$, and takes $\cvNet{}$ and $\cmX$ to derive $\OutCipherKey$, and takes
$\EphemeralPrivate$ as input. $\EphemeralPrivate$ as input.
\item Generate a proof $\Proof{}$ for the \actionStatement in \crossref{actionstatement}. \item Fill in the spending side of the \actionTransfer (\crossref{spendauthsig}),
\item Return $(\cv, \cm, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \Proof{})$. and generate a proof $\Proof{}$ for the \actionStatement in \crossref{actionstatement}.
\item Return $(\cv, \cmX, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \Proof{})$.
\end{algorithm} \end{algorithm}
\vspace{-1ex} \vspace{-1ex}
@ -5643,7 +5653,8 @@ constructed as follows:
\item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$. \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$.
\item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$. \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$.
\item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$. \item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$.
\item Let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. \item Choose uniformly random $\NoteUniqueRandPoint \leftarrowR \GroupP$.
\item Let $\NoteUniqueRand = \ExtractP(\NoteUniqueRandPoint)$.
\item Let $\cv = \ValueCommit{Orchard}{\ValueCommitRand}(\Value)$. \item Let $\cv = \ValueCommit{Orchard}{\ValueCommitRand}(\Value)$.
\item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}\big(\reprP\Of{\DiversifiedTransmitBase}, \item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}\big(\reprP\Of{\DiversifiedTransmitBase},
\reprP\Of{\DiversifiedTransmitPublic}, \reprP\Of{\DiversifiedTransmitPublic},
@ -6280,24 +6291,27 @@ both.}
Knowledge of the \spendingKey could have been proven directly in the \spendStatement\nufive{ or Knowledge of the \spendingKey could have been proven directly in the \spendStatement\nufive{ or
\actionStatement}, similar to the check in \crossref{sproutspendauthority} that is part of the \actionStatement}, similar to the check in \crossref{sproutspendauthority} that is part of the
\joinSplitStatement. The motivation for a separate signature is to allow devices that are limited in \joinSplitStatement. The motivation for a separate signature is to allow devices that are limited in
memory and computational capacity, such as hardware wallets, to authorize a \Sapling shielded Spend. memory and computational capacity, such as hardware wallets, to authorize a \SaplingOrOrchard
Typically such devices cannot create, and may not be able to verify, \zkSNARKProofs for shielded Spend. Typically such devices cannot create, and may not be able to verify, \zkSNARKProofs
a \statement of the size needed using the \BCTV or \Groth proving systems. for a \statement of the size needed using the \BCTV\notnufive{ or \Groth}\notbeforenufive{,
\Groth\nufive{, or \HaloTwo}} proving systems.
\vspace{1ex} \vspace{1ex}
The \validatingKey of the signature must be revealed in the \spendDescription so that The \validatingKey of the signature must be revealed in the \spendDescription so that the
the signature can be checked by validators. To ensure that the \validatingKey cannot signature can be checked by validators. To ensure that the \validatingKey cannot be linked
be linked to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we use a
use a \rerandomizableSignatureScheme. The \spendStatement proves that this \validatingKey \rerandomizableSignatureScheme. The \spendStatement\nufive{ or \actionStatement} proves that
is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ with a \randomizer this \validatingKey is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$
known to the signer. The \defining{\spendAuthSignature} is over the \sighashTxHash, so that it cannot be with a \randomizer known to the signer. The \defining{\spendAuthSignature} is over the
replayed in other \transactions. \sighashTxHash, so that it cannot be replayed in other \transactions.
\vspace{2ex} \vspace{2ex}
Let $\SigHash$ be the \sighashTxHash as defined in \cite{ZIP-243}, not associated with an input, Let $\SigHash$ be the \sighashTxHash as defined in \cite{ZIP-243}\nufive{ or as defined in
using the \sighashType $\SIGHASHALL$. \cite{ZIP-244} modified by \cite{ZIP-225}}, not associated with an input, using the
\sighashType $\SIGHASHALL$.
Let $\AuthSignPrivate$ be the \defining{\spendAuthPrivateKey} as defined in \crossref{saplingkeycomponents}. Let $\AuthSignPrivate$ be the \defining{\spendAuthPrivateKey} as defined in
\crossref{saplingkeycomponents}\nufive{ or in \crossref{orchardkeycomponents}}.
\notbeforenufive{ \notbeforenufive{
Let $\SpendAuthSig{}$ be $\SpendAuthSig{Sapling}$\nufive{ or $\SpendAuthSig{Orchard}$ as applicable}. Let $\SpendAuthSig{}$ be $\SpendAuthSig{Sapling}$\nufive{ or $\SpendAuthSig{Orchard}$ as applicable}.
@ -6305,7 +6319,8 @@ Let $\SpendAuthSig{}$ be $\SpendAuthSig{Sapling}$\nufive{ or $\SpendAuthSig{Orch
\introsection \introsection
\vspace{2ex} \vspace{2ex}
For each \spendDescription, the signer chooses a fresh \defining{\spendAuthRandomizer} $\AuthSignRandomizer$: For each \spendDescription\nufive{ or \actionDescription}, the signer chooses a fresh
\defining{\spendAuthRandomizer} $\AuthSignRandomizer$:
\begin{enumerate} \begin{enumerate}
\item Choose $\AuthSignRandomizer \leftarrowR \SpendAuthSigGenRandom{\maybeSapling}()$. \item Choose $\AuthSignRandomizer \leftarrowR \SpendAuthSigGenRandom{\maybeSapling}()$.
@ -6384,10 +6399,16 @@ $\NoteUniqueRandRepr = \reprJ(\NoteUniqueRand)$.
\nufive{ \nufive{
The derivation of \nullifiers for \Orchard \notes is a little more complicated. The derivation of \nullifiers for \Orchard \notes is a little more complicated.
Let $\GroupP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.
Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}.
Let $\GroupPHash$ be as defined in \crossref{concretegrouphashpallasandvesta}.
Define $\NullifierBaseOrchard := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{K}}\,$. Define $\NullifierBaseOrchard := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{K}}\,$.
To avoid repetition, we define a function $\DeriveNullifierAlg \typecolon To avoid repetition, we define a function $\DeriveNullifierAlg \typecolon
\NullifierKeyTypeOrchard \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \GroupP$ \NullifierKeyTypeOrchard \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \GroupP \rightarrow \GF{\ParamP{q}}$
as follows: as follows:
\begin{formulae} \begin{formulae}
@ -7015,9 +7036,10 @@ engineering rationale behind this encryption scheme.
\extralabel{saplinginband}{\lsubsection{In-band secret distribution (\SaplingAndOrchardText)}{saplingandorchardinband}} \extralabel{saplinginband}{\lsubsection{In-band secret distribution (\SaplingAndOrchardText)}{saplingandorchardinband}}
\vspace{-1ex} \vspace{-1ex}
In \SaplingAndOrchard, the secrets that need to be transmitted to a recipient of funds In \SaplingAndOrchard, the secrets that need to be transmitted to a recipient
in order for them to later spend, are $\Diversifier$, $\Value$, and $\NoteCommitRand$. of a \note so that they can later spend it, are $\Diversifier$, $\Value$, and
A \memo (\crossref{noteptconcept}) is also transmitted. $\NoteCommitRand$\canopy{ or $\NoteSeedBytes$}. A \memo (\crossref{noteptconcept})
is also transmitted.
To transmit these secrets securely to a recipient \emph{without} requiring To transmit these secrets securely to a recipient \emph{without} requiring
an out-of-band communication channel, the \diversifiedTransmissionKey an out-of-band communication channel, the \diversifiedTransmissionKey
@ -7025,8 +7047,7 @@ $\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's
possession of the associated \incomingViewingKey $\InViewingKey$ is used to possession of the associated \incomingViewingKey $\InViewingKey$ is used to
reconstruct the original \note and \memo. reconstruct the original \note and \memo.
Unlike in a \Sprout \joinSplitDescription, each \SaplingOrOrchard \shieldedOutput Unlike in \Sprout, each \SaplingOrOrchard \shieldedOutput is encrypted by a fresh \ephemeralPublicKey.
is encrypted by a fresh \ephemeralPublicKey.
\vspace{0.5ex} \vspace{0.5ex}
\introlist \introlist
@ -7088,12 +7109,12 @@ spent, or an \outgoingViewingKey associated with a \cite{ZIP-32} account, or $\b
Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$ Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$
be the \SaplingOrOrchard \notePlaintext. be the \SaplingOrOrchard \notePlaintext.
$\NotePlaintext{}$ is encoded as defined in \crossref{notept}. $\NotePlaintext{}$ is encoded as defined in \crossref{notept}.
Let $\cv$ be the \valueCommitment for the new \note, and let $\cm$ be the \noteCommitment. Let $\cv$ be the \valueCommitment for the \outputDescription\nufive{ or \actionDescription (for \Orchard,
(These are needed to derive the \defining{\outgoingCipherKey} $\OutCipherKey$ in order to produce the this also depends on the value of the \note being spent)}, and let $\cm$ be the \noteCommitment.
\defining{\outgoingCiphertext} $\OutCiphertext$.) These are needed to derive the \defining{\outgoingCipherKey} $\OutCipherKey$ in order to produce the
\defining{\outgoingCiphertext} $\OutCiphertext$.
\introlist \introlist
\vspace{1ex} \vspace{1ex}
@ -7159,6 +7180,7 @@ $u$-coordinate\nufive{ or $x$-coordinate} of the \noteCommitment, i.e.\ $\Extrac
\vspace{-0.25ex} \vspace{-0.25ex}
Let the constant $\CanopyActivationHeight$ be as defined in \crossref{constants}. Let the constant $\CanopyActivationHeight$ be as defined in \crossref{constants}.
\vspace{-0.25ex}
Let $\BlockHeight$ be the \blockHeight of the \block containing this \transaction. Let $\BlockHeight$ be the \blockHeight of the \block containing this \transaction.
} %canopy } %canopy
@ -7760,7 +7782,7 @@ $\BlakeTwobGeneric$ is used to instantiate $\hSigCRH$, $\EquihashGen{}$,
and $\KDF{Sprout}$. and $\KDF{Sprout}$.
\overwinter{From \Overwinter onward, it is used to compute \sighashTxHashes \overwinter{From \Overwinter onward, it is used to compute \sighashTxHashes
as specified in \cite{ZIP-143}\sapling{, or as in \cite{ZIP-243} after as specified in \cite{ZIP-143}\sapling{, or as in \cite{ZIP-243} after
\Sapling activation}.} \Sapling activation}\nufive{, or as in \cite{ZIP-244} for version 5 \transactions}.}
\sapling{For \Sapling, it is also used to instantiate $\PRFexpand{}$, \sapling{For \Sapling, it is also used to instantiate $\PRFexpand{}$,
$\PRFock{Sapling}{}$, $\KDF{Sapling}$, and in the $\RedJubjub$ \signatureScheme $\PRFock{Sapling}{}$, $\KDF{Sapling}$, and in the $\RedJubjub$ \signatureScheme
which instantiates $\SpendAuthSig{Sapling}$ and $\BindingSig{Sapling}$.} which instantiates $\SpendAuthSig{Sapling}$ and $\BindingSig{Sapling}$.}
@ -9680,7 +9702,9 @@ The windowed Pedersen commitments defined in the preceding section are
highly efficient, but they do not support the homomorphic property we highly efficient, but they do not support the homomorphic property we
need when instantiating $\ValueCommitAlg{}$. need when instantiating $\ValueCommitAlg{}$.
For more details on the use of this property, see \crossref{saplingbalance}\nufive{, \crossref{orchardbalance},} and \crossref{spendsandoutputs}. For more details on the use of this property, see \crossref{saplingbalance}\nufive{ and \crossref{orchardbalance}}.
Useful background is given in \crossref{spendsandoutputs}\nufive{ and \crossref{actions}}.
\defining{In order to support this property, we also define \homomorphicPedersenCommitments for \Sapling:} \defining{In order to support this property, we also define \homomorphicPedersenCommitments for \Sapling:}
@ -10339,13 +10363,6 @@ $\ExtractJ$ is injective on $\SubgroupJ$.
\lsubsubsubsection{Group Hash into \JubjubText}{concretegrouphashjubjub} \lsubsubsubsection{Group Hash into \JubjubText}{concretegrouphashjubjub}
\vspace{-1ex} \vspace{-1ex}
Let $\GroupJHashInput := \byteseq{8} \times \byteseqs$, and
let $\GroupJHashURSType := \byteseq{64}$.
(The input element with type $\byteseq{8}$ is intended to act as a
``personalization'' parameter to distinguish uses of the \groupHash for
different purposes.)
Let $\URS$ be the MPC randomness beacon defined in \crossref{beacon}. Let $\URS$ be the MPC randomness beacon defined in \crossref{beacon}.
\vspace{-0.25ex} \vspace{-0.25ex}
@ -10357,6 +10374,13 @@ Let $\LEOStoIP{}$ be as defined in \crossref{endian}.
\vspace{-0.25ex} \vspace{-0.25ex}
Let $\SubgroupJ$, $\SubgroupJstar$, and $\abstJ$ be as defined in \crossref{jubjub}. Let $\SubgroupJ$, $\SubgroupJstar$, and $\abstJ$ be as defined in \crossref{jubjub}.
Let $\GroupJHashInput := \byteseq{8} \times \byteseqs$, and
let $\GroupJHashURSType := \byteseq{64}$.
(The input element with type $\byteseq{8}$ is intended to act as a
``personalization'' parameter to distinguish uses of the \groupHash for
different purposes.)
Let $D \typecolon \byteseq{8}$ be an $8$-byte domain separator, and Let $D \typecolon \byteseq{8}$ be an $8$-byte domain separator, and
let $M \typecolon \byteseqs$ be the hash input. let $M \typecolon \byteseqs$ be the hash input.
@ -11073,12 +11097,11 @@ instead of \BaseFiftyEightCheck.
\nnote{ZIP 173 is similar to \Bitcoin's BIP 173, except for dropping the limit of \nnote{ZIP 173 is similar to \Bitcoin's BIP 173, except for dropping the limit of
90 characters on an encoded \Bech string (which does not hold for \Sapling viewing keys, 90 characters on an encoded \Bech string (which does not hold for \Sapling viewing keys,
for example), and requirements specific to Bitcoin's Segwit addresses.} for example), and requirements specific to Bitcoin's Segwit addresses.}
} %sapling
\nufive{ \nufive{
\vspace{1ex} \vspace{1ex}
\Orchard introduces a new address format called a \unifiedPaymentAddress. This can \Orchard introduces a new address format called a \defining{\unifiedPaymentAddress}.
encode an \Orchard address, but also a \Sapling address, a \transparentAddress, This can encode an \Orchard address, but also a \Sapling address, a \transparentAddress,
and potentially future address formats, all in the same \unifiedPaymentAddress. and potentially future address formats, all in the same \unifiedPaymentAddress.
It is \RECOMMENDED to use \unifiedPaymentAddresses for all new applications, unless It is \RECOMMENDED to use \unifiedPaymentAddresses for all new applications, unless
compatibility with software that only accepts previous address formats is required. compatibility with software that only accepts previous address formats is required.
@ -11767,8 +11790,10 @@ A fifth upgrade, called \defining{\Canopy}, activated on \Mainnet on 18~November
at \blockHeight $1046400$ (coinciding with the first \blockSubsidy \halving) at \blockHeight $1046400$ (coinciding with the first \blockSubsidy \halving)
\cite{Zcash-Canopy} \cite{ZIP-251}. \cite{Zcash-Canopy} \cite{ZIP-251}.
\nufive{
This draft specification describes a set of changes codenamed \NUFive, which are This draft specification describes a set of changes codenamed \NUFive, which are
proposed to activate in a future \networkUpgrade. proposed to activate in a future \networkUpgrade.
} %nufive
This section summarizes the strategy for upgrading from \Sprout to subsequent versions This section summarizes the strategy for upgrading from \Sprout to subsequent versions
of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, and \Canopy), and for of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, and \Canopy), and for
@ -12256,11 +12281,6 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B
a corresponding standard rule but no consensus rule. a corresponding standard rule but no consensus rule.
\end{itemize} \end{itemize}
\preoverwinter{
Software that creates \transactions \SHOULD use version 1 for \transactions with no
\joinSplitDescriptions.
}
\introsection \introsection
\extralabel{joinsplitencoding}{\lsubsection{JoinSplit Description Encoding and Consensus}{joinsplitencodingandconsensus}} \extralabel{joinsplitencoding}{\lsubsection{JoinSplit Description Encoding and Consensus}{joinsplitencodingandconsensus}}
@ -12333,8 +12353,15 @@ Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.
Let $\reprJ$ and $\ParamJ{q}$ be as defined in \crossref{jubjub}. Let $\reprJ$ and $\ParamJ{q}$ be as defined in \crossref{jubjub}.
\vspace{-0.5ex} \vspace{-0.5ex}
Let $\spendAuthSig$ be the \spendAuthSignature for this \spendTransfer, and let $\ProofSpend$ be the
\zkSNARKProof of the corresponding \spendStatement. In a version 4 \transaction these are encoded in
the $\spendAuthSigField$ field and $\zkproof$ field respectively of the \spendDescription.\nufive{ In
a version 5 \transaction, \spendAuthSignatures in $\vSpendAuthSigs{Sapling}$ and proofs in
$\vSpendProofsSapling$ are in one-to-one correspondence with \spendDescriptions in $\vSpendsSapling$.}
\introsection
An abstract \spendDescription, as described in \crossref{spendsandoutputs}, is encoded in An abstract \spendDescription, as described in \crossref{spendsandoutputs}, is encoded in
a \transaction as an instance of a \type{SpendDescription} type as follows: a \transaction as an instance of a \type{SpendDescriptionV4}\nufive{ or \type{SpendDecriptionV5}} type:
\vspace{-1.5ex} \vspace{-1.5ex}
\begin{center} \begin{center}
@ -12354,7 +12381,7 @@ $32$ & $\nullifierField$ & \type{byte[32]} &
The \nullifier of the input \note, $\nf$. \\ \hline The \nullifier of the input \note, $\nf$. \\ \hline
$32$ & $\rkField$ & \type{byte[32]} & $32$ & $\rkField$ & \type{byte[32]} &
The randomized \validatingKey for $\spendAuthSigField$, $\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline The randomized \validatingKey for $\spendAuthSig$, $\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline
$192\nufive{\;\dagger}$ & $\zkproof$ & \type{byte[192]} & $192\nufive{\;\dagger}$ & $\zkproof$ & \type{byte[192]} &
An encoding of the \zkSNARKProof $\ProofSpend$ (see \crossref{groth}). \\ \hline An encoding of the \zkSNARKProof $\ProofSpend$ (see \crossref{groth}). \\ \hline
@ -12386,9 +12413,13 @@ Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.
\vspace{-0.5ex} \vspace{-0.5ex}
Let $\reprJ$ and $\ParamJ{q}$ be as in \crossref{jubjub}, and $\ExtractJ$ as in \crossref{concreteextractorjubjub}. Let $\reprJ$ and $\ParamJ{q}$ be as in \crossref{jubjub}, and $\ExtractJ$ as in \crossref{concreteextractorjubjub}.
Let $\ProofOutput$ be the \zkSNARKProof of the \outputStatement for this \outputStatement. In a version 4
\transaction this is encoded in the $\zkproof$ field of the \spendDescription.\nufive{ In a v5 \transaction,
proofs in $\vOutputProofsSapling$ are in one-to-one correspondence with \outputDescriptions in $\vOutputsSapling$.}
\vspace{-0.5ex} \vspace{-0.5ex}
An abstract \outputDescription, described in \crossref{spendsandoutputs}, is encoded in An abstract \outputDescription, described in \crossref{spendsandoutputs}, is encoded in
a \transaction as an instance of an \type{OutputDescription} type as follows: a \transaction as an instance of an \type{OutputDescriptionV4}\nufive{ or \type{OutputDecriptionV5}} type:
\vspace{-2.5ex} \vspace{-2.5ex}
\begin{center} \begin{center}
@ -12444,6 +12475,12 @@ Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.
Let $\reprP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. Let $\reprP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.
\vspace{-0.5ex} \vspace{-0.5ex}
Let $\spendAuthSig$ be the \spendAuthSignature for this \actionTransfer from $\vSpendAuthSigs{Orchard}$,
and let $\ProofAction$ be the \zkSNARKProof of the corresponding \actionStatement. \xSpendAuthSignatures
in the $\vSpendAuthSigs{Orchard}$ field of a version 5 \transaction and aggregated proofs in the
$\proofsOrchard$ field are in one-to-one correspondence with \actionDescriptions in $\vActionsOrchard$.
\vspace{0.5ex}
An abstract \actionDescription, as described in \crossref{actions}, is encoded in An abstract \actionDescription, as described in \crossref{actions}, is encoded in
a \transaction as an instance of an \type{ActionDescription} type: a \transaction as an instance of an \type{ActionDescription} type:
@ -12460,7 +12497,7 @@ minus the output \note, $\LEBStoOSP{256}\big(\reprP\Of{\cv}\kern-0.1em\big)$. \\
$32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline
$32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSigField$, $32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSig$,
$\LEBStoOSP{256}\big(\reprP\Of{\AuthSignRandomizedPublic}\kern-0.1em\big)$. \\ \hline $\LEBStoOSP{256}\big(\reprP\Of{\AuthSignRandomizedPublic}\kern-0.1em\big)$. \\ \hline
$32$ & $\cmxField$ & \type{byte[32]} & The $x$-coordinate of the \noteCommitment for the output \note, $32$ & $\cmxField$ & \type{byte[32]} & The $x$-coordinate of the \noteCommitment for the output \note,
@ -13974,7 +14011,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\lsection{Change History}{changehistory} \lsection{Change History}{changehistory}
\historyentry{2021.1.20}{2021-03-23} \historyentry{2021.1.20}{2021-03-25}
\begin{itemize} \begin{itemize}
\item Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, \item Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller,
Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart,
@ -14030,6 +14067,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}.
\item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}.
\item Various rationale updates for \NUFive. \item Various rationale updates for \NUFive.
\item Other fixes to the \Orchard specification, including generation of \dummyNotes and output \notes.
} %nufive } %nufive
\sapling{ \sapling{
\item Describe the recommended way to encode a \Sapling\nufive{ or unified} \paymentAddress \item Describe the recommended way to encode a \Sapling\nufive{ or unified} \paymentAddress