mirror of https://github.com/zcash/zips.git
Make the notation for sampling from randomized algorithms more explicit.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
dbfba45abf
commit
ccd8cdb5b1
|
@ -325,6 +325,7 @@
|
||||||
\newcommand{\xor}{\oplus}
|
\newcommand{\xor}{\oplus}
|
||||||
\newcommand{\mult}{\cdot}
|
\newcommand{\mult}{\cdot}
|
||||||
\newcommand{\rightarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\rightarrow}
|
\newcommand{\rightarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\rightarrow}
|
||||||
|
\newcommand{\leftarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\leftarrow}
|
||||||
|
|
||||||
% key pairs:
|
% key pairs:
|
||||||
\newcommand{\PaymentAddress}{\mathsf{addr_{pk}}}
|
\newcommand{\PaymentAddress}{\mathsf{addr_{pk}}}
|
||||||
|
@ -783,10 +784,14 @@ means the set of positive integers. $\Rat$ means the set of rationals.
|
||||||
|
|
||||||
The notation $x \typecolon T$ is used to specify that $x$ has type $T$.
|
The notation $x \typecolon T$ is used to specify that $x$ has type $T$.
|
||||||
A cartesian product type is denoted by $S \times T$, and a function type
|
A cartesian product type is denoted by $S \times T$, and a function type
|
||||||
by $S \rightarrow T$. The type of a randomized algorithm is denoted by $S \rightarrowR T$.
|
by $S \rightarrow T$. An argument to a function can determine other argument
|
||||||
|
or result types.
|
||||||
|
|
||||||
|
The type of a randomized algorithm is denoted by $S \rightarrowR T$.
|
||||||
The domain of a randomized algorithm may be $()$, indicating that it requires
|
The domain of a randomized algorithm may be $()$, indicating that it requires
|
||||||
no arguments. An argument to a function can determine other argument or result
|
no arguments. Given $f \typecolon S \rightarrowR T$ and $s \typecolon S$,
|
||||||
types.
|
sampling a variable $x \typecolon T$ from the output of $f$ applied to $s$
|
||||||
|
is denoted by $x \leftarrowR f(s)$.
|
||||||
|
|
||||||
Initial arguments to a function or randomized algorithm may be
|
Initial arguments to a function or randomized algorithm may be
|
||||||
written as subscripts, e.g.\ if $x \typecolon X$, $y \typecolon Y$, and
|
written as subscripts, e.g.\ if $x \typecolon X$, $y \typecolon Y$, and
|
||||||
|
@ -1271,8 +1276,8 @@ A signature scheme $\Sig$ defines:
|
||||||
\item a verifying algorithm $\SigVerify{} \typecolon \SigPublic \times \SigMessage \times \SigSignature \rightarrow \bit$;
|
\item a verifying algorithm $\SigVerify{} \typecolon \SigPublic \times \SigMessage \times \SigSignature \rightarrow \bit$;
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
such that for any key pair $(\sk, \vk) \leftarrow \SigGen()$, and
|
such that for any key pair $(\sk, \vk) \leftarrowR \SigGen()$, and
|
||||||
any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrow \SigSign{\sk}(m)$,
|
any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrowR \SigSign{\sk}(m)$,
|
||||||
$\SigVerify{\vk}(m, s) = 1$.
|
$\SigVerify{\vk}(m, s) = 1$.
|
||||||
|
|
||||||
\Zcash uses two signature schemes, one used for signatures that can be verified
|
\Zcash uses two signature schemes, one used for signatures that can be verified
|
||||||
|
@ -1351,7 +1356,7 @@ the \statement;
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
The security requirements below are supposed to hold with overwhelming
|
The security requirements below are supposed to hold with overwhelming
|
||||||
probability for $(\pk, \vk) \leftarrow \ZKGen()$.
|
probability for $(\pk, \vk) \leftarrowR \ZKGen()$.
|
||||||
|
|
||||||
\begin{securityrequirements}
|
\begin{securityrequirements}
|
||||||
\item \textbf{Completeness:} An honestly generated proof will convince a verifier:
|
\item \textbf{Completeness:} An honestly generated proof will convince a verifier:
|
||||||
|
@ -1473,7 +1478,7 @@ In order to send \xprotected value, the sender constructs a \transaction
|
||||||
containing one or more \joinSplitDescriptions. This involves first generating
|
containing one or more \joinSplitDescriptions. This involves first generating
|
||||||
a new $\JoinSplitSig$ key pair:
|
a new $\JoinSplitSig$ key pair:
|
||||||
|
|
||||||
\hskip 1.5em $(\joinSplitPrivKey, \joinSplitPubKey) \leftarrow \JoinSplitSigGen()$.
|
\hskip 1.5em $(\joinSplitPrivKey, \joinSplitPubKey) \leftarrowR \JoinSplitSigGen()$.
|
||||||
|
|
||||||
For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at
|
For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at
|
||||||
random on $\bitseq{\RandomSeedLength}$, and selects
|
random on $\bitseq{\RandomSeedLength}$, and selects
|
||||||
|
@ -1498,7 +1503,7 @@ After generating all of the \joinSplitDescriptions, the sender obtains the
|
||||||
$\dataToBeSigned$ (\crossref{nonmalleability}), and signs it with
|
$\dataToBeSigned$ (\crossref{nonmalleability}), and signs it with
|
||||||
the private \joinSplitSigningKey:
|
the private \joinSplitSigningKey:
|
||||||
|
|
||||||
\hskip 1.5em $\joinSplitSig \leftarrow \JoinSplitSigSign{\text{\small\joinSplitPrivKey}}(\dataToBeSigned)$
|
\hskip 1.5em $\joinSplitSig \leftarrowR \JoinSplitSigSign{\text{\small\joinSplitPrivKey}}(\dataToBeSigned)$
|
||||||
|
|
||||||
Then the encoded \transaction including $\joinSplitSig$ is submitted to the network.
|
Then the encoded \transaction including $\joinSplitSig$ is submitted to the network.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue