\documentclass{article} \RequirePackage{amsmath} \RequirePackage{bytefield} \RequirePackage{graphicx} \RequirePackage{newtxmath} \RequirePackage{mathtools} \RequirePackage{xspace} \RequirePackage{url} \RequirePackage{changepage} \RequirePackage{lmodern} \setlength{\oddsidemargin}{-0.25in} % Left margin of 1 in + 0 in = 1 in \setlength{\textwidth}{7in} % Right margin of 8.5 in - 1 in - 6.5 in = 1 in \setlength{\topmargin}{-.75in} % Top margin of 2 in -0.75 in = 1 in \setlength{\textheight}{9.2in} % Lower margin of 11 in - 9 in - 1 in = 1 in \setlength{\parskip}{1.5ex} \setlength{\parindent}{0ex} \mathchardef\mhyphen="2D \RequirePackage[usenames,dvipsnames]{xcolor} % https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips \newcommand{\eli}[1]{{\color{JungleGreen}\sf{Eli: #1}}} \newcommand{\sean}[1]{{\color{blue}\sf{Sean: #1}}} \newcommand{\taylor}[1]{{\color{red}\sf{Taylor: #1}}} \newcommand{\daira}[1]{{\color{RedOrange}\sf{Daira: #1}}} \newcommand{\nathan}[1]{{\color{ForestGreen}\sf{Nathan: #1}}} \newcommand{\todo}[1]{{\color{Sepia}\sf{TODO: #1}}} \newcommand{\changedcolor}{magenta} \newcommand{\setchanged}{\color{\changedcolor}} \newcommand{\changed}[1]{{\setchanged{#1}}} % terminology \newcommand{\term}[1]{\textsl{#1}\xspace} \newcommand{\termbf}[1]{\textbf{#1}\xspace} \newcommand{\conformance}[1]{\textmd{#1}\xspace} \newcommand{\Zcash}{\termbf{Zcash}} \newcommand{\Zerocash}{\termbf{Zerocash}} \newcommand{\Bitcoin}{\termbf{Bitcoin}} \newcommand{\ZEC}{\termbf{ZEC}} \newcommand{\zatoshi}{\term{zatoshi}} \newcommand{\MUST}{\conformance{MUST}} \newcommand{\MUSTNOT}{\conformance{MUST NOT}} \newcommand{\SHOULD}{\conformance{SHOULD}} \newcommand{\SHOULDNOT}{\conformance{SHOULD NOT}} \newcommand{\MAY}{\conformance{MAY}} \newcommand{\coin}{\term{coin}} \newcommand{\coins}{\term{coins}} \newcommand{\coinCommitment}{\term{coin commitment}} \newcommand{\coinCommitments}{\term{coin commitments}} \newcommand{\coinCommitmentTree}{\term{coin commitment tree}} \newcommand{\PourDescription}{\term{Pour description}} \newcommand{\PourDescriptions}{\term{Pour descriptions}} \newcommand{\sequenceOfPourDescriptions}{\changed{sequence of} \PourDescription\changed{\term{s}}} \newcommand{\PourTransfer}{\term{Pour transfer}} \newcommand{\PourTransfers}{\term{Pour transfers}} \newcommand{\fullnode}{\term{full node}} \newcommand{\fullnodes}{\term{full nodes}} \newcommand{\anchor}{\term{anchor}} \newcommand{\anchors}{\term{anchors}} \newcommand{\block}{\term{block}} \newcommand{\blocks}{\term{blocks}} \newcommand{\transaction}{\term{transaction}} \newcommand{\transactions}{\term{transactions}} \newcommand{\blockchainview}{\term{blockchain view}} \newcommand{\mempool}{\term{mempool}} \newcommand{\treestate}{\term{treestate}} \newcommand{\treestates}{\term{treestates}} \newcommand{\script}{\term{script}} \newcommand{\serialNumber}{\term{serial number}} \newcommand{\serialNumbers}{\term{serial numbers}} % Daira: This doesn't adequately distinguish between zk stuff and transparent stuff \newcommand{\paymentAddress}{\term{payment address}} \newcommand{\paymentAddresses}{\term{payment addresses}} \newcommand{\viewingKey}{\term{viewing key}} \newcommand{\viewingKeys}{\term{viewing keys}} \newcommand{\spendingKey}{\term{spending key}} \newcommand{\spendingKeys}{\term{spending keys}} \newcommand{\keyTuple}{\term{key tuple}} \newcommand{\coinPlaintext}{\term{coin plaintext}} \newcommand{\coinPlaintexts}{\term{coin plaintexts}} \newcommand{\coinsCiphertext}{\term{transmitted coins ciphertext}} \newcommand{\authKeypair}{\term{authorization}} \newcommand{\transmitKeypair}{\term{transmission}} \newcommand{\discloseKeypair}{\term{disclosure}} \newcommand{\keyPrivateAlgorithm}{\term{key-private encryption scheme}} \newcommand{\incrementalMerkleTree}{\term{incremental merkle tree}} \newcommand{\spentSerialsMap}{\term{spent serial numbers map}} \newcommand{\zkSNARK}{\term{zk-SNARK}} \newcommand{\zkSNARKs}{\term{zk-SNARKs}} \newcommand{\memo}{\term{memo field}} % key pairs: \newcommand{\PaymentAddress}{\mathsf{addr_{pk}}} \newcommand{\ViewingKey}{\mathsf{addr_{viewkey}}} \newcommand{\SpendingKey}{\mathsf{addr_{sk}}} \newcommand{\PaymentAddressLeadByte}{\mathbf{0x92}} \newcommand{\ViewingKeyLeadByte}{\mathbf{0x??}} \newcommand{\SpendingKeyLeadByte}{\mathbf{0x93}} \newcommand{\AuthPublic}{\mathsf{a_{pk}}} \newcommand{\AuthPrivate}{\mathsf{a_{sk}}} \newcommand{\AuthPublicOld}[1]{\mathsf{a^{old}_{pk,\mathnormal{#1}}}} \newcommand{\AuthPrivateOld}[1]{\mathsf{a^{old}_{sk,\mathnormal{#1}}}} \newcommand{\AuthPublicNew}[1]{\mathsf{a^{new}_{pk,\mathnormal{#1}}}} \newcommand{\AuthPrivateNew}[1]{\mathsf{a^{new}_{sk,\mathnormal{#1}}}} \newcommand{\AddressPublicNew}[1]{\mathsf{addr^{new}_{pk,\mathnormal{#1}}}} \newcommand{\enc}{\mathsf{enc}} \newcommand{\alleged}{\mathsf{alleged}} \newcommand{\disclose}{\mathsf{disclose}} \newcommand{\PublicKey}[1]{\mathsf{pk_\mathnormal{#1}}} \newcommand{\PrivateKey}[1]{\mathsf{sk_\mathnormal{#1}}} \newcommand{\EphemeralPublic}[1]{\mathsf{epk_\mathnormal{#1}}} \newcommand{\EphemeralPrivate}[1]{\mathsf{esk_\mathnormal{#1}}} \newcommand{\TransmitPublic}{\PublicKey{\enc}} \newcommand{\TransmitPublicNew}[1]{\mathsf{pk^{new}_{\enc,\mathnormal{#1}}}} \newcommand{\TransmitPrivate}{\PrivateKey{\enc}} \newcommand{\DisclosePublic}{\PublicKey{\disclose}} \newcommand{\DisclosePrivate}{\PrivateKey{\disclose}} \newcommand{\TransmitEphemeralPublic}{\EphemeralPublic{\enc}} \newcommand{\TransmitEphemeralPrivate}{\EphemeralPrivate{\enc}} \newcommand{\DiscloseEphemeralPublic}{\EphemeralPublic{\disclose}} \newcommand{\DiscloseEphemeralPrivate}{\EphemeralPrivate{\disclose}} \newcommand{\Value}{\mathsf{v}} % Coins \newcommand{\Coin}{\mathbf{c}} \newcommand{\CoinCommitRand}{\mathsf{r}} \newcommand{\CoinCommitRandOld}[1]{\mathsf{r^{old}_\mathnormal{#1}}} \newcommand{\CoinCommitRandNew}[1]{\mathsf{r^{new}_\mathnormal{#1}}} \newcommand{\CoinAddressRand}{\mathsf{\uprho}} \newcommand{\CoinAddressRandOld}[1]{\mathsf{\uprho^{old}_\mathnormal{#1}}} \newcommand{\CoinAddressRandNew}[1]{\mathsf{\uprho^{new}_\mathnormal{#1}}} \newcommand{\CoinAddressPreRand}{\mathsf{\upvarphi}} \newcommand{\CoinCommitS}{\mathsf{s}} \newcommand{\TransmitPlaintextVersionByte}{\mathbf{0x00}} \newcommand{\hSigInputVersionByte}{\mathbf{0x00}} \newcommand{\Memo}{\mathsf{memo}} \newcommand{\CryptoBox}{\mathsf{crypto\_box}} \newcommand{\CryptoBoxOpen}{\mathsf{crypto\_box\_open}} \newcommand{\CryptoBoxSeal}{\mathsf{crypto\_box\_seal}} \newcommand{\CryptoBoxSpecific}{\mathsf{crypto\_box\_curve25519xsalsa20poly1305}} \newcommand{\Plaintext}[1]{\mathbf{P}^\enc_{#1}} \newcommand{\AllegedPlaintext}[1]{\mathbf{P}^\alleged_{#1}} \newcommand{\DisclosePlaintext}{\mathbf{P}^\disclose} \newcommand{\TransmitCiphertext}[1]{\mathbf{C}^\enc_{#1}} \newcommand{\DiscloseCiphertext}{\mathbf{C}^\disclose} \newcommand{\Tag}[1]{\mathsf{tag}_{#1}} \newcommand{\Nonce}{\mathsf{nonce}} \newcommand{\Prenonce}{\mathsf{prenonce}} \newcommand{\Encrypt}[1]{\mathsf{Encrypt}_{#1}} \newcommand{\CRH}{\mathsf{CRH}} \newcommand{\CRHbox}[1]{\CRH\left(\;\raisebox{-1.3ex}{\usebox{#1}}\;\right)} \newcommand{\FullHash}{\mathtt{SHA256}} \newcommand{\FullHashbox}[1]{\FullHash\left(\;\raisebox{-1.3ex}{\usebox{#1}}\;\right)} \newcommand{\Justthebox}[1]{\;\raisebox{-1.3ex}{\usebox{#1}}\;} \newcommand{\PRF}[2]{\mathsf{{PRF}^{#2}_\mathnormal{#1}}} \newcommand{\PRFaddr}[1]{\PRF{#1}{addr}} \newcommand{\PRFsn}[1]{\PRF{#1}{sn}} \newcommand{\PRFpk}[1]{\PRF{#1}{pk}} \newcommand{\PRFrho}[1]{\PRF{#1}{\CoinAddressRand}} \newcommand{\SHA}{\mathtt{SHA256Compress}} \newcommand{\SHAName}{\term{SHA-256 compression}} \newcommand{\SHAOrig}{\term{SHA-256}} \newcommand{\cm}{\mathsf{cm}} \newcommand{\cmNew}[1]{\mathsf{{cm}^{new}_\mathnormal{#1}}} \newcommand{\InternalHashK}{\mathsf{k}} \newcommand{\InternalHash}{\mathsf{InternalH}} \newcommand{\Leading}[1]{\mathtt{Leading}_{#1}} \newcommand{\ReplacementCharacter}{\textsf{U+FFFD}} % merkle tree \newcommand{\MerkleDepth}{\mathsf{d}} \newcommand{\sn}{\mathsf{sn}} \newcommand{\snOld}[1]{\mathsf{{sn}^{old}_\mathnormal{#1}}} % bitcoin \newcommand{\vin}{\mathtt{vin}} \newcommand{\vout}{\mathtt{vout}} \newcommand{\vpour}{\mathtt{vpour}} \newcommand{\vpubOldField}{\mathtt{vpub\_old}} \newcommand{\vpubNewField}{\mathtt{vpub\_new}} \newcommand{\vsum}[2]{\smashoperator[r]{\sum_{#1}^{#2}}} \newcommand{\anchorField}{\mathtt{anchor}} \newcommand{\scriptSig}{\mathtt{scriptSig}} \newcommand{\scriptPubKey}{\mathtt{scriptPubKey}} \newcommand{\serials}{\mathtt{serials}} \newcommand{\commitments}{\mathtt{commitments}} \newcommand{\encEphemeral}{\mathtt{encEphemeral}} \newcommand{\encCiphertexts}{\mathtt{encCiphertexts}} \newcommand{\discloseEphemeral}{\mathtt{discloseEphemeral}} \newcommand{\discloseCiphertext}{\mathtt{discloseCiphertext}} \newcommand{\rt}{\mathsf{rt}} % pour \newcommand{\hSig}{\mathsf{h_{Sig}}} \newcommand{\h}[1]{\mathsf{h_{\mathnormal{#1}}}} \newcommand{\NOld}{\mathrm{N}^\mathsf{old}} \newcommand{\NNew}{\mathrm{N}^\mathsf{new}} \newcommand{\vmacs}{\mathtt{vmacs}} \newcommand{\zkproof}{\mathtt{zkproof}} \newcommand{\PourCircuit}{\term{\texttt{POUR} circuit}} \newcommand{\PourStatement}{\texttt{POUR}} \newcommand{\PourProof}{\pi_{\PourStatement}} \newcommand{\vpubOld}{\mathsf{v_{pub}^{old}}} \newcommand{\vpubNew}{\mathsf{v_{pub}^{new}}} \newcommand{\cOld}[1]{\mathbf{c}_{#1}^\mathsf{old}} \newcommand{\cNew}[1]{\mathbf{c}_{#1}^\mathsf{new}} \newcommand{\vOld}[1]{\mathsf{v}_{#1}^\mathsf{old}} \newcommand{\vNew}[1]{\mathsf{v}_{#1}^\mathsf{new}} \newcommand{\NP}{\mathsf{NP}} \newcommand{\treepath}[1]{\mathsf{path}_{#1}} \newcommand{\COMM}[1]{\mathsf{COMM}_{#1}} \newcommand{\COMMtrapdoor}{\term{\textsf{COMM} trapdoor}} \newcommand{\CoinCommitment}[1]{\mathtt{CoinCommitment}(#1)} \begin{document} \title{Zcash Protocol Specification \\ \Large Version 2.0-draft-2} \author{Sean Bowe | Daira Hopwood | Taylor Hornby} \date{\today} \maketitle \tableofcontents \newpage \section{Introduction} \Zcash is an implementation of the \term{Decentralized Anonymous Payment} scheme \Zerocash \cite{ZerocashOakland} 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 (\zkSNARKs). Changes from the original \Zerocash are highlighted in \changed{\changedcolor}. \section{Caution} \Zcash security depends on consensus. Should your program diverge from consensus, its security is weakened or destroyed. The cause of the divergence doesn't matter: it could be a bug in your program, it could be an error in this documentation which you implemented as described, or it could be you do everything right but other software on the network behaves unexpectedly. The specific cause will not matter to the users of your software whose wealth is lost. Having said that, a specification of \emph{intended} behaviour is essential for security analysis, understanding of the protocol, and maintenance of Zcash Core and related software. If you find any mistake in this specification, please contact \todo{address}. While the production \Zcash network has yet to be launched, please feel free to do so in public even if you believe the mistake may indicate a security weakness. \section{Concepts} \subsection{Integers, Bit Sequences, and Endianness} All integers visible in \Zcash-specific encodings are unsigned, have a fixed bit length, and are encoded as big-endian. In bit layout diagrams, each box of the diagram represents a sequence of bits. If the content of the box is a byte sequence, it is implicitly converted to a sequence of bits using big endian order. The bit sequences are then concatenated in the order shown from left to right, and the result is converted to a sequence of bytes, again using big-endian order. \nathan{An example would help here. It would be illustrative if it had a few differently-sized fields.} $\Leading{k}(x)$, where $k$ is an integer and $x$ is a bit sequence, returns the leading (initial) $k$ bits of its input. \subsection{Cryptographic Functions} $\CRH$ is a collision-resistant hash function. In \Zcash, the $\SHAName$ function is used which takes a 512-bit block and produces a 256-bit hash. This is different from the $\SHAOrig$ function, which hashes arbitrary-length strings. \cite{sha256} $\PRF{x}{}$ is a pseudo-random function seeded by $x$. \changed{Four} \emph{independent} $\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFsn{x}$, $\PRFpk{x}$\changed{, and $\PRFrho{x}$}. It is required that $\PRFsn{x}$ \changed{and $\PRFrho{x}$} be collision-resistant across all $x$ --- i.e. it should not be feasible to find $(x, y) \neq (x', y')$ such that $\PRFsn{x}(y) = \PRFsn{x'}(y')$\changed{, and similarly for $\PRFrho{}$}. In \Zcash, the $\SHAName$ function is used to construct all four of these functions. The bits $\mathtt{00}$, $\mathtt{01}$, $\mathtt{10}$\changed{, and $\mathtt{11}$} are included (respectively) within the blocks that are hashed, ensuring that the functions are independent. \newcommand{\iminusone}{\hspace{0.3pt}\scriptsize{$i$\hspace{0.6pt}-1}} \newsavebox{\addrbox} \begin{lrbox}{\addrbox} \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\AuthPrivate$} & \bitbox{18}{0} & \bitbox{18}{0} & \bitbox{222}{$0^{254}$} & \end{bytefield} \end{lrbox} \newsavebox{\snbox} \begin{lrbox}{\snbox} \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\AuthPrivate$} & \bitbox{18}{0} & \bitbox{18}{1} & \bitbox{222}{$\Leading{254}(\CoinAddressRand)$} & \end{bytefield} \end{lrbox} \newsavebox{\pkbox} \begin{lrbox}{\pkbox} \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\AuthPrivate$} & \bitbox{18}{1} & \bitbox{18}{0} & \bitbox{18}{\iminusone} & \bitbox{204}{$\Leading{253}(\hSig)$} \end{bytefield} \end{lrbox} \newsavebox{\rhobox} \begin{lrbox}{\rhobox} \setchanged \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\CoinAddressPreRand$} & \bitbox{18}{1} & \bitbox{18}{1} & \bitbox{18}{\iminusone} & \bitbox{204}{$\Leading{253}(\hSig)$} \end{bytefield} \end{lrbox} \nathan{Note: If we change input arity (i.e. $\NOld$), we need to be aware of how it is associated with this bit-packing.} \begin{equation*} \begin{aligned} \AuthPublic &:= \PRFaddr{\AuthPrivate}(0) &= \CRHbox{\addrbox} \\ \sn &:= \PRFsn{\AuthPrivate}(\CoinAddressRand) &= \CRHbox{\snbox} \\ \h{i} &:= \PRFpk{\AuthPrivate}(i, \hSig) &= \CRHbox{\pkbox} \\ \setchanged \CoinAddressRandNew{i} &\setchanged := \PRFrho{\CoinAddressPreRand}(i, \hSig) &\setchanged = \CRHbox{\rhobox} \end{aligned} \end{equation*} \daira{Should we instead define $\CoinAddressRand$ to be 254 bits and $\hSig$ to be 253 bits?} \subsection{Payment Addresses\changed{, Viewing Keys,} and Spending Keys} A \keyTuple $(\PaymentAddress, \changed{\ViewingKey,\;} \SpendingKey)$ is generated by users who wish to receive payments under this scheme. The parts of the \keyTuple are composed from \changed{three} distinct keypairs, called the \authKeypair, \transmitKeypair \changed{, and \discloseKeypair} keypairs. \begin{itemize} \item The \paymentAddress $\PaymentAddress$ is a pair $(\AuthPublic, \TransmitPublic)$, containing the \emph{public} components of the \authKeypair and \transmitKeypair keypairs respectively. \changed{ \item The \viewingKey $\ViewingKey$ is a pair $(\TransmitPrivate, \DisclosePrivate)$, containing the \emph{private} components of the \transmitKeypair and \discloseKeypair keypairs respectively. } \item The \spendingKey $\SpendingKey$ is a \changed{triple} $(\AuthPrivate, \TransmitPrivate\changed{, \DisclosePrivate})$, containing the \emph{private} components of the \authKeypair, \transmitKeypair\changed{, and \discloseKeypair} keypairs respectively. \end{itemize} The following diagram depicts the relations between key components. Arrows point from a private component to the corresponding public component derived from it. \begin{center} \includegraphics[scale=.5]{key_components} \end{center} Note that a \spendingKey holder can derive $(\AuthPublic, \TransmitPublic\changed{, \DisclosePublic})$, \changed{and a \viewingKey holder can derive $(\TransmitPublic, \DisclosePublic)$,} even though these components are not formally part of the respective keys. Implementations \MAY cache these derived public components, provided that they are deleted if the corresponding private component is deleted. The composition of \paymentAddresses\changed{, \viewingKeys,} and \spendingKeys is a cryptographic protocol detail that should not normally be exposed to users. However, user-visible operations should be provided to: \begin{itemize} \changed{ \item obtain a \viewingKey from a \spendingKey; and } \item obtain a \paymentAddress from a \spendingKey. \end{itemize} Users can accept payment from multiple parties with a single $\PaymentAddress$ and the fact that these payments are destined to the same payee is not revealed on the blockchain, even to the paying parties. \emph{However} if two parties collude to compare a $\PaymentAddress$ they can trivially determine they are the same. In the case that a payee wishes to prevent this they should create a distinct \paymentAddress for each payer. \subsection{Coins} A \coin (denoted $\Coin$) is a tuple $\changed{(\AuthPublic, \Value, \CoinAddressRand, \CoinCommitRand)}$ which represents that a value $\Value$ is spendable by the recipient who holds the $\authKeypair$ key pair $(\AuthPublic, \AuthPrivate)$ such that $\AuthPublic = \PRFaddr{\AuthPrivate}(0)$. $\CoinCommitRand$ is randomly generated by the sender. \changed{$\CoinAddressRand$ is generated from a random seed $\CoinAddressPreRand$ using $\PRFrho{\CoinAddressPreRand}$.} Only a commitment to these values is disclosed publicly, which allows the tokens $\CoinCommitRand$ and $\CoinAddressRand$ to blind the value and recipient \emph{except} to those who possess these tokens. \subsubsection{In-band secret distribution} In order to transmit the secret $\Value$, $\CoinAddressRand$, and $\CoinCommitRand$ (necessary for the recipient to later spend) \changed{and also a \memo} to the recipient \emph{without} requiring an out-of-band communication channel, the \transmitKeypair public key $\TransmitPublic$ is used to encrypt these secrets. The recipient's possession of the associated $(\PaymentAddress, \SpendingKey)$ (which contains both $\AuthPublic$ and $\TransmitPrivate$) is used to reconstruct the original \coin \changed{ and \memo}. \changed{To also transmit these values to a \viewingKey holder for outgoing \PourTransfers, the \discloseKeypair public key $\DisclosePublic$ is used to encrypt the ephemeral secret and address public keys from the preceding encryptions.} The encryptions are combined to form a \coinsCiphertext. \changed{ The encryption algorithm is defined in terms of $\CryptoBox$ (specifically, $\CryptoBoxSpecific$) \cite{cryptobox} as follows. } \newsavebox{\prenoncebox} \begin{lrbox}{\prenoncebox} \setchanged \begin{bytefield}[bitwidth=0.05em]{520} \bitbox{120}{64 bit $\Tag{i}$} & \bitbox{256}{256 bit $\EphemeralPublic{}$} \bitbox{256}{256 bit $\PublicKey{i}$} \end{bytefield} \end{lrbox} \newsavebox{\noncebox} \begin{lrbox}{\noncebox} \setchanged \begin{bytefield}[bitwidth=0.085em]{192} \bitbox{128}{$\Leading{128}(\Prenonce)$} & \bitbox{64}{64 bit $\Tag{i}$} \end{bytefield} \end{lrbox} \newsavebox{\tagibox} \begin{lrbox}{\tagibox} \setchanged \begin{bytefield}[bitwidth=0.09em]{64} \bitbox{64}{64 bit $i-1$} \end{bytefield} \end{lrbox} \newsavebox{\tagdbox} \begin{lrbox}{\tagdbox} \setchanged \begin{bytefield}[bitwidth=0.09em]{64} \bitbox{64}{$1^{64}$} \end{bytefield} \end{lrbox} \newsavebox{\disclosebox} \begin{lrbox}{\disclosebox} \setchanged \begin{bytefield}[bitwidth=0.04em]{1536} \bitbox{256}{256 bit $\TransmitEphemeralPrivate$} \bitbox{256}{256 bit $\TransmitPublicNew{\mathrm{1}}$} \bitbox{40}{...} \bitbox{256}{256 bit $\TransmitPublicNew{\NNew}$} \end{bytefield} \end{lrbox} Let $\TransmitPublicNew{\mathrm{1}..\NNew}$ be the \changed{Curve25519} public keys for the intended recipient addresses of each new \coin, \changed{let $\PublicKey{\disclose}$ be the sender's \discloseKeypair public key,} and let $\Plaintext{1..\NNew}$ be the \coinPlaintexts. \changed{ Define: \begin{equation*} \begin{aligned} \Prenonce(\Tag{i}, \EphemeralPublic, \PublicKey{i}) &:= \FullHashbox{\prenoncebox} \\ \Nonce(\Tag{i}, \EphemeralPublic, \PublicKey{i}) &:= \Justthebox{\noncebox} \\ \Tag{i} &:= \Justthebox{\tagibox} \\ \Tag{\disclose} &:= \Justthebox{\tagdbox} \\ \DisclosePlaintext &:= \Justthebox{\disclosebox} \end{aligned} \end{equation*} } Then to encrypt: \begin{itemize} \changed{ \item Generate two new independent Curve25519 (public, private) key pairs: $(\TransmitEphemeralPublic, \TransmitEphemeralPrivate)$ and $(\DiscloseEphemeralPublic, \DiscloseEphemeralPrivate)$. \item For $i$ in $\{1..\NNew\}$, let $\TransmitCiphertext{i} = \CryptoBox(\Plaintext{i}, \PublicKey{i}, \EphemeralPrivate, \Nonce(\Tag{i}, \TransmitEphemeralPublic, \TransmitPublicNew{i}))$ \item Let $\DiscloseCiphertext = \CryptoBox(\DisclosePlaintext, \DisclosePublic, \DiscloseEphemeralPrivate, \Nonce(\Tag{\disclose}, \DiscloseEphemeralPublic, \DisclosePublic))$ } \end{itemize} The resulting \coinsCiphertext is $\changed{(\TransmitEphemeralPublic,}\; \TransmitCiphertext{\mathrm{1}..\NNew}\changed{, \DiscloseEphemeralPublic, \DiscloseCiphertext)}$. Let $(\TransmitPublic, \TransmitPrivate)$ be the recipient's \changed{Curve25519} (public, private) key pair. Then for each $i$ in $\{1..\NNew\}$, the recipient will attempt to decrypt that ciphertext component as follows: \begin{itemize} \changed{ \item $\AllegedPlaintext{i} := \CryptoBoxOpen(\TransmitCiphertext{i}, \TransmitEphemeralPublic, \TransmitPrivate, \Nonce(\Tag{i}, \TransmitEphemeralPublic, \TransmitPublic))$ \item \todo{validation} } \end{itemize} \changed{ Similarly, let $(\DisclosePublic, \DisclosePrivate)$ be a \viewingKey holder's Curve25519 (public, private) key pair. Then for each \PourDescription in its \blockchainview, the \viewingKey holder will attempt to decrypt the corresponding \coinsCiphertext as follows: } \begin{itemize} \changed{ \item Let $\DisclosePlaintext := \CryptoBoxOpen(\DiscloseCiphertext, \DiscloseEphemeralPublic, \DisclosePrivate, \Nonce(\Tag{i}, \DiscloseEphemeralPublic, \DisclosePublic))$ \item Extract $\TransmitEphemeralPrivate$ and $\TransmitPublicNew{\mathrm{1}..\NNew}$ from $\DisclosePlaintext$. \item For $i$ in $\{1..\NNew\}$, \begin{itemize} \item let $\AllegedPlaintext{i} := \CryptoBoxOpen(\TransmitCiphertext{i}, \TransmitEphemeralPrivate, \TransmitPublicNew{i}, \Nonce(\Tag{i}, \TransmitEphemeralPublic, \TransmitPublicNew{i}))$ \item \todo{validation} \end{itemize} } \end{itemize} Any ciphertext components that fail to decrypt \MUST be ignored. Once a component has been decrypted, it \MUST be validated as described in section ``Coin Commitments''. \changed{ This is based loosely on the $\CryptoBoxSeal$ algorithm defined in libsodium \cite{cryptoboxseal}, but with the following differences: \begin{itemize} \item The same ephemeral key is used for all encryptions to the recipient keys in a given \PourDescription. \item The nonce for each ciphertext component depends on the index $i$. The particular nonce construction is chosen so that a known-nonce distinguisher for $\mathsf{Salsa20}$ would not directly lead to a break of the IK-CCA (key privacy) property. \item $\FullHash$ (the full hash, not the compression function) is used instead of $\mathsf{blake2b}$. \item The ephemeral secret $\TransmitEphemeralPrivate$ is included together with the \transmitKeypair public keys of the recipients, encrypted to the \discloseKeypair public key. This allows a \viewingKey holder to decrypt and validate these ciphertexts (if the sender constructs the \PourDescription honestly). It also ensures (without assuming honesty of the sender) that if the \viewingKey holder can decrypt a given component, then the indicated recipient also has enough information to decrypt it and will receive the same \coinPlaintext. \end{itemize} } \subsubsection{Coin Commitments} The underlying $\Value$ and $\AuthPublic$ are blinded with $\CoinAddressRand$ and $\CoinCommitRand$ using the collision-resistant hash function $\CRH$ in a multi-layered process. The resulting hash $\cm = \CoinCommitment{\Coin}$. \newsavebox{\ihbox} \begin{lrbox}{\ihbox} \begin{bytefield}[bitwidth=0.08em]{512} \bitbox{256}{256 bit $\AuthPublic$} & \bitbox{256}{256 bit $\CoinAddressRand$} \end{bytefield} \end{lrbox} \newsavebox{\ihkbox} \begin{lrbox}{\ihkbox} \begin{bytefield}[bitwidth=0.08em]{512} \bitbox{384}{384 bit $\CoinCommitRand$} & \bitbox{128}{$\Leading{128}(\InternalHash)$} \end{bytefield} \end{lrbox} \newsavebox{\cmbox} \begin{lrbox}{\cmbox} \begin{bytefield}[bitwidth=0.08em]{512} \bitbox{64}{64 bit $\Value$} & \bitbox{192}{192 bit padding} & \bitbox{256}{256 bit $\InternalHashK$} \end{bytefield} \end{lrbox} \begin{equation*} \begin{aligned} \InternalHash &:= \CRHbox{\ihbox} \\ \InternalHashK &:= \CRHbox{\ihkbox} \\ \cm &:= \CRHbox{\cmbox} \end{aligned} \end{equation*} \subsubsection{Serial numbers} A \serialNumber (denoted $\sn$) equals $\PRFsn{\AuthPrivate}(\CoinAddressRand)$. A \coin is spent by proving knowledge of $\CoinAddressRand$ and $\AuthPrivate$ in zero knowledge while disclosing $\sn$, allowing $\sn$ to be used to prevent double-spending. \subsection{Coin Commitment Tree} \begin{center} \includegraphics[scale=.4]{incremental_merkle} \end{center} The \coinCommitmentTree is an \incrementalMerkleTree of depth $\MerkleDepth$ used to store \coinCommitments that \PourTransfers produce. Just as the \term{unspent transaction output set} (UTXO) used in Bitcoin, it is used to express the existence of value and the capability to spend it. However, unlike the UTXO, it is \emph{not} the job of this tree to protect against double-spending, as it is append-only. Blocks in the blockchain are associated (by all nodes) with the root of this tree after all of its constituent \PourDescriptions' \coinCommitments have been entered into the tree associated with the previous block. \subsection{Spent Serials Map} Transactions insert \serialNumbers into a \spentSerialsMap which is maintained alongside the UTXO by all nodes. \eli{a tx is just a string, so it doesn't insert anything. Rather, nodes process tx's and the ``good'' ones lead to the addition of serials to the spent serials map.} Transactions that attempt to insert a \serialNumber into this map that already exists within it are invalid as they are attempting to double-spend. \eli{After defining \term{transaction}, one should define what a \term{legal tx} is (this definition depends on a particular blockchain [view]) and only then can one talk about ``attempts'' of transactions, and insertions of serial numbers into the spent serials map.} \subsection{The Blockchain} At a given point in time, the \blockchainview of each \fullnode consists of a sequence of one or more valid \blocks. Each \block consists of a sequence of one or more \transactions. In a given node's \blockchainview, \treestates are chained in an obvious way: \begin{itemize} \item The input \treestate of the first \block is the empty \treestate. \item The input \treestate of the first \transaction of a \block is the final \treestate of the immediately preceding \block. \item The input \treestate of each subsequent \transaction in a \block is the output \treestate of the immediately preceding \transaction. \item The final \treestate of a \block is the output \treestate of its last \transaction. \end{itemize} An \anchor is a Merkle tree root of a \treestate, and uniquely identifies that \treestate given the assumed security properties of the Merkle tree's hash function. Each \transaction is associated with a \sequenceOfPourDescriptions. \todo{They also have a transparent value flow that interacts with the Pour \changed{$\vpubOld$ and} $\vpubNew$.} Inputs and outputs are associated with a value. The total value of the outputs must not exceed the total value of the inputs. The \anchor of the \changed{first} \PourDescription in a \transaction must refer to some earlier \block's final \treestate. \changed{ The \anchor of each subsequent \PourDescription may refer either to some earlier \block's final \treestate, or to the output \treestate of the immediately preceding \PourDescription. } These conditions act as constraints on the blocks that a \fullnode will accept into its \blockchainview. We rely on Bitcoin-style consensus for \fullnodes to eventually converge on their views of valid \blocks, and therefore of the sequence of \treestates in those \blocks. \subparagraph{Value pool} Transaction inputs insert value into a \term{value pool}, and transaction outputs remove value from this pool. The remaining value in the pool is available to miners as a fee. \section{Pour Transfers and Descriptions} A \PourDescription is data included in a \block that describes a \PourTransfer, i.e. a confidential value transfer. This kind of value transfer is the primary \Zerocash-specific operation performed by transactions; it uses, but should not be confused with, the \PourCircuit used for the \zkSNARK proof and verification. A \PourTransfer spends $\NOld$ \coins $\cOld{1..\NOld}$ and creates $\NNew$ \coins $\cNew{1..\NNew}$. \Zcash transactions have an additional field $\vpour$, which is a \sequenceOfPourDescriptions. Each \PourDescription consists of: \begin{list}{}{} \changed{ \item $\vpubOldField$ which is a value $\vpubOld$ that the \PourTransfer removes from the value pool. } \item $\vpubNewField$ which is a value $\vpubNew$ that the \PourTransfer inserts into the value pool. \item $\anchorField$ which is a merkle root $\rt$ of the \coinCommitmentTree at some block height in the past, or the merkle root produced by a previous pour in this transaction. \sean{We need to be more specific here.} \item $\scriptSig$ which is a \script that creates conditions for acceptance of a \PourDescription in a transaction. \item $\scriptPubKey$ which is a \script used to satisfy the conditions of the $\scriptSig$. \item $\serials$ which is an $\NOld$ size sequence of serials $\snOld{\mathrm{1}..\NOld}$. \item $\commitments$ which is a $\NNew$ size sequence of \coinCommitments $\cmNew{\mathrm{1}..\NNew}$. \changed{ \item $\encEphemeral$ which is a Curve25519 public key $\TransmitEphemeralPublic$. \item $\encCiphertexts$ which is a $\NNew$ size sequence of ciphertext components, $\TransmitCiphertext{\mathrm{1}..\NNew}$. \item $\discloseEphemeral$ which is a Curve25519 public key $\DiscloseEphemeralPublic$. \item $\discloseCiphertext$ which is the ciphertext component $\DiscloseCiphertext$. (The preceding four fields together form the \coinsCiphertext.) } \item $\vmacs$ which is a $\NOld$ size sequence of message authentication tags $\h{\mathrm{1}..\NOld}$ that bind $\hSig$ to each $\AuthPrivate$ of the $\PourDescription$. \item $\zkproof$ which is the zero-knowledge proof $\PourProof$. \end{list} \subparagraph{Computation of $\hSig$} \newsavebox{\hsigbox} \begin{lrbox}{\hsigbox} \setchanged \begin{bytefield}[bitwidth=0.045em]{808} \bitbox{80}{$\hSigInputVersionByte$} & \bitbox{256}{256 bit $\snOld{0}$} & \bitbox{24}{...} & \bitbox{256}{256 bit $\snOld{\NOld-1}$} & \bitbox{256}{$\scriptPubKey$} \end{bytefield} \end{lrbox} \changed{ Given a \PourDescription, we define: \begin{itemize} \item[] $\hSig := \FullHashbox{\hsigbox}$ \end{itemize} } \subparagraph{Merkle root validity} A \PourDescription is valid if $\rt$ is a \coinCommitmentTree root found in either the blockchain or a merkle root produced by inserting the \coinCommitments of a previous $\PourDescription$ in the transaction to the \coinCommitmentTree identified by that previous $\PourDescription$'s $\anchor$. \subparagraph{Non-malleability} A \PourDescription is valid if the script formed by appending $\scriptPubKey$ to $\scriptSig$ returns $true$. The $\scriptSig$ is cryptographically bound to $\PourProof$. \subparagraph{Balance} A \PourTransfer can be seen, from the perspective of the transaction, as an input \changed{and an output simultaneously}. \changed{$\vpubOld$ takes value from the value pool and} $\vpubNew$ adds value to the value pool. As a result, \changed{$\vpubOld$ is treated like an \emph{output} value, whereas} $\vpubNew$ is treated like an \emph{input} value. \changed{ Note that unlike original \Zerocash \cite{ZerocashOakland}, \Zcash does not have a distinction between Mint and Pour transfers. The addition of $\vpubOld$ to a \PourDescription subsumes the functionality of Mint. Also, \PourDescriptions are indistinguishable regardless of the number of real input \coins. } \subparagraph{Commitments and Serials} A \transaction that contains one or more \PourDescriptions, when entered into the blockchain, appends to the \coinCommitmentTree with all constituent \coinCommitments. All of the constituent \serialNumbers are also entered into the \spentSerialsMap of the \blockchainview \emph{and} \mempool. A \transaction is not valid if it attempts to add a \serialNumber to the \spentSerialsMap that already exists in the map. \subsection{Pour Circuit and Proofs} In \Zcash, $\NOld$ and $\NNew$ are both $2$. A valid instance of $\PourProof$ assures that given a \term{primary input} $(\rt, \snOld{\mathrm{1}..\NOld}, \cmNew{\mathrm{1}..\NNew}, \changed{\vpubOld,\;} \vpubNew, \hSig, \h{1..\NOld})$, a witness of \term{auxiliary input} $(\treepath{1..\NOld}, \cOld{1..\NOld}, \AuthPrivateOld{\mathrm{1}..\NOld}, \cNew{1..\NNew}\changed{, \CoinAddressPreRand})$ exists, where: \begin{list}{}{} \item for each $i \in \{1..\NOld\}$: $\cOld{i}$ = $(\AuthPublicOld{i}, \vOld{i}, \CoinAddressRandOld{i}, \CoinCommitRandOld{i})$ \item for each $i \in \{1..\NNew\}$: $\cNew{i}$ = $(\AuthPublicNew{i}, \vNew{i}, \CoinAddressRandNew{i}, \CoinCommitRandNew{i})$ \item The following conditions hold: \end{list} \subparagraph{Merkle path validity} for each $i \in \{1..\NOld\}$ \changed{$\mid$ $\vOld{i} \neq 0$}: $\treepath{i}$ must be a valid path of depth $\MerkleDepth$ from \linebreak $\CoinCommitment{\cOld{i}}$ to Coin commitment merkle tree root $\rt$. \subparagraph{Balance} $\changed{\vpubOld +} \vsum{i=1}{\NOld} \vOld{i} = \vpubNew + \vsum{i=1}{\NNew} \vNew{i}$. \subparagraph{Serial integrity} for each $i \in \{1..\NNew\}$: $\snOld{i} = \PRFsn{\AuthPrivateOld{i}}(\CoinAddressRandOld{i})$. \subparagraph{Spend authority} for each $i \in \{1..\NOld\}$: $\AuthPublicOld{i} = \PRFaddr{\AuthPrivateOld{i}}(0)$. \subparagraph{Non-malleability} for each $i \in \{1..\NOld\}$: $\h{i}$ = $\PRFpk{\AuthPrivateOld{i}}(i, \hSig)$ \changed{ \subparagraph{Uniqueness of $\CoinAddressRandNew{i}$} for each $i \in \{1..\NNew\}$: $\CoinAddressRandNew{i}$ = $\PRFrho{\CoinAddressPreRand}(i, \hSig)$ } \subparagraph{Commitment integrity} for each $i \in \{1..\NNew\}$: $\cmNew{i}$ = $\CoinCommitment{\cNew{i}}$ \section{Encoding Addresses, Private keys, Coins, and Pour descriptions} This section describes how \Zcash encodes public addresses, private keys, coins, and \PourDescriptions. Addresses, keys, and coins, can be encoded as a byte string; this is called the \term{raw encoding}. This byte string can then be further encoded using Base58Check. The Base58Check layer is the same as for upstream \Bitcoin addresses \cite{Base58Check}. SHA-256 compression function outputs are always represented as strings of 32 bytes. The language consisting of the following encoding possibilities is prefix-free. \subsection{Transparent Public Addresses} These are encoded in the same way as in \Bitcoin \cite{Base58Check}. \subsection{Transparent Private Keys} These are encoded in the same way as in \Bitcoin \cite{Base58Check}. \subsection{Confidential Public Addresses} A \paymentAddress consists of $\AuthPublic$ and $\TransmitPublic$. $\AuthPublic$ is a SHA-256 compression function output. $\TransmitPublic$ is a \changed{Curve25519} public key, for use with the encryption scheme defined in section ``In-band secret distribution". \subsubsection{Raw Encoding} The raw encoding of a confidential address consists of: \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{520} \changed{ \bitbox{48}{$\PaymentAddressLeadByte$} &}\bitbox{256}{$\AuthPublic$ (32 bytes)} & \bitbox{256}{A \changed{32-byte} encoding of $\TransmitPublic$} \end{bytefield} \end{equation*} \begin{itemize} \changed{ \item A byte, $\PaymentAddressLeadByte$, indicating this version of the raw encoding of a \Zcash public address. } \item 32 bytes specifying $\AuthPublic$. \item \changed{32 bytes} specifying $\TransmitPublic$, \changed{using the normal encoding of a Curve25519 public key \cite{Curve25519}}. \end{itemize} \daira{check that this lead byte is distinct from other Bitcoin stuff, and produces `z' as the Base58Check leading character.} \nathan{what about the network version byte?} \subsection{Confidential Address Secrets} A confidential address secret consists of $\AuthPrivate$ and $\TransmitPrivate$. $\AuthPrivate$ is a SHA-256 compression function output. $\TransmitPrivate$ is a \changed{Curve25519} private key, for use with the encryption scheme defined in section ``In-band secret distribution". \subsubsection{Raw Encoding} The raw encoding of a confidential address secret consists of, in order: \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{520} \changed{ \bitbox{48}{$\SpendingKeyLeadByte$} &}\bitbox{256}{$\AuthPrivate$ (32 bytes)} & \bitbox{256}{$\TransmitPrivate$ (32 bytes)} \end{bytefield} \end{equation*} \begin{itemize} \changed{ \item A byte $\SpendingKeyLeadByte$ indicating this version of the raw encoding of a \Zcash private key. } \item 32 bytes specifying $\AuthPrivate$. \item 32 bytes specifying $\TransmitPrivate$. \end{itemize} \daira{check that this lead byte is distinct from other Bitcoin stuff, and produces `z' as the Base58Check leading character.} \nathan{what about the network version byte?} \subsection{Coins} Transmitted coins are stored on the blockchain in encrypted form, together with a \coinCommitment $\cm$. The \coinPlaintexts associated with a \PourDescription are encrypted to the respective \transmitKeypair keys $\PublicKey{\mathrm{1}..\NNew}$, and the result forms a \coinsCiphertext. Each \coinPlaintext consists of $(\changed{\AuthPublic, }\Value, \CoinAddressRand, \CoinCommitRand\changed{, \Memo})$, where: \begin{itemize} \changed{ \item $\AuthPublic$ is a 32-byte \authKeypair public key of the recipient. } \item $\Value$ is a 64-bit unsigned integer representing the value of the \coin in \zatoshi (1 \ZEC = $10^8$ \zatoshi). \item $\CoinAddressRand$ is a 32-byte $\PRFsn{\AuthPrivate}$ preimage. \item $\CoinCommitRand$ is a 48-byte \COMMtrapdoor. \changed{ \item $\Memo$ is a 64-byte \memo associated with this \coin. } \end{itemize} \changed{ The usage of the $\memo$ is by agreement between the sender and recipient of the \coin. It should be encoded as a UTF-8 human-readable string \cite{Unicode}, padded with zero bytes. Wallet software is expected to strip any trailing zero bytes and then display the resulting UTF-8 string to the recipient user, where applicable. Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters (\ReplacementCharacter). This does not preclude uses of the \memo by automated software, but specification of such usage is not in the scope of this document. } Note that the value $\CoinCommitS$ described as being part of a \coin in the \Zerocash paper is not encoded because the instantiation of $\COMM{\CoinCommitS}$ does not use it. \subsubsection{Raw Encoding} The raw encoding of a \coinPlaintext consists of, in order: \begin{equation*} \begin{bytefield}[bitwidth=0.03em]{1480} \changed{ \bitbox{88}{$\TransmitPlaintextVersionByte$}& \bitbox{256}{$\AuthPublic$ (32 bytes)}& &}\bitbox{168}{$\Value$ (8 bytes)} & \bitbox{256}{$\CoinAddressRand$ (32 bytes)} & \bitbox{384}{$\CoinCommitRand$ (48 bytes)} & \changed{\bitbox{512}{$\Memo$ (64 bytes)}} \end{bytefield} \end{equation*} \begin{itemize} \changed{ \item A byte $\TransmitPlaintextVersionByte$ indicating this version of the raw encoding of a \coinPlaintext. \item 32 bytes specifying $\AuthPublic$. } \item 8 bytes specifying a big-endian encoding of $\Value$. \item 32 bytes specifying $\CoinAddressRand$. \item 48 bytes specifying $\CoinCommitRand$. \changed{ \item 64 bytes specifying $\Memo$. } \end{itemize} \section{Pours (within a transaction on the blockchain)} TBD. \changed{Describe case where there are fewer than $\NOld$ real input coins.} \section{Transactions} TBD. \changed{ \section{Differences from the Zerocash paper} \begin{itemize} \item Instead of ECIES, we use an encryption scheme based on $\CryptoBox$, defined in section ``In-band secret distribution". \item Faerie Gold fix (TBD). \item The paper defines a coin as a tuple $(\AuthPublic, \Value, \CoinAddressRand, \CoinCommitRand, \CoinCommitS, \cm)$, whereas this specification defines it as $(\AuthPublic, \Value, \CoinAddressRand, \CoinCommitRand)$. This is just a clarification, because the instantiation of $\COMM{\CoinCommitS}$ in section 5.1 of the paper does not use $\CoinCommitS$, and $\cm$ can be computed from the other fields. \end{itemize} } \section{References} \begingroup \renewcommand{\section}[2]{} \bibliographystyle{plain} \bibliography{zcash} \endgroup \end{document}