@ -14,6 +14,9 @@
\RequirePackage { hhline}
\RequirePackage { comment}
\RequirePackage [style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=iso8601,backref=true,backrefstyle=none,backend=biber] { biblatex}
\addbibresource { zcash.bib}
% Fonts
\RequirePackage { lmodern}
\RequirePackage { bold-extra}
@ -34,6 +37,16 @@
% bold but not extended
\newcommand { \textbnx } [1]{ { \fontseries { b} \selectfont #1} }
\DeclareLabelalphaTemplate {
\labelelement { \field { citekey} }
}
\DefineBibliographyStrings { english} {
page = { page} ,
pages = { pages} ,
backrefpage = { $ \uparrow $ } ,
backrefpages = { $ \uparrow $ }
}
\setlength { \oddsidemargin } { -0.25in}
\setlength { \textwidth } { 7in}
@ -466,7 +479,7 @@
\nsection { Introduction}
\Zcash is an implementation of the \term { Decentralized Anonymous Payment}
scheme \Zerocash \cite { Zerocash } with some adjustments to terminology,
scheme \Zerocash \cite { BCG+2014 } with some adjustments to terminology,
functionality and performance. It bridges the existing \emph { transparent}
payment scheme used by \Bitcoin with a \emph { confidential} payment scheme
protected by zero-knowledge succinct non-interactive arguments of knowledge
@ -484,7 +497,7 @@ This specification is structured as follows:
\item Concrete Protocol | how the functions and encodings of the abstract
protocol are instantiated;
\item Differences from the \Zerocash protocol | a summary of changes from the
protocol in \cite { Zerocash } .
protocol in \cite { BCG+2014 } .
\end { itemize}
@ -522,9 +535,9 @@ The notation $a..b$, used as a subscript, means the sequence of values
with indices $ a $ through $ b $ inclusive. For example,
$ \AuthPublicNew { \allNew } $ means the sequence $ [ \AuthPublicNew { \mathrm { 1 } } ,
\AuthPublicNew { \mathrm { 2} } , ...\; \AuthPublicNew { \NNew } ]$ .
(For consistency with the notation in \cite { Zerocash} and in \cite { Equihash } ,
(For consistency with the notation in \cite { BCG+2014} and in \cite { BK2016 } ,
this specification uses 1-based indexing and inclusive ranges,
notwithstanding the compelling arguments to the contrary in \cite { EWD831} .)
notwithstanding the compelling arguments to the contrary in \cite { EWD- 831} .)
The notation $ \range { a } { b } $ means the set of integers from $ a $ through
$ b $ inclusive. $ k \range { a } { b } $ means the set containing integers $ kn $
@ -951,12 +964,12 @@ where
\item $ \CurveMultiply ( \bytes { n } , \bytes { q } ) $ performs point
multiplication of the Curve25519 public key represented by the byte
sequence $ \bytes { q } $ by the Curve25519 secret key represented by the
byte sequence $ \bytes { n } $ , as defined in section 2 of \cite { Curve25519 } ;
byte sequence $ \bytes { n } $ , as defined in \cite [section 2] { Bern2006} ;
\item $ \CurveBase $ is the public byte sequence representing the Curve25519
base point;
\item $ \Clamp ( \bytes { x } ) $ takes a 32-byte sequence $ \bytes { x } $ as input
and returns a byte sequence representing a Curve25519 private key, with
bits ``clamped'' as described in section 3 of \cite { Curve25519 } :
bits ``clamped'' as described in \cite [section 3] { Bern2006} :
``clear bits $ 0 , 1 , 2 $ of the first byte, clear bit $ 7 $ of the last byte,
and set bit $ 6 $ of the last byte.'' Here the bits of a byte are numbered
such that bit $ b $ has numeric weight $ 2 ^ b $ .
@ -1161,10 +1174,10 @@ key pair is generated for each \transaction, and the $\dataToBeSigned$ is
signed with the private signing key of this key pair. The corresponding public
verification key is included in the \transaction encoding as $ \joinSplitPubKey $ .
$ \JoinSplitSigAlg $ is instantiated as $ \JoinSplitSigSpecific $ \cite { ed25519 } ,
$ \JoinSplitSigAlg $ is instantiated as $ \JoinSplitSigSpecific $ \cite { BDL+2012 } ,
with the additional requirement that $ \EdDSAs $ (the integer represented
by $ \EdDSAS $ ) must be less than the prime
$ \ell = 2 ^ { 252 } + 27742317777372353535851937790883648493 $ defined in \cite { ed25519} ,
$ \ell = 2 ^ { 252 } + 27742317777372353535851937790883648493 $ ,
otherwise the signature is considered invalid.
$ \JoinSplitSigSpecific $ is defined as using $ \JoinSplitSigHashName $ internally.
@ -1192,9 +1205,9 @@ The encoding of a signature is:
\end { itemize}
\changed {
where $ \EdDSAR $ and $ \EdDSAS $ are as defined in \cite { ed25519 } .
where $ \EdDSAR $ and $ \EdDSAS $ are as defined in \cite { BDL+2012 } .
The encoding of a public key is as defined in \cite { ed25519 } .
The encoding of a public key is as defined in \cite { BDL+2012 } .
}
The condition enforced by the \joinSplitCircuit specified in \crossref { nonmalleablepour}
@ -1214,7 +1227,7 @@ treated like an \emph{output} value, whereas} $\vpubNew$ is treated like an
\changed {
\subparagraph { Note:}
Unlike original \Zerocash \cite { Zerocash } , \Zcash does not have
Unlike original \Zerocash \cite { BCG+2014 } , \Zcash does not have
a distinction between Mint and Pour operations. The addition of $ \vpubOld $ to a
\joinSplitDescription subsumes the functionality of both Mint and Pour. Also,
\joinSplitDescriptions are indistinguishable regardless of the number of real input
@ -1271,7 +1284,7 @@ $\treepath{i}$ must be a valid \merklePath of depth $\MerkleDepth$, as defined i
\crossref { merkle} , from $ \Commitment ( \nOld { i } ) $ to \noteCommitmentTree root $ \rt $ .
\textbf { Note:} Merkle path validity covers both conditions 1. (a) and 1. (d) of the NP statement
given in section 4.2 of \cite { Zerocash } .
given in \cite [section 4.2] { BCG+2014} .
\subparagraph { Balance}
@ -1323,7 +1336,7 @@ All of the resulting ciphertexts are combined to form a \notesCiphertext.
\changed {
Let $ \SymEncrypt { \Key } ( \Ptext ) $ be authenticated encryption using
$ \SymSpecific $ \cite { rfc 7539} encryption of plaintext $ \Ptext \in \Plaintext $ ,
$ \SymSpecific $ \cite { RFC- 7539} encryption of plaintext $ \Ptext \in \Plaintext $ ,
with empty ``associated data", all-zero nonce $ \zeros { 96 } $ , and 256-bit key
$ \Key \in \Keyspace $ .
@ -1394,7 +1407,7 @@ is defined as follows:
}
\textbf { Note:} This corresponds to step 3 (b) i. and ii. (first bullet point) of the
$ \Receive $ algorithm shown in Figure 2 of \cite { Zerocash } .
$ \Receive $ algorithm shown in \cite [Figure 2] { BCG+2014} .
To test whether a \note is unspent in a particular \blockchainview also requires
the \spendingKey $ \AuthPrivate $ ; the coin is unspent if and only if
@ -1408,7 +1421,7 @@ as \transactions are added to that view. Also, blockchain reorganisations can ca
the \transaction in which a \note was output to no longer be on the consensus
blockchain.
\item The nonce parameter to $ \SymSpecific $ is not used.
\item The ``IETF" definition of $ \SymSpecific $ from \cite { rfc 7539} is
\item The ``IETF" definition of $ \SymSpecific $ from \cite { RFC- 7539} is
used; this uses a 32-bit block count and a 96-bit nonce, rather than a 64-bit
block count and 64-bit nonce as in the original definition of $ \SymCipher $ .
\end { itemize}
@ -1512,7 +1525,7 @@ Define:
$ \MerkleCRH $ is used to hash \incrementalMerkleTree \merkleHashes .
It is instantiated by the $ \SHAName $ function, which takes a 512-bit block
and produces a 256-bit hash. \cite { sha2 }
and produces a 256-bit hash. \cite { NIST2015 }
\newsavebox { \merklebox }
\begin { lrbox} { \merklebox }
@ -1541,7 +1554,7 @@ $\GeneralCRH{\ell}$ is a collision-resistant hash function. It is used in
It is instantiated by $ \Blake { \ell } $ , that is, $ \BlakeGeneric $ with an output digest
length of $ \ell / 8 $ bytes. $ \GeneralCRH ( p, x ) $ applies unkeyed $ \Blake { \ell } $ , as
defined in \cite { blake2 } , to a 16-byte personalization string $ p $ and input $ x $ .
defined in \cite { ANWW2013 } , to a 16-byte personalization string $ p $ and input $ x $ .
\subparagraph { Note:}
$ \Blake { \ell } $ is not the same as $ \Blake { 512 } $ truncated to $ \ell $ bits.
@ -1693,12 +1706,12 @@ where
\item $ \CurveMultiply ( \bytes { n } , \bytes { q } ) $ performs point
multiplication of the Curve25519 public key represented by the byte
sequence $ \bytes { q } $ by the Curve25519 secret key represented by the
byte sequence $ \bytes { n } $ , as defined in section 2 of \cite { Curve25519 } ;
byte sequence $ \bytes { n } $ , as defined in \cite [section 2] { Bern2006} ;
\item $ \CurveBase $ is the public byte sequence representing the Curve25519
base point;
\item $ \Clamp ( \bytes { x } ) $ takes a 32-byte sequence $ \bytes { x } $ as input
and returns a byte sequence representing a Curve25519 private key, with
bits ``clamped'' as described in section 3 of \cite { Curve25519 } :
bits ``clamped'' as described in \cite [section 3] { Bern2006} :
``clear bits $ 0 , 1 , 2 $ of the first byte, clear bit $ 7 $ of the last byte,
and set bit $ 6 $ of the last byte.'' Here the bits of a byte are numbered
such that bit $ b $ has numeric weight $ 2 ^ b $ .
@ -1859,7 +1872,7 @@ and \spendingKeys.
Addresses and keys can be encoded as a byte sequence; this is called
the \term { raw encoding} . This byte sequence can then be further encoded using
Base58Check. The Base58Check layer is the same as for upstream \Bitcoin
addresses \cite { Base58Check } .
addresses \cite { Bitcoin-B ase58} .
$ \SHAName $ outputs are always represented as sequences of 32 bytes.
@ -1867,17 +1880,17 @@ The language consisting of the following encoding possibilities is prefix-free.
\nsubsubsection { Transparent Payment Addresses}
These are encoded in the same way as in \Bitcoin \cite { Base58Check } .
These are encoded in the same way as in \Bitcoin \cite { Bitcoin-B ase58} .
\nsubsubsection { Transparent Private Keys}
These are encoded in the same way as in \Bitcoin \cite { Base58Check } .
These are encoded in the same way as in \Bitcoin \cite { Bitcoin-B ase58} .
\nsubsubsection { Protected Payment Addresses}
A \paymentAddress consists of $ \AuthPublic $ and $ \TransmitPublic $ .
$ \AuthPublic $ is a $ \SHAName $ output.
$ \TransmitPublic $ is a \changed { Curve25519 } public key, for use with the
$ \TransmitPublic $ is a \changed { Bern2006 } public key, for use with the
encryption scheme defined in \crossref { inband} .
The raw encoding of a \paymentAddress consists of:
@ -1902,7 +1915,7 @@ The raw encoding of a \paymentAddress consists of:
}
\item 256 bits specifying $ \AuthPublic $ .
\item \changed { 256 bits} specifying $ \TransmitPublic $ , \changed { using the
normal encoding of a Curve25519 public key \cite { Curve25519 } } .
normal encoding of a Curve25519 public key \cite { Bern2006 } } .
\end { itemize}
\nsubsubsection { Spending Keys}
@ -1946,9 +1959,9 @@ Future key representations may make use of these padding bits.
\nsection { Zero-Knowledge Proving System} \label { proofs}
\Zcash uses \zkSNARKs generated by its fork of \libsnark \cite { libsnark}
using the proving system described in \cite { BCTV} , which is a refinement of
the system in \cite { Pinocchio } .
\Zcash uses \zkSNARKs generated by its fork of \libsnark \cite { libsnark-fork }
with the proving system described in \cite { BCTV2015 } , which is a refinement of
the system in \cite { PGHR2013 } .
The pairing implementation is $ \BNImpl $ .
@ -1994,7 +2007,7 @@ $(\pi_A \typecolon \GroupG{1},\;
\pi '_ C \typecolon \GroupG { 1} ,\;
\pi _ K \typecolon \GroupG { 1} ,\;
\pi _ H \typecolon \GroupG { 1} )$ .
It is computed as described in Appendix B of \cite { BCTV} .
It is computed as described in \cite [Appendix B] { BCTV2015 } .
\subparagraph { Note:}
Many details of the proving system are beyond the scope of this protocol
@ -2065,16 +2078,16 @@ For a point $P \typecolon \GroupG{2} = (x_P, y_P)$:
Non-normative notes:
\begin { itemize}
\item The use of big-endian byte order is different from the encoding
of other integers in this protocol. The above encodings are consistent with the
definition of $ \ECtoOSP { } $ for compressed curve points in section
5.5.6.2 of IEEE Std 1363a-2004 \cite { std1363a } . The LSB compressed
of other integers in this protocol. The above encodings are consistent
with the definition of $ \ECtoOSP { } $ for compressed curve points in
\cite [section 5.5.6.2] { IEEE2004} . The LSB compressed
form (i.e. $ \ECtoOSPXL $ ) is used for points on $ \GroupG { 1 } $ , and the
SORT compressed form (i.e. $ \ECtoOSPXS $ ) for points on $ \GroupG { 2 } $ .
\item Testing $ y > y' $ for the compression of $ \GroupG { 2 } $ points is equivalent
to testing whether $ ( a _ { y, 1 } , a _ { y, 0 } ) > ( a _ { - y, 1 } , a _ { - y, 0 } ) $ in lexicographic order.
\item Algorithms for decompressing points from the above encodings are
given in Appendix A.12.8 of \cite { std1363 } for $ \GroupG { 1 } $ , and
Appendix A.12.11 of \cite { std1363a } for $ \GroupG { 2 } $ .
given in \cite [Appendix A.12.8] { IEEE2000} for $ \GroupG { 1 } $ , and
\cite [Appendix A.12.11] { IEEE2004} for $ \GroupG { 2 } $ .
\end { itemize}
When computing square roots in $ \GF { q } $ or $ \GF { q ^ 2 } $ in order to decompress
@ -2108,7 +2121,7 @@ The resulting proof size is 296 bytes.
\vspace { 0.8ex}
In addition to the steps to verify a proof given in \cite { BCTV} Appendix B , the
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;
@ -2152,7 +2165,7 @@ accept \blocks with headers more than two hours in the future according to its c
4 & $ \nBits $ & \type { uint32\_ t} & An encoded version of the target threshold this \block 's
header hash must be less than or equal to, in the same nBits format used by \Bitcoin .
\cite { nb its} \\ \hline
\cite { Bitcoin-nB its} \\ \hline
32 & $ \nNonce $ & \type { char[32]} & An arbitrary field miners change to modify the
header hash in order to produce a hash below the target threshold. \\ \hline
@ -2163,7 +2176,7 @@ according to \crossref{equihash}. \\ \hline
\end { tabularx}
\end { center}
The changes relative to \Bitcoin version 4 blocks as described in \cite { blockheaders } are:
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 $
@ -2176,9 +2189,9 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{blockhea
\nsubsection { Proof of Work}
\Zcash uses Equihash \cite { Equihash } 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 { whyequihash } .
in \cite { WG2016 } .
A \block satisfies the Proof of Work if and only if:
\begin { itemize}
@ -2325,8 +2338,7 @@ for this is that little-endian serialization of \blockHeaders is consistent
with \Bitcoin , but using little-endian ordering of bits in the solution
encoding would require bit-reversal (as opposed to only shifting). The
comparison of $ \Xi _ r $ values obtained by a big-endian conversion is equivalent
to lexicographic comparison as specified in \mbox { section IV A.} of
\cite { Equihash} .
to lexicographic comparison as specified in \cite [section IV A] { BK2016} .
\nsubsubsection { Difficulty filter} \label { difficulty}
@ -2418,7 +2430,7 @@ multiple \notes with different $\Value$ and $\NoteCommitRand$
An adversary can use this to mislead a \note recipient, by sending
two \notes both of which are verified as valid by $ \Receive $ (as
defined in Figure 2 of \cite { Zerocash } ), but only one of
defined in \cite [Figure 2] { BCG+2014} ), but only one of
which can be spent.
We call this a ``Faerie Gold'' attack --- referring to various Celtic
@ -2427,7 +2439,7 @@ but which soon after reveals itself to be leaves, gorse blossoms,
gingerbread cakes, or other less valuable things \cite { LG2004} .
This attack does not violate the security definitions given in
\cite { Zerocash } . The issue could be framed as a problem
\cite { BCG+2014 } . The issue could be framed as a problem
either with the definition of Completeness, or the definition of
Balance:
@ -2505,13 +2517,13 @@ $2^{64}$, to find distinct values of $\NoteAddressRand$ with colliding
outputs of the truncated hash, and therefore the same \noteCommitment .
This would have allowed such an attacker to break the balance property
by double-spending \notes , potentially creating arbitrary amounts of
currency for themself. \cite { fixingvulns}
currency for themself \cite { HW2016} .
\Zcash uses a simpler construction with a single $ \FullHashName $ evaluation
for the commitment. The motivation for the nested construction in \Zerocash
was to allow Mint transactions to be publically verified without requiring
a ZK proof (as described under step 3 in section 1.3 of
\cite { Zerocash} ). Since \Zcash combines ``Mint'' and ``Pour''
a ZK proof (as described under step 3 in
\cite [section 1.3] { BCG+2014} ). Since \Zcash combines ``Mint'' and ``Pour''
transactions into a generalized \joinSplitTransfer which always uses a ZK proof,
it does not require the nesting. A side benefit is that this reduces the
number of $ \SHA $ evaluations needed to compute each \noteCommitment from
@ -2521,7 +2533,7 @@ three to two, saving a total of four $\SHA$ evaluations in the
\subparagraph { Note:}
\Zcash \noteCommitments are not statistically hiding,
so \Zcash does not support the ``everlasting anonymity'' property
described in section 8.1 of the \Zerocash paper \cite { Zerocash } ,
described in \cite [section 8.1] { BCG+2014} ,
even when used as described in that section. While it is possible to
define a statistically hiding, computationally binding commitment scheme
for this use at a 128-bit security level, the overhead of doing so
@ -2541,7 +2553,7 @@ collision resistance of $\CRH$.
encryption scheme used for the in-band secret distribution. This has been
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 { cryptoboxs eal} .
and on the $ \CryptoBoxSeal $ scheme defined in libsodium \cite { libsodium-S eal} .
The motivations for this change were as follows:
@ -2549,11 +2561,11 @@ The motivations for this change were as follows:
\item The \Zerocash paper did not specify the curve to be used.
We believe that Curve25519 has significant side-channel resistance,
performance, implementation complexity, and robustness advantages
over most other available curve choices, as explained in \cite { Curve25519 } .
over most other available curve choices, as explained in \cite { Bern2006 } .
\item ECIES permits many options, which were not specified. There are at least
--counting conservatively-- 576 possible combinations of options and
algorithms over the four standards (ANSI X9.63, IEEE Std 1363a-2004,
ISO/IEC 18033-2, and SEC 1) that define ECIES variants \cite { eciescomparison } .
ISO/IEC 18033-2, and SEC 1) that define ECIES variants \cite { MAEA2010 } .
\item Although the \Zerocash paper states that ECIES satisfies key privacy
(as defined in \cite { BBDP2001} ), it is not clear that this holds for
all curve parameters and key distributions. For example, if a group of
@ -2562,10 +2574,10 @@ The motivations for this change were as follows:
ephemeral and recipient public keys. Public key validity is also a concern.
Curve25519 key agreement is defined in a way that avoids these concerns
due to the curve structure and the ``clamping'' of private keys.
\item Unlike the DHAES/DHIES proposal on which it is based \cite { dhaes } , ECIES
\item Unlike the DHAES/DHIES proposal on which it is based \cite { ABR1999 } , ECIES
does not require a representation of the sender's ephemeral public key
to be included in the input to the KDF, which may impair the security
properties of the scheme. (The Std 1363a-2004 version of ECIES \cite { std1363a }
properties of the scheme. (The Std 1363a-2004 version of ECIES \cite { IEEE2004 }
has a ``DHAES mode'' that allows this, but the representation of the key
input is underspecified, leading to incompatible implementations.)
The scheme we use has both the ephemeral and recipient public key
@ -2608,7 +2620,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 .
The error is in the proof of Balance in section D.3 of \cite { Zerocash } .
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:
\begin { itemize}
@ -2651,7 +2663,7 @@ distinct openings of the \noteCommitment when Condition I or II is violated.
This differs from the 296 bytes specified in \crossref { proofencoding} ,
because the paper did not take into account the need to encode compressed
$ y $ -coordinates. The fork of \libsnark used by \Zcash uses a different
format to upstream \libsnark , in order to follow \cite { std1363a } .
format to upstream \libsnark , in order to follow \cite { IEEE2004 } .
\end { itemize}
@ -2747,9 +2759,10 @@ of $\PRFaddr{}$ was found by Daira Hopwood.
\nsection { References}
\begingroup
\hfuzz =0.2pt
\renewcommand { \section } [2]{ }
\bibliographystyle { plain }
\bibliography { zcash}
\renewcommand { \emph } [1]{ \textit { #1} }
\print bibliography
\endgroup
\end { document}
Daira Hopwood
8 years ago