zips/protocol/protocol.tex

\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}}
\newcommand{\spentSerials}{\term{spent serial number set}}
% 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{\discloseKey}{\term{disclosure key}}
\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_{vk}}}
\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{\DiscloseKey}{\mathsf{a_{vk}}}
\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{\EphemeralPublic}{\mathsf{epk}}
\newcommand{\EphemeralPrivate}{\mathsf{esk}}
\newcommand{\TransmitPublic}{\mathsf{pk_{enc}}}
\newcommand{\TransmitPublicNew}[1]{\mathsf{pk^{new}_{\enc,\mathnormal{#1}}}}
\newcommand{\TransmitPrivate}{\mathsf{sk_{enc}}}
\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{\ephemeralKey}{\mathtt{ephemeralKey}}
\newcommand{\encCiphertexts}{\mathtt{encCiphertexts}}
\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 or output arity (i.e. $\NOld$ or $\NNew$), 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, Viewing Keys, and Spending Keys}

A \keyTuple $(\SpendingKey, \changed{\ViewingKey, }\PaymentAddress)$ is
generated by users who wish to receive payments under this scheme.
\changed{The \viewingKey $\ViewingKey$ is derived from the \spendingKey
$\SpendingKey$, and the \paymentAddress $\PaymentAddress$ is derived from
the \viewingKey.}

The following diagram depicts the relations between key components.
Arrows point from a component to any other component(s) that can be derived
from it.

\begin{center}
\includegraphics[scale=.8]{key_components}
\end{center}

Note that a \spendingKey holder can derive the other components\changed{,
and a \viewingKey holder can derive $(\AuthPublic, \TransmitPublic)$,}
even though these components are not formally part of the respective keys.
Implementations \MAY cache these derived components, provided that
they are deleted if the corresponding source 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 \paymentAddress from a \viewingKey; and
}
  \item obtain a \paymentAddress\changed{ or \viewingKey} from a \spendingKey.
\end{itemize}

\todo{Describe derivations.}

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 \discloseKey $\DiscloseKey$ is used to symmetrically
encrypt them, and also to encrypt the ephemeral secret and address public
keys (to allow the \viewingKey holder to check whether the other encryptions
are valid).} All of these 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 $\TransmitPublicNew{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{\disclosebox}
\begin{lrbox}{\disclosebox}
\setchanged
\begin{bytefield}[bitwidth=0.05em]{768}
        \bitbox{256}{256 bit $\EphemeralPrivate$}
        \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 $\DiscloseKey$ be the sender's \discloseKey,}
and let $\Plaintext{1..\NNew}$ be the \coinPlaintexts.

\changed{
Define:
\begin{equation*}
\begin{aligned}
\Prenonce(\Tag{i}, \EphemeralPublic, \TransmitPublicNew{i}) &:= \FullHashbox{\prenoncebox} \\
\Nonce(\Tag{i}, \EphemeralPublic, \TransmitPublicNew{i}) &:= \Justthebox{\noncebox} \\
\Tag{i} &:= \Justthebox{\tagibox} \\
\DisclosePlaintext &:= \Justthebox{\disclosebox}
\end{aligned}
\end{equation*}
}

Then to encrypt:

\begin{itemize}
\changed{
  \item Generate a new Curve25519 (public, private) key pair:
$(\EphemeralPublic, \EphemeralPrivate)$.
  \item For $i$ in $\{1..\NNew\}$, let $\TransmitCiphertext{i} =
\CryptoBox(\Plaintext{i}, \TransmitPublicNew{i}, \EphemeralPrivate,
\Nonce(\Tag{i}, \EphemeralPublic, \TransmitPublicNew{i}))$
  \item Let $\DiscloseCiphertext = ???_{\DiscloseKey}(\DisclosePlaintext)$
}
\end{itemize}

The resulting \coinsCiphertext is $\changed{(\TransmitPublic,}\;
\TransmitCiphertext{\mathrm{1}..\NNew}\changed{, \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},
\EphemeralPublic, \TransmitPrivate, \Nonce(\Tag{i}, \EphemeralPublic, \TransmitPublic))$
  \item \todo{validation}
}
\end{itemize}

To test whether a \coin is unspent in a particular \blockchainview also requires
the \authKeypair private key $\AuthPrivate$; the coin is unspent if and only if
$\sn = \PRFsn{\AuthPrivate}(\CoinAddressRand)$ is not in the \spentSerials
for that \blockchainview.

Note that a coin may change from being unspent to spent on a given \blockchainview,
as transactions are added to that view. Also, blockchain reorganisations may cause
the transaction in which a coin was output to no longer be on the consensus
blockchain.

\changed{
Similarly, let $\DiscloseKey$ be a \viewingKey holder's \discloseKey.
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 := ???_{\DiscloseKey}(\DiscloseCiphertext)$
  \item Extract $\EphemeralPrivate$ and $\TransmitPublicNew{\mathrm{1}..\NNew}$
from $\DisclosePlaintext$.
  \item For $i$ in $\{1..\NNew\}$,
    \begin{itemize}
      \item let $\AllegedPlaintext{i} :=
\CryptoBoxOpen(\TransmitCiphertext{i}, \EphemeralPrivate,
\TransmitPublicNew{i}, \Nonce(\Tag{i}, \EphemeralPublic, \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 $\EphemeralPrivate$ is included together with
        the \transmitKeypair public keys of the recipients, encrypted to the
        \discloseKey. 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 $\ephemeralKey$ which is a Curve25519 public key $\EphemeralPublic$.

\item $\encCiphertexts$ which is a $\NNew$ size sequence of ciphertext
components, $\TransmitCiphertext{\mathrm{1}..\NNew}$.

\item $\discloseCiphertext$ which is the ciphertext component
$\DiscloseCiphertext$.

(The preceding three 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 $\TransmitPublicNew{\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}