diff --git a/protocol/protocol.tex b/protocol/protocol.tex index b8426544..962a2e14 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -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. diff --git a/protocol/zcash.bib b/protocol/zcash.bib index aa5f784c..f4ac4454 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -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},