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

Cleanup: remove duplicate macro \CommitIvkRandom in favour of \CommitIvkRand. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-04-28 18:44:58 +01:00
parent 0c53d8815f
commit dbd7339c3f
1 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
protocol/protocol.tex
View File

@ -1491,7 +1491,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\DiversifierKeyLength}{\mathsf{\ell_{\DiversifierKey}}}
\newcommand{\DiversifierKeyType}{\byteseq{\DiversifierKeyLength/8}}
\newcommand{\DiversifierIndex}{\mathsf{index}}
\newcommand{\CommitIvkRandom}{\mathsf{rivk}}
\newcommand{\FVK}{\mathsf{FVK}}
\newcommand{\DiversifiedTransmitBase}{\mathsf{g_d}}
\newcommand{\DiversifiedTransmitBaseRepr}{\mathsf{g\Repr_d}}
@ -5107,7 +5106,7 @@ The \diversifiedPaymentAddress with \diversifierIndex $0$ is called the \definin
usage in the context of hierarchical deterministic wallets.
\item Address generators \MAY encode information in the \diversifierIndex
that can be recovered by the recipient of a payment, given the \diversifierKey.
\item $\CommitIvkRandom$ is used both as a randomizer for $\CommitIvk{}$, and as a
\item $\CommitIvkRand$ is used both as a randomizer for $\CommitIvk{}$, and as a
key for $\PRFexpand{}$ to derive $\DiversifierKey$ and $\OutViewingKey$.
If $\DiversifierKey$ and $\OutViewingKey$ are known to an adversary, then
this reuse prevents proving that the use of $\CommitIvk{}$ in this context is
@ -7129,7 +7128,7 @@ $\AuthSignRandomizedPublic = \SpendAuthSigRandomizePublic{Orchard}(\AuthSignRand
\snarkcondition{Diversified address integrity}{actionaddressintegrity}
$\InViewingKey = \bot$ or $\DiversifiedTransmitPublicOld = \scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$ where
$\InViewingKey = \CommitIvk{\CommitIvkRandom}\big(\ExtractP(\AuthSignPublicPoint), \NullifierKey\big)$.
$\InViewingKey = \CommitIvk{\CommitIvkRand}\big(\ExtractP(\AuthSignPublicPoint), \NullifierKey\big)$.
\snarkcondition{New note commitment integrity}{actionnewnotecommitmentintegrity}
$\ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRandNew{}}(\reprP(\DiversifiedTransmitBaseNew),
@ -7191,7 +7190,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h
where the statement only requires to prove knowledge of the scalar, without using it
elsewhere --- i.e.\ the multiplications by $\NoteCommitRandOld{}$ or $\NoteCommitRandNew{}$
in $\NoteCommitAlg{Orchard}$, by $\ValueCommitRand$ in $\ValueCommitAlg{Orchard}$, by
$\CommitIvkRandom$ in $\CommitIvkAlg$, and by $\AuthSignRandomizer$ in
$\CommitIvkRand$ in $\CommitIvkAlg$, and by $\AuthSignRandomizer$ in
$\SpendAuthSigRandomizePublic{Orchard}$. In particular, the representation of
$(\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) + \NoteNullifierRand) \bmod \ParamP{q}$
that is used for the scalar multiplication in $\DeriveNullifierAlg$ \MUST be checked to be
@ -12062,12 +12061,12 @@ Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.
Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}.
An \Orchard{} \defining{\fullViewingKey} consists of $\AuthSignPublic \typecolon \AuthSignPublicTypeOrchard$,
$\NullifierKey \typecolon \NullifierKeyTypeOrchard$, and $\CommitIvkRandom \typecolon \GF{\ParamP{r}}$.
$\NullifierKey \typecolon \NullifierKeyTypeOrchard$, and $\CommitIvkRand \typecolon \GF{\ParamP{r}}$.
$\AuthSignPublic$ is the \authValidatingKey, a result of applying $\ExtractP$ to a
point on the \pallasCurve (see \crossref{pallasandvesta}). $\NullifierKey$ is the
\nullifierDerivingKey, a field element in $\NullifierKeyTypeOrchard$.
$\CommitIvkRandom$ is the \commitIvkRandomness, a field element in $\GF{\ParamP{r}}$.
$\CommitIvkRand$ is the \commitIvkRandomness, a field element in $\CommitIvkRandType$.
They are derived as described in \crossref{orchardkeycomponents}.
Let $\ItoLEOSP{}$ be as defined in \crossref{endian}.
@ -12080,7 +12079,7 @@ The \rawEncoding of an \Orchard \fullViewingKey consists of:
\begin{bytefield}[bitwidth=0.05em]{512}
\sbitbox{256}{$\ItoLEOSPOf{256}{\AuthSignPublic}$}
\sbitbox{256}{$\ItoLEOSPOf{256}{\NullifierKey}$}
\sbitbox{256}{$\ItoLEOSPOf{256}{\CommitIvkRandom}$}
\sbitbox{256}{$\ItoLEOSPOf{256}{\CommitIvkRand}$}
\end{bytefield}
\end{equation*}
@ -12088,13 +12087,13 @@ The \rawEncoding of an \Orchard \fullViewingKey consists of:
\begin{itemize}
\item $32$ bytes (little-endian) specifying $\AuthSignPublic$.
\item $32$ bytes (little-endian) specifying $\NullifierKey$.
\item $32$ bytes (little-endian) specifying $\CommitIvkRandom$.
\item $32$ bytes (little-endian) specifying $\CommitIvkRand$.
\end{itemize}
\introlist
\vspace{-1ex}
When decoding this representation, the key \MUST be considered invalid if $\AuthSignPublic$,
$\NullifierKey$, or $\CommitIvkRandom$ are not canonically encoded elements of their respective
$\NullifierKey$, or $\CommitIvkRand$ are not canonically encoded elements of their respective
fields, or if $\AuthSignPublic$ is not a valid \Pallas $x$-coordinate.
There is no \BechOptm encoding defined for an individual \Orchard \fullViewingKey;
@ -15108,7 +15107,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct and clarify \theoremref{thmsinsemillacr} and \theoremref{thmsinsemillaex}.
\item Clarify that a \dummyNote should be created if no real \Orchard \note is being
spent in an \actionTransfer.
\item Add a caveat in \crossref{orchardkeycomponents} about reuse of $\CommitIvkRandom$
\item Add a caveat in \crossref{orchardkeycomponents} about reuse of $\CommitIvkRand$
between $\PRFexpand{}$ and $\CommitIvk{}$.
\item Expand the set of ZIPs associated with \NUFive in \crossref{networkupgrades}, and
reference \cite{Zcash-Orchard} and \cite{Zcash-halo2} there.