Various rationale updates for NU5.

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

protocol/protocol.tex

@@ -809,6 +809,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\spendProof}{\term{Spend proof}}
 \newcommand{\spendAuthSignature}{\term{spend authorization signature}}
 \newcommand{\spendAuthSignatures}{\terms{spend authorization signature}}
+\newcommand{\xSpendAuthSignatures}{\termxs{spend authorization signature}}
 \newcommand{\spendAuthRandomizer}{\term{spend authorization randomizer}}
 \newcommand{\spendAuthRandomizers}{\terms{spend authorization randomizer}}
 \newcommand{\spendAuthAddressKey}{\term{spend authorization address key}}
@@ -1019,6 +1020,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\nullifierSets}{\terms{nullifier set}}
 \newcommand{\paymentAddress}{\term{payment address}}
 \newcommand{\paymentAddresses}{\termes{payment address}}
+\newcommand{\xPaymentAddresses}{\termxes{payment address}}
 \newcommand{\shieldedPaymentAddress}{\term{shielded payment address}}
 \newcommand{\shieldedPaymentAddresses}{\termes{shielded payment address}}
 \newcommand{\unifiedPaymentAddress}{\term{unified payment address}}
@@ -1157,6 +1159,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\xSinsemillaHashes}{\termes{Sinsemilla hash}}
 \newcommand{\xSinsemillaCommitment}{\term{Sinsemilla commitment}}
 \newcommand{\xSinsemillaCommitments}{\terms{Sinsemilla commitment}}
+\newcommand{\xPedersenOrSinsemillaCommitments}{\termandindex{Pedersen}{Pedersen commitment}\nufive{ or \termandindex{Sinsemilla}{Sinsemilla commitment}} commitments\xspace}
 \newcommand{\chunks}{\termandindex{chunks}{chunk (of a Pedersen hash input)}}
 \newcommand{\segments}{\termandindex{segments}{segment (of a Pedersen hash input)}}
 \newcommand{\pieces}{\termandindex{pieces}{piece (of a Sinsemilla hash input)}}
@@ -3779,7 +3782,7 @@ All of these \pseudoRandomFunctions are instantiated in \crossref{concreteprfs}.
 
 \vspace{-2ex}
 \nnote{$\PRFnf{Sprout}{}$ was called $\PRFsn{}$ in \Zerocash \cite{BCGGMTV2014}, and just $\PRFnf{}{}$ in
-previous versions of this specification.}
+some previous versions of this specification.}
 
 
 \nufive{
@@ -13486,27 +13489,27 @@ potential knowledge of viewing keys.
 } %saplingonward
 
 \nufiveonward{
-In \Orchard, the \nullifier is computed as
+In \Orchard, the \nullifier is computed using a construction that combines
-$\DeriveNullifier{\NullifierKey}(\NoteUniqueRand, \NoteNullifierRand, \cm)$
+elliptic curve cryptography and the $\Poseidon$-based $\PRFnf{Orchard}{}$
-as described in \crossref{commitmentsandnullifiers}. This construction
+in a way that, for privacy, aims to provide defence in depth against potential
-combines elliptic curve cryptography and the $\Poseidon$-based $\PRFnf{Orchard}{}$
+weaknesses in either (see \cite[Section 3.5 Nullifiers]{Zcash-Orchard} and
-in a way that, for privacy properties, aims to provide defence in depth
+\crossref{commitmentsandnullifiers}).
-against potential weaknesses in either. Resistance to Faerie Gold attacks, on
+
-the other hand, depends entirely on hardness of the Discrete Logarithm Problem.
+Resistance to Faerie Gold attacks, on the other hand, depends entirely on hardness
-The $\NoteUniqueRand$ value of a \note created in a given \actionTransfer is obtained
+of the Discrete Logarithm Problem. The $\NoteUniqueRand$ value of a \note created
-from the \nullifier of the \note spent in that \actionTransfer; this ensures
+in a given \actionTransfer is obtained from the \nullifier of the \note spent in
-(without any cryptographic assumption) that all $\NoteUniqueRand$ values of
+that \actionTransfer; this ensures (without any cryptographic assumption) that all
-\notes added to the \noteCommitmentTree are unique. Then, the \nullifier
+$\NoteUniqueRand$ values of \notes added to the \noteCommitmentTree are unique.
-derivation can be considered as computing a modified Pedersen commitment on
+Then, the \nullifier derivation can be considered as computing a vector Pedersen
-input that includes $\NoteUniqueRand$, so that the binding property of that
+commitment on input that includes $\NoteUniqueRand$, so that the binding property of
-\commitmentScheme ensures that \Orchard \nullifiers will be unique. (Specifically,
+that \commitmentScheme ensures that \Orchard \nullifiers will be unique. (Specifically,
 this is a Sinsemilla commitment with an additional term having base $\NullifierBaseOrchard$,
 truncated to its $x$-coordinate. The $x$-coordinate truncation cannot harm
 \collisionResistance because, assuming hardness of the Discrete Logarithm
-Problem on the \pallasCurve, the security proof in \theoremref{thmshortsinsemillacr}
+Problem on the \pallasCurve, \crossref{sinsemillasecurity} covers the case where
-covers the case where the additional term is added.) Roadblock attacks are
+the additional term is added.) Roadblock attacks are not possible because $\NoteUniqueRand$
-not possible because $\NoteUniqueRand$ does not repeat for \notes in the
+does not repeat for \notes in the \noteCommitmentTree, and by a corresponding argument
-\noteCommitmentTree, and by a corresponding argument to \Sapling for \dummyNotes.
+to \Sapling for \dummyNotes.
 } %nufiveonward
 
 \lsubsection{Internal hash collision attack and fix}{internalh}
