diff --git a/protocol/protocol.tex b/protocol/protocol.tex index eb7380b1..7dbb3aea 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -15,6 +15,8 @@ \RequirePackage{hhline} \RequirePackage[usestackEOL]{stackengine} \RequirePackage{comment} +\RequirePackage{needspace} +\RequirePackage[nobottomtitles]{titlesec} \RequirePackage[style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=iso8601,backref=true,backrefstyle=none,backend=biber]{biblatex} \addbibresource{zcash.bib} @@ -57,12 +59,18 @@ \setlength{\textwidth}{7in} \setlength{\topmargin}{-0.75in} \setlength{\textheight}{9.2in} -\setlength{\parskip}{1.5ex} \setlength{\parindent}{0ex} \renewcommand{\arraystretch}{1.4} \overfullrule=2cm -\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,after=\vspace{1.5ex}} +\renewcommand{\bottomtitlespace}{8ex} + +% Use rubber lengths between paragraphs to improve default pagination. +% https://tex.stackexchange.com/questions/17178/vertical-spacing-pagination-and-ideal-results +\setlength{\parskip}{1.5ex plus 1pt minus 1pt} + +\setlist[enumerate]{before=\vspace{-1ex}} +\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,before=\vspace{-1ex},after=\vspace{1.5ex}} \newlist{formulae}{itemize}{3} \setlist[formulae]{itemsep=0.2ex,topsep=0ex,leftmargin=1.5em,label=,before=\vspace{-1ex},after=\vspace{1.5ex}} @@ -92,6 +100,8 @@ \newcommand{\nsubsection}[1]{\subsection{\nstrut{#1}}} \newcommand{\nsubsubsection}[1]{\subsubsection{\nstrut{#1}}} +\newcommand{\introlist}{\needspace{15ex}} + \mathchardef\mhyphen="2D % http://tex.stackexchange.com/a/309445/78411 @@ -632,12 +642,12 @@ \newcommand{\EnforceCommit}[1]{\mathsf{enforce}_{#1}} -\newcommand{\consensusrule}[1]{\subparagraph{Consensus rule:}{#1}} -\newenvironment{consensusrules}{\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}} -\newcommand{\securityrequirement}[1]{\subparagraph{Security requirement:}{#1}} -\newenvironment{securityrequirements}{\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}} +\newcommand{\consensusrule}[1]{\needspace{3ex}\subparagraph{Consensus rule:}{#1}} +\newenvironment{consensusrules}{\introlist\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}} +\newcommand{\securityrequirement}[1]{\needspace{3ex}\subparagraph{Security requirement:}{#1}} +\newenvironment{securityrequirements}{\introlist\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}} \newcommand{\pnote}[1]{\subparagraph{Note:}{#1}} -\newenvironment{pnotes}{\subparagraph{Notes:}\begin{itemize}}{\end{itemize}} +\newenvironment{pnotes}{\introlist\subparagraph{Notes:}\begin{itemize}}{\end{itemize}} \begin{document} @@ -678,6 +688,8 @@ 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 lower case as plain English words, absent their normative meanings. +\vspace{2ex} +\introlist This specification is structured as follows: \begin{itemize} @@ -737,6 +749,7 @@ this \spendingKey. An unspent valid \note, at a given point on the \blockchain, is one for which the \noteCommitment has been publically revealed on the \blockchain prior to that point, but the \nullifier has not. +\introlist A \transaction can contain \transparent inputs, outputs, and scripts, which all work as in \Bitcoin \cite{Bitcoin-Protocol}. It also contains a sequence of zero or more \joinSplitDescriptions. Each of these describes a \joinSplitTransfer\hairspace\footnote{ @@ -940,6 +953,7 @@ an adversary would have to know $\TransmitPublic$ in order to exploit a hypothetical weakness in that cryptosystem. } +\needspace{20ex} \nsubsection{\Notes} A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, @@ -1022,6 +1036,7 @@ a \noteCommitmentTree state given the assumed security properties of the Merkle hash function. Since the \nullifierSet is always updated together with the \noteCommitmentTree, this also identifies a particular state of the \nullifierSet. +\introlist In a given node's \blockchainview, \treestates are chained as follows: \begin{itemize} @@ -1150,6 +1165,7 @@ the Equihash parameters $n$ and $k$, are written subscripted. It is instantiated in \crossref{equihashgen}. } +\introlist \nsubsubsection{\PseudoRandomFunctions} \label{abstractprfs} $\PRF{x}{}$ is a \pseudoRandomFunction keyed by $x$. \changed{Four} \emph{independent} @@ -1251,6 +1267,7 @@ independently at random from $\KAPrivate$. Let $\TransmitPublicSup{j} := \KADerivePublic(\TransmitPrivateSup{j})$. +\introlist An adversary can adaptively query a function $Q \typecolon \range{1}{2} \times \hSigType \rightarrow \KAPublic \times \Keyspace_{\allNew}$ where $Q_j(\hSig)$ is defined as follows: @@ -1279,6 +1296,7 @@ This is not considered to be a significant security weakness. } +\introlist \nsubsubsection{Signatures} \label{abstractsig} A signature scheme $\Sig$ defines: @@ -1329,10 +1347,12 @@ pair without access to the signing key. \end{pnotes} +\introlist \nsubsubsection{Commitment} \label{abstractcomm} A \commitmentScheme is a function that, given a random \commitmentTrapdoor 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 (``hiding''), \item given the \trapdoor and input, the commitment can be verified to ``open'' @@ -1357,6 +1377,7 @@ 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. +\introlist A \ppzkSNARK instance $\ZK$ defines: \begin{itemize} @@ -1414,6 +1435,7 @@ Let $\KA$ be a \keyAgreementScheme, instantiated in \crossref{concretekeyagreeme A new \spendingKey $\AuthPrivate$ is generated by choosing a bit string uniformly at random from $\bitseq{\AuthPrivateLength}$. +\introlist \changed{ $\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived from $\AuthPrivate$ @@ -1437,6 +1459,7 @@ Each \transaction includes a sequence of zero or more \joinSplitDescriptions. When this sequence is non-empty, the \transaction also includes encodings of a $\JoinSplitSig$ public verification key and signature. +\introlist Each \joinSplitDescription consists of $(\vpubOld, \vpubNew, \rt, \nfOld{\allOld}, \cmNew{\allNew}, \EphemeralPublic, \RandomSeed, \h{\allOld}, \JoinSplitProof, \TransmitCiphertext{\allNew})$ @@ -1472,6 +1495,7 @@ where The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphertext. +\introlist The value $\hSig$ is also computed from \changed{$\RandomSeed$, $\nfOld{\allOld}$, and} the $\joinSplitPubKey$ of the containing \transaction: @@ -1491,6 +1515,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}. \vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof_{\JoinSplit}) = 1$. \end{consensusrules} +\introlist \nsubsection{Sending \Notes} \label{send} In order to send \shielded value, the sender constructs a \transaction @@ -1501,12 +1526,14 @@ a new $\JoinSplitSig$ key pair: \item $(\joinSplitPrivKey, \joinSplitPubKey) \leftarrowR \JoinSplitSigGen()$. \end{formulae} +\introlist For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at random on $\bitseq{\RandomSeedLength}$, and selects the input \notes. At this point there is sufficient information to compute $\hSig$, as described in the previous section. \changed{The sender also chooses $\NoteAddressPreRand$ uniformly at random on $\bitseq{\NoteAddressPreRandLength}$.} Then it creates each output \note with index $i \typecolon \setofNew$ as follows: + \begin{itemize} \item Choose $\NoteCommitRandNew{i}$ uniformly at random on $\bitseq{\NoteCommitRandLength}$. \changed{ @@ -1522,6 +1549,7 @@ of the input \notes and of the output \notes. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. +\introlist After generating all of the \joinSplitDescriptions, the sender obtains the $\dataToBeSigned$ (\crossref{nonmalleability}), and signs it with the private \joinSplitSigningKey: @@ -1539,9 +1567,11 @@ 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. +\introlist \changed{ A \dummy input \note, with index $i$ in the \joinSplitDescription, is constructed as follows: + \begin{itemize} \item Generate a new random \spendingKey $\AuthPrivateOld{i}$ and derive its \payingKey $\AuthPublicOld{i}$. @@ -1578,6 +1608,7 @@ When a \noteCommitment is added to the tree, it occupies the \merkleLeafNode It is assumed to be infeasible to find a preimage \note $\NoteTuple{}$ such that $\NoteCommit(\NoteTuple{}) = \Uncommitted$. +\introlist The \merkleNodes at \merkleLayers $0$ to $\MerkleDepth-1$ inclusive are called \merkleInternalNodes, and are associated with $\MerkleCRH$ outputs. \MerkleInternalNodes are computed from their children in the next \merkleLayer @@ -1587,6 +1618,7 @@ as follows: for $0 \leq h < \MerkleDepth$ and $0 \leq i < 2^h$, \item $\MerkleNode{h}{i} := \MerkleCRH(\MerkleNode{h+1}{2i}, \MerkleNode{h+1}{2i+1})$. \end{formulae} +\introlist A \merklePath from \merkleLeafNode $\MerkleNode{\MerkleDepth}{i}$ in the \incrementalMerkleTree is the sequence @@ -1679,6 +1711,7 @@ exists in the set. \nsubsection{\JoinSplitStatement} \label{jsstatement} +\introlist A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}: \begin{formulae} @@ -1692,6 +1725,7 @@ A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}: \h{\allOld} \typecolon \typeexp{\PRFOutput}{\NOld})$, \end{formulae} +\introlist the prover knows an \term{auxiliary input}: \begin{formulae} @@ -1704,6 +1738,7 @@ the prover knows an \term{auxiliary input}: \EnforceCommit{\allOld} \typecolon \bitseq{\NOld}})$, \end{formulae} +\introlist where: \begin{formulae} @@ -1713,6 +1748,7 @@ where: \vNew{i}, \NoteAddressRandNew{i}, \NoteCommitRandNew{i})$ \end{formulae} +\introlist such that the following conditions hold: \subparagraph{Merkle path validity} \label{merklepathvalidity} @@ -1776,7 +1812,9 @@ the original \note \changed{ and \memo}. All of the resulting ciphertexts are combined to form a \notesCiphertext. +\introlist For both encryption and decryption, + \begin{itemize} \item Let $\Sym$ be the \encryptionScheme instantiated in \crossref{concretesym}. \item Let $\KDF$ be the \keyDerivationFunction instantiated in \crossref{concretekdf}. @@ -1791,7 +1829,9 @@ for the intended recipient addresses of each new \note. Let $\NotePlaintext{\allNew}$ be the \notePlaintexts as defined in \crossref{notept}. +\introlist Then to encrypt: + \begin{itemize} \changed{ \item Generate a new $\KA$ (public, private) key pair @@ -1829,6 +1869,7 @@ Let $\PaymentAddress = (\AuthPublic, \TransmitPublic)$ be the recipient's Let $\cmNew{\allNew}$ be the \noteCommitments of each output coin. +\introlist Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext component as follows: @@ -1841,6 +1882,7 @@ component as follows: \AuthPublic).$ \end{itemize} +\introlist $\DecryptNote(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i}, \AuthPublic)$ is defined as follows: @@ -1951,6 +1993,7 @@ For example, the following diagrams are all equivalent: and represent the byte sequence $[\hexint{D2}, \hexint{BC}, \hexint{3A}, \hexint{12}]$. \end{comment} +\introlist \nsubsection{Constants} \label{constants} Define: @@ -1976,6 +2019,7 @@ Define: \end{formulae} +\introlist \nsubsection{Concrete Cryptographic Functions} \nsubsubsection{Merkle Tree Hash Function} \label{merklecrh} @@ -2006,6 +2050,7 @@ $\SHA$ must be collision-resistant, and it must be infeasible to find a preimage such that $\SHA(x) = \zeros{256}$. } +\introlist \nsubsubsection{\hSigText{} Hash Function} \label{hsigcrh} \newsavebox{\hsigbox} @@ -2043,6 +2088,7 @@ block. $\Blake{256}(\ascii{ZcashComputehSig}, x)$ must be collision-resistant. } +\introlist \nsubsubsection{Equihash Generator} \label{equihashgen} $\EquihashGen{n, k}$ is a specialized hash function that maps an input @@ -2069,6 +2115,7 @@ Let $\powtag := \Justthebox{\powtagbox}$. Let $\powcount(g) := \Justthebox{\powcountbox}$. \vspace{2ex} +\introlist % Blech. Dijkstra was right \cite{EWD831}. Let $\EquihashGen{n, k}(S, i) := T_{h+1\hairspace..\hairspace h+n}$, where \begin{formulae} @@ -2098,6 +2145,7 @@ the number of calls to $\BlakeGeneric$ can be reduced by a factor of $\floor{\fr in the best case (which is a factor of 2 for $n = 200$). } +\introlist \nsubsubsection{\PseudoRandomFunctions} \label{concreteprfs} The \changed{four} independent PRFs described in \crossref{abstractprfs} are @@ -2242,6 +2290,7 @@ Define $\KAFormatPrivate(x) := \Clamp(x)$. Define $\KAAgree(n, q) := \CurveMultiply(n, q)$. } +\introlist \nsubsubsection{\KeyDerivation} \label{concretekdf} \newsavebox{\kdftagbox} @@ -2309,6 +2358,7 @@ $\JoinSplitSigSpecific$ is defined as using $\JoinSplitSigHashName$ internally. \end{bytefield} \end{lrbox} +\introlist \changed{ The encoding of a signature is: } @@ -2322,6 +2372,7 @@ where $\EdDSAR$ and $\EdDSAS$ are as defined in \cite{BDL+2012}. The encoding of a public key is as defined in \cite{BDL+2012}. } +\introlist \nsubsubsection{Commitment} \label{concretecomm} \newsavebox{\cmbox} @@ -2372,8 +2423,10 @@ $(\Value, \NoteAddressRand, \NoteCommitRand\changed{, \Memo})$. The first three of these fields are as defined earlier. \changed{$\Memo$ is a 512-byte \memo associated with this \note. +\introlist The usage of the \memo is by agreement between the sender and recipient of the \note. The \memo{} \SHOULD be encoded either as: + \begin{itemize} \item a UTF-8 human-readable string \cite{Unicode}, padded by appending zero bytes; or \item an arbitrary sequence of 512 bytes starting with a byte value of $\hexint{F5}$ @@ -2391,7 +2444,9 @@ A start byte of $\hexint{F6}$ or greater is reserved for use in future \Zcash protocol extensions. } +\introlist The encoding of a \notePlaintext consists of, in order: + \begin{equation*} \begin{bytefield}[bitwidth=0.029em]{1608} \changed{ @@ -2436,6 +2491,7 @@ The language consisting of the following encoding possibilities is prefix-free. \xTransparent payment addresses are either P2SH (Pay to Script Hash) \cite{BIP-13} or P2PKH (Pay to Public Key Hash) \cite{Bitcoin-P2PKH} addresses. +\introlist The raw encoding of a P2SH address consists of: \begin{equation*} @@ -2455,6 +2511,7 @@ The raw encoding of a P2SH address consists of: \item 160 bits specifying a script hash \cite{Bitcoin-P2SH}. \end{itemize} +\introlist The raw encoding of a P2PKH address consists of: \begin{equation*} @@ -2501,6 +2558,7 @@ $\TransmitPublic$ is a $\KAPublic$ key (see \crossref{concretekeyagreement}), for use with the encryption scheme defined in \crossref{inband}. These components are derived from a \spendingKey as described in \crossref{keycomponents}. +\introlist The raw encoding of a \paymentAddress consists of: \begin{equation*} @@ -2538,6 +2596,7 @@ cause the first two characters of the Base58Check encoding to be fixed as A \spendingKey consists of $\AuthPrivate$, which is a sequence of \changed{252} bits (see \crossref{keycomponents}). +\introlist The raw encoding of a \spendingKey consists of, in order: \begin{equation*} @@ -2589,6 +2648,7 @@ the systems in \cite{PGHR2013} and \cite{BCGTV2013}. The pairing implementation is $\BNImpl$. +\introlist Let $q = 21888242871839275222246405745257275088696311157297823662689037894645226208583$. Let $r = 21888242871839275222246405745257275088548364400416034343698204186575808495617$. @@ -2597,7 +2657,9 @@ Let $b = 3$. ($q$ and $r$ are prime.) +\introlist The pairing is of type $\GroupG{1} \times \GroupG{2} \rightarrow \GroupG{T}$, where: + \begin{itemize} \item $\GroupG{1}$ is a Barreto--Naehrig curve over $\GF{q}$ with equation $y^2 = x^3 + b$. This curve has embedding degree 12 with respect to $r$. @@ -2609,6 +2671,7 @@ irreducible polynomial $t^2 + 1$. $\GFstar{q^{12}}$. \end{itemize} +\introlist Let $\PointP{1} \typecolon \GroupG{1} = (1, 2)$. \begin{tabular}{@{}l@{}r@{}l@{}} @@ -2681,7 +2744,9 @@ Define $\ItoOSP{} \typecolon (k \typecolon \Nat) \times \range{0}{256^k\!-\!1} \ \typeexp{\range{0}{255}}{k}$ such that $\ItoOSP{\ell}(n)$ is the sequence of $\ell$ bytes representing $n$ in big-endian order. +\introlist For a point $P \typecolon \GroupG{1} = (x_P, y_P)$: + \begin{itemize} \item The field elements $x_P$ and $y_P \typecolon \GF{q}$ are represented as integers $x$ and $y \typecolon \range{0}{q\!-\!1}$. @@ -2689,7 +2754,9 @@ For a point $P \typecolon \GroupG{1} = (x_P, y_P)$: \item $P$ is encoded as $\Justthebox{\gonebox}$. \end{itemize} +\introlist For a point $P \typecolon \GroupG{2} = (x_P, y_P)$: + \begin{itemize} \item A field element $w \typecolon \GF{q^2}$ is represented as a polynomial $a_{w,1} \mult t + a_{w,0} \typecolon \GF{q}[t]$ modulo $t^2 + 1$. @@ -2703,7 +2770,9 @@ For a point $P \typecolon \GroupG{2} = (x_P, y_P)$: \item $P$ is encoded as $\Justthebox{\gtwobox}$. \end{itemize} +\introlist \subparagraph{Non-normative notes:} + \begin{itemize} \item The use of big-endian byte order is different from the encoding of most other integers in this protocol. The above encodings are consistent @@ -2722,6 +2791,7 @@ When computing square roots in $\GF{q}$ or $\GF{q^2}$ in order to decompress a point encoding, the implementation \MUSTNOT assume that the square root exists, or that the encoding represents a point on the curve. +\introlist \nsubsubsection{Encoding of \ZeroKnowledgeProofs} \label{proofencoding} \newsavebox{\proofbox} @@ -2748,9 +2818,10 @@ A proof is encoded by concatenating the encodings of its elements: The resulting proof size is 296 bytes. \vspace{0.8ex} - +\introlist In addition to the steps to verify a proof given in \cite[Appendix B]{BCTV2015}, the verifier \MUST check, for the encoding of each element, that: + \begin{itemize} \item the lead byte is of the required form; \item the remaining bytes encode a big-endian representation of an integer @@ -2760,6 +2831,7 @@ verifier \MUST check, for the encoding of each element, that: the subgroup $\GroupG{2}$). \end{itemize} +\introlist \nsubsection{\JoinSplitParameters} \label{jsparameters} For the \Zcash production \blockchain and testnet, the $\FullHashName$ hashes of the @@ -2774,6 +2846,7 @@ format, are: These parameters were obtained by a multi-party computation described in \cite{GitHub-mpc}. +\needspace{30ex} \nsection{Consensus Changes from \Bitcoin} \nsubsection{Encoding of \Transactions} \label{txnencoding} @@ -2822,7 +2895,9 @@ $\versionField > 1$ and $\nJoinSplit > 0$. The encoding of $\joinSplitPubKey$ and the data to be signed are specified in \crossref{nonmalleability}. +\introlist The changes relative to \Bitcoin version 1 transactions as described in \cite{Bitcoin-Format} are: + \begin{itemize} \item The \transactionVersionNumber{} can be either 1 or 2. A version 1 \transaction is equivalent to a version 2 \transaction with $\nJoinSplit = 0$. Software that parses @@ -2843,6 +2918,7 @@ it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY} as specified in 9, 112 and 113. } +\introlist \nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding} An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in @@ -2938,7 +3014,9 @@ according to \crossref{equihash}. \\ \hline \end{tabularx} \end{center} +\introlist The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are: + \begin{itemize} \item The \blockVersionNumber{} \MUST be 4. Previous versions are not supported. Software that parses blocks \MUSTNOT assume, when an encoded \block starts with an $\nVersion$ @@ -2964,7 +3042,9 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin- changing the Proof of Work from \SHAd used by \Bitcoin are described in \cite{WG2016}. +\introlist A \block satisfies the Proof of Work if and only if: + \begin{itemize} \item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}. \item The \blockHeader satisfies the difficulty check according to \crossref{difficulty}. @@ -2982,6 +3062,7 @@ The Generalized Birthday Problem is defined as follows: given a sequence $X_{1..\mathrm{N}}$ of $n$-bit strings, find $2^k$ distinct $X_{i_j}$ such that $\vxor{j=1}{2^k} X_{i_j} = 0$. +\introlist In Equihash, $\mathrm{N} = 2^{\frac{n}{k+1}+1}$, and the sequence $X_{1..\mathrm{N}}$ is derived from the \blockHeader and a nonce: @@ -3017,6 +3098,7 @@ $\vxor{j=1}{2^k} X_{i_j} = 0$. \subparagraph{Algorithm Binding conditions} +\introlist For all $r \in \range{1}{k\!-\!1}$, for all $w \in \range{0}{2^{k-r}\!-\!1}$: \begin{itemize} \item $\vxor{j=1}{2^r} X_{i_{w \mult 2^r + j}}$ has $\frac{n \mult r}{k+1}$ leading zeroes; and @@ -3028,6 +3110,7 @@ This does not include a difficulty condition, because here we are defining valid of an Equihash solution independent of difficulty. } +\introlist An Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\solution$ field of a \blockHeader as follows: @@ -3067,7 +3150,7 @@ field of a \blockHeader as follows: \item $\Justthebox{\solutionbox}$ \end{formulae} -\vspace{1ex} +\introlist Recall from \crossref{boxnotation} that bits in the above diagram are ordered from most to least significant in each byte. For example, if the first 3 elements of $i$ are $[69, 42, 2^{21}]$, @@ -3136,6 +3219,7 @@ one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHei \renewcommand{\arraystretch}{0.95} +\introlist For the production network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is: \begin{tabular}{@{\hskip 2.5em}l@{\;}l} @@ -3165,6 +3249,7 @@ For the production network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddress & \ascii{t3R3Y5vnBLrEn8L6wFjPjBLnxSUQsKnmFpv}, \ascii{t3Pcm737EsVkGTbhsu2NekKtJeG92mvYyoN}\, ] \end{tabular} +\introlist For the test network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is: \begin{tabular}{@{\hskip 2.5em}l@{\;}l} @@ -3201,6 +3286,7 @@ P2SH multisig address. Let $\SlowStartShift$ be defined as in the previous section. +\introlist Define: \begin{formulae} @@ -3325,10 +3411,12 @@ the recipient of each output \note. This feature is described in more detail in \crossref{notept}. +\introlist \nsubsection{Unification of Mints and Pours} In the original \Zerocash protocol, there were two kinds of transaction relating to \shieldedNotes: + \begin{itemize} \item a ``Mint'' transaction takes value from \transparent UTXOs as input and produces a new \shieldedNote as output. @@ -3375,6 +3463,7 @@ legends in which faeries pay mortals in what appears to be gold, but which soon after reveals itself to be leaves, gorse blossoms, gingerbread cakes, or other less valuable things \cite{LG2004}. +\introlist This attack does not violate the security definitions given in \cite{BCG+2014}. The issue could be framed as a problem either with the definition of Completeness, or the definition of @@ -3489,9 +3578,11 @@ to 254 bits in the input to $\PRFsn{}$ (which corresponds to $\PRFnf{}$ in \Zcas Also, $\hSig$ is truncated from 256 to 253 bits in the input to $\PRFpk{}$. These truncations are not taken into account in the security proofs. +\introlist Both truncations affect the validity of the proof sketch for Lemma D.2 in the proof of Ledger Indistinguishability in \cite[Appendix D]{BCG+2014}. In more detail: + \begin{itemize} \item In the argument relating $\mathbf{H}$ and $\Game_2$, it is stated that in $\Game_2$, ``for each $i \in \setof{1, 2}, \mathsf{sn}_i := \PRFsn{\AuthPrivate}(\NoteAddressRand)$ @@ -3549,6 +3640,7 @@ changed to a scheme based on Curve25519 key agreement, 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}. +\introlist The motivations for this change were as follows: \begin{itemize} @@ -3633,6 +3725,7 @@ The \joinSplitStatements are still valid because they can only check that the $\AuthPrivate$ in the witness is \emph{some} preimage of the $\AuthPublic$ used in the \noteCommitment. +\introlist The error is in the proof of Balance in \cite[Appendix D.3]{BCG+2014}. For the ``$\Adversary$ violates Condition I'' case, the proof says: @@ -3717,6 +3810,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \crossref{truncation} were also found by Daira Hopwood. +\introlist \nsection{Change history} \subparagraph{2016.0-beta-1.13} @@ -3725,6 +3819,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Define $\PRFaddr{}$ in \crossref{keycomponents}. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.12} \begin{itemize} @@ -3734,6 +3829,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Add acknowledgements for Filippo Valsorda and Zaki Manian. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.11} \begin{itemize} @@ -3742,6 +3838,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in follow \cite{BIP-34}. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.10} \begin{itemize} @@ -3751,6 +3848,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Clarify the discussion of proof size in ``Differences from the \Zerocash paper''. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.9} \begin{itemize} @@ -3758,6 +3856,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Change \quotedterm{protected} terminology to \quotedterm{shielded}. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.8} \begin{itemize} @@ -3774,6 +3873,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \type{uint32\_t}. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.7} \begin{itemize} @@ -3781,6 +3881,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in response to an issue raised by the NCC audit. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.6} \begin{itemize} @@ -3798,6 +3899,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in Jay Graber, and Jack Gavigan. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.5} \begin{itemize} @@ -3805,6 +3907,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Add some clarifications based on Eli Ben-Sasson's review. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.4} \begin{itemize} @@ -3814,6 +3917,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in ``$\typeexp{T}{\ell}$'' for sequence types) to avoid ambiguity. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.3} \begin{itemize} @@ -3824,6 +3928,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in and for the NCC Group and Coinspect security audits. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.2} \begin{itemize} @@ -3832,6 +3937,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Correct the security requirement for $\EquihashGen{}$. \end{itemize} +\introlist \subparagraph{2016.0-beta-1.1} \begin{itemize} @@ -3841,6 +3947,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in than as a distribution of parameters. \end{itemize} +\introlist \subparagraph{2016.0-beta-1} \begin{itemize} @@ -3882,18 +3989,21 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Terminology changes. \end{itemize} +\introlist \subparagraph{2016.0-alpha-3.1} \begin{itemize} \item Change main font to Quattrocento. \end{itemize} +\introlist \subparagraph{2016.0-alpha-3} \begin{itemize} \item Change version numbering convention (no other changes). \end{itemize} +\introlist \subparagraph{2.0-alpha-3} \begin{itemize} @@ -3902,6 +4012,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Add change history. \end{itemize} +\introlist \subparagraph{2.0-alpha-2} \begin{itemize} @@ -3916,6 +4027,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in \item Changes to terminology around keys. \end{itemize} +\introlist \subparagraph{2.0-alpha-1} \begin{itemize}