From be1b95e76ef725e1b27dc2f036c6fc9ea8db67cc Mon Sep 17 00:00:00 2001 From: Daira-Emma Hopwood Date: Sun, 14 Apr 2024 17:45:32 +0100 Subject: [PATCH] Protocol spec: cosmetics and improved indexing. Signed-off-by: Daira-Emma Hopwood --- protocol/protocol.tex | 540 ++++++++++++++++++++++-------------------- protocol/zcash.bib | 4 +- 2 files changed, 289 insertions(+), 255 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 03e11767..ca902fbc 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -38,7 +38,7 @@ \usepackage[nobottomtitles,explicit]{titlesec} \usepackage[hang]{footmisc} \usepackage{xstring} -\usepackage[usenames,dvipsnames]{xcolor} +\usepackage[dvipsnames]{xcolor} \usepackage{etoolbox} \usepackage{subdepth} \usepackage{fix-cm} @@ -764,25 +764,58 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\OPTIONAL}{\conformance{OPTIONAL}} \newcommand{\ALLCAPS}{\conformance{ALL CAPS}} -\newcommand{\collisionResistant}{\termandindex{collision\hyp resistant}{collision resistance}} +\newcommand{\collisionResistant}{\termandindex{collision-resistant}{collision resistance}} \newcommand{\collisionResistance}{\term{collision resistance}} \newcommand{\xCollisionResistance}{\termx{collision resistance}} \newcommand{\binding}{\termandindex{binding}{binding (commitment scheme)}} \newcommand{\hiding}{\termandindex{hiding}{hiding (commitment scheme)}} \newcommand{\quotedBinding}{\quotedtermandindex{binding}{binding (commitment scheme)}} \newcommand{\quotedHiding}{\quotedtermandindex{hiding}{hiding (commitment scheme)}} +\newcommand{\reRandomized}{\term{re-randomized}} +\newcommand{\xReRandomized}{\termx{re-randomized}} +\newcommand{\reRandomizable}{\termandindex{re-randomizable}{re-randomized}} +\newcommand{\reRandomization}{\termandindex{re-randomization}{re-randomized}} \newcommand{\randomOracle}{\term{random oracle}} \newcommand{\randomOracles}{\terms{random oracle}} \newcommand{\randomOracleAdjective}{\termandindex{random-oracle}{random oracle}} -\newcommand{\nonCanonicalPoint}{\termandindex{non\hyp canonical}{non-canonical (compressed encoding of a point)}} -\newcommand{\nonCanonicalFieldElement}{\termandindex{non\hyp canonical}{non-canonical (encoding of a field element)}} -\newcommand{\nonCanonicallyFieldElement}{\termandindex{non\hyp canonically}{non-canonical (encoding of a field element)}} +\newcommand{\nonCanonicalPoint}{\termandindex{non-canonical}{non-canonical (compressed encoding of a point)}} +\newcommand{\nonCanonicalFieldElement}{\termandindex{non-canonical}{non-canonical (encoding of a field element)}} +\newcommand{\nonCanonicallyFieldElement}{\termandindex{non-canonically}{non-canonical (encoding of a field element)}} +\newcommand{\smallOrder}{\termandindex{small order}{small order (of a group element)}} +\newcommand{\smallOrderAdjective}{\termandindex{small-order}{small order (of a group element)}} +\newcommand{\primeOrder}{\termandindex{prime order}{prime order (of a group element)}} +\newcommand{\primeOrderAdjective}{\termandindex{prime-order}{prime order (of a group element)}} +\newcommand{\primeOrderGroup}{\term{prime-order group}} +\newcommand{\primeOrderSubgroup}{\term{prime-order subgroup}} +\newcommand{\primeOrderCurve}{\term{prime-order curve}} +\newcommand{\primeOrderCurves}{\terms{prime-order curve}} +\newcommand{\hashToCurve}{\term{hash-to-curve}} \newcommand{\xDiscreteLogarithmProblem}{\term{Discrete Logarithm Problem}} \newcommand{\xDiscreteLogarithm}{\termandindex{Discrete Logarithm}{Discrete Logarithm Problem}} \newcommand{\xDecisionalDiffieHellmanProblem}{\term{Decisional Diffie--Hellman Problem}} \newcommand{\xDecisionalDiffieHellman}{\termandindex{Decisional Diffie--Hellman}{Decisional Diffie--Hellman Problem}} \newcommand{\partitioningOracleAttack}{\term{partitioning oracle attack}} \newcommand{\partitioningOracleAttacks}{\terms{partitioning oracle attack}} +\newcommand{\sideChannel}{\term{side-channel}} +\newcommand{\multiPartyComputation}{\term{multi-party computation}} + +\newcommand{\doubleSpend}{\term{double-spend}} +\newcommand{\doubleSpends}{\terms{double-spend}} +\newcommand{\doubleSpending}{\termandindex{double-spending}{double-spend}} +\newcommand{\proofOfWork}{\term{proof-of-work}} +\newcommand{\peerToPeerProtocol}{\term{peer-to-peer protocol}} +\newcommand{\peerToPeerNetwork}{\termandindex{peer-to-peer network}{peer-to-peer protocol}} +\newcommand{\inBand}{\term{in-band}} +\newcommand{\outOfBand}{\term{out-of-band}} +\newcommand{\xUSASCII}{\term{US-ASCII}} +\newcommand{\bitSequence}{\term{bit sequence}} +\newcommand{\bitSequences}{\terms{bit sequence}} +\newcommand{\bitSequenceAdjective}{\termandindex{bit-sequence}{bit sequence}} +\newcommand{\byteSequence}{\term{byte sequence}} +\newcommand{\byteSequences}{\terms{byte sequence}} +\newcommand{\byteSequenceAdjective}{\termandindex{byte-sequence}{byte sequence}} +\newcommand{\littleEndian}{\term{little-endian}} +\newcommand{\bigEndian}{\term{big-endian}} \newcommand{\shaHash}{\termandindexx{$\SHAFull$}{SHA-256}} \newcommand{\shadHash}{\termandindexx{$\SHAFulld$}{SHA-256d}} @@ -799,8 +832,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\privateKeys}{\terms{private key}} \newcommand{\keyPrivacy}{\term{key privacy}} \newcommand{\xKeyPrivacy}{\termx{key privacy}} -\newcommand{\keyPrivate}{\termandindex{key\hyp private}{key privacy}} -\newcommand{\xKeyPrivate}{\termandindex{Key\hyp private}{key privacy}} +\newcommand{\keyPrivate}{\termandindex{key-private}{key privacy}} +\newcommand{\xKeyPrivate}{\termandindex{Key-private}{key privacy}} \newcommand{\ephemeralPublicKey}{\term{ephemeral public key}} \newcommand{\ephemeralPrivateKey}{\term{ephemeral private key}} @@ -904,6 +937,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\provingSystem}{\termandindex{proving system}{proving system (preprocessing zk-SNARK)}} \newcommand{\provingSystems}{\termandindex{proving systems}{proving system (preprocessing zk-SNARK)}} \newcommand{\zeroKnowledgeProvingSystem}{\termandindex{zero-knowledge proving system}{proving system (preprocessing zk-SNARK)}} +\newcommand{\zeroKnowledgeProvingSystems}{\termandindex{zero-knowledge proving systems}{proving system (preprocessing zk-SNARK)}} +\newcommand{\zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge}{\termandindex{zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs)}{proving system (preprocessing zk-SNARK)}} \newcommand{\quadraticConstraintProgram}{\term{quadratic constraint program}} \newcommand{\quadraticConstraintPrograms}{\terms{quadratic constraint program}} \newcommand{\quadraticArithmeticProgram}{\term{Quadratic Arithmetic Program}} @@ -1177,11 +1212,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\merkleIndices}{\termandindex{indices}{index (of a Merkle tree node)}} \newcommand{\zkSNARK}{\termandindex{zk-SNARK}{proving system (preprocessing zk-SNARK)}} \newcommand{\zkSNARKs}{\termandindex{zk-SNARKs}{proving system (preprocessing zk-SNARK)}} -\newcommand{\zkProof}{\termandindex{zk proof}{zk-SNARK proof}} -\newcommand{\zkSNARKProof}{\term{zk-SNARK proof}} -\newcommand{\zkSNARKProofs}{\terms{zk-SNARK proof}} -\newcommand{\zkSNARKCircuit}{\term{zk-SNARK circuit}} -\newcommand{\zkSNARKCircuits}{\terms{zk-SNARK circuit}} +\newcommand{\zkProof}{\termandindex{zk~proof}{zk-SNARK proof}} +\newcommand{\zeroKnowledgeProof}{\termandindex{zero-knowledge proof}{zk-SNARK proof}} +\newcommand{\zeroKnowledgeProofs}{\termandindex{zero-knowledge proofs}{zk-SNARK proof}} +\newcommand{\zkSNARKProof}{\termandindex{zk-SNARK proof}{zk-SNARK proof}} +\newcommand{\zkSNARKProofs}{\termandindex{zk-SNARK proofs}{zk-SNARK proof}} +\newcommand{\zkSNARKCircuit}{\termandindex{zk-SNARK circuit}{zk-SNARK circuit}} +\newcommand{\zkSNARKCircuits}{\termandindex{zk-SNARK circuits}{zk-SNARK circuit}} \newcommand{\libsnark}{\termandindex{libsnark}{libsnark (Zcash fork)}} \newcommand{\bellman}{\term{bellman}} \newcommand{\memo}{\term{memo field}} @@ -1198,7 +1235,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\signatureScheme}{\term{signature scheme}} \newcommand{\signatureSchemes}{\terms{signature scheme}} \newcommand{\oneTimeSignatureScheme}{\termandindex{one-time signature scheme}{one-time (signature scheme)}} -\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re\hyp randomizable keys}{signature scheme with re-randomizable keys}} +\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re-randomizable keys}{signature scheme with re-randomizable keys}} \newcommand{\keyMonomorphicSignatureScheme}{\term{signature scheme with key monomorphism}} \newcommand{\monomorphism}{\term{monomorphism}} \newcommand{\sigNonmalleable}{\termandindex{nonmalleable}{nonmalleability (of signatures)}} @@ -2500,12 +2537,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \begin{abstract} \normalsize \noindent \textbf{Abstract.} \defining{\Zcash} is an implementation of the \term{Decentralized Anonymous Payment scheme} -\Zerocash, with security fixes and improvements to performance and -functionality. It bridges the existing transparent payment scheme used by -\Bitcoin with a \emph{shielded} payment scheme secured by zero-knowledge -succinct non-interactive arguments of knowledge (\zkSNARKs). It attempted -to address the problem of mining centralization by use of the \Equihash -memory-hard proof-of-work algorithm. +\Zerocash, with security fixes and improvements to performance and functionality. +It bridges the existing transparent payment scheme used by \Bitcoin with a \emph{shielded} +payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge. +It attempted to address the problem of mining centralization by use of the \Equihash +memory-hard \proofOfWork algorithm. \vspace{1.5ex} \notblossom{\sapling{\noindent This specification defines the \Zcash consensus protocol @@ -2562,8 +2598,7 @@ This document was built with Lua\TeX, which is \href{https://github.com/zcash/zi \Zerocash \cite{BCGGMTV2014}}, with security fixes and improvements to performance and functionality. It bridges the existing transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with a -\emph{shielded} payment scheme secured by zero-knowledge succinct -non-interactive arguments of knowledge (\zkSNARKs). +\emph{shielded} payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge. \vspace{1ex} In this document, technical terms for concepts that play an important rôle in \Zcash are @@ -2608,7 +2643,7 @@ This specification is structured as follows: \begin{itemize} \item Notation — definitions of notation used throughout the document; \item Concepts — the principal abstractions needed to understand the protocol; - \item Abstract Protocol — a high-level description of the protocol in terms + \item Abstract Protocol — a \nh{high-level} description of the protocol in terms of ideal cryptographic components; \item Concrete Protocol — how the functions and encodings of the abstract protocol are instantiated; @@ -2765,7 +2800,7 @@ other proposals for private payment systems, such as CoinJoin \cite{Bitcoin-Coin or \CryptoNote \cite{vanSaberh2014}, that are based on mixing of a limited number of transactions and that therefore have smaller \noteTraceabilitySets. -The \nullifiers are necessary to prevent double-spending: each \note on the +The \nullifiers are necessary to prevent \doubleSpending: each \note on the \blockChain only has one valid \nullifier, and so attempting to spend a \note twice would reveal the \nullifier twice, which would cause the second \transaction to be rejected. @@ -2829,7 +2864,7 @@ means the type of sequences of length $\ell$ with elements in $T$. For example, $\bitseq{\ell}$ means the set of sequences of $\ell$ bits, and $\byteseq{k}$ means the set of sequences of $k$ bytes. -$\byteseqs$ means the type of byte sequences of arbitrary length. +$\byteseqs$ means the type of \byteSequences of arbitrary length. $\length(S)$ means the length of (number of elements in) $S$. @@ -2840,8 +2875,8 @@ digits means the corresponding integer converted from hexadecimal. $\zerobytes{\ell}$ means the sequence of $\ell$ zero bytes. $\ascii{...}$ means the given string represented as a -sequence of bytes in US-ASCII. For example, $\ascii{abc}$ represents the -byte sequence $\hexarray{61,62,63}$. +sequence of bytes in \xUSASCII. For example, $\ascii{abc}$ represents the +\byteSequence $\hexarray{61,62,63}$. $\zeros{\ell}$ means the sequence of $\ell$ zero bits. $\ones{\ell}$ means the sequence of $\ell$ one bits. @@ -2867,7 +2902,7 @@ inclusive, in descending order. $a \bconcat b$ means the concatenation of sequences $a$ then $b$. $\concatbits(S)$ means the sequence of bits obtained by -concatenating the elements of $S$ as bit sequences. +concatenating the elements of $S$ as \bitSequences. $\sorted(S)$ means the sequence formed by sorting the elements of $S$. @@ -2913,19 +2948,19 @@ means the remainder on dividing $a$ by $q$. (This usage does not conflict with the notation above for the unique representative of a field element.) -$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 +$a \xor b$ means the \nh{bitwise-exclusive-or} of $a$ and $b$, +and $a \band b$ means the \nh{bitwise-and} of $a$ and $b$. These are defined on integers (which include bits and bytes), or elementwise on equal-length sequences of integers, according to context. \vspace{-0.5ex} $\!\vsum{i=1}{\rmN} a_i$ means the sum of $a_{\allN{}}$.\; $\vproduct{i=1}{\rmN} a_i$ means the product of $a_{\allN{}}$.\; -$\vxor{i=1}{\rmN} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$. +$\vxor{i=1}{\rmN} a_i$ means the \nh{bitwise-exclusive-or} of $a_{\allN{}}$. When $N = 0$ these yield the appropriate neutral element, i.e. $\ssum{i=1}{0} a_i = 0$, $\sproduct{i=1}{0} a_i = 1$, and -$\sxor{i=1}{0} a_i = 0$ or the all-zero bit sequence of length given +$\sxor{i=1}{0} a_i = 0$ or the \nh{all-zero} \bitSequence of length given by the type of $a$. $\possqrt{a}$, where $a \typecolon \GF{q}$, means the positive square root @@ -2951,7 +2986,7 @@ The $\scalarmult{k}{P}$ notation for scalar multiplication in a group is defined in \crossref{abstractgroup}. The convention of affixing $\Repr$ to a variable name is used -for variables that denote bit-sequence representations of group elements. +for variables that denote \bitSequence representations of group elements. The binary relations $<$, $\leq$, $=$, $\geq$, and $>$ have their conventional meanings on integers and rationals, and are defined lexicographically on @@ -2981,7 +3016,7 @@ The following integer constants will be instantiated in \crossref{constants}: \end{formulae} The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$;\notnufive{ and} -the bit sequence constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and +the \bitSequenceAdjective constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and $\Uncommitted{Sapling} \typecolon \bitseq{\smash{\MerkleHashLength{Sapling}}}$}\nufive{; and the constant $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$} will also be defined in that section. @@ -3216,7 +3251,7 @@ a representation of the \noteCommitment $\cm$ described in \crossref{notecommitm A \notePlaintext also includes a $\MemoByteLength$-byte \defining{\memo} associated with this \note. The usage of the \memo is by agreement between the sender and recipient -of the \note. \RECOMMENDED non-consensus constraints on the \memo contents are specified +of the \note. \RECOMMENDED{} \nh{non-consensus} constraints on the \memo contents are specified in \cite{ZIP-302}. For \Sprout, the \notePlaintexts in each \joinSplitDescription are encrypted to the respective @@ -3363,7 +3398,7 @@ of a \Pallas curve point, as specified in \crossref{actiondesc}. \lsubsubsection{Nullifiers}{nullifierconcept} The \nullifier for a \note, denoted $\nf$, is a value unique to the \note that is used -to prevent double-spends. When a \transaction that contains one or more +to prevent \doubleSpends. When a \transaction that contains one or more \joinSplitDescriptions\sapling{ or \spendDescriptions}\nufive{ or \actionDescriptions} is entered into the \blockChain, all of the \defining{\nullifiers} for \notes spent by that \transaction are added to the \nullifierSet of the associated \treestate. A \transaction @@ -3374,14 +3409,14 @@ in the set. in \crossref{nullifierset}. \vspace{1.5ex} -In more detail, when a \note is spent, the spender creates a zero-knowledge proof that +In more detail, when a \note is spent, the spender creates a \zeroKnowledgeProof that it knows $(\NoteUniqueRand, \AuthPrivate)$\sapling{ or $(\NoteUniqueRand, \AuthSignPublic, \AuthProvePrivate)$}\nufive{ or $(\NoteUniqueRand, \AuthSignPublic, \NullifierKey)$}, consistent with the publically disclosed \nullifier and some previously committed \noteCommitment. Because each \note can have only a single \nullifier, and the same \nullifier value -cannot appear more than once in a \validBlockChain, double-spending is prevented. +cannot appear more than once in a \validBlockChain, \doubleSpending is prevented. \vspace{1.5ex} The \nullifier for a \Sprout \note is derived from the $\NoteUniqueRand$ value and @@ -3430,7 +3465,7 @@ that it received first. The consensus protocol is designed to ensure that for any given \blockHeight, the vast majority of well-connected nodes should eventually agree on their \bestValidBlockChain up to that height. A \fullValidator\footnote{There is reason to follow the requirements -in this section also for non-full validators, but those are outside the scope of this +in this section also for \nh{non-full~validators}, but those are outside the scope of this protocol specification.} \SHOULD attempt to obtain candidate \blocks from multiple sources in order to increase the likelihood that it will find a \validBlockChain that reflects a recent consensus state. @@ -3458,7 +3493,7 @@ Each \transaction has a \defining{\transactionID}. \xTransactionIDs are used to rooted at $\hashMerkleRoot$, and in other parts of the ecosystem; for example they are shown in \blockChain explorers and can be used in higher-level protocols. \nufive{Version 5 \transactions also have a \defining{\wtxid}, which is used instead of -the \transactionID when gossiping \transactions in the peer-to-peer protocol \cite{ZIP-239}.} +the \transactionID when gossiping \transactions in the \peerToPeerProtocol \cite{ZIP-239}.} The computation of \transactionIDs\nufive{ and \wtxids} is described in \crossref{txnidentifiers}. \nufive{For more detail on the distinction between these two identifiers and when to use each of them, see \cite{ZIP-239} and \cite{ZIP-244}.} @@ -3540,7 +3575,7 @@ The \anchor of each \joinSplitDescription in a \transaction{} refers to a \Sprout \treestate. For each of the $\NOld$ \shieldedInputs, a \nullifier is revealed. This allows -detection of double-spends as described in \crossref{nullifierset}. +detection of \doubleSpends as described in \crossref{nullifierset}. For each \joinSplitDescription in a \transaction, an interstitial output \treestate is constructed which adds the \noteCommitments and \nullifiers specified in that @@ -3608,7 +3643,7 @@ This approach allows all of the \zkSNARK \statements to be independent of each other, potentially increasing opportunities for precomputation. A \spendDescription specifies an \anchor, which refers to the output \Sapling \treestate -of a previous \block. It also reveals a \nullifier, which allows detection of double-spends +of a previous \block. It also reveals a \nullifier, which allows detection of \doubleSpends as described in \crossref{nullifierconcept}. \vspace{-2ex} @@ -3697,7 +3732,7 @@ defined in \crossref{constants}. \noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers}\nufive{ or \actionTransfers} produce. Just as the \defining{\utxoSetFull} used in \Bitcoin, it is used to express the existence of value and the capability to spend it. However, unlike the \utxoSet, -it is \emph{not} the job of this tree to protect against double-spending, as it is +it is \emph{not} the job of this tree to protect against \doubleSpending, as it is append-only. A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate @@ -3736,7 +3771,7 @@ each \treestate. As valid \transactions containing \joinSplitTransfers\sapling{ revealed in \joinSplitDescriptions\sapling{ and \spendDescriptions}\nufive{ and \actionDescriptions} are inserted into the \nullifierSet associated with the new \treestate. \xNullifiers are enforced to be unique within a \validBlockChain, in order to prevent -double-spends. +\doubleSpends. \consensusrule{ A \nullifier \MUSTNOT repeat either within a \transaction, or across \transactions @@ -3877,7 +3912,7 @@ rely only on the original abstraction. An abstraction can also be incomplete (not quite the same thing as being leaky): it intentionally --usually for simplicity-- does not model an aspect of behaviour that is important to security or correctness. An example -would be resistance to side-channel attacks; this specification says little about side-channel defence, among +would be resistance to \sideChannel attacks; this specification says little about \sideChannel defence, among many other implementation concerns. @@ -4095,7 +4130,7 @@ $\SymDecrypt{\Key}(\SymEncrypt{\Key}(\Ptext)) = \Ptext$. $\bot$ is used to represent the decryption of an invalid ciphertext. \securityrequirement{ -$\Sym$ must be \defining{\oneTime} (INT-CTXT $\wedge$ IND-CPA)-secure \cite{BN2007}. +$\Sym$ must be \defining{\oneTime} \nh{(INT-CTXT $\wedge$ IND-CPA)-secure} \cite{BN2007}. \quotedtermnoindex{One-time} here means that an honest protocol participant will almost surely encrypt only one message with a given key; however, the adversary may make many adaptive chosen ciphertext queries for a given key. @@ -4184,12 +4219,12 @@ with $\KA{Orchard}$ and derives keys for $\SymEncrypt{}$. \vspace{-1.5ex} \begin{securityrequirements} \item The asymmetric encryption scheme in \crossref{sproutinband}, constructed - from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be IND-CCA2-secure + from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be \nh{IND-CCA2-secure} and \keyPrivate. \item \sapling{ The asymmetric encryption scheme in \crossref{saplingandorchardinband}, constructed from $\KA{Sapling}$, $\KDF{Sapling}$ and $\Sym$\nufive{ or from $\KA{Orchard}$, - $\KDF{Orchard}$ and $\Sym$}, is required to be IND-CCA2-secure and \keyPrivate. + $\KDF{Orchard}$ and $\Sym$}, is required to be \nh{IND-CCA2-secure} and \keyPrivate. } %sapling \end{securityrequirements} @@ -4256,7 +4291,7 @@ in \crossref{abstractsigmono}.} \vspace{-1ex} \securityrequirement{ $\JoinSplitSig$\sapling{ and\nufive{ each instantiation of} $\BindingSig{}$} must be -Strongly Unforgeable under (non-adaptive) Chosen Message Attack (SU-CMA), as defined for example in +Strongly Unforgeable under (non-adaptive) Chosen Message Attack \nh{(SU-CMA)}, as defined for example in \cite[Definition 6]{BDEHR2011}.\footnote{The scheme defined in that paper was attacked in \cite{LM2017}, but this has no impact on the applicability of the definition.} This allows an adversary to obtain signatures on chosen messages, and then requires it to be @@ -4287,7 +4322,7 @@ pair without access to the \signingKey. in the same distribution as of freshly generated key pairs, for each \transaction containing \spendDescriptions or \outputDescriptions\nufive{ or \actionDescriptions}.} - \item SU-CMA security requires it to be infeasible for the adversary, not + \item \nh{SU-CMA} security requires it to be infeasible for the adversary, not knowing the \defining{\privateKey}, to forge a distinct signature on a previously seen message. That is, \joinSplitSignatures\sapling{ and \saplingBindingSignatures}\nufive{ and \orchardBindingSignatures} @@ -4340,13 +4375,13 @@ such that: \vspace{-1.5ex} The following security requirement for such \signatureSchemes is based on that -given in \cite[section 3]{FKMSSS2016}. Note that we require Strong Unforgeability -with Re-randomized Keys, not Existential Unforgeability with Re-randomized Keys -(the latter is called ``Unforgeability under Re-randomized Keys'' in -\cite[Definition 8]{FKMSSS2016}). Unlike the case for $\JoinSplitSig$, we require +given in \cite[section 3]{FKMSSS2016}. \defining{Note that we require Strong Unforgeability +with \xReRandomized Keys, not Existential Unforgeability with \xReRandomized Keys +(the latter is called ``Unforgeability under \xReRandomized Keys'' in +\cite[Definition 8]{FKMSSS2016}).} Unlike the case for $\JoinSplitSig$, we require security under adaptive chosen message attack with multiple messages signed using -a given key. (Although each \note uses a different re-randomized key pair, the same -original key pair can be re-randomized for multiple \notes, and also it can happen +a given key. (Although each \note uses a different \reRandomized key pair, the same +original key pair can be \reRandomized for multiple \notes, and also it can happen that multiple \transactions spending the same \note are revealed to an adversary.) \introlist @@ -4381,15 +4416,15 @@ $(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$. are swapped relative to \cite[section 3]{FKMSSS2016}. \vspace{-0.5ex} \item The requirement for the identity \randomizer $\SigRandomizerId$ simplifies the - definition of SURK-CMA by removing the need for two oracles (because the oracle for + definition of \nh{SURK-CMA} by removing the need for two oracles (because the oracle for original keys, called $\Oracle_1$ in \cite{FKMSSS2016}, is a special case of the oracle for randomized keys). \vspace{-0.5ex} \item Since $\SigRandomizePrivate(\SigRandomizer, \sk) : \SigRandomizer \leftarrowR \SigRandom$ has an identical distribution to $\SigGenPrivate()$, - and since $\SigDerivePublic$ is a deterministic function, the combination of a re-randomized + and since $\SigDerivePublic$ is a deterministic function, the combination of a \reRandomized \validatingKey and signature(s) under that key do not reveal the key from which it was - re-randomized. + \reRandomized. \vspace{-0.5ex} \item Since $\SigRandomizePrivate_{\SigRandomizer}$ is injective and easily invertible, knowledge of $\SigRandomizePrivate(\SigRandomizer, \sk)$ @@ -4916,7 +4951,7 @@ Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concretep Let $\KA{Sprout}$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}. \vspace{0.3ex} -A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence +A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a \bitSequence uniformly at random from $\bitseq{\AuthPrivateLength}$. \introlist @@ -4974,7 +5009,7 @@ Define $\AuthProveBaseSapling := \FindGroupJHash\Of{\ascii{Zcash\_H\_}, \ascii{} Define $\ToScalar{Sapling}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamJ{r}}$. \introlist -A new \Sapling \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Sapling \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence uniformly at random from $\SpendingKeyType$. \vspace{-0.2ex} @@ -5151,7 +5186,7 @@ Define $\ToBase{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutpu Define $\ToScalar{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{r}}$. \introlist -A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence uniformly at random from $\SpendingKeyType$. From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamP{r}}$, @@ -5391,7 +5426,7 @@ where \vspace{-1ex} \begin{consensusrules} \item Elements of a \spendDescription \MUST be valid encodings of the types given above. - \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ + \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignRandomizedPublic}$ \MUSTNOT be $\ZeroJ$. \item The proof $\Proof{\Spend}$ \MUST be valid given a \primaryInput formed from the other fields except $\spendAuthSig$ --- @@ -5412,7 +5447,7 @@ where \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$. \vspace{-0.25ex} - \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be small-order has the effect + \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be \smallOrderAdjective has the effect of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\AuthSignRandomizedPublic}\kern0.05em} = \AuthSignRandomizedPublic$. @@ -5474,7 +5509,7 @@ where \begin{consensusrules} \item Elements of an \outputDescription \MUST be valid encodings of the types given above. \vspace{-0.3ex} - \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ + \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\EphemeralPublic}$ \MUSTNOT be $\ZeroJ$. \vspace{-0.3ex} \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed @@ -5487,7 +5522,7 @@ where \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$. \vspace{-0.25ex} - \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be small-order has the effect + \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be \smallOrderAdjective has the effect of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\EphemeralPublic}\kern0.05em} = \AuthSignRandomizedPublic$. @@ -5557,9 +5592,9 @@ where the \outgoingCipherKey (which can be derived from a \fullViewingKey) to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey $\EphemeralPrivate$, hence the entire \notePlaintext; - \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued} spends in this Action; - \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued} outputs in this Action; \vspace{-0.25ex} \item $\Proof{} \typecolon \ActionProof$ is a \zkSNARKProof with \primaryInput @@ -5669,7 +5704,7 @@ and signs it with the private \defining{\joinSplitSigningKey}: \end{formulae} \vspace{-0.5ex} -Then the encoded \transaction including $\joinSplitSig$ is submitted to the peer-to-peer network. +Then the encoded \transaction including $\joinSplitSig$ is submitted to the \peerToPeerNetwork. \canopyonwardpnote{\cite{ZIP-211} specifies that nodes and wallets \MUST disable any facilities to send to \Sprout addresses. This \SHOULD be made clear in user interfaces and API documentation.} @@ -5789,7 +5824,7 @@ performs the following steps: In order to minimize information leakage, the sender \SHOULD randomize the order of \outputDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. -The encoded \transaction is submitted to the peer-to-peer network. +The encoded \transaction is submitted to the \peerToPeerNetwork. } %sapling @@ -5878,7 +5913,7 @@ and use that \dummyNote's \nullifier as the $\NoteUniqueRand$ value. In order to minimize information leakage, the sender \SHOULD randomize the order of \actionDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. -The encoded \transaction is submitted to the peer-to-peer network. +The encoded \transaction is submitted to the \peerToPeerNetwork. \pnote{ The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are @@ -6083,7 +6118,7 @@ The following discussion applies independently to the \Sprout\sapling{ and \Sapl \noteCommitmentTrees. Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash, -which is a bit sequence. +which is a \bitSequence. The \merkleLayer numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has $2^h$ \merkleNodes with \merkleIndices $0$ to $2^h-1$ inclusive. @@ -6132,7 +6167,7 @@ $\MerkleNode{\MerkleDepth{}}{i}$ is in a tree with a given \merkleRoot $\rt{} = \sapling{ \begin{pnotes} - \item For \Sapling, Merkle \merkleHashes are specified to be encoded as bit sequences, but the + \item For \Sapling, Merkle \merkleHashes are specified to be encoded as \bitSequences, but the \merkleRoot $\rt{Sapling}$ is encoded for the \primaryInput of a \spendProof as an element of $\GF{\ParamJ{q}}$, as specified in \crossref{cctsaplingspend}. The \spendCircuit allows inputs to $\MerkleCRH{Sapling}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded, @@ -6161,7 +6196,7 @@ $\MerkleNode{\MerkleDepth{}}{i}$ is in a tree with a given \merkleRoot $\rt{} = \introsection \lsubsection{SIGHASH Transaction Hashing}{sighash} -\Bitcoin and \Zcash use signatures and/or non-interactive proofs associated +\Bitcoin and \Zcash use signatures and/or \nh{non-interactive} proofs associated with \transaction inputs to authorize spending. Because these signatures or proofs could otherwise be replayed in a different \transaction, it is necessary to ``bind'' them to the \transaction for which they are intended. This is done by hashing information @@ -6392,7 +6427,7 @@ $\BindingSig{Sapling}$, $\combplus$, and $\grpplus$ are instantiated in \crossre \crossref{abstractsigmono} specifies these operations and the derived notation $\combminus$, $\scombsum{i=1}{\rmN}$, $\grpminus$, and $\sgrpsum{i=1\vphantom{p}}{\rmN}$, which in this section are to be interpreted as -operating on the prime-order subgroup of the \jubjubCurve and its scalar field. +operating on the \primeOrderSubgroup of points on the \jubjubCurve and on its scalar field. \vspace{1ex} \introlist @@ -6742,7 +6777,7 @@ The \validatingKey of the signature must be revealed in the \spendDescription so signature can be checked by validators. To ensure that the \validatingKey cannot be linked to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we use a \rerandomizableSignatureScheme. The \spendStatement\nufive{ or \actionStatement} proves that -this \validatingKey is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ +this \validatingKey is a \reRandomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ with a \randomizer known to the signer. The \defining{\spendAuthSignature} is over the \sighashTxHash, so that it cannot be replayed in other \transactions. @@ -7044,7 +7079,7 @@ $\cvOld{} = \ValueCommit{Sapling}{\ValueCommitRandOld{}}(\vOld{})$. \snarkcondition{Small order checks}{spendnonsmall} $\DiversifiedTransmitBase$ and $\AuthSignPublic$ -are not of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$ +are not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignPublic} \neq \ZeroJ$. \snarkcondition{Nullifier integrity}{spendnullifierintegrity} @@ -7081,11 +7116,11 @@ For details of the form and encoding of \spendStatement proofs, see \crossref{gr i.e.\ $\GroupJ$. \vspace{-0.5ex} \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its - input bit sequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer + input \bitSequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer from the previous \merkleLayer. \vspace{-0.5ex} \item It is \emph{not} checked in the \spendStatement that $\AuthSignRandomizedPublic$ is not of - small order. However, this \emph{is} checked outside the \spendStatement, as specified in + \smallOrder. However, this \emph{is} checked outside the \spendStatement, as specified in \crossref{spenddesc}. \vspace{-0.5ex} \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$. @@ -7148,7 +7183,7 @@ where $\DiversifiedTransmitBaseRepr = \reprJ\Of{\DiversifiedTransmitBase}$\,. $\cvNew{} = \ValueCommit{Sapling}{\ValueCommitRandNew{}}(\vNew{})$. \snarkcondition{Small order check}{outputnonsmall} -$\DiversifiedTransmitBase$ is not of small order, +$\DiversifiedTransmitBase$ is not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$. \vspace{0.5ex} @@ -7166,7 +7201,7 @@ For details of the form and encoding of \outputStatement proofs, see \crossref{g The $\ValueCommitOutput{Sapling}$ type also represents points, i.e. $\GroupJ$. \vspace{-0.5ex} \item The validity of $\DiversifiedTransmitPublicRepr$ is \emph{not} checked in this circuit (which is the reason - why it is typed as a bit sequence rather than as a point). + why it is typed as a \bitSequence rather than as a point). \vspace{-0.5ex} \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$. \end{pnotes} @@ -7301,7 +7336,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h range $\SignedValueDifferenceType$, which is different to the range $\SignedValueFieldType$ of $\vBalance{Orchard}$. \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its - input bit sequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer + input \bitSequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer from the previous \merkleLayer. \item As specified in \crossref{merklepath}, the validity check is permitted to be implemented in such a way that it can pass if any $\MerkleCRH{Orchard}$ hash on the \merklePath outputs $0$. @@ -7330,7 +7365,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h $\SpendAuthSigRandomizePublic{Orchard}$. In particular, the representation of $(\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) + \NoteNullifierRand) \bmod \ParamP{q}$ that is used for the scalar multiplication in $\DeriveNullifierAlg$ \MUST be checked to be - canonical in order to avoid a potential double-spend vulnerability, and similarly for the + canonical in order to avoid a potential \doubleSpend vulnerability, and similarly for the representation of $\InViewingKey$ in $\scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$. \end{pnotes} @@ -7373,7 +7408,7 @@ $\NoteUniqueRand$, and $\NoteCommitRand$. A \memo (\crossref{noteptconcept}) is also transmitted. To transmit these secrets securely to a recipient -\emph{without} requiring an out-of-band communication channel, the +\emph{without} requiring an \outOfBand communication channel, the \transmissionKey $\TransmitPublic$ is used to encrypt them. The recipient's possession of the associated \incomingViewingKey $\InViewingKey$ is used to reconstruct the original \note and \memo. @@ -7435,12 +7470,12 @@ The resulting \defining{\notesCiphertextSprout} is $(\EphemeralPublic, \Transmit \introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note -with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band +with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random \publicKey (rather than a random bit sequence) to ensure +still be generated as a random \publicKey (rather than a random \bitSequence) to ensure indistinguishability from other \joinSplitDescriptions. This mode of operation raises further security considerations, for example of how to validate a \Sprout{} -\note received out-of-band, which are not addressed in this document. +\note received \outOfBand, which are not addressed in this document. } \lsubsubsection{Decryption (\SproutText)}{sproutdecrypt} @@ -7522,7 +7557,7 @@ $\NoteCommitRand$\canopy{ or $\NoteSeedBytes$}. A \memo (\crossref{noteptconcept is also transmitted. To transmit these secrets securely to a recipient \emph{without} requiring -an out-of-band communication channel, the \diversifiedTransmissionKey +an \outOfBand communication channel, the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's possession of the associated $\KA{Sapling}$\nufive{ or $\KA{Orchard}$} \privateKey $\InViewingKey$ is used to reconstruct the original \note and \memo. @@ -7626,12 +7661,12 @@ The resulting \defining{\noteCiphertextSapling} is $(\ephemeralKey, \TransmitCip \introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{}$ for a given \note -with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band +with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random \publicKey (rather than a random bit sequence) to ensure +still be generated as a random \publicKey (rather than a random \bitSequence) to ensure indistinguishability from other \outputDescriptions. This mode of operation raises further security considerations, for example of how to validate a \SaplingOrOrchard \note -received out-of-band, which are not addressed in this document. +received \outOfBand, which are not addressed in this document. } %pnote } %sapling @@ -7849,7 +7884,7 @@ from $\TransmitPlaintext{}$ \notnufive{\introlist} \vspace{-0.5ex} \item A previous version of this specification did not have the requirement for the decoded point - $\DiversifiedTransmitPublic$ of a \Sapling \note to be in the set of prime-order points + $\DiversifiedTransmitPublic$ of a \Sapling \note to be in the set of \primeOrderAdjective points \smash{$\SubgroupJstar$ (i.e.\ ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJstar$}, return $\bot$''). That did not match the implementation in \zcashd. In fact the history is a little more complicated. The current specification matches the implementation in \librustzcash as of @@ -7875,7 +7910,7 @@ from $\TransmitPlaintext{}$ After \NUFive activation, the above algorithm explicitly returns $\bot$ if $\reprP\big(\DiversifiedTransmitPublic\big) \neq \DiversifiedTransmitPublicRepr$. However, this is technically redundant with the later check that returns $\bot$ if - $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only small-order \jubjubCurve + $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only \smallOrderAdjective \jubjubCurve points have \nonCanonicalPoint encodings. This check is enforced retrospectively for consensus by current \zcashd and \zebra versions, and for wallet rescanning by current \zcashd. Versions of \zcashd prior to \cite{zcashd-6725} could however @@ -7973,8 +8008,8 @@ to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \mem \vspace{-1ex} In \SaplingAndOrchard, \blockChain scanning requires only the $\NullifierKey$ and $\InViewingKey$ key components, rather than a \spendingKey as in \Sprout. -Typically, these components are derived from a \fullViewingKey as described in -\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}. +Typically, these components are derived from a \fullViewingKey +(\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}). \vspace{0.5ex} Let $\PRFOutputLengthNfSapling$ be as defined in \crossref{constants}. @@ -8037,7 +8072,7 @@ status (spent or unspent). \item When scanning only part of a \blockChain, it may be useful to augment the above algorithm with decryption of $\OutCiphertext$ components for each \transaction, in order to obtain information about \notes that were spent in the scanned period but received outside it. - \item The above algorithm does not detect \notes that were sent ``out-of-band'' or with incorrect + \item The above algorithm does not detect \notes that were sent ``\outOfBand'' or with incorrect \noteCiphertextsSapling. It is possible to detect whether such \notes were spent only if their \nullifiers are known. \end{nnotes} @@ -8070,14 +8105,14 @@ and integers: big-endian order. \item $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$ such that $\LEBStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the - bit sequence $S$ of length $\ell$. + \bitSequence $S$ of length $\ell$. \item $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ such that $\LEOStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the - byte sequence $S$ of length $\ell/8$. + \byteSequence $S$ of length $\ell/8$. \notbeforenufive{ \item $\BEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ such that $\BEOStoIPOf{\ell}{S}$ is the integer represented in big-endian order by the - byte sequence $S$ of length $\ell/8$. + \byteSequence $S$ of length $\ell/8$. } %notbeforenufive \item $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ defined as follows: pad the input on the right with $8 \mult \ceiling{\ell/8} - \ell$ zero bits @@ -8094,19 +8129,19 @@ and integers: \extralabel{boxnotation}{\lsubsection{Bit layout diagrams}{bitlayout}} We sometimes use bit layout diagrams, in which each box of the diagram represents -a sequence of bits. Diagrams are read from left-to-right, with lines read from -top-to-bottom; the breaking of boxes across lines has no significance. +a sequence of bits. Diagrams are read from left to right, with lines read from +top to bottom; the breaking of boxes across lines has no significance. The bit length $\ell$ is given explicitly in each box, except when it is obvious (e.g. for a single bit, or for the notation $\zeros{\ell}$ representing the sequence of $\ell$ zero bits, or for the output of $\LEBStoOSP{\ell}$). The entire diagram represents the sequence of \emph{bytes} formed by first -concatenating these bit sequences, and then treating each subsequence of 8 bits +concatenating these \bitSequences, and then treating each subsequence of 8 bits as a byte with the bits ordered from \emph{most significant} to \emph{least significant}. Thus the \emph{most significant} bit in each byte is toward the left of a diagram. \sapling{(This convention is used only in descriptions of the $\Sprout$ design; in the \SaplingAndOrchard additions, -bit/byte sequence conversions are always specified explicitly.)} Where bit fields +\bitSequence/\byteSequence conversions are always specified explicitly.)} Where bit fields are used, the text will clarify their position in each case. @@ -8225,11 +8260,11 @@ SHA-256 and SHA-512 are defined by \cite{NIST2015}. \end{formulae} \cite{NIST2015} strictly speaking only specifies the application of SHA-256 to -messages that are bit sequences, producing outputs (``message digests'') that -are also bit sequences. In practice, SHA-256 is universally implemented with a +messages that are \bitSequences, producing outputs (``message digests'') that +are also \bitSequences. In practice, SHA-256 is universally implemented with a byte-sequence interface for messages and outputs, such that the \emph{most significant} bit of each byte corresponds to the first bit of the -associated bit sequence. (In the NIST specification ``first'' is conflated with +associated \bitSequence. (In the NIST specification ``first'' is conflated with ``leftmost''.) \introlist @@ -8359,7 +8394,7 @@ such that $\SHACompress(x) = \zeros{256}$. \begin{pnotes} \item The $\layerInput$ argument does not affect the output. \item \shaCompress is not the same as the \shaHash function, which hashes arbitrary-length - byte sequences. + \byteSequences. \end{pnotes} \sapling{ @@ -8568,27 +8603,27 @@ the third address was derived from. return $\bot$) is modelled as a \randomOracle from \diversifiers to points of order $\ParamJ{r}$ on the \jubjubCurve. In this model, Unlinkability of $\DiversifyHash{Sapling}$ holds under the \xDecisionalDiffieHellman assumption on the - prime-order subgroup of the \jubjubCurve. + \primeOrderSubgroup of points on the \jubjubCurve. To prove this, consider the ElGamal encryption scheme \cite{ElGamal1985} - on this prime-order subgroup, restricted to encrypting plaintexts encoded + on this \primeOrderSubgroup, restricted to encrypting plaintexts encoded as the group identity $\ZeroJ$. (ElGamal was originally defined for $\GFstar{p}$ - but works in any prime-order group.) ElGamal \publicKeys then have the same form + but works in any \primeOrderGroup.) ElGamal \publicKeys then have the same form as \diversifiedPaymentAddresses. If we make the assumption above on $\GroupJHash{}$, then generating a new \diversifiedPaymentAddress from a given address $\pk$, gives the same distribution of $(\DiversifiedTransmitBase', \DiversifiedTransmitPublic')$ pairs as the distribution of ElGamal ciphertexts obtained by encrypting $\ZeroJ$ under $\pk$. \todo{check whether this is justified.} - Then, the definition of \keyPrivacy (IK-CPA as defined in \cite[Definition 1]{BBDP2001}) + Then, the definition of \keyPrivacy (\nh{IK-CPA} as defined in \cite[Definition 1]{BBDP2001}) for ElGamal corresponds to the definition of Unlinkability for $\DiversifyHash{Sapling}$. - (IK-CCA corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$ + (\nh{IK-CCA} corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$ remains Unlinkable when given Diffie--Hellman key agreement oracles for each of the candidate \diversifiedPaymentAddresses.) So if ElGamal is \keyPrivate, then $\DiversifyHash{Sapling}$ is Unlinkable under the same conditions. \cite[Appendix A]{BBDP2001} gives a security proof for \keyPrivacy - (both IK-CPA and IK-CCA) of ElGamal under the \xDecisionalDiffieHellman + (both \nh{IK-CPA} and \nh{IK-CCA}) of ElGamal under the \xDecisionalDiffieHellman assumption on the relevant group. (In fact the proof needed is the ``small modification'' described in the last paragraph in which the generator is chosen at random for each key.) @@ -9032,7 +9067,7 @@ this is a nontrivial discrete logarithm relation between independent bases. \begin{nnotes} \item \cite[Lemma 3]{JT2020} proves a tight reduction from finding a nontrivial discrete logarithm - relation in a prime-order group to solving the \xDiscreteLogarithmProblem in that group. + relation in a \primeOrderGroup to solving the \xDiscreteLogarithmProblem in that group. \item The above theorem easily extends to the case where additional scalar multiplication terms with independent bases may be added to the $\SinsemillaHashToPoint$ output before applying $\ExtractPbot$. This is needed to show security of the $\SinsemillaShortCommitAlg$ \commitmentScheme defined in @@ -9107,14 +9142,14 @@ reference implementation \cite{Poseidon-1.1}.\footnote{\nufive{Previous versions implementation were inconsistent with the paper. For verifying the parameters used in Zcash, we recommend the fork \cite{Poseidon-Zc1.1} which avoids use of the obsolete PyCrypto library.}} -The S-box function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and +The \nh{S-box} function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and the number of partial rounds $R_P$ is $56$. We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise addition in $\GF{\ParamP{q}}$ replacing exclusive-or of bit strings\footnote{\nufive{The sponge construction was originally proposed as operating on an arbitrary group. \cite{BDPA2007}}}) to construct a \hashFunction. The sponge capacity is one field element, the rate is two field elements, and -the output is one field element. We use the ``Constant-Input-Length''\strut mode described in +the output is one field element. We use the \nh{``Constant-Input-Length''} \strut mode described in \cite[section 4.2]{GKRRS2019}: for a $2$-element input, the initial value of the capacity element is $2^{65}$, and no padding of the input message is needed. @@ -9145,14 +9180,14 @@ by \texttt{calc\_round\_numbers.py} in that implementation, for a $128$-bit secu $2^{32} \mult 3 \mult 463 \mult 539204044132271846773 \mult 8999194758858563409123804352480028797519453$. Furthermore, previous cryptanalysis of $\Poseidon$ has focussed mainly on the case - of S-box $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because + of \nh{S-box} $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because $x \mapsto x^3$ would not be a permutation. $\alpha = 5$ is the smallest integer for which $x \mapsto x^\alpha$ is a permutation in $\GF{\ParamP{q}}$. On the other hand, the number of rounds chosen includes a significant security margin, even taking into account these considerations. For small $t$, such as $t = 3$ as used here, the results of \cite{KR2020} are positive for security since they indicate that - the number of active S-boxes through the middle rounds is larger than originally + the number of active \nh{S-boxes} through the middle rounds is larger than originally estimated by the $\Poseidon$ designers (and the number of rounds is based on this original conservative estimate). @@ -9171,7 +9206,7 @@ by \texttt{calc\_round\_numbers.py} in that implementation, for a $128$-bit secu on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from an ideal PRF. \item The constant $2^{65}$ comes from \cite[section 4.2]{GKRRS2019}: - ``Constant-Input-Length Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ + ``\nh{Constant-Input-Length} Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ where $o$ is the output length.'' In this case the input length ($\mathit{length}$) is $2$ field elements, and the output length is $1$ field element. \end{nnotes} @@ -9398,7 +9433,7 @@ It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \cross \vspace{-2ex} \securityrequirement{ -$\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a +The function $\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a \collisionResistant \xPRF for output range $\byteseq{32}$ when keyed by the bits corresponding to $\NullifierKeyRepr$, with input in the bits corresponding to $\NoteUniqueRandRepr$. Note that @@ -9488,7 +9523,7 @@ $\Key \in \Keyspace$. Similarly, let $\SymDecrypt{\Key}(\Ctext)$ be $\SymSpecific$ decryption of ciphertext $\Ctext \in \Ciphertext$, with empty ``associated data", all-zero nonce $\zeros{96}$, and $256$-bit key -$\Key \in \Keyspace$. The result is either the plaintext byte sequence, +$\Key \in \Keyspace$. The result is either the plaintext \byteSequence, or $\bot$ indicating failure to decrypt. \pnote{ @@ -9547,13 +9582,13 @@ secret keys. Let $\KASproutCurveMultiply(\bytes{n}, \bytes{q})$ be the result of point multiplication of the $\KASproutCurve$ \publicKey represented by the byte sequence $\bytes{q}$ by the $\KASproutCurve$ secret key represented by the -byte sequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}. +\byteSequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}. -Let $\KABase{Sprout} := \KASproutCurveBase$ be the public byte sequence representing +Let $\KABase{Sprout} := \KASproutCurveBase$ be the public \byteSequence representing the $\KASproutCurve$ base point. Let $\KASproutCurveClamp(\bytes{x})$ take a 32-byte sequence $\bytes{x}$ as input -and return a byte sequence representing a $\KASproutCurve$ \privateKey, with +and return a \byteSequence representing a $\KASproutCurve$ \privateKey, with bits ``clamped'' as described in \cite[section 3]{Bernstein2006}: ``clear bits $0, 1, 2$ of the first byte, clear bit $7$ of the last byte, and set bit $6$ of the last byte.'' Here the bits of a byte are numbered @@ -9748,7 +9783,7 @@ Let $a = -1$. Let $d = -121665/121666 \pmod{p}$. Let $\ell = 2^{252} + 27742317777372353535851937790883648493$ (the order of the \EdSpecific -curve's prime-order subgroup). +curve's \primeOrderSubgroup). Let $\EdDSABase$ be the base point given in \cite{BDLSY2012}. @@ -9862,7 +9897,7 @@ to accurately document the history of consensus changes.} \sapling{ \extralabel{concreteredjubjub}{\lsubsubsection{\RedDSAText{}\notnufive{ and \RedJubjubText{}}\notbeforenufive{, \RedJubjubText{}, and \RedPallasText{}}}{concretereddsa}} -$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key re-randomization +$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key \reRandomization as described in \crossref{abstractsigrerand}. It also supports a Secret Key to Public Key Monomorphism as described in \crossref{abstractsigmono}. It is based on a scheme from \cite[section 3]{FKMSSS2016}, with some ideas from @@ -9875,7 +9910,7 @@ The \spendAuthSignatureScheme $\SpendAuthSig{Sapling}$ is instantiated by $\RedJ parameters defined in \crossref{concretespendauthsig}. The \bindingSignatureScheme $\BindingSig{Sapling}$ is instantiated by $\RedJubjub$ without -key re-randomization, using parameters defined in \crossref{concretebindingsig}. +key \reRandomization, using parameters defined in \crossref{concretebindingsig}. \nufive{ $\RedPallas$ is a specialization of $\RedDSA$ to the \pallasCurve defined in \crossref{pallasandvesta}, @@ -9885,7 +9920,7 @@ The \spendAuthSignatureScheme $\SpendAuthSig{Orchard}$ is instantiated by $\RedP parameters defined in \crossref{concretespendauthsig}. The \bindingSignatureScheme $\BindingSig{Orchard}$ is instantiated by $\RedPallas$ without -key re-randomization, using parameters defined in \crossref{concretebindingsig}. +key \reRandomization, using parameters defined in \crossref{concretebindingsig}. } %nufive Let $\ItoLEBSP{}$, $\ItoLEOSP{}$, $\LEOStoIP{}$, and $\LEBStoOSP{}$ be as defined in \crossref{endian}. @@ -9939,7 +9974,7 @@ Define $\RedDSADerivePublic \typecolon \RedDSAPrivate \rightarrow \RedDSAPublic$ \introlist Define $\RedDSAGenRandom \typecolon () \rightarrowR \RedDSARandom$ as: \begin{formulae} - \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. + \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Return $\RedDSAHashToScalar(T)$. \end{formulae} @@ -9961,7 +9996,7 @@ Define $\RedDSARandomizePublic \typecolon \RedDSARandom \times \RedDSAPublic \ri \introlist Define $\RedDSASign{} \typecolon (\sk \typecolon \RedDSAPrivate) \times (M \typecolon \RedDSAMessage) \rightarrowR \RedDSASignature$ as: \begin{algorithm} - \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. + \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Let $\vkBytes{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\RedDSADerivePublic(\sk)}\kern 0.05em}$. \vspace{-0.75ex} \item Let $r = \RedDSAHashToScalar(T \bconcat \vkBytes{} \bconcat M)$. @@ -10050,8 +10085,8 @@ As required, $\RedDSADerivePublic$ is a group monomorphism, since it is injectiv \end{tabular} \vspace{0.5ex} -A $\RedDSA$ \validatingKey $\vk$ can be encoded as a bit sequence $\reprG{}\Of{\vk}$\, of -length $\ellG{}$ bits (or as a corresponding byte sequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$). +A $\RedDSA$ \validatingKey $\vk$ can be encoded as a \bitSequence $\reprG{}\Of{\vk}$\, of +length $\ellG{}$ bits (or as a corresponding \byteSequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$). \vspace{0.5ex} \introlist @@ -10095,7 +10130,7 @@ Let $\RedJubjub$ be as defined in \crossref{concretereddsa}. Define $\AuthSignBase{Sapling} := \FindGroupJHash\Of{\ascii{Zcash\_G\_}, \ascii{}}$. The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Sapling}$ is instantiated as $\RedJubjub$ -with key re-randomization and with generator $\GenG{} = \AuthSignBase{Sapling}$. +with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Sapling}$. \nufive{ Let $\RedPallas$ be as defined in \crossref{concretereddsa}. @@ -10103,7 +10138,7 @@ Let $\RedPallas$ be as defined in \crossref{concretereddsa}. Define $\AuthSignBase{Orchard} := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{G}}$. The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Orchard}$ is instantiated as $\RedPallas$ -with key re-randomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. +with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. } %nufive \vspace{0.5ex} @@ -10111,7 +10146,7 @@ See \crossref{spendauthsig} for details on the use of this \signatureScheme. \vspace{-2ex} \securityrequirement{ -\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a SURK-CMA secure \rerandomizableSignatureScheme +\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a \nh{SURK-CMA-secure} \rerandomizableSignatureScheme as defined in \crossref{abstractsigrerand}. } %securityrequirement } %sapling @@ -10125,18 +10160,18 @@ as defined in \crossref{abstractsigrerand}. Let $\RedJubjub$\nufive{ and $\RedPallas$} be as defined in \crossref{concreteredjubjub}. The \Sapling{} \defining{\bindingSignatureScheme}, $\BindingSig{Sapling}$, is instantiated as $\RedJubjub$ -without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in +without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in \crossref{concretevaluecommit}. See \crossref{saplingbalance} for details on the use of this \signatureScheme. \nufive{ The \Orchard{} \defining{\bindingSignatureScheme}, $\BindingSig{Orchard}$, is instantiated as $\RedPallas$ -without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in +without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in \crossref{concretevaluecommit}. See \crossref{orchardbalance} for details on the use of this \signatureScheme. } %nufive \vspace{-2ex} \securityrequirement{ -\nufive{Each instantiation of} $\BindingSig{}$ must be a SUF-CMA secure \keyMonomorphicSignatureScheme +\nufive{Each instantiation of} $\BindingSig{}$ must be a \nh{SUF-CMA-secure} \keyMonomorphicSignatureScheme as defined in \crossref{abstractsigmono}. A signature must prove knowledge of the discrete logarithm of the \validatingKey with respect to the base $\ValueCommitRandBase{Sapling}$\nufive{ or $\ValueCommitRandBase{Orchard}$}. @@ -10231,7 +10266,7 @@ instantiated as follows using $\WindowedPedersenCommitAlg$: (see \crossref{saplingmerklecrh}). The prefix $\ones{6}$ distinguishes the use of $\WindowedPedersenCommitAlg$ in $\NoteCommitAlg{Sapling}$ from the layer prefix used in $\MerkleCRH{Sapling}$. - That layer prefix is a $6$-bit little-endian encoding of an integer + That layer prefix is a $6$-bit \littleEndian encoding of an integer in the range $\range{0}{\MerkleDepth{Sapling}-1}$; because $\MerkleDepth{Sapling} < 64$, it cannot collide with $\ones{6}$. \item The arguments to $\NoteCommitAlg{Sapling}$ are in a different order to their encodings @@ -10354,7 +10389,7 @@ which is equivalent to: \vspace{-1ex} \nnote{The output of $\HomomorphicPedersenCommit{Sapling}{}$ may (with negligible probability for a randomly -chosen \commitmentTrapdoor) be the zero point $\ZeroJ$. This would be rejected by consensus if it appeared as +chosen \commitmentTrapdoor) be the zero point of the curve, $\ZeroJ$. This would be rejected by consensus if it appeared as the $\cv$ field of a \spendDescription (\crossref{spenddesc}) or \outputDescription (\crossref{outputdesc}). An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$.} @@ -10618,7 +10653,7 @@ For a point $P \typecolon \SubgroupGstar{2} = (\xP, \yP)$: \item A rational point $P \neq \ZeroG{2}$ on the curve $\CurveG{2}$ can be verified to be of order $\ParamG{r}$, and therefore in $\SubgroupGstar{2}$, by checking that $\ParamG{r} \mult P = \ZeroG{2}$. - \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding + \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. The encodings for $\SubgroupGstar{1, 2}$ are consistent with the definition of $\ECtoOSP{}$ for compressed curve points in @@ -10765,11 +10800,11 @@ For a point $P \typecolon \SubgroupSstar{2} = (\xP, \yP)$: \item The points at infinity $\ZeroS{1, 2}$ never occur in proofs and have no defined encodings in this protocol. \item In contrast to the corresponding \BNPairing curve, $\CurveS{1}$ over $\GF{\ParamS{q}}$ - is \emph{not} of prime order. + is \emph{not} a \primeOrderCurve. \item A rational point $P \neq \ZeroS{i}$ on the curve $\CurveS{i}$ for $i \in \setof{1, 2}$ can be verified to be of order $\ParamS{r}$, and therefore in $\SubgroupSstar{i}$, by checking that $\ParamS{r} \mult P = \ZeroS{i}$. - \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding + \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. \item The encodings for $\SubgroupSstar{1, 2}$ are specific to \Zcash. \item Algorithms for decompressing points from the encodings of @@ -11299,7 +11334,7 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type \item Unlike other uses of $\BlakeTwobGeneric$ in \Zcash, zero bytes are used for the $\BlakeTwobGeneric$ personalization, in order to follow the Internet Draft which encodes $\DST$ in the hash inputs instead. - \item The conversion from bytes to field elements uses big-endian order, again in order + \item The conversion from bytes to field elements uses \bigEndian order, again in order to follow the Internet Draft\rlap{.} \item A minor optimization is to cache the state of the $\BlakeTwob{512}$ instance used to compute $b_0$ after processing $\zerobytes{128}$, since this state does @@ -11357,7 +11392,7 @@ Let $\GroupGHashInput := \byteseqs \times \byteseqs$. The first input element acts as a domain separator to distinguish uses of the \groupHash for different purposes; the second input element is the message. -This hash-to-curve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$. +This \hashToCurve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$. \introlist The hash $\GroupGHash(D \typecolon \byteseqs, M \typecolon \byteseqs) \typecolon \GroupG{}$ @@ -11382,7 +11417,7 @@ is calculated as follows: to the Internet Draft, the definition here takes precedence. \item It is not necessary to use the $\clearcofactor$ function specified in the Internet Draft, because \Pallas and \Vesta (and therefore \IsoPallas and \IsoVesta) - are prime-order. + are \primeOrderCurves. \item The above description incorporates optimizations from \cite{WB2019} that avoid inversions and unnecessary square tests in the computation of $\maptocurvesimpleswuIsoG$. In order to fully avoid inversions, the output of $\maptocurvesimpleswuIsoG$ can be @@ -11510,7 +11545,7 @@ verifier \MUST check, for the encoding of each element, that: \vspace{-0.5ex} \item the lead byte is of the required form; \vspace{-0.5ex} - \item the remaining bytes encode a big-endian representation of an integer in + \item the remaining bytes encode a \bigEndian representation of an integer in $\range{0}{\ParamS{q}\!-\!1}$ or (for $\Proof{B}$) $\range{0}{\ParamSexp{q}{2}\!-\!1}$; \vspace{-0.5ex} @@ -11585,7 +11620,7 @@ verifier \MUST check, for the encoding of each element, that: \vspace{-0.5ex} \item the leading bitfield is of the required form; \vspace{-0.5ex} - \item the remaining bits encode a big-endian representation of an integer + \item the remaining bits encode a \bigEndian representation of an integer in $\range{0}{\ParamS{q}\!-\!1}$ or (in the case of $\Proof{B}$) two integers in that range; \vspace{-0.5ex} @@ -11608,7 +11643,7 @@ For \Orchard \actionDescriptions in version 5 \transactions, \Zcash uses \zkSNAR \lsubsubsubsubsection{Encoding of \HaloTwoText{} Proofs}{halo2encoding} \vspace{-1ex} -\HaloTwo proofs are defined as byte sequences, and so the encoding is the proof itself. +\HaloTwo proofs are defined as \byteSequences, and so the encoding is the proof itself. } %nufive @@ -11672,9 +11707,9 @@ The encoding of a \SaplingOrOrchard \notePlaintext consists of: This section describes how \Zcash encodes \shieldedPaymentAddresses, \incomingViewingKeys, and \spendingKeys. -Addresses and keys can be encoded as a byte sequence; this is called +Addresses and keys can be encoded as a \byteSequence; this is called the \defining{\rawEncoding}. For \Sprout \shieldedPaymentAddresses, this -byte sequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck +\byteSequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck layer is the same as for upstream \Bitcoin addresses \cite{Bitcoin-Base58}. \sapling{ @@ -11954,7 +11989,7 @@ When decoding the representation of $\DiversifiedTransmitPublic$, the address \M considered invalid if $\abstJ$ returns $\bot$. \nufive{\cite{ZIP-216} specifies that the address \MUST also be considered invalid if the -resulting $\DiversifiedTransmitPublic$ is not in the prime-order subgroup $\SubgroupJ$, or +resulting $\DiversifiedTransmitPublic$ is not in the \primeOrderSubgroup $\SubgroupJ$, or if it is a \nonCanonicalPoint encoding as defined in \crossref{abstractgroup}. This \MAY be enforced in advance of activation of \NUFive.} @@ -11990,7 +12025,7 @@ The \rawEncoding of a \Sapling \incomingViewingKey consists of: \vspace{-1.5ex} \begin{itemize} - \item $32$ bytes (little-endian) specifying $\InViewingKey$, padded with zeros in the most + \item $32$ bytes (\littleEndian) specifying $\InViewingKey$, padded with zeros in the most significant bits. \end{itemize} @@ -12195,7 +12230,7 @@ The \rawEncoding of an \Orchard \incomingViewingKey consists of: \vspace{-2.5ex} \begin{itemize} \item $32$ bytes specifying $\DiversifierKey$. - \item $32$ bytes (little-endian) specifying $\InViewingKey$. + \item $32$ bytes (\littleEndian) specifying $\InViewingKey$. \end{itemize} \vspace{-1.5ex} @@ -12242,9 +12277,9 @@ The \rawEncoding of an \Orchard \fullViewingKey consists of: \vspace{-2.5ex} \begin{itemize} - \item $32$ bytes (little-endian) specifying $\AuthSignPublic$. - \item $32$ bytes (little-endian) specifying $\NullifierKey$. - \item $32$ bytes (little-endian) specifying $\CommitIvkRand$. + \item $32$ bytes (\littleEndian) specifying $\AuthSignPublic$. + \item $32$ bytes (\littleEndian) specifying $\NullifierKey$. + \item $32$ bytes (\littleEndian) specifying $\CommitIvkRand$. \end{itemize} \introlist @@ -12305,7 +12340,7 @@ encoded in \libsnark format, are: \end{lines} \vspace{-0.5ex} -These parameters were obtained by a multi-party computation described in +These parameters were obtained by a \multiPartyComputation described in \cite{BGG-mpc} and \cite{BGG2017}. \sapling{They are used only before \Sapling activation.} Due to the security vulnerability described in \crossref{bctv}, it is not recommended to use these parameters in new protocols, and it is recommended to @@ -12331,7 +12366,7 @@ the \Sprout \joinSplitCircuit used after \Sapling activation, are respectively: \texttt{d5054e371842b3f88fa1b9d7e8e075249b3ebabd167fa8b0f3161292d36c180a sprout-groth16.params} \end{lines} -These parameters were obtained by a multi-party computation described in \cite{BGM2017}. +These parameters were obtained by a \multiPartyComputation described in \cite{BGM2017}. } %sapling @@ -12342,7 +12377,7 @@ These parameters were obtained by a multi-party computation described in \cite{B Let $\URS := \ascii{096b36a5804bfacef1691e173c366a47ff5ba84a44f26ddd7e8d9f79d5b42df0}$. This value is used in the definition of $\GroupJHash{}$ in \crossref{concretegrouphashjubjub}, -and in the multi-party computation to obtain the \Sapling parameters given in +and in the \multiPartyComputation to obtain the \Sapling parameters given in \crossref{grothparameters}. \introlist @@ -12350,13 +12385,13 @@ It is derived as described in \cite{Bowe2018}: \begin{itemize} \item Take the hash of the \Bitcoin \block at height $514200$ in \rpcByteOrder, - i.e.\ the big-endian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$. + i.e.\ the \bigEndian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$. \item Apply \shaHash $2^{42}$ times. - \item Convert to a US-ASCII lowercase hexadecimal string. + \item Convert to a \xUSASCII lowercase hexadecimal string. \end{itemize} \vspace{-2ex} -\pnote{$\URS$ is a $64$-byte US-ASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.} +\pnote{$\URS$ is a $64$-byte \xUSASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.} } %sapling @@ -12416,7 +12451,7 @@ Each \networkUpgrade is introduced as a \end{itemize} Full support for each \networkUpgrade is indicated by a minimum version -of the peer-to-peer protocol. At the planned \activationHeight, +of the \peerToPeerProtocol. At the planned \activationHeight, nodes that support a given upgrade will disconnect from (and will not reconnect to) nodes with a protocol version lower than this minimum. \overwinter{See \cite{ZIP-201} for how this applies to the \Overwinter @@ -12683,7 +12718,7 @@ of the \transaction encoding in the \notbeforenufive{pre-v5} format described ab \nufive{ The \transactionID of a version 5 \transaction is as defined in \cite{ZIP-244}. A v5 -\transaction also has a \wtxid (used for example in the peer-to-peer protocol) as defined +\transaction also has a \wtxid (used for example in the \peerToPeerProtocol) as defined in \cite{ZIP-239}. } %nufive @@ -12764,7 +12799,7 @@ in \cite{ZIP-239}. \item A \coinbaseTransaction for a \block at \blockHeight greater than $0$ \MUST have a script that, as its first item, encodes the \blockHeight $\BlockHeight$ as follows. For $\BlockHeight$ in the range $\range{1}{16}$, the encoding is a single byte of value $\hexint{50} + \BlockHeight$. - Otherwise, let $\heightBytes$ be the signed little-endian representation of $\BlockHeight$, + Otherwise, let $\heightBytes$ be the signed \littleEndian representation of $\BlockHeight$, using the minimum nonzero number of bytes such that the most significant byte is $< \hexint{80}$. The length of $\heightBytes$ \MUST be in the range $\range{1}{5}$. Then the encoding is the length of $\heightBytes$ encoded as one byte, followed by $\heightBytes$ itself. This matches @@ -13214,7 +13249,7 @@ $1344$ & $\solution$ & \type{byte[1344]} & The \Equihash solution. \\ \hline \vspace{2ex} A \block consists of a \blockHeader and a sequence of \transactions. How transactions -are encoded in a \block is part of the Zcash peer-to-peer protocol but not part of +are encoded in a \block is part of the Zcash \peerToPeerProtocol but not part of the consensus protocol. \vspace{1ex} @@ -13350,12 +13385,12 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin- \introsection \lsubsection{Proof of Work}{pow} -\Zcash uses \Equihash \cite{BK2016} as its Proof of Work. The original motivations for -changing the Proof of Work from \shadHash used by \Bitcoin were described in \cite{WG2016}. +\Zcash uses \Equihash \cite{BK2016} as its \proofOfWork. The original motivations for +changing the \proofOfWork from \shadHash used by \Bitcoin were described in \cite{WG2016}. \vspace{1ex} \introlist -A \block satisfies the Proof of Work if and only if: +A \block satisfies the \proofOfWork if and only if: \begin{itemize} \item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}. @@ -13481,10 +13516,10 @@ and so the first $7$ bytes of $\solution$ would be $[0, 2, 32, 0, 10, 127, 255]$. \pnote{ -$\ItoBEBSP{}$ is big-endian, while integer field encodings in $\powheader$ -and in the instantiation of $\EquihashGen{}$ are little-endian. -The rationale for this is that little-endian serialization of -\blockHeaders is consistent with \Bitcoin, but little-endian +$\ItoBEBSP{}$ is \bigEndian, while integer field encodings in $\powheader$ +and in the instantiation of $\EquihashGen{}$ are \littleEndian. +The rationale for this is that \littleEndian serialization of +\blockHeaders is consistent with \Bitcoin, but \littleEndian ordering of bits in the solution encoding would require bit-reversal (as opposed to only shifting). } @@ -13498,7 +13533,7 @@ Difficulty is defined in terms of a \targetThreshold, which is adjusted for each The difficulty filter is unchanged from \Bitcoin, and is calculated using \shadHash on the whole \blockHeader (including $\solutionSize$ and $\solution$). -The result is interpreted as a $256$-bit integer represented in little-endian +The result is interpreted as a $256$-bit integer represented in \littleEndian byte order, which \MUST be less than or equal to the \targetThreshold given by $\ToTarget(\nBitsField)$. @@ -14007,7 +14042,7 @@ for which the ``height in coinbase'' was inadvertently omitted. in \crossref{transparentaddrencoding}. \introlist -\cite{BIP-111} applies from peer-to-peer network protocol version $170004$ onward; that is: +\cite{BIP-111} applies from \peerToPeerProtocol version $170004$ onward; that is: \begin{itemize} \item references to protocol version $70002$ are to be replaced by $170003$; \item references to protocol version $70011$ are to be replaced by $170004$; @@ -14086,7 +14121,7 @@ as input, allowing \joinSplitTransfers to subsume the functionality of Mints. An advantage of this is that a \Zcash \transaction that takes input from a \utxo can produce up to $\NNew$ output \notes, improving the indistinguishability properties of the protocol. A related change -conceals the input arity of the \joinSplitTransfer: an unused (zero-value) +conceals the input arity of the \joinSplitTransfer: an unused (zero-valued) input is indistinguishable from an input that takes value from a \note. } @@ -14298,7 +14333,7 @@ attacker, with a work factor on the order of $2^{64}$, to find distinct pairs $(\AuthPublic, \NoteUniqueRand)$ and $(\AuthPublic\!', \NoteUniqueRand')$ with colliding outputs of the truncated hash, and therefore the same \noteCommitment. This would have allowed such an attacker to break the -Balance property by double-spending \notes, potentially creating arbitrary +Balance property by \doubleSpending \notes, potentially creating arbitrary amounts of currency for themself \cite{HW2016}. \Zcash uses a simpler construction with a single hash evaluation for the @@ -14452,8 +14487,8 @@ $\InViewingKey$ is removed. \lsubsection{In-band secret distribution}{inbandrationale} \Zerocash specified ECIES (referencing Certicom's SEC 1 standard) as the -encryption scheme used for the in-band secret distribution. This has been -changed to a key agreement scheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or +encryption scheme used for the \inBand secret distribution. This has been +changed to a \keyAgreementScheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or \Jubjub (for \Sapling)} and the authenticated encryption algorithm $\SymSpecific$. This scheme is still loosely based on ECIES, and on the $\CryptoBoxSeal$ scheme defined in libsodium \cite{libsodium-Seal}. @@ -14463,7 +14498,7 @@ The motivations for this change were as follows: \begin{itemize} \item The \Zerocash paper did not specify the curve to be used. - We believe that $\KASproutCurve$ has significant side-channel resistance, + We believe that $\KASproutCurve$ has significant \sideChannel resistance, performance, implementation complexity, and robustness advantages over most other available curve choices, as explained in \cite{Bernstein2006}. \sapling{For \Sapling, the \jubjubCurve was designed according to a @@ -14471,7 +14506,7 @@ 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.} \nufive{For \Orchard, we define a prime-order curve + spend authentication.} \nufive{For \Orchard, we define a \primeOrderCurve \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 @@ -14553,7 +14588,7 @@ expected to cause any weakness in \note encryption. For all shielded protocols, the checking of \noteCommitments makes \defining{\partitioningOracleAttacks} \cite{LGR2021} against the \noteCiphertext -infeasible, at least in the absence of side-channel attacks. \sapling{The following +infeasible, at least in the absence of \sideChannel attacks. \sapling{The following argument applies to \Sapling\nufive{ and \Orchard}, but can be adapted to \Sprout by replacing $\InViewingKey$ with $\TransmitPrivate$, $\DiversifiedTransmitPublic$ with $\TransmitPublic$, and using a fixed base. The decryption procedure @@ -14596,7 +14631,7 @@ Suppose that an adversary finds a collision on $\PRFaddr{}$ such that $\AuthPrivateSup{1}$ and $\AuthPrivateSup{2}$ are distinct \spendingKeys for the same $\AuthPublic$. Because the \noteCommitment is to $\AuthPublic$, but the \nullifier is computed from $\AuthPrivate$ (and $\NoteUniqueRand$), -the adversary is able to double-spend the note, once with each $\AuthPrivate$. +the adversary is able to \doubleSpend the note, once with each $\AuthPrivate$. This is not detected because each Spend reveals a different \nullifier. The \joinSplitStatements are still valid because they can only check that the $\AuthPrivate$ in the witness is \emph{some} preimage of @@ -14681,7 +14716,7 @@ and also \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornb Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik \nh{Ogilvie-Wigley}, Ariel Gabizon, George Tankersley, Ying~Tong Lai, Kris Nuttycombe, Jack Gavigan, Steven Smith, and Greg Pfeil. -The \Equihash proof-of-work algorithm was designed by Alex Biryukov and +The \Equihash \proofOfWork algorithm was designed by Alex Biryukov and Dmitry Khovratovich. The authors would like to thank everyone with whom they have discussed the @@ -14742,8 +14777,8 @@ used in \crossref{grothbatchverify}, by applying them to \BCTV. The arithmetization used by \HaloTwo is based on that used by \PLONK \cite{GWC2019}, which was designed by Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru. -Numerous people have contributed to the science of zero-knowledge proving -systems, but we would particularly like to acknowledge the work of +Numerous people have contributed to the science of \zeroKnowledgeProvingSystems, +but we would particularly like to acknowledge the work of Shafi Goldwasser, Silvio Micali, Oded Goldreich, Mihir Bellare, Charles Rackoff, Rosario Gennaro, Bryan Parno, Jon Howell, Craig Gentry, Mariana Raykova, Jens Groth, Rafail Ostrovsky, and Amit Sahai. @@ -14754,11 +14789,11 @@ Josh Cincinnati, Tanya Karsou, Henrik Jose, Chris Ward, and others for their work on the Zero Knowledge Podcast, ZK Summits, and ZK Study Club. These efforts have enriched the zero knowledge community immeasurably. -Many of the ideas used in \Zcash{} ---including the use of zero-knowledge proofs +Many of the ideas used in \Zcash{} ---including the use of \zeroKnowledgeProofs to resolve the tension between privacy and auditability, Merkle trees over note commitments (using Pedersen hashes as in \Sapling), and the use of ``serial numbers'' or \nullifiers to detect or prevent -double-spends--- were first applied to privacy-preserving digital currencies +\doubleSpends--- were first applied to privacy-preserving digital currencies by Tomas Sander and Amnon \nh{Ta-Shma}. To a large extent \Zcash is a refinement of their ``Auditable, Anonymous Electronic Cash'' proposal in \cite{ST1999}. @@ -14776,11 +14811,12 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \intropart \lsection{Change History}{changehistory} -\historyentry{Unreleased}{2024-03-02} +\historyentry{Unreleased}{2024-04-14} \begin{itemize} \item Add the hyphen in \nh{Daira-Emma} Hopwood. \item Correct some author lists in the References. + \item Prevent incorrect line-breaking on hyphens. \end{itemize} @@ -14815,14 +14851,14 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item In the discussion of partitioning oracle attacks on \note encryption in \crossref{inbandrationale}, we now use the fact that $\DiversifiedTransmitBase$ has order greater than the maximum value of $\InViewingKey$, rather than assuming that $\DiversifiedTransmitBase$ is a non-zero point - in the prime-order subgroup. (In the case of \Sapling, the circuits only enforce that - $\DiversifiedTransmitBase$ is not a small-order point, not that it is in the prime-order - subgroup. It is true that honestly generated addresses have prime-order $\DiversifiedTransmitBase$ + in the \primeOrderSubgroup. (In the case of \Sapling, the circuits only enforce that + $\DiversifiedTransmitBase$ is not a \smallOrderAdjective point, not that it is in the \primeOrderSubgroup. + It is true that honestly generated addresses have \primeOrderAdjective $\DiversifiedTransmitBase$ which would have been sufficient for the security argument against this class of attacks, but the chosen fix is more direct.) \item Delete a confusing claim in \crossref{spenddesc} that ``The check that $\AuthSignRandomizedPublic$ - is not of small order is technically redundant with a check in the \spendCircuit ...''. - The small-order check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority} + is not of \smallOrder is technically redundant with a check in the \spendCircuit ...''. + The \smallOrderAdjective check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority} check that this claim was intending to reference does not. \item An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$, in order to avoid @@ -14937,7 +14973,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. apply only when $\effectiveVersion \geq 5$ (since v4 \transactions did not explicitly encode the \nConsensusBranchId{} field). \item Correction in \crossref{constants}: - $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a bit sequence. + $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a \bitSequence. \item In \crossref{txnencoding}, add the calculation for \sizeProofsOrchard{} to the v5 \transaction format table. } @@ -15066,8 +15102,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. may be sampled from $\range{0}{2^{128}-1}$ instead of $\range{1}{2^{128}-1}$. \item Add note in \crossref{inbandrationale} about resistance of \note encryption to \partitioningOracleAttacks \cite{LGR2021}. - \item Add acknowledgement to Mihir Bellare for contributions to the science of zero-knowledge - proofs. + \item Add acknowledgement to Mihir Bellare for contributions to the science of \zeroKnowledgeProofs. \item Add acknowledgement to Sasha Meyer. \end{itemize} @@ -15085,7 +15120,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. $\rt{Orchard} \in \GroupP_{\!x}$ would require a square root and is unnecessary. \item Witness $\DiversifiedTransmitBaseNew$ and $\DiversifiedTransmitPublicNew$ in the \Orchard \actionCircuit as $\GroupPstar$, i.e.\ non-identity Pallas points, - rather than witnessing their representations as bit sequences. This reflects + rather than witnessing their representations as \bitSequences. This reflects the existing \zcashd implementation. \item Note that $\AuthSignPublicPoint$ in \Orchard cannot be the identity. } %nufive @@ -15128,9 +15163,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.2.13}{2021-07-29} \begin{itemize} - \item Add consensus rules in \crossref{notecommitmenttrees} that a \block \MUSTNOT add - \noteCommitments that exceed the capacity of any of the \Sprout\sapling{ or - \Sapling}\nufive{ or \Orchard} \noteCommitmentTrees. + \item Add consensus rules in \crossref{notecommitmenttrees} that, for each \noteCommitmentTree, + a \block \MUSTNOT add \noteCommitments that exceed the capacity of that tree. \end{itemize} @@ -15237,7 +15271,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \nufive{ \item Correct the type of $\Uncommitted{Orchard}$, which should be $\GroupP_{\!x}$ rather than a - bit sequence. + \bitSequence. \item Explicitly say that padding in \crossref{concretesinsemillahash} is by appending zero bits. \item Add a step to the algorithm for generating an \Orchard \note in \crossref{orchardsend}, to restart if $\EphemeralPrivate = 0$. @@ -15321,7 +15355,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. $\barerange{1}{16}$. \item Clarify, in \crossref{blockchain}, requirements on the range of \blockHeights that should be supported. - \item Delete the sentence ``All conversions between \EdSpecific points, byte sequences, + \item Delete the sentence ``All conversions between \EdSpecific points, \byteSequences, and integers used in this section are as specified in \cite{BDLSY2012}.'' from \crossref{concreteed25519}. This sentence was misleading given that the conversions in $\cite{BDLSY2012}$ are not sufficiently well-specified for a consensus @@ -15467,7 +15501,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. } %nufive \sapling{ \item Fix type error in $\kdfinput$ for $\KDF{Sapling}$\nufive{ and $\KDF{Orchard}$} - ($\ephemeralKey$ is already a byte sequence). + ($\ephemeralKey$ is already a \byteSequence). \item Make a note in \crossref{inbandrationale} of the divergence of $\InViewingKey$ for \SaplingAndOrchard from a uniform scalar. } %sapling @@ -15663,10 +15697,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \sapling{ \item Correct the \Sapling \note decryption algorithms: \begin{itemize} - \item $\ephemeralKey$ is kept as a byte sequence rather than immediately converted to a + \item $\ephemeralKey$ is kept as a \byteSequence rather than immediately converted to a curve point; this matters because of \nonCanonicalPoint encoding. \item The representation of $\DiversifiedTransmitPublic$ in a \notePlaintext may also be - \nonCanonicalPoint and need not be in the prime subgroup. + \nonCanonicalPoint and need not be in the \primeOrderSubgroup. \item Move checking of $\cmU$ in decryption with $\InViewingKey$ to the end of the algorithm, to more closely match the implementation. \item The note about decryption of outputs in \mempool \transactions should have been @@ -15695,7 +15729,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. (This rule was correctly implemented in \zcashd.) \sapling{ \item Fix a type error in the output of $\PRFnf{Sapling}{}$; a \Sapling \nullifier is a - sequence of $32$ bytes, not a bit sequence. + sequence of $32$ bytes, not a \bitSequence. \item Correct an off-by-one in an expression used in the definition of $c$ in \crossref{concretepedersenhash} (this does not change the value of $c$). } %sapling @@ -15770,7 +15804,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \sapling{ \item Correct an error introduced in \historyref{2020.1.8}; ``$-\ZeroJ$'' was incorrectly used when the point $(0, -1)$ on \Jubjub was meant. - \item Precisely specify the conversion from a bit sequence in $\abstJ$. + \item Precisely specify the conversion from a \bitSequence in $\abstJ$. } %sapling \end{itemize} @@ -16119,7 +16153,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. at \blockHeight $299188$. \item Add Eirik \nh{Ogilvie-Wigley} and Benjamin Winston to acknowledgements. \sapling{ - \item Rename zk-SNARK Parameters sections to be named according to the proving + \item Rename \zkSNARK Parameters sections to be named according to the proving system (\BCTV or \Groth), not the shielded protocol construction (\Sprout or \Sapling). \item In \crossref{networkupgrades}, say when \Sapling activated. @@ -16145,7 +16179,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. to match sapling-crypto. \item Describe $2$-bit window lookup with conditional negation in \crossref{cctpedersenhash}. \item Fix or complete various calculations of constraint costs. - \item Adjust the notation used for scalar multiplication in Appendix A to allow bit sequences + \item Adjust the notation used for scalar multiplication in Appendix A to allow \bitSequences as scalars. } %sapling \end{itemize} @@ -16258,7 +16292,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. how verification depends on \primaryInputs. } %sapling \item Add Charles Rackoff, Rafail Ostrovsky, and Amit Sahai to the acknowledgements - section for their work on zero-knowledge proofs. + section for their work on \zeroKnowledgeProofs. \end{itemize} \historyentry{2018.0-beta-26}{2018-08-05} @@ -16338,7 +16372,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Clarify attribution of the \Zcash protocol design. \item Acknowledge Alex Biryukov and Dmitry Khovratovich as the designers of \Equihash. \item Acknowledge Shafi Goldwasser, Silvio Micali, Oded Goldreich, Rosario Gennaro, Bryan Parno, Jon Howell, - Craig Gentry, Mariana Raykova, and Jens Groth for their work on zero-knowledge proving systems. + Craig Gentry, Mariana Raykova, and Jens Groth for their work on \zeroKnowledgeProvingSystems. \item Acknowledge Tomas Sander and Amnon \nh{Ta-Shma} for \cite{ST1999}. \item Acknowledge Kudelski Security's audit. \sapling{ @@ -16352,7 +16386,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. field of an \outputDescription{} must be canonical encodings. \item Enforce that $\EphemeralPrivate$ in $\outCiphertext$ is a canonical encoding. \item Add consensus rules that $\cv$ in a \spendDescription, and $\cv$ and $\EphemeralPublic$ in an - \outputDescription, are not of small order. Exclude $0$ from the range of $\EphemeralPrivate$ + \outputDescription, are not of \smallOrder. Exclude $0$ from the range of $\EphemeralPrivate$ when encrypting \Sapling notes. \item Add a consensus rule that $\valueBalance{Sapling}$ is in the range $\range{-\MAXMONEY}{\MAXMONEY}$. \item Enforce stronger constraints on the types of key components $\DiversifiedTransmitPublic$, @@ -16422,7 +16456,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Change the notation $\RedDSAHash^{\star}$ to $\RedDSAHashToScalar$ in \crossref{concreteredjubjub}, to avoid confusion with the $^{\Repr}$ convention for representations of group elements. \item $\cmuField$ encodes only the $u$-coordinate of the \noteCommitment, not the full curve point. - \item $\AuthSignRandomizedPublic$ is checked to be not of small order outside the \spendStatement, + \item $\AuthSignRandomizedPublic$ is checked to be not of \smallOrder outside the \spendStatement, not in the \spendStatement. \item Change terminology describing constraint systems. } %sapling @@ -16466,10 +16500,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Explicitly note that outputs from \coinbaseTransactions include \foundersReward outputs. \item The point represented by $\EdDSAReprR{}$ in an \EdSpecific signature is checked - to not be of small order; this is not the same as checking that it is of - prime order $\ell$. + to not be of \smallOrder; this is not the same as checking that it is of + \primeOrder $\ell$. \item Specify support for \cite{BIP-111} (the \texttt{NODE\_BLOOM} service bit) - in peer-to-peer network protocol version $170004$. + in \peerToPeerProtocol version $170004$. \item Give references \cite{Vercauter2009} and \cite{AKLGL2010} for the optimal ate pairing. \item Give references for BLS \cite{BLS2002} and BN \cite{BN2005} curves. \item Define $\KADerivePublic{Sprout}$ for $\KASproutCurve$. @@ -16514,7 +16548,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Updates to \Sapling construction, changing how the \nullifier is computed and separating it from the \authRandomizedValidatingKey ($\AuthSignRandomizedPublic$). - \item Clarify conversions between bit and byte sequences for + \item Clarify conversions between \bitSequences and \byteSequences for $\SpendingKey$, $\reprJ\Of{\AuthSignPublic}$, and $\reprJ\Of{\NullifierKey}$. } %sapling \item Change the \Makefile to avoid multiple reloads in PDF readers while @@ -16551,7 +16585,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item delete not-all-one component which is no longer needed \item factor out xor into its own component \item specify [un]packing more precisely; separate it from boolean constraints - \item optimize checking for non-small order + \item optimize checking for non-\smallOrder \item notation in variable-base multiplication algorithm. \end{itemize} } @@ -16651,7 +16685,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. collision with $\KASproutCurve$ scalar ``clamping''. \item Change uses of the term \term{full node} to \fullValidator. A \defining{\term{full node}} by definition participates in the - peer-to-peer network, whereas a \fullValidator just needs a copy + \peerToPeerNetwork, whereas a \fullValidator just needs a copy of the \blockChain from somewhere. The latter is what was meant. \sapling{ \item Add an explanation of how \Sapling prevents Faerie Gold and @@ -16741,7 +16775,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2017.0-beta-2.5}{2017-03-07} \begin{itemize} - \item Clarify the consensus rule preventing double-spends. + \item Clarify the consensus rule preventing \doubleSpends. \item Clarify what a \noteCommitment opens to in \crossref{crprf}. \item Correct the order of arguments to $\CommitAlg$ in \crossref{concretesproutnotecommit}. \item Correct a statement about indistinguishability of \joinSplitDescriptions. @@ -16869,7 +16903,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Update the section on encoding of \transparentAddresses. (The precise prefixes are not decided yet.) \item Clarify why $\BlakeTwob{\ell}$ is different from truncated $\BlakeTwob{512}$. - \item Clarify a note about SU-CMA security for signatures. + \item Clarify a note about \nh{SU-CMA} security for signatures. \item Add a note about $\PRFnf{Sprout}{}$ corresponding to $\PRFsn{}$ in \Zerocash. \item Add a paragraph about key length in \crossref{inbandrationale}. \item Add acknowledgements for John Tromp, Paige Peterson, Maureen Walsh, @@ -16925,7 +16959,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Major reorganization to separate the abstract cryptographic protocol from the algorithm instantiations. \item Add type declarations. - \item Add a ``High-level Overview'' section. + \item Add a ``\nh{High-level} Overview'' section. \item Add a section specifying the \zeroKnowledgeProvingSystem and the encoding of proofs. Change the encoding of points in proofs to follow IEEE Std 1363[a]. @@ -16940,7 +16974,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. match the implemented protocol. \item Add a consensus rule about the ranges of $\vpubOld$ and $\vpubNew$. \item Clarify cryptographic security requirements and added definitions - relating to the in-band secret distribution. + relating to the \inBand secret distribution. \item Add various citations: the ``Fixing Vulnerabilities in the Zcash Protocol'' and ``Why Equihash?'' blog posts, several crypto papers for security definitions, the \Bitcoin whitepaper, the \CryptoNote @@ -17065,9 +17099,9 @@ A point $P$ is normally represented by two $\GF{\ParamS{r}}$ variables, which we name as $(P^u, P^{\spv})$ for an \affineCtEdwards point, for instance. The implementations of scalar multiplication require the scalar to be represented -as a bit sequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning +as a \bitSequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning $\scalarmult{\LEBStoIPOf{\length(k\Repr)}{k\Repr}}{P}$. There will be no ambiguity -because variables representing bit sequences are named with a $\Repr$ suffix. +because variables representing \bitSequences are named with a $\Repr$ suffix. \introlist The \defining{\MontgomeryCurve} $\MontCurve$ has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$. @@ -17102,7 +17136,7 @@ ctEdwards coordinates: \item $\CompressedCtEdwardsJubjub := (\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 +See \crossref{jubjub} for how this type is represented as a \byteSequence in external encodings. \vspace{2ex} @@ -17348,7 +17382,7 @@ constrains $a_i$ to be $0$ if $\Pi_{i+1} = 1$, otherwise it constrains $a_i \in So all of $a_{\barerange{0}{n-1}}$ are at least boolean-constrained. To prove the rest of the theorem we proceed by induction on decreasing $m$, -i.e.\ taking successively longer prefixes of the big-endian binary representations +i.e.\ taking successively longer prefixes of the \bigEndian binary representations of $a$ and $c$. Base case $m = n-1$: since $c_{n-1} = 1$, the constraint system has @@ -17712,11 +17746,11 @@ $(u, \varv) = (u_1, \varv_1) = (u_2, \varv_2)$ and observing that $u \mult \varv \lsubsubsubsection{Affine-ctEdwards nonsmall-order check}{cctednonsmallorder} In order to avoid small-subgroup attacks, we check that certain points used in the -circuit are not of small order. In practice the \Sapling circuit uses this +circuit are not of \smallOrder. In practice the \Sapling circuit uses this in combination with a check that the coordinates are on the curve (\crossref{cctedvalidate}), so we combine the two operations. -The \jubjubCurve has a large prime-order subgroup with a cofactor of $8$. +The \jubjubCurve has a large \primeOrderSubgroup with a cofactor of $8$. To check for a point $P$ of order $8$ or less, the \Sapling circuit doubles three times (as in \crossref{cctedarithmetic}) and checks that the resulting $u$-coordinate is not $0$ (as in \crossref{cctnonzero}). @@ -17728,7 +17762,7 @@ only $\ZeroJ$. The total cost, including the curve check, is $4 + 3 \mult 5 + 1 = 20$ constraints. -\pnote{This \emph{does not} ensure that the point is in the prime-order subgroup.} +\pnote{This \emph{does not} ensure that the point is in the \primeOrderSubgroup.} \begin{nnotes} \item It would have been sufficient to do two doublings rather than three, because @@ -17779,8 +17813,8 @@ $s = 4 \smult s_2 + 2 \smult s_1 + s_0$, we use: - \spv_2 \smult s_1 \plus \spv_4 \smult s\suband - \spv_4 \smult s_2 - \spv_6 \smult s\suband}$ \end{formulae} -For a full-length ($252$-bit) scalar this costs $3$ constraints for each of $84$ window lookups, -plus $6$ constraints for each of $83$ ctEdwards additions (as in \crossref{cctedarithmetic}), for +For a \nh{full-length ($252$-bit)} scalar this costs $3$ constraints for each of $84$ window lookups, +plus $6$ constraints for each of $83$ \xCtEdwards additions (as in \crossref{cctedarithmetic}), for a total of $750$ constraints. Fixed-base scalar multiplication is also used in two places with shorter scalars: @@ -17849,8 +17883,8 @@ Given $k = \ssum{i=0}{250} k_i \smult 2^i$, we calculate $R = \scalarmult{k}{B}$ \item let $R = \Acc_{250}$. \end{algorithm} -This costs $5$ constraints for each of $250$ ctEdwards doublings, $6$ constraints for each -of $250$ ctEdwards additions, and $2$ constraints for each of $251$ point selections, +This costs $5$ constraints for each of $250$ \xCtEdwards doublings, $6$ constraints for each +of $250$ \xCtEdwards additions, and $2$ constraints for each of $251$ point selections, for a total of $3252$ constraints. \nnote{ @@ -17915,7 +17949,7 @@ are defined as in \crossref{concretepedersenhash}. \vspace{1ex} We have to prove that: \begin{itemize} - \item the Montgomery-to-ctEdwards conversions can be implemented without + \item the Montgomery-to-\xCtEdwards conversions can be implemented without exceptional cases; \item the \distinctXCriterion is met for all Montgomery additions within a segment. @@ -17926,10 +17960,10 @@ all indices of addition inputs are in the range $\bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$. Because the $\PedersenGen(D, j)$ (which are outputs of $\GroupJHash{}$) -are all of prime order, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, +are all of \primeOrder, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, it is guaranteed that all of the terms $\scalarmult{\PedersenEncode{M_j}}{\PedersenGen(D, j)}$ -to be converted to ctEdwards form are of prime order. +to be converted to \xCtEdwards form are of \primeOrder. From \theoremref{thmconversiontoedwardsnoexcept}, we can infer that the conversions will not encounter exceptional cases. @@ -18047,8 +18081,8 @@ The cost is then: \begin{itemize} \item $2 \smult c$ constraints for the lookups; \item $3 \smult (c-n)$ constraints for incomplete additions on the \MontgomeryCurve; - \item $2 \smult n$ constraints for Montgomery-to-ctEdwards conversions; - \item $6 \smult (n-1)$ constraints for ctEdwards additions; + \item $2 \smult n$ constraints for Montgomery-to-\xCtEdwards conversions; + \item $6 \smult (n-1)$ constraints for \xCtEdwards additions; \end{itemize} \vspace{-1ex} @@ -18085,7 +18119,7 @@ We define $\MixingPedersenHash \typecolon \range{0}{\ParamJ{r}-1} \end{formulae} This costs $92$ constraints for a scalar multiplication -(\crossref{cctfixedscalarmult}), and $6$ constraints for a ctEdwards addition +(\crossref{cctfixedscalarmult}), and $6$ constraints for a \xCtEdwards addition (\crossref{cctedarithmetic}), for a total of $98$ constraints. @@ -18109,7 +18143,7 @@ that is, it is \emph{not} necessary to ensure that the left or right inputs to t hash represent integers in the range $\range{0}{\ParamS{r}-1}$. Since the root of the Merkle tree is calculated outside the circuit using the canonical representations, and since the \xPedersenHashes are \collisionResistant -on arbitrary bit-sequence inputs, an attempt by an adversarial prover to use a +on arbitrary \bitSequenceAdjective inputs, an attempt by an adversarial prover to use a \nonCanonicalFieldElement input would result in the wrong root being calculated, and the overall path check would fail. @@ -18142,7 +18176,7 @@ This can be implemented in: $\ell = 6 + \length(s)$ bits, where $c = \ceiling{\hfrac{\ell}{3}}$ and $n = \ceiling{\hfrac{\ell}{3 \mult 63}}$; \item $750$ constraints for the fixed-base scalar multiplication; - \item $6$ constraints for the final ctEdwards addition. + \item $6$ constraints for the final \xCtEdwards addition. \end{itemize} When $\WindowedPedersenCommit{}$ is used to instantiate $\NoteCommitAlg{Sapling}$, @@ -18178,7 +18212,7 @@ $\ValueCommitAlg{}$ can be implemented in: \begin{itemize} \item $750$ constraints for the $252$-bit fixed-base multiplication by $\ValueCommitRand$; \item $191$ constraints for the $64$-bit fixed-base multiplication by $\Value$; - \item $6$ constraints for the ctEdwards addition + \item $6$ constraints for the \xCtEdwards addition \end{itemize} \vspace{-1.5ex} for a total cost of $947$ constraints. This does not include the cost to boolean-constrain @@ -18269,7 +18303,7 @@ Define $\BlakeTwos{256} \typecolon (p \typecolon \byteseq{8}) \times (x \typecol \item return $\LEBStoOSPOf{256}{\concatbits\Of{\listcomp{\ItoLEBSPOf{32}{h_i \xor v_i \xor v_{i+8}} \for i \from 0 \upto 7}}}$ \end{formulae} -In practice the message and output will be expressed as bit sequences. In the \Sapling +In practice the message and output will be expressed as \bitSequences. In the \Sapling circuit, the personalization string will be constant for each use. Each 32-bit exclusive-or is implemented in $32$ constraints, one for each bit position @@ -18417,7 +18451,7 @@ Check & Implements & \heading{Cost} & Reference \\ $\AuthSignPublic$ is on the curve \small\todo{FIXME also decompressed below} & $\AuthSignPublic \typecolon \SpendAuthSigPublic{Sapling}$ & 4 & \shortcrossref{cctedvalidate} \\ \hline - $\AuthSignPublic$ is not small order + $\AuthSignPublic$ is not \smallOrderAdjective & \snarkref{Small order checks}{spendnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\AuthSignRandomizerRepr \typecolon \bitseq{\ScalarLength{Sapling}}$ @@ -18451,7 +18485,7 @@ Check & Implements & \heading{Cost} & Reference \\ $\DiversifiedTransmitBase$ is on the curve & $\DiversifiedTransmitBase \typecolon \GroupJ$ & 4 & \shortcrossref{cctedvalidate} \\ \hline - $\DiversifiedTransmitBase$ is not small order + $\DiversifiedTransmitBase$ is not \smallOrderAdjective & \snarkref{Small order checks}{spendnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\DiversifiedTransmitPublic = \scalarmult{\InViewingKeyRepr}{\DiversifiedTransmitBase}$ @@ -18508,12 +18542,12 @@ Check & Implements & \heading{Cost} & Reference \\ \end{center} \vspace{1ex} -$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a bit sequence and dropping the most -significant $5$~bits, not by converting to an integer and back to a bit sequence as literally specified. +$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a \bitSequence and dropping the most +significant $5$~bits, not by converting to an integer and back to a \bitSequence as literally specified. \pnote{The implementation represents $\AuthSignRandomizerRepr$, $\AuthProvePrivateRepr$, $\InViewingKeyRepr$, -$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers. It -represents $\nf$ as a bit sequence rather than a byte sequence.} +$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers. It +represents $\nf$ as a \bitSequence rather than a \byteSequence.} \introsection @@ -18589,7 +18623,7 @@ Check & Implements & \heading{Cost} & Reference \\ $\DiversifiedTransmitBaseRepr = \reprJ(\DiversifiedTransmitBase \typecolon \GroupJ)$ & \snarkref{Note commitment integrity}{outputnotecommitmentintegrity} & 392 & \shortcrossref{ccteddecompressvalidate} \\ \hline - $\DiversifiedTransmitBase$ is not small order + $\DiversifiedTransmitBase$ is not \smallOrderAdjective & \snarkref{Small order checks}{outputnonsmall} & 16 & \shortcrossref{cctednonsmallorder} \\ \hline $\EphemeralPrivateRepr \typecolon \bitseq{\ScalarLength{Sapling}}$ @@ -18618,7 +18652,7 @@ Check & Implements & \heading{Cost} & Reference \\ \end{center} \pnote{The implementation represents $\EphemeralPrivateRepr$, $\DiversifiedTransmitPublicRepr$, -$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers.} +$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers.} \lsection{Batching Optimizations}{batching} diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 6d831b2c..3efa7d4d 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -304,7 +304,7 @@ Conference on Computer and Communications Security}, booktitle={Public Key Cryptography -- PKC 2006. Proceedings of the 9th International Conference on Theory and Practice in Public-Key Cryptography (New York, NY, USA, April~24--26, 2006)}, - publisher={Springer-Verlag}, + publisher={Springer}, date={2006-02-09}, url={https://cr.yp.to/papers.html#curve25519}, urldate={2021-04-05}, @@ -895,7 +895,7 @@ L. Hernández Encinas and C. Sánchez Ávila}, @misc{ABR1999, presort={ABR1999}, author={Michel Abdalla and Mihir Bellare and Phillip Rogaway}, - title={{DHAES}: {A}n {E}ncryption {S}cheme {B}ased on the {D}iffie-{H}ellman {P}roblem}, + title={{DHAES}: {A}n {E}ncryption {S}cheme {B}ased on the {D}iffie--{H}ellman {P}roblem}, url={https://eprint.iacr.org/1999/007}, urldate={2016-08-21}, date={1998-09},