@@ -13528,14 +13531,16 @@ Balance property by double-spending \notes, potentially creating arbitrary
 amounts of currency for themself \cite{HW2016}.
 
 \Zcash uses a simpler construction with a single hash evaluation for the
-commitment: \shaHash for \Sprout\sapling{, and $\PedersenHash$ for \Sapling}.
+commitment: \shaHash for \Sprout \notes\sapling{,\notnufive{ and} $\PedersenHashToPoint$
+for \Sapling \notes}\nufive{, and $\SinsemillaHashToPoint$ for \Orchard \notes}.
 The motivation for the nested construction in \Zerocash
 was to allow Mint transactions to be publically verified without requiring
 \zkSNARKProofs (\cite[section 1.3, under step 3]{BCGGMTV2014}).
 Since \Zcash combines ``Mint'' and ``Pour''
-transactions into generalized \joinSplitTransfers (for \Sprout),
+transactions into generalized \joinSplitTransfers (for \Sprout)\sapling{, or
-\sapling{or \spendTransfers and \outputTransfers (for \Sapling)}, and each
+\spendTransfers and \outputTransfers (for \Sapling)}\nufive{, or
-transfer always uses a \zkSNARKProof\!\!, \Zcash does not require the nesting.
+\actionTransfers (for \Orchard)}, and each transfer always uses a
+\zkSNARKProof\!\!, \Zcash does not require the nesting.
 A side benefit is that this reduces the cost of computing the
 \noteCommitments: for \Sprout it reduces the number of \shaCompress
 evaluations needed to compute each \noteCommitment from three to two,
@@ -13552,12 +13557,12 @@ benefits.
 }
 
 \saplingonward{
-In \Sapling, \xPedersenCommitments are used instead of \shaCompress.
+In \Sapling, \xPedersenOrSinsemillaCommitments are used instead of \shaCompress.
 These commitments are statistically hiding, and so ``everlasting anonymity''
-is supported for \Sapling notes under the same conditions as in \Zerocash
+is supported for \SaplingAndOrchard notes under the same conditions as in \Zerocash
 (by the protocol, not necessarily by \zcashd). Note that
 \diversifiedPaymentAddresses can be linked if the Discrete Logarithm Problem
-on the \jubjubCurve can be broken.
+on the \jubjubCurve\nufive{ or \pallasCurve} can be broken.
 }
 
 \lsubsection{Changes to PRF inputs and truncation}{truncation}
@@ -13662,7 +13667,8 @@ The motivations for this change were as follows:
         \cite{BL-SafeCurves} \cite{Hopwood2018}.
         This retains $\KASproutCurve$'s advantages while keeping \shieldedPaymentAddress sizes
         short, because the same \publicKey material supports both encryption and
