mirror of https://github.com/zcash/zips.git
Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
f361159dfe
commit
f3d210742e
|
@ -144,6 +144,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
|
|||
|
||||
\mathchardef\mhyphen="2D
|
||||
|
||||
\newcommand{\lrarrow}{\texorpdfstring{$\leftrightarrow$}{↔}}
|
||||
|
||||
% https://tex.stackexchange.com/a/309445/78411
|
||||
\DeclareFontFamily{U}{FdSymbolA}{}
|
||||
\DeclareFontShape{U}{FdSymbolA}{m}{n}{
|
||||
|
@ -541,7 +543,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
|
|||
\newcommand{\union}{\cup}
|
||||
\newcommand{\intersection}{\cap}
|
||||
\newcommand{\lincomb}[1]{(\kern-.025em{#1}\kern-0.04em)}
|
||||
\newcommand{\constraint}[3]{\lincomb{#1} \times \lincomb{#2} = \lincomb{#3}}
|
||||
\newcommand{\constraint}[3]{\lincomb{#1}\hairspace \times\hairspace \lincomb{#2}\hairspace =\hairspace \lincomb{#3}}
|
||||
|
||||
% key pairs:
|
||||
\newcommand{\PaymentAddress}{\mathsf{addr_{pk}}}
|
||||
|
@ -1286,11 +1288,13 @@ $a \xor b$ means the bitwise-exclusive-or of $a$ and $b$,
|
|||
and $a \band b$ means the bitwise-and of $a$ and $b$. These are
|
||||
defined either on integers or bit sequences according to context.
|
||||
|
||||
$b \bchoose x : y$ means $x$ when $b = 1$, or $y$ when $b = 0$.
|
||||
|
||||
$\vsum{i=1}{\mathrm{N}} a_i$ means the sum of $a_{\allN{}}$.\;
|
||||
$\vxor{i=1}{\mathrm{N}} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$.
|
||||
|
||||
\notsprout{
|
||||
$b \bchoose x : y$ means $x$ when $b = 1$, or $y$ when $b = 0$.
|
||||
}
|
||||
|
||||
The binary relations $<$, $\leq$, $=$, $\geq$, and $>$ have their conventional
|
||||
meanings on integers and rationals, and are defined lexicographically on
|
||||
sequences of integers.
|
||||
|
@ -1320,8 +1324,8 @@ $\PoWMaxAdjustUp$ will also be defined in that section.
|
|||
|
||||
Users who wish to receive payments under this scheme first generate a
|
||||
random \spendingKey\sprout{ $\AuthPrivate$}.
|
||||
\sapling{In \Sprout this is called $\AuthPrivate$ and in \Sapling it is
|
||||
called $\AuthPrivateSeed$.}
|
||||
\notsprout{In \Sprout this is called $\AuthPrivate$ \sapling{and in \Sapling it is
|
||||
called $\AuthPrivateSeed$}.}
|
||||
|
||||
The following diagram depicts the relations between key
|
||||
components\notsprout{ in \Sprout}\sapling{ and \Sapling}.
|
||||
|
@ -1414,7 +1418,7 @@ to $\AuthPublic$, as described in the previous section.
|
|||
\end{itemize}
|
||||
|
||||
\sproutonly{
|
||||
Let $\NoteType$ be the type of a \note, i.e. \changed{
|
||||
Let $\NoteType$ be the type of a \note, i.e.\ \changed{
|
||||
$\PRFOutput \times \range{0}{\MAXMONEY} \times \PRFOutput \times \bitseq{\NoteCommitRandLength}$}.
|
||||
}
|
||||
|
||||
|
@ -2208,7 +2212,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}.
|
|||
\item Either $\vpubOld$ or $\vpubNew$ \MUST be zero.
|
||||
\item The proof $\Proof{\JoinSplit}$ \MUST be valid given a \primaryInput formed
|
||||
from the other fields and $\hSig$.
|
||||
I.e. it must be the case that $\JoinSplitVerify{}((\rt, \nfOld{\allOld}, \cmNew{\allNew},
|
||||
I.e.\ it must be the case that $\JoinSplitVerify{}((\rt, \nfOld{\allOld}, \cmNew{\allNew},
|
||||
\vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}) = 1$.
|
||||
\end{consensusrules}
|
||||
|
||||
|
@ -2424,7 +2428,7 @@ attempts to add a \nullifier to the \nullifierSet that already exists in the set
|
|||
|
||||
\nsubsection{\ZkSNARKStatements} \label{snarkstatements}
|
||||
|
||||
\nsubsubsection{\JoinSplitStatement \notsprout{(\Sprout)}} \label{joinsplitstatement}
|
||||
\nsubsubsection{\JoinSplitStatement{} \notsprout{(\Sprout)}} \label{joinsplitstatement}
|
||||
|
||||
A valid instance of $\ProofJoinSplit$ assures that given a \term{primary input}:
|
||||
|
||||
|
@ -5117,7 +5121,7 @@ The motivations for this change were as follows:
|
|||
performance, implementation complexity, and robustness advantages
|
||||
over most other available curve choices, as explained in \cite{Bern2006}.
|
||||
\sapling{For \Sapling, the $\JubjubCurve$ curve was designed according to a
|
||||
similar design process following the ``Safe curves'' criteria \cite{BLSafeCurves}.
|
||||
similar design process following the ``Safe curves'' criteria \cite{BL-SafeCurves}.
|
||||
This retains Curve25519's advantages while keeping \paymentAddress sizes
|
||||
short, because the same public key material supports both encryption and
|
||||
spend authentication.}
|
||||
|
@ -5710,7 +5714,7 @@ The latter has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = -40964$.
|
|||
Usually, elliptic curve arithmetic over prime fields is implemented using
|
||||
some form of projective coordinates, in order to reduce the number of expensive
|
||||
inversions required. In the circuit, it turns out that a division can be
|
||||
implemented at the same cost as a multiplication, i.e. one constraint.
|
||||
implemented at the same cost as a multiplication, i.e.\ one constraint.
|
||||
Therefore it is beneficial to use affine coordinates.
|
||||
|
||||
We define the following types representing affine Edwards and Montgomery
|
||||
|
@ -5723,14 +5727,15 @@ coordinates respectively:
|
|||
\ParamM{B} \smult y^2 = x^3 + \ParamM{A} \smult x^2 + x$
|
||||
\end{formulae}
|
||||
|
||||
We also define a type representing compressed, \emph{not necessarily valid}, Edwards coordinates:
|
||||
We also define a type representing compressed, \emph{not necessarily valid},
|
||||
Edwards coordinates:
|
||||
|
||||
\begin{formulae}
|
||||
\item $\CompressedEdwardsJubjub = (\tilde{u} \typecolon \bit) \times (\varv \typecolon \GF{\ParamS{r}})$
|
||||
\end{formulae}
|
||||
\vspace{-1.5ex}
|
||||
(See \crossref{jubjub} for how this type is represented as a byte sequence in
|
||||
external encodings.)
|
||||
See \crossref{jubjub} for how this type is represented as a byte sequence in
|
||||
external encodings.
|
||||
|
||||
\vspace{2ex}
|
||||
We use affine Montgomery arithmetic in parts of the circuit because it is
|
||||
|
@ -5776,8 +5781,7 @@ This can be implemented by:
|
|||
|
||||
|
||||
|
||||
|
||||
\nsubsubsection{Edwards $\leftrightarrow$ Montgomery conversion} \label{cctconversion}
|
||||
\nsubsubsection{Edwards \lrarrow\ Montgomery conversion} \label{cctconversion}
|
||||
|
||||
Define $\EdwardsToMont \typecolon \AffineEdwardsJubjub \rightarrow \AffineMontJubjub$
|
||||
as follows:
|
||||
|
@ -5814,7 +5818,7 @@ For reference, the incomplete affine-Montgomery addition formulae given in
|
|||
\cite[section 4.3.2]{BL2017} are:
|
||||
|
||||
\begin{formulae}
|
||||
\item $x_3 = \ParamM{B} \smult \lambda^2 - \ParamM{A} - x1 - x2$
|
||||
\item $x_3 = \ParamM{B} \smult \lambda^2 - \ParamM{A} - x_1 - x_2$
|
||||
\item $y_3 = (x_1 - x_3) \smult \lambda^2 - y_1$
|
||||
\item where $\lambda = \begin{cases}
|
||||
\hfrac{3 \smult x_1^2 + 2 \smult \ParamM{A} \smult x_1 + 1}{2 \smult \ParamM{B} \smult y_1},
|
||||
|
@ -5924,7 +5928,7 @@ by requiring the prover to exhibit the inverse, $z$:
|
|||
If the base point $B$ is fixed for a given scalar multiplication $\scalarmult{k}{B}$,
|
||||
we can fully precompute window tables for each window position.
|
||||
|
||||
It is most efficient to use 3-bit fixed windows. Since the length of
|
||||
It is most efficient to use $3$-bit fixed windows. Since the length of
|
||||
$\ParamG{s}$ is $252$ bits, we need $84$ windows.
|
||||
|
||||
Let $k = \vsum{i=0}{83} k_i \smult 8^i$.
|
||||
|
@ -5982,7 +5986,7 @@ of $250$ Edwards additions, and $2$ constraints for each of $251$ point selectio
|
|||
for a total of $3252$ constraints.
|
||||
|
||||
\pnote{
|
||||
It would be more efficient to use 2-bit fixed windows, but there are only
|
||||
It would be more efficient to use $2$-bit fixed windows, but there are only
|
||||
two instances of variable-base scalar multiplication in the \spendCircuit
|
||||
and one in the \outputCircuit, so the additional complexity was not considered
|
||||
justified.
|
||||
|
@ -6047,7 +6051,7 @@ This can be implemented in:
|
|||
(again assuming that the first 6 bits are fixed);
|
||||
\item ... constraints for the fixed-base scalar multiplication;
|
||||
\item ... constraints for the Montgomery-to-Edwards conversion;
|
||||
\item 5 constraints for the final Edwards addition (saving a
|
||||
\item $5$ constraints for the final Edwards addition (saving a
|
||||
constraint because the $\varv$-coordinate is not needed)
|
||||
\end{itemize}
|
||||
for a total of ... constraints.
|
||||
|
@ -6086,7 +6090,7 @@ Additions not involving a message word require 33 constraints:
|
|||
|
||||
...
|
||||
|
||||
Additions of message words require one extra constraint each, i.e. $a + b + m = c$
|
||||
Additions of message words require one extra constraint each, i.e.\ $a + b + m = c$
|
||||
is implemented by declaring a 34-bit boolean array, and ...
|
||||
|
||||
There are $10 \smult 4 \smult 2$ such message word additions.
|
||||
|
|
|
@ -151,7 +151,7 @@ Received \mbox{March 30,} 2017.}
|
|||
howpublished={Technical Report.}
|
||||
}
|
||||
|
||||
@misc{BLSafeCurves,
|
||||
@misc{BL-SafeCurves,
|
||||
author={Daniel Bernstein and Tanja Lange},
|
||||
title={SafeCurves: choosing safe curves for elliptic-curve cryptography},
|
||||
url={https://safecurves.cr.yp.to},
|
||||
|
|
Loading…
Reference in New Issue