diff --git a/protocol/protocol.tex b/protocol/protocol.tex index b6459153..dea6dad8 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -577,17 +577,16 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\Note}{\titleterm{Note}} \newcommand{\Notes}{\titleterms{Note}} \newcommand{\dummy}{\term{dummy}} -\newcommand{\dummyNotes}{\term{dummy notes}} \newcommand{\DummyNotes}{\titleterms{Dummy Note}} \newcommand{\commitmentScheme}{\term{commitment scheme}} \newcommand{\commitmentSchemes}{\terms{commitment scheme}} \newcommand{\commitmentTrapdoor}{\term{commitment trapdoor}} -\newcommand{\xCommitment}{\term{commitment}} \newcommand{\commitmentTrapdoors}{\terms{commitment trapdoor}} \newcommand{\trapdoor}{\termandindex{trapdoor}{trapdoor (of a commitment)}} \newcommand{\noteCommitment}{\term{note commitment}} \newcommand{\noteCommitments}{\terms{note commitment}} \newcommand{\xNoteCommitments}{\termxs{note commitment}} +\newcommand{\notesCommitment}{\termandindex{note's commitment}{note commitment}} \newcommand{\NoteCommitment}{\titleterm{Note Commitment}} \newcommand{\NoteCommitments}{\titleterms{Note Commitment}} \newcommand{\noteCommitmentTree}{\term{note commitment tree}} @@ -673,6 +672,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\zkProof}{\term{zk proof}} \newcommand{\zeroKnowledgeProof}{\term{zero-knowledge proof}} \newcommand{\zeroKnowledgeProofs}{\terms{zero-knowledge proof}} +\newcommand{\proofNonmalleability}{\termandindex{nonmalleability}{nonmalleability (of proofs)}} +\newcommand{\proofBatchEntries}{\termandindex{proof batch entries}{proof batch entry}} \newcommand{\provingSystem}{\term{proving system}} \newcommand{\provingSystems}{\terms{proving system}} \newcommand{\zeroKnowledgeProvingSystem}{\term{zero-knowledge proving system}} @@ -694,6 +695,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\HashExtractor}{\titleterm{Hash Extractor}} \newcommand{\groupHash}{\term{group hash}} \newcommand{\groupHashes}{\termes{group hash}} +\newcommand{\familyOfGroupHashesIntoTheSubgroup}{\termandindex{family of group hashes into the subgroup}{family of group hashes into a subgroup}} \newcommand{\representedPairing}{\term{represented pairing}} \newcommand{\RepresentedPairing}{\titleterm{Represented Pairing}} \newcommand{\RepresentedGroupsAndPairings}{\titleterms{Represented Groups and Pairing}} @@ -757,6 +759,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\genesisBlock}{\term{genesis block}} \newcommand{\transaction}{\term{transaction}} \newcommand{\transactions}{\terms{transaction}} +\newcommand{\Transaction}{\titleterm{Transaction}} \newcommand{\Transactions}{\titleterms{Transaction}} \newcommand{\transactionFee}{\term{transaction fee}} \newcommand{\transactionFees}{\terms{transaction fee}} @@ -794,6 +797,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\Blockchain}{\titleterm{Block Chain}} \newcommand{\validBlockchain}{\term{valid block chain}} \newcommand{\bestValidBlockchain}{\term{best valid block chain}} +\newcommand{\blockchainReorganization}{\term{block chain reorganization}} +\newcommand{\blockchainReorganizations}{\terms{block chain reorganization}} \newcommand{\branch}{\term{branch}} \newcommand{\branches}{\termes{branch}} \newcommand{\mempool}{\term{mempool}} @@ -898,14 +903,18 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\HashFunction}{\titleterm{Hash Function}} \newcommand{\HashFunctions}{\titleterms{Hash Function}} \newcommand{\encryptionScheme}{\term{encryption scheme}} +\newcommand{\oneTime}{\termandindex{one-time}{one-time (authenticated symmetric encryption)}} \newcommand{\symmetricEncryptionScheme}{\termandindex{authenticated one-time symmetric encryption scheme}{authenticated one-time symmetric encryption}} \newcommand{\SymmetricEncryption}{\titleterm{Authenticated One-Time Symmetric Encryption}} \newcommand{\signatureScheme}{\term{signature scheme}} \newcommand{\signatureSchemes}{\terms{signature scheme}} -\newcommand{\rerandomizableSignatureSchemes}{\term{signature schemes with re\hyp randomizable keys}} -\newcommand{\keyHomomorphicSignatureSchemes}{\term{signature schemes with private key to public key homomorphism}} +\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{\keyHomomorphicSignatureScheme}{\term{signature scheme with key homomorphism}} +\newcommand{\sigNonmalleable}{\termandindex{nonmalleable}{nonmalleability (of signatures)}} +\newcommand{\sigBatchEntries}{\termandindex{signature batch entries}{signature batch entry}} +\newcommand{\xPRF}{\termandindex{PRF}{Pseudo Random Function}} +\newcommand{\xPRFs}{\termandindex{PRFs}{Pseudo Random Function}} \newcommand{\pseudoRandomFunction}{\term{Pseudo Random Function}} \newcommand{\pseudoRandomFunctions}{\terms{Pseudo Random Function}} \newcommand{\PseudoRandomFunctions}{\titleterms{Pseudo Random Function}} @@ -1387,8 +1396,10 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\blockSubsidy}{\term{block subsidy}} \newcommand{\minerSubsidy}{\term{miner subsidy}} \newcommand{\foundersReward}{\term{Founders' Reward}} +\newcommand{\FoundersRewardText}{\titleterm{Founders' Reward}} \newcommand{\slowStartPeriod}{\term{slow-start period}} \newcommand{\halvingInterval}{\term{halving interval}} +\newcommand{\utxoSet}{\term{unspent transaction output set}} \newcommand{\BlossomActivationHeight}{\mathsf{BlossomActivationHeight}} \newcommand{\IsBlossomActivated}{\mathsf{IsBlossomActivated}} @@ -1579,8 +1590,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\rkField}{\mathtt{rk}} \newcommand{\cvField}{\mathtt{cv}} \newcommand{\cmuField}{\mathtt{cmu}} -\newcommand{\commitment}{\mathtt{commitment}} -\newcommand{\commitments}{\mathtt{commitments}} +\newcommand{\commitmentsField}{\mathtt{commitments}} \newcommand{\ephemeralKey}{\mathtt{ephemeralKey}} \newcommand{\encCiphertext}{\mathtt{encCiphertext}} \newcommand{\encCiphertexts}{\mathtt{encCiphertexts}} @@ -1608,6 +1618,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % Equihash and block headers +\newcommand{\Equihash}{\term{Equihash}} +\newcommand{\EquihashText}{\titleterm{Equihash}} \newcommand{\validEquihashSolution}{\term{valid Equihash solution}} \newcommand{\powtag}{\mathsf{powtag}} \newcommand{\powheader}{\mathsf{powheader}} @@ -1860,6 +1872,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % Consensus rules +\newcommand{\networkUpgrade}{\term{network upgrade}} + \newcommand{\consensusrule}[1]{\needspace{2ex}\subparagraph{Consensus rule:}{#1}} \newenvironment{consensusrules}{\vspace{-4ex}\introlist\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}} \newcommand{\sproutspecificitem}[1]{\item \sproutspecific{#1}} @@ -1917,12 +1931,12 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \renewcommand{\abstractname}{} \begin{abstract} \normalsize \noindent \textbf{Abstract.} -\Zcash is an implementation of the \term{Decentralized Anonymous Payment} -scheme \Zerocash, with security fixes and improvements to performance and +\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 +to address the problem of mining centralization by use of the \Equihash memory-hard proof-of-work algorithm. \vspace{1.5ex} @@ -1969,10 +1983,10 @@ This document was built with Lua\TeX, which is \href{https://github.com/zcash/zi \section{Introduction} -\Zcash is an implementation of the \term{Decentralized Anonymous Payment} -scheme \Zerocash \cite{BCGGMTV2014}, with security fixes and improvements +\Zcash is an implementation of the \defining{\term{Decentralized Anonymous Payment scheme} +\Zerocash \cite{BCGGMTV2014}}, with security fixes and improvements to performance and functionality. It bridges the existing -transparent payment scheme used by \Bitcoin \cite{Nakamoto2008} with a +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). @@ -1990,13 +2004,13 @@ The name \Sprout is used for the \Zcash protocol prior to \Sapling } %notsprout Technical terms for concepts that play an important rôle in \Zcash are -written in \term{slanted text}. \emph{Italics} are used for emphasis and +written in \defining{\term{slanted text}}. \emph{Italics} are used for emphasis and for references between sections of the document. -The key words \MUST, \MUSTNOT, \SHOULD, -\sprout{and \SHOULDNOT}\notsprout{\SHOULDNOT, \MAY, and \RECOMMENDED} in +The key words \defining{\MUST, \MUSTNOT, \SHOULD, +\sprout{and \SHOULDNOT}\notsprout{\SHOULDNOT, \MAY, and \RECOMMENDED}} in this document are to be interpreted as described in \cite{RFC-2119} when -they appear in \ALLCAPS. These words may also appear in this document in +they appear in \defining{\ALLCAPS}. These words may also appear in this document in lower case as plain English words, absent their normative meanings. \vspace{2ex} @@ -2055,8 +2069,8 @@ used notwithstanding.} Value in \Zcash is either \transparent or \shielded. Transfers of \transparent value work essentially as in \Bitcoin and have the same privacy properties. \xShielded value is carried by \notes\footnotewithlabel{notesandnullifiers}{In -\Zerocash \cite{BCGGMTV2014}, \notes were called \quotedterm{coins}, and \nullifiers -were called \quotedterm{serial numbers}.}, +\Zerocash \cite{BCGGMTV2014}, \notes were called \definingquotedterm{coins}, and \nullifiers +were called \definingquotedterm{serial numbers}.}, which specify an amount and \sprout{a \payingKey. The \payingKey is part of} \notsprout{(indirectly)} a \paymentAddress, which is a destination to which \notes can be sent. @@ -2420,8 +2434,8 @@ coordinates (see \crossref{jubjub}). \subsection{Payment Addresses and Keys} \label{addressesandkeys} -Users who wish to receive payments under this scheme first generate a -random \spendingKey\sprout{ $\AuthPrivate$}. +\defining{Users who wish to receive payments under this scheme first generate a +random \spendingKey\sprout{ $\AuthPrivate$}.} \notsprout{In \Sprout this is called $\AuthPrivate$ \sapling{and in \Sapling it is called $\SpendingKey$}.} @@ -2438,19 +2452,19 @@ abstractions. \end{center} \sproutspecific{ -The \receivingKey $\TransmitPrivate$, the \incomingViewingKey +\defining{The \receivingKey $\TransmitPrivate$, the \incomingViewingKey $\InViewingKey = (\AuthPublic, \TransmitPrivate)$, and the \paymentAddress $\PaymentAddress = (\AuthPublic, \TransmitPublic)$ are derived from -$\AuthPrivate$, as described in \crossref{sproutkeycomponents}. +$\AuthPrivate$, as described in \crossref{sproutkeycomponents}.} } %sproutspecific \saplingonward{ -The \authSigningKey $\AuthSignPrivate$, +\defining{The \authSigningKey $\AuthSignPrivate$, \authProvingKey $(\AuthSignPublic, \AuthProvePrivate)$, \fullViewingKey $(\AuthSignPublic, \AuthProvePublic, \OutViewingKey)$, \incomingViewingKey $\InViewingKey$, and each \diversifiedPaymentAddress $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$ -are derived from $\SpendingKey$, as described in \crossref{saplingkeycomponents}. +are derived from $\SpendingKey$, as described in \crossref{saplingkeycomponents}.} } %saplingonward The composition of \paymentAddresses, \changed{\incomingViewingKeys,} @@ -2479,9 +2493,9 @@ of scanning the \blockchain for relevant \transactions. \vspace{-1ex} \pnote{ It is conventional in cryptography to refer to the key used to encrypt -a message in an asymmetric encryption scheme as the \quotedterm{public key}. -However, the public key used as the \transmissionKey component of an address -($\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$}) need not be +a message in an asymmetric encryption scheme as the \definingquotedterm{public key}. +However, the public key used as \defining{the \transmissionKey component of an address +($\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$})} need not be publically distributed; it has the same distribution as the \paymentAddress itself. As mentioned above, limiting the distribution of the \paymentAddress is important for some use cases. This also helps to reduce reliance of the overall protocol @@ -2496,13 +2510,13 @@ in order to exploit a hypothetical weakness in that cryptosystem. \subsection{\Notes} \label{notes} \sprout{ -A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, +A \defining{\note} (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, \NoteAddressRand, \NoteCommitRand)}$. It represents that a value $\Value$ is spendable by the recipient who holds the \spendingKey $\AuthPrivate$ corresponding to $\AuthPublic$, as described in the previous section. } %sprout \notsprout{ -A \note (denoted $\NoteTuple{}$) can be a \Sprout \note\sapling{ or a +A \defining{\note} (denoted $\NoteTuple{}$) can be a \Sprout \note\sapling{ or a \Sapling \note}. In either case it represents that a value $\Value$ is spendable by the recipient who holds the \spendingKey corresponding to a given \paymentAddress. @@ -2644,7 +2658,7 @@ The \notePlaintexts in each \joinSplitDescription are encrypted to the respective \transmissionKeys $\TransmitPublicNew{\allNew}$. \introlist -Each \SproutOrNothing{} \notePlaintext (denoted $\NotePlaintext{}$) consists of +Each \SproutOrNothing{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists of \vspace{-1ex} \begin{formulae} @@ -2657,7 +2671,7 @@ The \notePlaintext in each \outputDescription is encrypted to the \diversifiedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$. \introlist -Each \Sapling{} \notePlaintext (denoted $\NotePlaintext{}$) consists of +Each \Sapling{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists of \vspace{-1ex} \begin{formulae} @@ -2687,13 +2701,13 @@ in the tree refers to its parent via the $\hashPrevBlock$ \blockHeader field A path from the root toward the leaves of the tree consisting of a sequence of one or more valid \blocks consistent with consensus rules, is called a -\validBlockchain. +\defining{\validBlockchain}. -Each \block in a \blockchain has a \blockHeight. The \blockHeight of the -\genesisBlock is $0$, and the \blockHeight of each subsequent \block in the -\blockchain increments by $1$. +Each \block in a \defining{\blockchain} has a \defining{\blockHeight}. The \blockHeight +of the \defining{\genesisBlock} is $0$, and the \blockHeight of each subsequent \block +in the \blockchain increments by $1$. -In order to choose the \bestValidBlockchain in its view of the +In order to choose the \defining{\bestValidBlockchain} in its view of the overall \block tree, a node sums the work, as defined in \crossref{workdef}, of all \blocks in each \validBlockchain, and considers the \validBlockchain with greatest total work to be best. To break ties between leaf \blocks, a node will prefer the @@ -2706,9 +2720,9 @@ up to that height. \subsection{Transactions and Treestates} \label{transactions} -Each \block contains one or more \transactions. +Each \block contains one or more \defining{\transactions}. -\xTransparentInputs to a \transaction insert value into a \transparentValuePool +\defining{\xTransparentInputs} to a \transaction insert value into a \defining{\transparentValuePool} associated with the \transaction, and \transparentOutputs remove value from this pool. As in \Bitcoin, the remaining value in the pool is available to miners as a fee. @@ -2719,9 +2733,9 @@ The remaining value in the \transparentValuePool{} \MUST be nonnegative. \vspace{2ex} \introlist -\sprout{To each \transaction there is associated an initial \treestate. +\sprout{To each \transaction there is associated an initial \defining{\treestate}. A \treestate consists of:} -\notsprout{To each \transaction there are associated initial \treestates +\notsprout{To each \transaction there are associated initial \defining{\treestates} for \Sprout\sapling{ and for \Sapling}. \sapling{Each} \treestate consists of:} \begin{itemize} @@ -2733,7 +2747,7 @@ Validation state associated with \transparentTransfers, such as the UTXO (Unspent Transaction Output) set, is not described in this document; it is used in essentially the same way as in \Bitcoin. -An \anchor is a Merkle tree root of a \noteCommitmentTree\sapling{ (either the +An \defining{\anchor} is a Merkle tree root of a \noteCommitmentTree\sapling{ (either the \Sprout tree or the \Sapling tree)}. It uniquely identifies a \noteCommitmentTree state given the assumed security properties of the Merkle tree's \hashFunction. Since the \nullifierSet is always updated together with the @@ -2761,8 +2775,8 @@ In a given \blockchain, \sapling{for each of \Sprout and \Sapling,} \subsection{\JoinSplitTransfers{} and Descriptions} \label{joinsplit} -A \joinSplitDescription is data included in a \transaction that describes a \joinSplitTransfer, -i.e.\ a \shielded value transfer. +A \defining{\joinSplitDescription} is data included in a \transaction that describes a +\defining{\joinSplitTransfer}, i.e.\ a \shielded value transfer. \sprout{This kind of value transfer is} \notsprout{In \Sprout, this kind of value transfer was} the primary \Zcash-specific operation performed by \transactions. @@ -2815,11 +2829,11 @@ it is not known where it will eventually appear in a mined \block. Therefore the \sapling{ \subsection{\SpendTransfers, \OutputTransfers, and their Descriptions} \label{spendsandoutputs} -\joinSplitTransfers are not used for \Sapling \notes. Instead, there is a +\joinSplitTransfers are not used for \Sapling \notes. \defining{Instead, there is a separate \spendTransfer for each \shieldedInput, and a separate \outputTransfer -for each \shieldedOutput. +for each \shieldedOutput.} -\spendDescriptions and \outputDescriptions are data included in a transaction +\defining{\spendDescriptions and \outputDescriptions} are data included in a transaction that describe \spendTransfers and \outputTransfers, respectively. A \spendTransfer spends a \note $\nOld{}$. Its \spendDescription includes a @@ -2828,7 +2842,7 @@ It is associated with an instance of a \spendStatement (\crossref{spendstatement for which it provides a \zkSNARKProof{}. An \outputTransfer creates a \note $\nNew{}$. Similarly, its \outputDescription -includes a \xPedersenValueCommitment to the \note value. +includes a \defining{\xPedersenValueCommitment} to the \note value. It is associated with an instance of an \outputStatement (\crossref{outputstatement}) for which it provides a \zkSNARKProof{}. @@ -2841,7 +2855,7 @@ The result of adding two \xPedersenValueCommitments, committing to values $\Valu $\Value_2$, is a new \xPedersenValueCommitment that commits to $\Value_1 + \Value_2$. Subtraction works similarly. -Therefore, balance can be enforced by adding all of the \valueCommitments for +Therefore, balance can be enforced by adding all of the \defining{\valueCommitments} for \shieldedInputs, subtracting all of the \valueCommitments for \shieldedOutputs, and proving by use of a \bindingSignature (as described in \crossref{bindingsig}) that the result commits to a value consistent with the net \transparent value change. @@ -2879,32 +2893,32 @@ for the whole \transaction to balance. \vspace{-2ex} %\sapling{\todo{The commitment indices in the above diagram should be zero-based to reflect the \notePosition{}.}} -A \noteCommitmentTree is an \incrementalMerkleTree of fixed depth used to store +\defining{A \noteCommitmentTree is an \incrementalMerkleTree} of fixed depth used to store \noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers} produce. -Just as the \term{unspent transaction output set} (UTXO set) used in \Bitcoin, +Just as the \defining{\utxoSet} (UTXO set) used in \Bitcoin, it is used to express the existence of value and the capability to spend it. However, unlike the UTXO set, it is \emph{not} the job of this tree to protect against double-spending, as it is append-only. -A \merkleRoot of a \noteCommitmentTree is associated with each \treestate +A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate (\crossref{transactions}). -Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash of -size $\MerkleHashLengthSprout$ \sapling{ or $\MerkleHashLengthSapling$} bits. -The \merkleLayer numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has -$2^h$ \merkleNodes with \merkleIndices $0$ to $2^h-1$ inclusive. -The \merkleHash associated with the \merkleNode at \merkleIndex $i$ in \merkleLayer $h$ +Each \defining{\merkleNode} in the \incrementalMerkleTree is associated with a +\defining{\merkleHash} of size $\MerkleHashLengthSprout$ \sapling{ or $\MerkleHashLengthSapling$} bits. +The \defining{\merkleLayer} numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has +$2^h$ \merkleNodes with \defining{\merkleIndices} $0$ to $2^h-1$ inclusive. +The \defining{\merkleHash} associated with the \merkleNode at \merkleIndex $i$ in \merkleLayer $h$ is denoted $\MerkleNode{h}{i}$. -The index of a \note's \xCommitment at the leafmost layer -($\MerkleDepthSproutOrSapling$) is called its \notePosition. +The \merkleIndex of a \notesCommitment at the leafmost layer +($\MerkleDepthSproutOrSapling$) is called its \defining{\notePosition}. \subsection{\NullifierSets} \label{nullifierset} -Each \fullValidator maintains a \nullifierSet logically associated with each \treestate. +Each \fullValidator maintains a \defining{\nullifierSet} logically associated with each \treestate. As valid \transactions containing \joinSplitTransfers \sapling{ or \spendTransfers} are -processed, the \nullifiers revealed in \joinSplitDescriptions \sapling{ and \spendDescriptions} +processed, the \defining{\nullifiers} revealed in \joinSplitDescriptions \sapling{ and \spendDescriptions} 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. @@ -2917,11 +2931,11 @@ considered disjoint, even if they have the same bit pattern.} } -\subsection{Block Subsidy and Founders' Reward} \label{subsidyconcepts} +\subsection{Block Subsidy and \FoundersRewardText} \label{subsidyconcepts} Like \Bitcoin, \Zcash creates currency when \blocks are mined. The value created on -mining a \block is called the \blockSubsidy. It is composed of a \minerSubsidy and a -\foundersReward. As in \Bitcoin, the miner of a \block also receives \transactionFees. +mining a \block is called the \defining{\blockSubsidy}. It is composed of a \defining{\minerSubsidy} and a +\foundersReward. As in \Bitcoin, the miner of a \block also receives \defining{\transactionFees}. The calculations of the \blockSubsidy, \minerSubsidy, and \foundersReward depend on the \blockHeight, as defined in \crossref{blockchain}. @@ -2931,7 +2945,7 @@ These calculations are described in \crossref{subsidies}. \subsection{\CoinbaseTransactions} \label{coinbasetransactions} -The first (and only the first) \transaction in a block is a \coinbaseTransaction, +The first (and only the first) \transaction in a block is a \defining{\coinbaseTransaction}, which collects and spends any \minerSubsidy and \transactionFees paid by \transactions included in this \block. The \coinbaseTransaction{} \MUST also pay the \foundersReward as described in \crossref{foundersreward}. @@ -2978,8 +2992,8 @@ It is instantiated in \crossref{hsigcrh}. $\EquihashGen{} \typecolon (n \typecolon \PosInt) \times \PosInt \times \byteseqs \times \PosInt \rightarrow \bitseq{n}$ is another \hashFunction, used in \crossref{equihash} to generate -input to the Equihash solver. The first two arguments, representing -the Equihash parameters $n$ and $k$, are written subscripted. +input to the \Equihash solver. The first two arguments, representing +the \Equihash parameters $n$ and $k$, are written subscripted. It is instantiated in \crossref{equihashgen}. } @@ -3006,7 +3020,7 @@ from a \diversifier in \crossref{saplingkeycomponents}. \introsection \subsubsection{\PseudoRandomFunctions} \label{abstractprfs} -$\PRF{x}{}$ is a \pseudoRandomFunction keyed by $x$. +$\PRF{x}{}$ is a \defining{\pseudoRandomFunction} keyed by $x$. Let $\AuthPrivateLength$, $\NoteAddressPreRandLength$, $\hSigLength$, $\PRFOutputLengthSprout$, \sapling{$\SpendingKeyLength$, $\OutViewingKeyLength$, @@ -3054,7 +3068,7 @@ $\PRFnfSapling{}$ is used in \crossref{spendstatement}. \vspace{-2ex} \begin{securityrequirements} - \item Security definitions for \pseudoRandomFunctions are given in \cite[section 4]{BDJR2000}. + \item Security definitions for \defining{\pseudoRandomFunctions} are given in \cite[section 4]{BDJR2000}. \item In addition to being \pseudoRandomFunctions, it is required that $\PRFnf{x}$,\changed{ $\PRFaddr{x}$,\sprout{ and} $\PRFrho{x}$}\sapling{, and $\PRFnfSapling{x}$} be \collisionResistant across all $x$ --- i.e.\ finding $(x, y) \neq (x', y')$ @@ -3069,7 +3083,7 @@ $\PRFnfSapling{}$ is used in \crossref{spendstatement}. \introsection \subsubsection{\SymmetricEncryption} \label{abstractsym} -Let $\Sym$ be an \symmetricEncryptionScheme with keyspace $\Keyspace$, encrypting +Let $\Sym$ be an \defining{\symmetricEncryptionScheme} with keyspace $\Keyspace$, encrypting plaintexts in $\Plaintext$ to produce ciphertexts in $\Ciphertext$. $\SymEncrypt{} \typecolon \Keyspace \times \Plaintext \rightarrow \Ciphertext$ @@ -3083,15 +3097,15 @@ $\bot$ is used to represent the decryption of an invalid ciphertext. \vspace{-3ex} \securityrequirement{ -$\Sym$ must be one-time (INT-CTXT $\wedge$ IND-CPA)-secure \cite{BN2007}. -\quotedterm{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. +$\Sym$ must be \oneTime (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. } \subsubsection{\KeyAgreement} \label{abstractkeyagreement} -A \keyAgreementScheme is a cryptographic protocol in which two parties agree +A \defining{\keyAgreementScheme} is a cryptographic protocol in which two parties agree a shared secret, each using their private key and the other party's public key. A \keyAgreementScheme $\KA$ defines a type of public keys $\KAPublic$, a type @@ -3128,7 +3142,7 @@ specification. \subsubsection{\KeyDerivation} \label{abstractkdf} -A \keyDerivationFunction is defined for a particular \keyAgreementScheme and +A \defining{\keyDerivationFunction} is defined for a particular \keyAgreementScheme and \symmetricEncryptionScheme; it takes the shared secret produced by the key agreement and additional arguments, and derives a key suitable for the encryption scheme. @@ -3218,7 +3232,7 @@ with $\KASapling$ and derives keys for $\SymEncrypt{}$. \introlist \subsubsection{Signature} \label{abstractsig} -A signature scheme $\Sig$ defines: +A \defining{\signatureScheme} $\Sig$ defines: \begin{itemize} \item a type of signing keys $\SigPrivate$; @@ -3287,7 +3301,7 @@ pair without access to the signing key. \item A fresh signature key pair is generated for each \transaction containing a \joinSplitDescription{}. Since each key pair is only used for one signature (see \crossref{sproutnonmalleability}), - a one-time signature scheme would suffice for $\JoinSplitSig$. + a \defining{\oneTimeSignatureScheme} would suffice for $\JoinSplitSig$. This is also the reason why only security against \emph{non-adaptive} chosen message attack is needed. In fact the instantiation of $\JoinSplitSig$ uses a scheme designed for security under adaptive attack even when multiple @@ -3299,7 +3313,7 @@ pair without access to the signing key. \item SU-CMA security requires it to be infeasible for the adversary, not knowing the private key, to forge a distinct signature on a previously seen message. That is, \joinSplitSignatures\sapling{ and \bindingSignatures} - are intended to be nonmalleable in the sense of \cite{BIP-62}. + are intended to be \defining{\sigNonmalleable} in the sense of \cite{BIP-62}. \end{nnotes} @@ -3307,7 +3321,7 @@ pair without access to the signing key. \introsection \subsubsubsection{Signature with Re-Randomizable Keys} \label{abstractsigrerand} -A \rerandomizableSignatureScheme $\Sig$ is a \signatureScheme that +A \defining{\rerandomizableSignatureScheme} $\Sig$ is a \signatureScheme that additionally defines: \begin{itemize} @@ -3400,7 +3414,7 @@ $(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$. \introlist \subsubsubsection{Signature with Private Key to Public Key Homomorphism} \label{abstractsighom} -A \keyHomomorphicSignatureScheme $\Sig$ is a \signatureScheme that +A \defining{\keyHomomorphicSignatureScheme} $\Sig$ is a \signatureScheme that additionally defines: \begin{itemize} @@ -3437,7 +3451,7 @@ and $\vk_1 \combminus \vk_2$ means $\vk_1 \combplus\, (\combneg \vk_2)$. \vspace{2ex} With a change of notation from $\mu$ to $\SigDerivePublic$, $+$ to $\grpplus$, and $\mult$ to $\combplus$, -this is similar to the definition of a \quotedterm{Signature with Secret Key to Public Key Homomorphism} +this is similar to the definition of a \quotedtermnoindex{Signature with Secret Key to Public Key Homomorphism} in \cite[Definition 13]{DS2016}, except for an additional requirement for the homomorphism to be injective. \introsection @@ -3456,14 +3470,16 @@ when at least one of $\sk_{\alln}$ is unknown.) \introlist \subsubsection{Commitment} \label{abstractcommit} +\defining{ A \commitmentScheme is a function that, given a \commitmentTrapdoor generated at random and an input, can be used to commit to the input in such a way that: \begin{itemize} - \item no information is revealed about it without the \trapdoor (\quotedterm{hiding}), - \item given the \trapdoor and input, the commitment can be verified to \quotedterm{open} - to that input and no other (\quotedterm{binding}). + \item no information is revealed about it without the \trapdoor (\quotedtermandindex{hiding}{hiding (commitment scheme)}), + \item given the \trapdoor and input, the commitment can be verified to \quotedtermandindex{open}{open (a commitment)} + to that input and no other (\quotedtermandindex{binding}{binding (commitment scheme)}). \end{itemize} +} %defining \vspace{-3ex} A \commitmentScheme $\CommitAlg$ defines a type of inputs $\CommitInput$, @@ -3629,8 +3645,8 @@ efficiently computable left inverse. \introlist \subsubsection{Group Hash} \label{abstractgrouphash} -Given a \representedSubgroup $\SubgroupG{}$, a \term{family of group hashes into\, $\SubgroupG{}$}, -$\GroupGHash{}$, consists of: +Given a \representedSubgroup $\SubgroupG{}$, a \familyOfGroupHashesIntoTheSubgroup, +denoted $\GroupGHash{}$, consists of: \begin{itemize} \item a type $\GroupGHashURSType$ of \uniformRandomStrings; @@ -3714,18 +3730,18 @@ A \representedPairing $\GroupP{}$ consists of: \subsubsection{\ZeroKnowledgeProvingSystem} \label{abstractzk} -A \zeroKnowledgeProvingSystem is a cryptographic protocol that allows +\defining{A \zeroKnowledgeProvingSystem is a cryptographic protocol that allows proving a particular \statement, dependent on \primary and \auxiliaryInputs, in zero knowledge --- that is, without revealing information about the -\auxiliaryInputs other than that implied by the \statement. The type of -\zeroKnowledgeProvingSystem needed by \Zcash is a \ppzkSNARK. +\auxiliaryInputs other than that implied by the \statement.} The type of +\zeroKnowledgeProvingSystem needed by \Zcash is a \defining{\ppzkSNARK}. \introlist A \ppzkSNARK instance $\ZK$ defines: \begin{itemize} - \item a type of \zkProvingKeys, $\ZKProvingKey$; - \item a type of \zkVerifyingKeys, $\ZKVerifyingKey$; + \item a type of \defining{\zkProvingKeys}, $\ZKProvingKey$; + \item a type of \defining{\zkVerifyingKeys}, $\ZKVerifyingKey$; \item a type of \primaryInputs $\ZKPrimary$; \item a type of \auxiliaryInputs $\ZKAuxiliary$; \item a type of proofs $\ZKProof$; @@ -3786,8 +3802,8 @@ infeasible to find a new proof $\Proof{}$ where $\ZKVerify{\vk}(x, \Proof{}) = 1 \emph{there existing} an \auxiliaryInput $w$ such that $(x, w) \in \ZKSatisfying$. \vspace{-1ex} -\nnote{The above properties do not include nonmalleability \cite{DSDCOPS2001}, and the -design of the protocol using the \zeroKnowledgeProvingSystem must take this +\nnote{The above properties do not include \defining{\proofNonmalleability} \cite{DSDCOPS2001}, +and the design of the protocol using the \zeroKnowledgeProvingSystem must take this into account.} \vspace{2ex} @@ -3968,7 +3984,7 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. \begin{pnotes} \vspace{-1ex} \item The protocol does not prevent using the \diversifier $\Diversifier$ to produce - \quotedterm{vanity} addresses that start with a meaningful string when + \definingquotedterm{vanity} addresses that start with a meaningful string when encoded in Bech32 (see \crossref{saplingpaymentaddrencoding}). Users and writers of software that generates addresses should be aware that this provides weaker privacy properties than a randomly chosen \diversifier, @@ -3984,13 +4000,13 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. \vspace{-3ex} \begin{nnotes} \vspace{-0.5ex} - \item Assume that $\PRFexpand{}$ is a PRF with output range $\PRFOutputExpand$, where + \item Assume that $\PRFexpand{}$ is a \xPRF with output range $\PRFOutputExpand$, where $2^{\PRFOutputLengthExpand}$ is large compared to $\ParamJ{r}$. Define $f \typecolon \SpendingKeyType \times \PRFInputExpand \rightarrow \GF{\ParamJ{r}}$ by $f_{\sk}(t) := \ToScalar(\PRFexpand{\SpendingKey}(t))$. - Then $f$ is also a PRF, since + Then $f$ is also a \xPRF, since $\LEOStoIP{\PRFOutputLengthExpand} \typecolon \PRFOutputExpand \rightarrow \binaryrange{\PRFOutputLengthExpand}$ is injective, and the bias introduced by the reduction modulo $\ParamJ{r}$ is small because \crossref{constants} defines $\PRFOutputLengthExpand$ as $512$, while $\ParamJ{r}$ @@ -4008,7 +4024,7 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. is bijective, the distribution of $\reprJ\Of{\AuthProvePublic}$ will be computationally indistinguishable from the uniform distribution on $\SubgroupReprJ$ which is the keyspace of $\PRFnfSapling{}$. - \item The zcashd wallet generates \diversifiers according to \cite{ZIP-32} rather than + \item The \zcashd wallet generates \diversifiers according to \cite{ZIP-32} rather than using the default \diversifier specified above. \end{nnotes} \vspace{-2ex} @@ -4277,7 +4293,7 @@ this payment. This may be one of: \begin{itemize} \item the \outgoingViewingKey for the address (or one of the addresses) from which the payment was sent; - \item the \outgoingViewingKey for all payments associated with an \quotedterm{account}, + \item the \outgoingViewingKey for all payments associated with an \definingquotedterm{account}, to be defined in \cite{ZIP-32}; \item $\bot$, if the sender should not be able to decrypt the payment once it has deleted its own copy. @@ -4350,7 +4366,7 @@ scope of this specification. The encoded \transaction is submitted to the networ The fields in a \joinSplitDescription allow for $\NOld$ input \notes, and $\NNew$ output \notes. In practice, we may wish to encode a \joinSplitTransfer -with fewer input or output \notes. This is achieved using \dummyNotes. +with fewer input or output \notes. This is achieved using \dummy \notes. Let $\AuthPrivateLength$ and $\PRFOutputLengthSprout$ be as defined in \crossref{constants}. @@ -4386,7 +4402,7 @@ zero value, and sent to a random \paymentAddress. \introsection \subsubsection{\DummyNotes{} (\SaplingText)} \label{saplingdummynotes} -In \Sapling there is no need to use \dummyNotes simply in order to fill +In \Sapling there is no need to use \dummy \notes simply in order to fill otherwise unused inputs as in the case of a \joinSplitDescription; nevertheless it may be useful for privacy to obscure the number of real \shieldedInputs from \Sapling{} \notes{}. @@ -4627,7 +4643,7 @@ according to client implementation. \Sapling adds \spendTransfers and \outputTransfers to the transparent and \joinSplitTransfers present in \Sprout. The net value of \spendTransfers minus \outputTransfers in a \transaction is -called the \balancingValue, measured in \zatoshi as a signed integer $\vBalance$. +called the \defining{\balancingValue}, measured in \zatoshi as a signed integer $\vBalance$. $\vBalance$ is encoded explicitly in a \transaction as the field \valueBalance{}; see \crossref{txnencoding}. @@ -4639,7 +4655,7 @@ As a result, positive $\vBalance$ is treated like an \emph{input} to the from that pool. Consistency of $\vBalance$ with the \valueCommitments in \spendDescriptions -and \outputDescriptions is enforced by the \bindingSignature. This signature +and \outputDescriptions is enforced by the \defining{\bindingSignature}. This signature has a dual rôle in the \Sapling protocol: \begin{itemize} @@ -4797,7 +4813,7 @@ other parties that are cooperating to create the \transaction. If all of the \nnote{ The technique of checking signatures using a public key derived from a sum of \xPedersenCommitments is also used in the \Mimblewimble protocol \cite{Jedusor2016}. -The private key $\BindingPrivate$ acts as a \quotedterm{synthetic blinding factor}, +The private key $\BindingPrivate$ acts as a \definingquotedterm{synthetic blinding factor}, in the sense that it is synthesized from the other blinding factors (trapdoors) $\ValueCommitRandOld{\alln}$ and $\ValueCommitRandNew{\allm}$; this technique is also used in \Bulletproofs \cite{Dalek-notes}. @@ -5331,9 +5347,9 @@ for that \blockchain. \item The decryption algorithm corresponds to step 3 (b) i. and ii. (first bullet point) of the $\Receive$ algorithm shown in \cite[Figure 2]{BCGGMTV2014}. \vspace{-0.5ex} - \item A \note can change from being unspent to spent as a node's view of the best - \blockchain is extended by new \transactions. Also, \blockchain reorganizations - can cause a node to switch to a different best \blockchain that does not + \item A \note can change from being unspent to spent as a node's view of the + \bestValidBlockchain is extended by new \transactions. Also, \blockchainReorganizations + can cause a node to switch to a different \bestValidBlockchain that does not contain the \transaction in which a \note was output. \end{pnotes} @@ -5473,9 +5489,9 @@ $\nf = \PRFnfSapling{\AuthProvePublicRepr}\big(\reprJ(\NoteAddressRand)\kern-0.1 \vspace{-3ex} \pnote{ -A \note can change from being unspent to spent as a node's view of the best -\blockchain is extended by new \transactions. Also, \blockchain reorganizations -can cause a node to switch to a different best \blockchain that does not +A \note can change from being unspent to spent as a node's view of the +\bestValidBlockchain is extended by new \transactions. Also, \blockchainReorganizations +can cause a node to switch to a different \bestValidBlockchain that does not contain the \transaction in which a \note was output. } %pnote } %sapling @@ -6229,7 +6245,7 @@ Define $\PedersenHashToPoint(D \typecolon \byteseq{8}, M \typecolon \bitseq{\Pos \begin{algorithm} \item Pad $M$ to a multiple of $3$ bits by appending zero bits, giving $M'$. \item Let $n = \ceiling{\hfrac{\length(M')}{3 \mult c}}$. - \item Split $M'$ into $n$ \quotedterm{segments} $M_\barerange{1}{n}$ + \item Split $M'$ into $n$ \definingquotedterm{segments} $M_\barerange{1}{n}$ so that $M' = \concatbits(M_\barerange{1}{n})$, and each of $M_\barerange{1}{n-1}$ is of length $3 \smult c$ bits. ($M_n$ may be shorter.) @@ -6243,7 +6259,7 @@ $\PedersenEncode{\paramdot} \typecolon \bitseq{3 \mult \range{1}{c}} \rightarrow \begin{algorithm} \item Let $k_i = \length(M_i)/3$. - \item Split $M_i$ into $3$-bit \quotedterm{chunks} $m_\barerange{1}{k_i}$ + \item Split $M_i$ into $3$-bit \definingquotedterm{chunks} $m_\barerange{1}{k_i}$ so that $M_i = \concatbits(m_\barerange{1}{k_i})$. \item Write each $m_j$ as $[\sj{0}, \sj{1}, \sj{2}]$, and let $\enc(m_j) = (1 - 2 \smult \sj{2}) \mult (1 + \sj{0} + 2 \smult \sj{1}) \typecolon \Int$. @@ -6374,7 +6390,7 @@ See \crossref{cctmixinghash} for efficient circuit implementation of this functi \introlist -\subsubsubsection{Equihash Generator} \label{equihashgen} +\subsubsubsection{\EquihashText Generator} \label{equihashgen} $\EquihashGen{n, k}$ is a specialized \hashFunction that maps an input and an index to an output of length $n$ bits. It is used in \crossref{equihash}. @@ -6415,13 +6431,13 @@ $\BlakeTwobOf{\ell}{p, x}$ is defined in \crossref{concreteblake2}. \securityrequirement{ $\BlakeTwobOf{\ell}{\powtag, x}$ must generate output that is sufficiently -unpredictable to avoid short-cuts to the Equihash solution process. +unpredictable to avoid short-cuts to the \Equihash solution process. It would suffice to model it as a random oracle. } \pnote{ When $\EquihashGen{}$ is evaluated for sequential indices, as -in the Equihash solving process (\crossref{equihash}), +in the \Equihash solving process (\crossref{equihash}), the number of calls to $\BlakeTwobGeneric$ can be reduced by a factor of $\floor{\frac{512}{n}}$ in the best case (which is a factor of 2 for $n = 200$). @@ -6502,7 +6518,7 @@ defined in \crossref{concretesha256}: \begin{securityrequirements} \item The \shaCompressFunction must be \collisionResistant\!. - \item The \shaCompressFunction must be a PRF when keyed by the bits + \item The \shaCompressFunction must be a \xPRF when keyed by the bits corresponding to $x$, $\AuthPrivate$ or $\NoteAddressPreRand$ in the above diagrams, with input in the remaining bits. \end{securityrequirements} @@ -6519,7 +6535,7 @@ function; see \crossref{concretesproutnotecommit}. (The specific bit patterns chosen here were motivated by the possibility of future extensions that might have increased $\NOld$ and/or $\NNew$ to 3, or added an additional bit to $\AuthPrivate$ to encode a new key type, or that would have -required an additional PRF.\sapling{ In fact since \Sapling switches to +required an additional \xPRF.\sapling{ In fact since \Sapling switches to non-$\SHACompress$-based cryptographic primitives, these extensions are unlikely to be necessary.}) } @@ -6561,7 +6577,7 @@ It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in \vspace{-4.5ex} \securityrequirement{ -$\BlakeTwobOf{512}{\ascii{Zcash\_ExpandSeed}, \LEBStoOSPOf{256}{\SpendingKey} \bconcat t}$ must be a PRF for output range +$\BlakeTwobOf{512}{\ascii{Zcash\_ExpandSeed}, \LEBStoOSPOf{256}{\SpendingKey} \bconcat t}$ must be a \xPRF for output range $\PRFOutputExpand$ when keyed by the bits corresponding to $\SpendingKey$, with input in the bits corresponding to $t$. } %securityrequirement @@ -6599,7 +6615,7 @@ It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \cross \vspace{-3.5ex} \securityrequirement{ $\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a -\collisionResistant PRF for output range $\byteseq{32}$ when keyed by the bits +\collisionResistant \xPRF for output range $\byteseq{32}$ when keyed by the bits corresponding to $\AuthProvePublicRepr$, with input in the bits corresponding to $\NoteAddressRandRepr$. Note that {$\AuthProvePublicRepr$}{$\typecolon$}{$\SubgroupReprJ$} % {$...$} hack needed for reasonable spacing @@ -7001,8 +7017,8 @@ Let $\RedJubjub$ be as defined in \crossref{concreteredjubjub}. Define $\AuthSignBase := \FindGroupJHash\Of{\ascii{Zcash\_G\_}, \ascii{}}$. -$\SpendAuthSig$ is instantiated as $\RedJubjub$ with key re-randomization, and -with generator $\GenG{} = \AuthSignBase$. +The \defining{\spendAuthSignatureScheme}, $\SpendAuthSig$, is instantiated as $\RedJubjub$ +with key re-randomization, and with generator $\GenG{} = \AuthSignBase$. \vspace{2ex} See \crossref{spendauthsig} for details on the use of this \signatureScheme. @@ -7021,8 +7037,8 @@ Let $\RedJubjub$ be as defined in \crossref{concreteredjubjub}. Let $\ValueCommitRandBase$ be the randomness base defined in \crossref{concretevaluecommit}. -$\BindingSig$ is instantiated as $\RedJubjub$, without use of key re-randomization, -and with generator $\GenG{} = \ValueCommitRandBase$. +The \defining{\bindingSignatureScheme}, $\BindingSig$, is instantiated as $\RedJubjub$ without +use of key re-randomization, and with generator $\GenG{} = \ValueCommitRandBase$. \vspace{2ex} See \crossref{bindingsig} for details on the use of this \signatureScheme. @@ -7073,9 +7089,9 @@ The leading byte of the $\SHAFull$ input is $\hexint{B0}$. \begin{securityrequirements} \item The \shaCompressFunction must be \collisionResistant\!. - \item The \shaCompressFunction must be a PRF when keyed by the bits corresponding + \item The \shaCompressFunction must be a \xPRF when keyed by the bits corresponding to the position of $\NoteCommitRand$ in the second block of $\SHAFull$ - input, with input to the PRF in the remaining bits of the block and + input, with input to the \xPRF in the remaining bits of the block and the chaining variable. \end{securityrequirements} @@ -7085,7 +7101,7 @@ The leading byte of the $\SHAFull$ input is $\hexint{B0}$. \subsubsubsection{Windowed Pedersen commitments} \label{concretewindowedcommit} \label{concretesaplingnotecommit} \crossref{concretepedersenhash} defines a \xPedersenHash construction. -We construct \quotedterm{windowed} \xPedersenCommitments by reusing that construction, +We construct \definingquotedterm{windowed} \xPedersenCommitments by reusing that construction, and adding a randomized point on the \jubjubCurve (see \crossref{jubjub}): \begin{formulae} @@ -7139,7 +7155,7 @@ need when instantiating $\ValueCommit{}$. For more details on the use of this property, see \crossref{saplingbalance} and \crossref{spendsandoutputs}. -In order to support this property, we also define \quotedterm{homomorphic} +In order to support this property, we also define \definingquotedterm{homomorphic} \xPedersenCommitments as follows: \begin{formulae} @@ -7720,7 +7736,7 @@ It is described completely in \cite[Theorem 2.4]{BCTV2014a} and in In practice it will be necessary to use the specific proving and verification keys that were generated for the \Zcash production \blockchain, given in \crossref{bctvparameters}, together with a \provingSystem implementation that is -interoperable with the \Zcash fork of \libsnark, to ensure compatibility. +interoperable with the \Zcash fork of \defining{\libsnark}, to ensure compatibility. } \vuln{ @@ -7803,7 +7819,7 @@ After \Sapling activation, \Zcash uses \zkSNARKs with the \provingSystem describ security proof of this system is given in \cite{Maller2018}. These \zkSNARKs are used in \transactionVersion 4 and later (\crossref{txnencoding}) for proofs both in \Sprout \joinSplitDescriptions, and in \Sapling \spendDescriptions and \outputDescriptions. -They are generated by the \bellman library \cite{Bowe-bellman}. +They are generated by the \defining{\bellman} library \cite{Bowe-bellman}. A $\Groth$ proof consists of $(\Proof{A} \typecolon \SubgroupSstar{1},\, @@ -8399,14 +8415,14 @@ It is derived as described in \cite{Bowe2018}: \section{Network Upgrades} \label{networkupgrades} \Zcash launched with a protocol revision that we call \Sprout. -A first network upgrade, called \Overwinter, activated on the production \Zcash network +A first \networkUpgrade, called \Overwinter, activated on the production \Zcash network on 26 June 2018 at block height $347500$ \cite{Swihart2018}. A second upgrade, called \Sapling, activated on the production network on 28 October 2018 at block height $419200$ \cite{Hamdon2018}. This section summarizes the strategy for upgrading from \Sprout to \Overwinter to \Sapling, and then to future upgrades. -The upgrade mechanism is described in \cite{ZIP-200}. +\defining{The \networkUpgrade mechanism is described in \cite{ZIP-200}.} \overwinter{The specifications of the \Overwinter upgrade are described in this document, \cite{ZIP-201}, \cite{ZIP-202}, \cite{ZIP-203}, and \cite{ZIP-143}.} \sapling{The specifications of the \Sapling upgrade are described in this document, @@ -8414,22 +8430,22 @@ The upgrade mechanism is described in \cite{ZIP-200}. \vspace{1ex} \introlist -Each network upgrade is introduced as a -\quotedterm{bilateral consensus rule change}. In this kind of upgrade, +Each \networkUpgrade is introduced as a +\definingquotedterm{bilateral consensus rule change}. In this kind of upgrade, \begin{itemize} - \item there is a \blockHeight at which the \consensusRuleChange + \item there is an \defining{\activationHeight} at which the \consensusRuleChange takes effect; \item \blocks and \transactions that are valid according to the post-upgrade rules are not valid before the upgrade \blockHeight; \item \blocks and \transactions that are valid according to the pre-upgrade rules are no longer valid at or after the - upgrade \blockHeight. + \activationHeight. \end{itemize} -Full support for each upgrade is indicated by a minimum version -of the peer-to-peer protocol. At the planned upgrade \blockHeight, +Full support for each \networkUpgrade is indicated by a minimum version +of the peer-to-peer protocol. 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 @@ -8443,9 +8459,9 @@ network. This allows us to specify arbitrary protocol changes that take effect at a given \blockHeight. Note, however, that a -\blockchain reorganization across the upgrade \blockHeight is possible. +\blockchainReorganization across the upgrade \activationHeight is possible. In the case of such a reorganization, \blocks at a height -before the upgrade \blockHeight will still be created and +before the \activationHeight will still be created and validated according to the pre-upgrade rules, and upgrade-supporting nodes \MUST allow for this. @@ -8631,7 +8647,7 @@ each \spendDescription (\crossref{spendencoding}), and each \outputDescription ( % \item \todo{Describe interpretation of \fOverwintered{} and \versionField{}.} %} \overwinteronwarditem{The purpose of \versionGroupID{} is to allow unambiguous parsing of - \quotedterm{loose} \transactions, independent of the context of a \blockchain. + \definingquotedterm{loose} \transactions, independent of the context of a \blockchain. Code that parses \transactions is likely to be reused between \blockchain \branches as defined in \cite{ZIP-200}, and in that case the \fOverwintered{} and \versionField{} fields alone may be insufficient to determine the format to be used for parsing.} @@ -8697,7 +8713,7 @@ $32$ & $\anchorField$ & \type{char[32]} & A \merkleRoot $\rt$ of the \SproutOrNo $64$ & $\nullifiersField$ & \type{char[32][$\NOld$]} & A sequence of \nullifiers of the input \notes $\nfOld{\allOld}$. \\[0.4ex] \hline -$64$ & $\commitments$ & \type{char[32][$\NNew$]} & A sequence of \noteCommitments for the +$64$ & $\commitmentsField$ & \type{char[32][$\NNew$]} & A sequence of \noteCommitments for the output \notes $\cmNew{\allNew}$. \\ \hline \setchanged $32$ &\setchanged $\ephemeralKey$ &\setchanged \type{char[32]} &\mbox{}\setchanged @@ -8725,10 +8741,10 @@ components for the encrypted output \notes, $\TransmitCiphertext{\allNew}$. \\ \ \end{center} \notsprout{ -$\dagger$ $\BCTV$ proofs are used when the \transaction version is $2$ or $3$, i.e.\ before +$\dagger$ $\BCTV$ proofs are used when the \transactionVersion is $2$ or $3$, i.e.\ before \Sapling activation. -\sapling{$\ddagger$ $\Groth$ proofs are used when the \transaction version is $\geq 4$, i.e.\ after +\sapling{$\ddagger$ $\Groth$ proofs are used when the \transactionVersion is $\geq 4$, i.e.\ after \Sapling activation.} } @@ -8879,9 +8895,9 @@ $4$ & $\nBitsField$ & \type{uint32} & An encoded version of the \targetThreshold $32$ & $\nNonce$ & \type{char[32]} & An arbitrary field that miners can change to modify the \header hash in order to produce a hash less than or equal to the \targetThreshold. \\ \hline -$3$ & $\solutionSize$ & \compactSize & The size of an Equihash solution in bytes (always $1344$). \\ \hline +$3$ & $\solutionSize$ & \compactSize & The size of an \Equihash solution in bytes (always $1344$). \\ \hline -$1344$ & $\solution$ & \type{char[1344]} & The Equihash solution. \\ \hline +$1344$ & $\solution$ & \type{char[1344]} & The \Equihash solution. \\ \hline \end{tabularx} \end{center} @@ -8901,7 +8917,7 @@ be the constant defined in \crossref{constants}. \item For a \block at \blockHeight $\BlockHeight$, $\nBitsField$ \MUST be equal to $\ThresholdBits(\BlockHeight)$. \item The \block{} \MUST pass the difficulty filter defined in \crossref{difficulty}. - \item $\solution$ \MUST represent a valid Equihash solution as defined in \crossref{equihash}. + \item $\solution$ \MUST represent a \validEquihashSolution as defined in \crossref{equihash}. \item $\nTimeField$ \MUST be strictly greater than the median time of the previous $\PoWMedianBlockSpan$ \blocks. \item The size of a \block{} \MUST be less than or equal to $2000000$ bytes. @@ -8935,7 +8951,7 @@ rejected by this rule at a given point in time may later be accepted. \item Like other serialized fields of type $\compactSize$, the $\solutionSize$ field \MUST be encoded with the minimum number of bytes ($3$ in this case), and other encodings \MUST be rejected. This is necessary to avoid a potential attack in which a miner - could test several distinct encodings of each Equihash solution against the difficulty + could test several distinct encodings of each \Equihash solution against the difficulty filter, rather than only the single intended encoding. \item As in \Bitcoin, the $\nTimeField$ field \MUST represent a time \emph{strictly greater than} the median of the timestamps of the past $\PoWMedianBlockSpan$ \blocks. The @@ -8966,7 +8982,7 @@ The changes relative to \Bitcoin version $4$ blocks as described in \cite{Bitcoi \intropart \subsection{Proof of Work} -\Zcash uses Equihash \cite{BK2016} as its Proof of Work. Motivations for +\Zcash uses \Equihash \cite{BK2016} as its Proof of Work. Motivations for changing the Proof of Work from \SHAd used by \Bitcoin are described in \cite{WG2016}. @@ -8980,18 +8996,18 @@ A \block satisfies the Proof of Work if and only if: \introsection -\subsubsection{Equihash} \label{equihash} +\subsubsection{\EquihashText} \label{equihash} -An instance of the Equihash algorithm is parameterized by positive integers $n$ and $k$, +An instance of the \Equihash algorithm is parameterized by positive integers $n$ and $k$, such that $n$ is a multiple of $k+1$. We assume $k \geq 3$. -The Equihash parameters for the production and test networks are $n = 200, k = 9$. +The \Equihash parameters for the production and test networks are $n = 200, k = 9$. -Equihash is based on a variation of the Generalized Birthday Problem \cite{AR2017}: +\Equihash is based on a variation of the Generalized Birthday Problem \cite{AR2017}: given a sequence $X_\barerange{1}{\rmN}$ of $n$-bit strings, find $2^k$ distinct $X_{i_j}$ such that $\sxor{j=1}{2^k} X_{i_j} = 0$. -In Equihash, $\rmN = 2^{\frac{n}{k+1}+1}$, and the sequence $X_\barerange{1}{\rmN}$ is +In \Equihash, $\rmN = 2^{\frac{n}{k+1}+1}$, and the sequence $X_\barerange{1}{\rmN}$ is derived from the \blockHeader and a nonce. \newsavebox{\powheaderbox} @@ -9040,14 +9056,14 @@ $\vxor{j=1}{2^k} X_{i_j} = 0$. \vspace{-3ex} \begin{pnotes} \item This does not include a difficulty condition, because here we are - defining validity of an Equihash solution independent of difficulty. + defining validity of an \Equihash solution independent of difficulty. \item Previous versions of this specification incorrectly specified the range of $r$ to be $\range{1}{k\!-\!1}$ for both parts of the algorithm binding condition. The implementation in \zcashd was as intended. \end{pnotes} \introlist -An Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\solution$ +An \Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\solution$ field of a \blockHeader as follows: \newsavebox{\solutionbox} @@ -9247,7 +9263,7 @@ in its \blockHeader is defined as $\floor{\hfrac{2^{256}}{\ToTarget(\nBits) + 1} \introlist -\subsection{Calculation of Block Subsidy and Founders' Reward} \label{subsidies} +\subsection{Calculation of Block Subsidy and \FoundersRewardText} \label{subsidies} \crossref{subsidyconcepts} defines the \blockSubsidy, \minerSubsidy, and \foundersReward. Their amounts in \zatoshi are calculated from the \blockHeight using @@ -9286,7 +9302,7 @@ and $\FoundersFraction$ are instantiated in \crossref{constants}. \end{formulae} \introsection -\subsection{Payment of Founders' Reward} \label{foundersreward} +\subsection{Payment of \FoundersRewardText} \label{foundersreward} The \foundersReward is paid by a \transparent output in the \coinbaseTransaction, to one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHeight. @@ -9485,7 +9501,7 @@ and would require an RFC in order to do so.) \introsection \section{Differences from the \ZerocashText{} paper} \label{differences} -\subsection{Transaction Structure} \label{trstructure} +\subsection{\Transaction{} Structure} \label{trstructure} \Zerocash introduces two new operations, which are described in the paper as new transaction types, in addition to the original @@ -9629,7 +9645,7 @@ Instead, \Zcash enforces that an adversary must choose distinct values for each $\NoteAddressRand$, by making use of the fact that all of the \nullifiers in \joinSplitDescriptions that appear in a \validBlockchain must be distinct. This is true regardless of whether the \nullifiers -corresponded to real or dummy notes (see \crossref{sproutdummynotes}). +corresponded to real or \dummy \notes (see \crossref{sproutdummynotes}). The \nullifiers are used as input to $\hSigCRH$ to derive a public value $\hSig$ which uniquely identifies the transaction, as described in \crossref{joinsplitdesc}. ($\hSig$ was already used in \Zerocash @@ -9765,8 +9781,8 @@ on the \jubjubCurve can be broken. \subsection{Changes to PRF inputs and truncation} \label{truncation} -The format of inputs to the PRFs instantiated in \crossref{concreteprfs} -has changed relative to \Zerocash. There is also a requirement for another PRF, +The format of inputs to the \xPRFs instantiated in \crossref{concreteprfs} +has changed relative to \Zerocash. There is also a requirement for another \xPRF, $\PRFrho{}$, which must be domain-separated from the others. In the \Zerocash protocol, $\NoteAddressRandOld{i}$ is truncated from $256$ @@ -9822,8 +9838,8 @@ $\NoteAddressRand$. } \sproutspecific{ -Since the PRFs are instantiated using $\SHACompress$ which has an input block -size of $512$ bits (of which $256$ bits are used for the PRF input and $4$ bits +Since the \xPRFs are instantiated using $\SHACompress$ which has an input block +size of $512$ bits (of which $256$ bits are used for the \xPRF input and $4$ bits are used for domain separation), it was necessary to reduce the size of the PRF key to $252$ bits. The key is set to $\AuthPrivate$ in the case of $\PRFaddr{}$, $\PRFnf{}$, and $\PRFpk{}$, and to $\NoteAddressPreRand$ (which @@ -9905,7 +9921,7 @@ The motivations for this change were as follows: This facilitates security analysis as explained in \cite{DGKM2011} --- see section 7 of that paper for a security proof that can be applied to this construction under the assumption that single-block $\BlakeTwob{256}$ is a - ``weak PRF''. + \definingquotedterm{weak PRF}. Note that $\hSig$ is authenticated, by the \zkSNARKProof\!\!, as having been chosen with knowledge of $\AuthPrivateOld{\allOld}$, so an adversary cannot modify it in a ciphertext from someone else's transaction for use in a @@ -9940,7 +9956,7 @@ $\AuthPrivate$ is $252$ bits, and $\TransmitPrivate$ is no shorter than $\AuthPr \subsection{Omission in \ZerocashText{} security proof} \label{crprf} -The abstract \Zerocash protocol requires $\PRFaddr{}$ only to be a PRF; +The abstract \Zerocash protocol requires $\PRFaddr{}$ only to be a \xPRF; it is not specified to be \collisionResistant\!. This reveals a flaw in the proof of the Balance property. @@ -10028,7 +10044,7 @@ Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. The designers of the \Zcash protocol are the \Zerocash inventors and also Daira Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, Nathan Wilcox, Zooko Wilcox, Jay Graber, Ariel Gabizon, and George Tankersley. -The Equihash proof-of-work algorithm was designed by Alex Biryukov and +The \Equihash proof-of-work algorithm was designed by Alex Biryukov and Dmitry Khovratovich. The authors would like to thank everyone with whom they have discussed the @@ -10140,7 +10156,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. 2019-05-01 \begin{itemize} - \item Fix a specification error in the Founders' Reward calculation during + \item Fix a specification error in the \foundersReward calculation during the slow start period. \item Correct an inconsistency in difficulty adjustment between the spec and \zcashd implementation for the first $\PoWAveragingWindow - 1$ \blocks @@ -10203,7 +10219,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \blocks with a \blockVersionNumber{} greater than $4$, has been removed. This is because such \blocks (mined nonconformantly) exist in the current consensus chain on the production \Zcash network. - \item Clarify that Equihash is based on a \emph{variation} of the Generalized + \item Clarify that \Equihash is based on a \emph{variation} of the Generalized Birthday Problem, and cite \cite{AR2017}. \item Update reference \cite{BGG2017} (previously [BGG2016]). \sapling{ @@ -10505,7 +10521,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Correct the definition of set difference ($S \setminus T$). \item Add a note concerning malleability of \zeroKnowledgeProofs. \item Clarify attribution of the \Zcash protocol design. - \item Acknowledge Alex Biryukov and Dmitry Khovratovich as the designers of Equihash. + \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. \item Acknowledge Tomas Sander and Amnon Ta–Shma for \cite{ST1999}. @@ -10759,7 +10775,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Add a section on re-randomizable signatures. \item Add definition of $\PRF{}{\mathsf{nr}}$. \item Work-in-progress on \Sapling \statements. - \item Rename \quotedterm{raw} to \quotedterm{homomorphic} \xPedersenCommitments. + \item Rename \quotedtermnoindex{raw} to \quotedtermnoindex{homomorphic} \xPedersenCommitments. \item Add packing modulo the field size and range checks to Appendix A. \item Update the algorithm for variable-base scalar multiplication to what is implemented by sapling-crypto. @@ -10942,7 +10958,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. 2017-07-10 \begin{itemize} - \item Fix an off-by-one error in the specification of the Equihash algorithm + \item Fix an off-by-one error in the specification of the \Equihash algorithm binding condition. (The implementation in \zcashd was as intended.) \item Correct the types and consensus rules for \transactionVersionNumbers and \blockVersionNumbers. (Again, the implementation in \zcashd was as @@ -11024,7 +11040,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Make the description of \blockchains more consistent with upstream \Bitcoin documentation (referring to ``best`` chains rather than using the concept of a \term{block chain view}). - \item Define how nodes select a best chain. + \item Define how nodes select a \bestValidBlockchain. \end{itemize} \introlist @@ -11063,7 +11079,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. 2016-10-30 \begin{itemize} - \item Update reference to the Equihash paper \cite{BK2016}. (The newer version + \item Update reference to the \Equihash paper \cite{BK2016}. (The newer version has no algorithmic changes, but the section discussing potential ASIC implementations is substantially expanded.) \item Clarify the discussion of proof size in ``Differences from the \Zerocash paper''. @@ -11075,7 +11091,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Add \foundersReward addresses for the production network. - \item Change \quotedterm{protected} terminology to \quotedterm{shielded}. + \item Change \quotedtermnoindex{protected} terminology to \quotedtermnoindex{shielded}. \end{itemize} \introlist @@ -11110,7 +11126,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. 2016-09-26 \begin{itemize} - \item Fix an error in the definition of the sortedness condition for Equihash: + \item Fix an error in the definition of the sortedness condition for \Equihash: it is the sequences of indices that are sorted, not the sequences of hashes. \item Correct the number of bytes in the encoding of $\solutionSize$. @@ -11190,7 +11206,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. encoding of proofs. Change the encoding of points in proofs to follow IEEE Std 1363[a]. \item Add a section on consensus changes from \Bitcoin, and the specification - of Equihash. + of \Equihash. \item Complete the ``Differences from the \Zerocash paper'' section. \item Correct the Merkle tree depth to 29. \item Change the length of \memos to 512 bytes. @@ -11513,7 +11529,7 @@ Let $n \typecolon \PosInt$ be a constant. The operation of converting a field element, $a \typecolon \GF{\ParamS{r}}$, to a sequence of boolean variables $b_\barerange{0}{n-1} \typecolon \bitseq{n}$ such that $a = \ssum{i=0}{n-1} b_i \mult 2^i \pmod{\ParamS{r}}$, is called -\quotedterm{unpacking}. The inverse operation is called \quotedterm{packing}. +\definingquotedterm{unpacking}. The inverse operation is called \definingquotedterm{packing}. In the \quadraticConstraintProgram these are the same operation (but see the note about canonical representation below). We assume that @@ -12860,7 +12876,7 @@ be as defined in that section. \vspace{2ex} Implementations \MAY alternatively use the optimized procedure described in this section to perform faster verification of a batch of signatures, i.e.\ to determine whether all signatures in a batch are valid. -Its input is a sequence of $N$ \quotedterm{batch entries}, each of which is a +Its input is a sequence of $N$ \defining{\sigBatchEntries}, each of which is a (public key, message, signature) triple. \vspace{2ex} @@ -12898,7 +12914,7 @@ Define $\RedDSABatchVerify \typecolon (\Entry{\barerange{0}{N-1}} \typecolon \ty otherwise $0$. \end{algorithm} -The $z_j$ values \MUST be chosen independently of the batch entries. +The $z_j$ values \MUST be chosen independently of the \sigBatchEntries. The performance benefit of this approach arises partly from replacing the per-signature scalar multiplication of the base $\GenG{}$ with one such multiplication per batch, @@ -12999,7 +13015,7 @@ Define $\GrothSBatchVerify \typecolon (\Entry{\barerange{0}{N-1}} \typecolon \ty otherwise $0$. \end{algorithm} -The $z_j$ values \MUST be chosen independently of the batch entries. +The $z_j$ values \MUST be chosen independently of the \proofBatchEntries. The performance benefit of this approach arises from computing two of the three Miller loops, and the final exponentation, per batch instead of per proof. For the multiplications by $z_j$, an efficient