-        spend authentication.}
+        spend authentication.} \nufive{For \Orchard, we define a prime-order curve
+        \Pallas \cite{Hopwood2020}, with similar advantages to \Jubjub.}
   \item ECIES permits many options, which were not specified. There are at least
         --counting conservatively-- 576 possible combinations of options and
         algorithms over the four standards (ANSI X9.63, IEEE Std 1363a-2004,
@@ -13676,7 +13682,9 @@ The motivations for this change were as follows:
         $\KASproutCurve$ \sapling{(and \Jubjub)} key agreement is defined in a way that
         avoids these concerns due to the curve structure and the ``clamping'' of
         \privateKeys\sapling{ (or explicit cofactor multiplication and point
-        validation for \Sapling)}.
+        validation for \Sapling)}. \nufive{The \pallasCurve is prime-order, but
+        we still validate points, and use a similar \keyAgreementScheme to \Sapling
+        for consistency and ease of analysis.}
   \item Unlike the DHAES/DHIES proposal on which it is based \cite{ABR1999}, ECIES
         does not require a representation of the sender's \ephemeralPublicKey
         to be included in the input to the KDF, which may impair the security
@@ -13686,13 +13694,13 @@ The motivations for this change were as follows:
         The scheme we use for \Sprout has both the ephemeral and
         recipient \publicKey encodings --which are unambiguous for $\KASproutCurve$--
         and also $\hSig$ and a nonce as described below, as input to the KDF.
-        \sapling{For \Sapling, it is only possible to include the ephemeral public
+        \sapling{For \SaplingAndOrchard, it is only possible to include the ephemeral public
         key encoding, but this is sufficient to retain the original security properties
         of DHAES.} Note that being able to break the Elliptic Curve Diffie--Hellman Problem
-        on $\KASproutCurve$\sapling{ or \Jubjub} (without breaking
+        on $\KASproutCurve$\sapling{ or \Jubjub}\nufive{ or \Pallas} (without breaking
         $\SymSpecific$ as an authenticated encryption scheme or $\BlakeTwob{256}$ as
         a KDF) would not help to decrypt the \noteOrNotesCiphertext unless
-        $\TransmitPublic$ is known or guessed.
+        $\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$} is known or guessed.
   \item \sproutspecific{The KDF also takes a public seed $\hSig$ as input.
         This can be modeled as using a different ``randomness extractor'' for each
         \joinSplitTransfer, which limits degradation of security with the number of
@@ -13705,8 +13713,8 @@ The motivations for this change were as follows:
         with knowledge of $\AuthPrivateOld{\allOld}$, so an adversary cannot
         modify it in a ciphertext from someone else's transaction for use in a
         chosen-ciphertext attack without detection.}
-        \sapling{(In \Sapling, there is no equivalent to $\hSig$, but the \bindingSignature
+        \sapling{(In \SaplingAndOrchard, there is no equivalent to $\hSig$, but the
-        and \spendAuthSignatures prevent such modifications.)}
+        \bindingSignature and \spendAuthSignatures prevent such modifications.)}
   \item \sproutspecific{The scheme used by \Sprout includes an optimization that reuses
         the same ephemeral key (with different nonces) for the two ciphertexts
         encrypted in each \joinSplitDescription.}
@@ -13806,7 +13814,8 @@ distinct openings of the \noteCommitment when Condition I or II is violated.
           defined in \cite{IEEE2004}. The fork of \libsnark used by \Zcash uses
           this standard encoding rather than the less efficient (uncompressed) one
           used by upstream \libsnark.} \sapling{In \Sapling, a customized encoding
-          is used for \BLSPairing points in \Groth proofs to minimize length.}
+          is used for \BLSPairing points in \Groth proofs to minimize length\nufive{, and
+          similarly for \Pallas and \Vesta points in \Orchard}.}
     \item The range of monetary values differs. In \Zcash this range is
           $\range{0}{\MAXMONEY}$, while in \Zerocash it is $\ValueType$.
           (The \joinSplitStatement still only directly enforces that the sum
@@ -13932,6 +13941,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
           \end{itemize}
     \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}.
     \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}.
+    \item Various rationale updates for \NUFive.
 } %nufive
     \item Remove specification of \memo contents, which will be in \cite{ZIP-302}.
     \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}).

protocol/zcash.bib

@@ -1422,6 +1422,16 @@ Last revised February~5, 2018.}
    addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.}
 }
 
+@misc{Hopwood2020,
+   presort={Hopwood2020},
+   author={Daira Hopwood},
+   title={GitHub repository `\hairspace zcash/pasta'\hairspace:
+{G}enerator and supporting evidence for security of the {P}allas/{V}esta pair of elliptic curves suitable for {H}alo},
+   url={https://github.com/zcash/pasta},
+   urldate={2021-03-23},
+   addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.}
+}
+
 @misc{Bowe2018,
    presort={Bowe2018},
    author={Sean Bowe},