Cosmetics.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

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.

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},