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{\mult}{\cdot}
|
||||
\newcommand{\rightarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\rightarrow}
|
||||
\newcommand{\leftarrowR}{\buildrel{\scriptstyle\mathrm{R}}\over\leftarrow}
|
||||
|
||||
% key pairs:
|
||||
\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$.
|
||||
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
|
||||
no arguments. An argument to a function can determine other argument or result
|
||||
types.
|
||||
no arguments. Given $f \typecolon S \rightarrowR T$ and $s \typecolon S$,
|
||||
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
|
||||
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$;
|
||||
\end{itemize}
|
||||
|
||||
such that for any key pair $(\sk, \vk) \leftarrow \SigGen()$, and
|
||||
any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrow \SigSign{\sk}(m)$,
|
||||
such that for any key pair $(\sk, \vk) \leftarrowR \SigGen()$, and
|
||||
any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrowR \SigSign{\sk}(m)$,
|
||||
$\SigVerify{\vk}(m, s) = 1$.
|
||||
|
||||
\Zcash uses two signature schemes, one used for signatures that can be verified
|
||||
|
@ -1351,7 +1356,7 @@ the \statement;
|
|||
\end{itemize}
|
||||
|
||||
The security requirements below are supposed to hold with overwhelming
|
||||
probability for $(\pk, \vk) \leftarrow \ZKGen()$.
|
||||
probability for $(\pk, \vk) \leftarrowR \ZKGen()$.
|
||||
|
||||
\begin{securityrequirements}
|
||||
\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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue