\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{\disclose}{\mathsf{disclose}} \newcommand{\shared}{\mathsf{shared}} \newcommand{\DHSecret}[1]{\mathsf{dhsecret}_{#1}} \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}[1]{\mathbf{c}_{#1}} \newcommand{\CoinPlaintext}[1]{\mathbf{cp}_{#1}} \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{\CurveMultiply}{\mathsf{Curve25519}} \newcommand{\CryptoBox}{\mathsf{crypto\_box}} \newcommand{\CryptoBoxOpen}{\mathsf{crypto\_box\_open}} \newcommand{\CryptoBoxSeal}{\mathsf{crypto\_box\_seal}} \newcommand{\CryptoBoxSpecific}{\mathsf{crypto\_box\_curve25519xsalsa20poly1305}} \newcommand{\DecryptCoin}{\mathtt{DecryptCoin}} \newcommand{\Plaintext}{\mathbf{P}} \newcommand{\Ciphertext}{\mathbf{C}} \newcommand{\Key}{\mathsf{K}} \newcommand{\TransmitPlaintext}[1]{\Plaintext^\enc_{#1}} \newcommand{\TransmitCiphertext}[1]{\Ciphertext^\enc_{#1}} \newcommand{\TransmitKey}[1]{\Key^\enc_{#1}} \newcommand{\DiscloseCiphertext}[1]{\Ciphertext^\disclose_{#1}} \newcommand{\SharedPlaintext}[1]{\Plaintext^\shared_{#1}} \newcommand{\SharedCiphertext}{\Ciphertext^\shared} \newcommand{\SharedKey}[1]{\Key^\shared_{#1}} \newcommand{\Tag}[1]{\mathsf{tag}_{#1}} \newcommand{\KDF}{\mathsf{KDF}} \newcommand{\Prenonce}{\mathsf{prenonce}} \newcommand{\PkEncrypt}[1]{\mathsf{PkEncrypt}_{#1}} \newcommand{\SymEncrypt}[1]{\mathsf{SymEncrypt}_{#1}} \newcommand{\SymDecrypt}[1]{\mathsf{SymDecrypt}_{#1}} \newcommand{\SymSpecific}{\mathsf{AEAD\_CHACHA20\_POLY1305}} \newcommand{\Clamp}{\mathsf{clamp_{Curve25519}}} \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{\discloseCiphertexts}{\mathtt{discloseCiphertexts}} \newcommand{\sharedCiphertext}{\mathtt{sharedCiphertext}} \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}{\mathtt{CoinCommitment}} \newcommand{\Receive}{\mathsf{Receive}} \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{Conventions} \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 (except in the definition of $\SymSpecific$ \cite{rfc7539} which internally uses length fields encoded as little-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. The notation $1..\mathrm{N}$, used as a subscript, means the sequence of values with indices $1$ through $\mathrm{N}$ inclusive. For example, $\AuthPublicNew{\mathrm{1}..\NNew}$ means the sequence $[\AuthPublicNew{\mathrm{1}}, \AuthPublicNew{\mathrm{2}}, ...\;\AuthPublicNew{\NNew}]$. \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{\addrboxa} \begin{lrbox}{\addrboxa} \setchanged \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\AuthPrivate$} & \bitbox{18}{0} & \bitbox{18}{0} & \bitbox{186}{$0^{252}$} & \bitbox{18}{0} & \bitbox{18}{0} & \end{bytefield} \end{lrbox} \newsavebox{\addrboxb} \begin{lrbox}{\addrboxb} \setchanged \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\DiscloseKey$} & \bitbox{18}{0} & \bitbox{18}{0} & \bitbox{186}{$0^{252}$} & \bitbox{18}{0} & \bitbox{18}{1} & \end{bytefield} \end{lrbox} \newsavebox{\addrboxc} \begin{lrbox}{\addrboxc} \setchanged \begin{bytefield}[bitwidth=0.065em]{512} \bitbox{242}{256 bit $\AuthPrivate$} & \bitbox{18}{0} & \bitbox{18}{0} & \bitbox{186}{$0^{252}$} & \bitbox{18}{1} & \bitbox{18}{0} & \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} \setchanged \DiscloseKey &\setchanged := \PRFaddr{\AuthPrivate}(0) &\setchanged = \CRHbox{\addrboxa} \\ \setchanged \AuthPublic &\setchanged := \PRFaddr{\DiscloseKey}(1) &\setchanged = \CRHbox{\addrboxb} \\ \setchanged \TransmitPrivate' &\setchanged := \PRFaddr{\AuthPrivate}(2) &\setchanged = \CRHbox{\addrboxc} \\ \setchanged \TransmitPrivate &\setchanged := \Clamp(\TransmitPrivate') & \\ \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?} \section{Concepts} \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} Each key component, i.e. each of $\AuthPublic$, $\TransmitPublic$, \changed{$\DiscloseKey$, }$\TransmitPrivate$, and $\AuthPrivate$, is a sequence of 32 bytes. \changed{$\AuthPublic$, $\DiscloseKey$, and $\TransmitPrivate$ are derived as follows:} \begin{equation*} \begin{aligned} \setchanged \DiscloseKey &\setchanged := \PRFaddr{\AuthPrivate}(0) & \hspace{30em} \\ \setchanged \AuthPublic &\setchanged := \PRFaddr{\DiscloseKey}(1) & \\ \setchanged \TransmitPrivate &\setchanged := \Clamp(\PRFaddr{\AuthPrivate}(2)) & \end{aligned} \end{equation*} \changed{ $\Clamp$ performs the clamping of Curve25519 private key bits, and $\CurveMultiply$ performs point multiplication, both as defined in \cite{Curve25519}. Let $\TransmitPublic := \CurveMultiply(\TransmitPrivate)$, i.e. the public key corresponding to the private key $\TransmitPrivate$. } 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{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 $\discloseCiphertexts$ which is a $\NOld$ size sequence of ciphertext components, $\DiscloseCiphertext{\mathrm{1}..\NOld}$. \item $\sharedCiphertext$ which is the ciphertext component $\SharedCiphertext$. (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} \todo{Describe case where there are fewer than $\NOld$ real input coins.} \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 $\CoinCommitment(\cOld{i})$ to \coinCommitmentTree 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{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{ Let $\SymEncrypt{\Key}(\Plaintext)$ be the $\SymSpecific$ encryption \cite{rfc7539} of plaintext $\Plaintext$ with empty ``additional data", empty nonce, and key $\Key$. } \newsavebox{\kdfbox} \begin{lrbox}{\kdfbox} \setchanged \begin{bytefield}[bitwidth=0.032em]{832} \bitbox{256}{256 bit $\DHSecret{i}$} & \bitbox{256}{256 bit $\EphemeralPublic$} & \bitbox{256}{256 bit $\TransmitPublicNew{i}$} & \bitbox{160}{8 bit $i-1$} \end{bytefield} \end{lrbox} \newsavebox{\sharedbox} \begin{lrbox}{\sharedbox} \setchanged \begin{bytefield}[bitwidth=0.045em]{768} \bitbox{256}{256 bit $\TransmitPublicNew{\mathrm{1}}$} \bitbox{40}{...} \bitbox{256}{256 bit $\TransmitPublicNew{\NNew}$} \bitbox{256}{256 bit $\EphemeralPrivate$} \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 $\CoinPlaintext{1..\NNew}$ be the \coinPlaintexts. Let $\TransmitPlaintext{i}$ be the raw encoding of $\CoinPlaintext{i}$. \changed{ Define: \begin{equation*} \begin{aligned} \KDF(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i) &:= \FullHashbox{\kdfbox} \\ \SharedPlaintext{} &:= \Justthebox{\sharedbox} \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\}$, \begin{itemize} \item Let $\DHSecret{i} := \CurveMultiply(\TransmitPublicNew{i}, \EphemeralPrivate)$. \item Let $\TransmitKey{i} := \KDF(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i)$. \item Let $\TransmitCiphertext{i} := \SymEncrypt{\TransmitKey{i}}(\TransmitPlaintext{i})$. \end{itemize} \item Let $\SharedKey{} := ...$. \item Let $\SharedCiphertext := \SymEncrypt{\SharedKey{}}(\SharedPlaintext{})$. \item For $i$ in $\{1..\NOld\}$, \begin{itemize} \item Let $\DiscloseCiphertext{i} := \SymEncrypt{\DiscloseKey{i}}(\SharedKey{})$. \end{itemize} } \end{itemize} The resulting \coinsCiphertext is $\changed{(\EphemeralPublic, \TransmitCiphertext{\mathrm{1}..\NNew}, \DiscloseCiphertext{\mathrm{1}..\NOld}, \SharedCiphertext)}$. Let $(\TransmitPublic, \TransmitPrivate)$ be the recipient's \changed{Curve25519} (public, private) key pair, and let $\cmNew{\mathrm{1}..\NNew}$ be the coin commitments of each output coin. Then for each $i$ in $\{1..\NNew\}$, the recipient will attempt to decrypt that ciphertext component as follows: \changed{ \begin{itemize} \item Let $\DHSecret{i} := \CurveMultiply(\EphemeralPublic, \TransmitPrivate)$. \item Return $\DecryptCoin(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i, \TransmitCiphertext{i}, \cmNew{i}).$ \end{itemize} $\DecryptCoin(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i, \TransmitCiphertext{i}, \cmNew{i})$ is defined as follows: \begin{itemize} \item Let $\TransmitKey{i} := \KDF(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i)$. \item Let $\TransmitPlaintext{i} := \SymDecrypt{\TransmitKey{i}}(\TransmitCiphertext{i})$. \item If $\TransmitPlaintext{i} = \bot$, return $\bot$. \item Extract $\CoinPlaintext{i} := (\AuthPublic, \Value, \CoinAddressRand, \CoinCommitRand, \Memo)$ from $\TransmitPlaintext{i}$. \item If $\CoinCommitment(\Coin{i}) \neq \cmNew{i}$, return $\bot$, else return $\CoinPlaintext{i}$. \end{itemize} } Note that this corresponds to step 3 (b) i. and ii. (first bullet point) of the $\Receive$ algorithm shown in Figure 2 of \cite{ZerocashOakland}. 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{ 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: } \changed{ \begin{enumerate} \item Set $\SharedPlaintext{} := \bot$. \item For $i$ in $\{1..\NNew\}$, \begin{itemize} \item Let $\SharedKey{i} := \SymDecrypt{\DiscloseKey{}}(\DiscloseCiphertext{i}, \Tag{i})$. \item If $\SharedKey{i} = \bot$ then continue with the next $i$. \item Let $\SharedPlaintext{i} := \SymDecrypt{\SharedKey{i}}(\SharedCiphertext)$. \item If $\SharedPlaintext{i} = \bot$ then continue with the next $i$. \item Set $\SharedPlaintext{} := \SharedPlaintext{i}$ and exit the loop. \end{itemize} \item If $\SharedPlaintext{} = \bot$ (i.e. it was not set in the loop), then this transaction does not contain any information decryptable by the \viewingKey; return $\bot$. \item Extract $\TransmitPublicNew{\mathrm{1}..\NNew}$ and $\EphemeralPrivate$ from $\SharedPlaintext{}$. \item For $i$ in $\{1..\NNew\}$, \begin{itemize} \item Let $\DHSecret{i} := \CurveMultiply(\TransmitPublicNew{i}, \EphemeralPrivate)$. \item Let $\CoinPlaintext{i} := \DecryptCoin(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i, \TransmitCiphertext{i}, \cmNew{i}).$ \end{itemize} \item Return $\CoinPlaintext{\mathrm{1}..\NNew}$. \end{enumerate} } If a party holds more than one \viewingKey, it may optimize the above procedure by performing the loop in step 2 for the $\DiscloseKey{}$ of each \viewingKey. It may be assumed that the first $\SharedPlaintext{i}$ that decrypts correctly is the one that should be used in step 4 onward. (However, additional information is provided by which \viewingKey was able to decrypt each $\DiscloseCiphertext{i}$.) \changed{ The public key encryption used in this part of the protocol 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 check whether the indicated recipients would be able to decrypt a given component, and if so to decrypt the memo field. (We do not rely on this to ensure that a \viewingKey holder can decrypt the other components of the output coins; instead, those are symmetrically encrypted to the \viewingKey and the correctness of this encryption is checked by the \PourCircuit.) \end{itemize} } \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 Payment 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{Private Payment 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{Spending Keys} 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} \changed{ \section{Differences from the Zerocash paper} \subsection{Faerie Gold attack and fix} \todo{} \subsection{In-band secret distribution} \todo{} \subsection{Miscellaneous} \begin{itemize} \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}