diff --git a/protocol/protocol.pdf b/protocol/protocol.pdf index c124306d0..bcf1c70be 100644 Binary files a/protocol/protocol.pdf and b/protocol/protocol.pdf differ diff --git a/protocol/protocol.tex b/protocol/protocol.tex index fae4726aa..7a1d3e340 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11,6 +11,8 @@ \RequirePackage[unicode,bookmarksnumbered,bookmarksopen,pdfview=Fit]{hyperref} \RequirePackage{nameref} \RequirePackage{enumitem} +\RequirePackage{tabularx} +\RequirePackage{hhline} \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 @@ -18,6 +20,7 @@ \setlength{\textheight}{9.2in} % Lower margin of 11 in - 9 in - 1 in = 1 in \setlength{\parskip}{1.5ex} \setlength{\parindent}{0ex} +\renewcommand{\arraystretch}{1.4} \overfullrule=2cm \setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,after=\vspace{1.5ex}} @@ -58,6 +61,7 @@ % terminology \newcommand{\term}[1]{\textsl{#1}\xspace} +\newcommand{\titleterm}[1]{#1\xspace} \newcommand{\termbf}[1]{\textbf{#1}\xspace} \newcommand{\conformance}[1]{\textmd{#1}\xspace} @@ -73,16 +77,22 @@ \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{\coin}{\term{note}} +\newcommand{\coins}{\term{notes}} +\newcommand{\Coin}{Note} +\newcommand{\Coins}{Notes} +\newcommand{\coinCommitment}{\term{note commitment}} +\newcommand{\coinCommitments}{\term{note commitments}} +\newcommand{\CoinCommitment}{\titleterm{Note Commitment}} +\newcommand{\CoinCommitments}{\titleterm{Note Commitments}} +\newcommand{\coinCommitmentTree}{\term{note commitment tree}} +\newcommand{\pourDescription}{\term{Xfer description}} +\newcommand{\pourDescriptions}{\term{Xfer descriptions}} +\newcommand{\sequenceOfPourDescriptions}{\changed{sequence of} \pourDescription\changed{\term{s}}\xspace} +\newcommand{\pourTransfer}{\term{Xfer operation}} +\newcommand{\pourTransfers}{\term{Xfer operations}} +\newcommand{\PourTransfer}{\titleterm{Xfer Operation}} +\newcommand{\PourTransfers}{\titleterm{Xfer Operations}} \newcommand{\fullnode}{\term{full node}} \newcommand{\fullnodes}{\term{full nodes}} \newcommand{\anchor}{\term{anchor}} @@ -95,9 +105,12 @@ \newcommand{\mempool}{\term{mempool}} \newcommand{\treestate}{\term{treestate}} \newcommand{\treestates}{\term{treestates}} -\newcommand{\serialNumber}{\term{serial number}} -\newcommand{\serialNumbers}{\term{serial numbers}} -\newcommand{\spentSerials}{\term{spent serial number set}} +\newcommand{\serialNumber}{\term{nullifier}} +\newcommand{\serialNumbers}{\term{nullifiers}} +\newcommand{\SerialNumber}{\titleterm{Nullifier}} +\newcommand{\SerialNumbers}{\titleterm{Nullifiers}} +\newcommand{\spentSerials}{\term{nullifier set}} +\newcommand{\SpentSerials}{\titleterm{Nullifier Set}} % Daira: This doesn't adequately distinguish between zk stuff and transparent stuff \newcommand{\paymentAddress}{\term{payment address}} \newcommand{\paymentAddresses}{\term{payment addresses}} @@ -106,17 +119,18 @@ \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{\coinPlaintext}{\term{note plaintext}} +\newcommand{\coinPlaintexts}{\term{note plaintexts}} +\newcommand{\CoinPlaintexts}{\titleterm{Note Plaintexts}} +\newcommand{\coinsCiphertext}{\term{transmitted notes ciphertext}} \newcommand{\authKeypair}{\term{authorization}} \newcommand{\transmitKeypair}{\term{transmission}} \newcommand{\discloseKey}{\term{disclosure key}} \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}} +\newcommand{\Memos}{\titleterm{Memo Fields}} % conventions \newcommand{\bytes}[1]{\underline{\raisebox{-0.22ex}{}\smash{#1}}} @@ -135,7 +149,7 @@ \newcommand{\SpendingKey}{\mathsf{addr_{sk}}} \newcommand{\PaymentAddressLeadByte}{\hexint{92}} \newcommand{\SpendingKeyLeadByte}{\hexint{??}} -\newcommand{\CoinCommitmentLeadByte}{\hexint{C0}} +\newcommand{\CoinCommitmentLeadNibble}{\mathbf{0}} \newcommand{\AuthPublic}{\mathsf{a_{pk}}} \newcommand{\AuthPrivate}{\mathsf{a_{sk}}} \newcommand{\AuthPublicOld}[1]{\mathsf{a^{old}_{pk,\mathnormal{#1}}}} @@ -159,8 +173,8 @@ \newcommand{\ValueNew}[1]{\mathsf{v^{new}_\mathnormal{#1}}} % Coins -\newcommand{\Coin}[1]{\mathbf{c}_{#1}} -\newcommand{\CoinPlaintext}[1]{\mathbf{cp}_{#1}} +\newcommand{\CoinTuple}[1]{\mathbf{n}_{#1}} +\newcommand{\CoinPlaintext}[1]{\mathbf{np}_{#1}} \newcommand{\CoinCommitRand}{\mathsf{r}} \newcommand{\CoinCommitRandOld}[1]{\mathsf{r^{old}_\mathnormal{#1}}} \newcommand{\CoinCommitRandNew}[1]{\mathsf{r^{new}_\mathnormal{#1}}} @@ -169,11 +183,13 @@ \newcommand{\CoinAddressRandNew}[1]{\mathsf{\uprho^{new}_\mathnormal{#1}}} \newcommand{\CoinAddressPreRand}{\mathsf{\upvarphi}} \newcommand{\CoinCommitS}{\mathsf{s}} -\newcommand{\hSigInputVersionByte}{\hexint{C1}} +\newcommand{\sn}{\mathsf{nf}} +\newcommand{\snOld}[1]{\sn^\mathsf{old}_\mathnormal{#1}} +\newcommand{\hSigInputLeadNibble}{\mathbf{1}} \newcommand{\Memo}{\mathsf{memo}} \newcommand{\CurveMultiply}{\mathsf{Curve25519}} \newcommand{\CurveBase}{\bytes{9}} -\newcommand{\DecryptCoin}{\mathtt{DecryptCoin}} +\newcommand{\DecryptNote}{\mathtt{DecryptNote}} \newcommand{\Plaintext}{\mathbf{P}} \newcommand{\Ciphertext}{\mathbf{C}} \newcommand{\Key}{\mathsf{K}} @@ -186,7 +202,7 @@ \newcommand{\DiscloseCiphertext}[1]{\Ciphertext^\disclose_{#1}} \newcommand{\SharedPlaintext}{\Plaintext^\shared} \newcommand{\KDF}{\mathsf{KDF}} -\newcommand{\KDFLeadByte}{\hexint{C2}} +\newcommand{\KDFLeadNibble}{\mathbf{2}} \newcommand{\SymEncrypt}[1]{\mathsf{SymEncrypt}_{#1}} \newcommand{\SymDecrypt}[1]{\mathsf{SymDecrypt}_{#1}} \newcommand{\SymSpecific}{\mathsf{AEAD\_CHACHA20\_POLY1305}} @@ -195,7 +211,7 @@ \newcommand{\Clamp}{\mathsf{clamp_{Curve25519}}} \newcommand{\PRF}[2]{\mathsf{{PRF}^{#2}_\mathnormal{#1}}} \newcommand{\PRFaddr}[1]{\PRF{#1}{addr}} -\newcommand{\PRFsn}[1]{\PRF{#1}{sn}} +\newcommand{\PRFsn}[1]{\PRF{#1}{\sn}} \newcommand{\PRFpk}[1]{\PRF{#1}{pk}} \newcommand{\PRFrho}[1]{\PRF{#1}{\CoinAddressRand}} \newcommand{\PRFdk}[1]{\PRF{#1}{dk}} @@ -211,28 +227,31 @@ % 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{\npour}{\mathtt{nxfer}} +\newcommand{\vpour}{\mathtt{vxfer}} \newcommand{\vpubOldField}{\mathtt{vpub\_old}} \newcommand{\vpubNewField}{\mathtt{vpub\_new}} \newcommand{\vsum}[2]{\smashoperator[r]{\sum_{#1}^{#2}}} \newcommand{\anchorField}{\mathtt{anchor}} -\newcommand{\pourSig}{\mathtt{pourSig}} -\newcommand{\pourPubKey}{\mathtt{pourPubKey}} -\newcommand{\serials}{\mathtt{serials}} +\newcommand{\pourSig}{\mathtt{xferSig}} +\newcommand{\pourPubKey}{\mathtt{xferPubKey}} +\newcommand{\dataToBeSigned}{\mathtt{dataToBeSigned}} +\newcommand{\serials}{\mathtt{nullifiers}} \newcommand{\commitments}{\mathtt{commitments}} \newcommand{\ephemeralKey}{\mathtt{ephemeralKey}} \newcommand{\encCiphertexts}{\mathtt{encCiphertexts}} \newcommand{\discloseCiphertexts}{\mathtt{discloseCiphertexts}} \newcommand{\randomSeed}{\mathtt{randomSeed}} \newcommand{\rt}{\mathsf{rt}} +\newcommand{\Varies}{\textit{Varies}} +\newcommand{\heading}[1]{\multicolumn{1}{c|}{#1}} +\newcommand{\type}[1]{\texttt{#1}} -% pour +% xfer \newcommand{\hSig}{\mathsf{h_{Sig}}} \newcommand{\hSigText}{\texorpdfstring{$\hSig$}{hSig}} \newcommand{\h}[1]{\mathsf{h_{\mathnormal{#1}}}} @@ -244,22 +263,23 @@ \newcommand{\setofOld}{\setof{\allOld}} \newcommand{\setofNew}{\setof{\allNew}} \newcommand{\vmacs}{\mathtt{vmacs}} +\newcommand{\zkproofSize}{\mathtt{zkproofSize}} \newcommand{\zkproof}{\mathtt{zkproof}} -\newcommand{\PourCircuit}{\term{\texttt{POUR} circuit}} -\newcommand{\PourStatement}{\texttt{POUR}} +\newcommand{\PourCircuit}{\term{\texttt{Xfer} circuit}} +\newcommand{\PourStatement}{\texttt{Xfer}} \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{\cpNew}[1]{\mathbf{cp}_{#1}^\mathsf{new}} +\newcommand{\cOld}[1]{\mathbf{n}_{#1}^\mathsf{old}} +\newcommand{\cNew}[1]{\mathbf{n}_{#1}^\mathsf{new}} +\newcommand{\cpNew}[1]{\mathbf{np}_{#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{\Commitment}{\mathtt{NoteCommitment}} \newcommand{\Receive}{\mathsf{Receive}} @@ -310,7 +330,7 @@ \section{Conventions} \subsection{Integers, Bit Sequences, and Endianness} All integers in \emph{\Zcash-specific} encodings are unsigned, have a fixed -bit length, and are encoded as big-endian. \changed{The definition of +bit length, and are encoded as little-endian. \changed{The definition of the encryption scheme based on $\SymSpecific$ \cite{rfc7539} in \crossref{inband} uses length fields encoded as little-endian. Also, Curve25519 public and private keys are defined as byte sequences, which are converted from integers @@ -323,29 +343,59 @@ \subsection{Integers, Bit Sequences, and Endianness} The bit length is given explicitly in each box, except for the case of a single bit, or for the notation $\zeros{n}$ which represents the sequence of $n$ zero 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 +a sequence of bits using little-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. +to a sequence of bytes, again using little-endian order. Note that the +\emph{least significant} bit of each byte is first, i.e. shown toward the left +of the diagram. -\newsavebox{\examplebox} -\begin{lrbox}{\examplebox} +\newsavebox{\exampleabox} +\begin{lrbox}{\exampleabox} \setchanged -\begin{bytefield}[bitwidth=0.6em]{32} - \bitbox{2}{0} & - \bitbox{2}{1} & - \bitbox{2}{0} & - \bitbox{2}{0} & +\begin{bytefield}[bitwidth=1.3em]{32} + \bitbox{1}{0} & + \bitbox{1}{1} & + \bitbox{1}{0} & + \bitbox{1}{0} & \bitbox{16}{16 bit $\hexint{ABCD}$} & - \bitbox{12}{12 bit $\hexint{0123}$} & + \bitbox{12}{12 bit $\hexint{123}$} & \end{bytefield} \end{lrbox} -For example, the diagram +\newsavebox{\examplebbox} +\begin{lrbox}{\examplebbox} +\setchanged +\begin{bytefield}[bitwidth=1.3em]{32} + \bitbox{4}{4 bit $\hexint{2}$} & + \bitbox{4}{4 bit $\hexint{D}$} & + \bitbox{4}{4 bit $\hexint{C}$} & + \bitbox{4}{4 bit $\hexint{B}$} & + \bitbox{4}{4 bit $\hexint{A}$} & + \bitbox{4}{4 bit $\hexint{3}$} & + \bitbox{4}{4 bit $\hexint{2}$} & + \bitbox{4}{4 bit $\hexint{1}$} & +\end{bytefield} +\end{lrbox} + +\newsavebox{\examplecbox} +\begin{lrbox}{\examplecbox} +\setchanged +\begin{bytefield}[bitwidth=1.3em]{32} + \bitbox{8}{8 bit $\hexint{D2}$} & + \bitbox{8}{8 bit $\hexint{BC}$} & + \bitbox{8}{8 bit $\hexint{A3}$} & + \bitbox{8}{8 bit $\hexint{12}$} & +\end{bytefield} +\end{lrbox} + +For example, the following diagrams are all equivalent: \begin{itemize} - \item[] $\Justthebox{\examplebox}{-1.3ex}$ + \item[] $\Justthebox{\exampleabox}{-1.3ex}$ + \item[] $\Justthebox{\examplebbox}{-1.3ex}$ + \item[] $\Justthebox{\examplecbox}{-1.3ex}$ \end{itemize} -represents the byte sequence $[\hexint{4A}, \hexint{BC}, \hexint{D1}, \hexint{23}]$. +and represent the byte sequence $[\hexint{D2}, \hexint{BC}, \hexint{A3}, \hexint{12}]$. The notation $\allN{}$, used as a subscript, means the sequence of values with indices $1$ through $\mathrm{N}$ inclusive. For example, @@ -378,13 +428,13 @@ \subsection{Cryptographic Functions} \begin{lrbox}{\addrbox} \setchanged \begin{bytefield}[bitwidth=0.06em]{512} - \bitbox{18}{0} & - \bitbox{18}{0} & + \bitbox{18}{1} & + \bitbox{18}{1} & \bitbox{18}{0} & \bitbox{18}{0} & \bitbox{224}{252 bit $x$} & - \bitbox{200}{$\zeros{253}$} & - \bitbox{56}{3 bit $t$} & + \bitbox{56}{2 bit $t$} & + \bitbox{200}{$\zeros{254}$} \end{bytefield} \end{lrbox} @@ -392,12 +442,12 @@ \subsection{Cryptographic Functions} \begin{lrbox}{\snbox} \setchanged \begin{bytefield}[bitwidth=0.06em]{512} - \bitbox{18}{0} & \bitbox{18}{1} & - \bitbox{18}{0} & + \bitbox{18}{1} & + \bitbox{18}{1} & \bitbox{18}{0} & \bitbox{224}{252 bit $\AuthPrivate$} & - \bitbox{256}{256 bit $\CoinAddressRand$} & + \bitbox{256}{256 bit $\CoinAddressRand$} \end{bytefield} \end{lrbox} @@ -405,10 +455,10 @@ \subsection{Cryptographic Functions} \begin{lrbox}{\pkbox} \setchanged \begin{bytefield}[bitwidth=0.06em]{512} - \bitbox{18}{0} & \bitbox{18}{\iminusone} & \bitbox{18}{0} & - \bitbox{18}{1} & + \bitbox{18}{0} & + \bitbox{18}{0} & \bitbox{224}{252 bit $\AuthPrivate$} & \bitbox{256}{256 bit $\hSig$} \end{bytefield} @@ -418,8 +468,8 @@ \subsection{Cryptographic Functions} \begin{lrbox}{\rhobox} \setchanged \begin{bytefield}[bitwidth=0.06em]{512} - \bitbox{18}{0} & \bitbox{18}{\iminusone} & + \bitbox{18}{0} & \bitbox{18}{1} & \bitbox{18}{0} & \bitbox{224}{252 bit $\CoinAddressPreRand$} & @@ -439,11 +489,15 @@ \subsection{Cryptographic Functions} \changed{ \subparagraph{Note:} -The most significant four bits of the first byte are used to distinguish -different uses of $\CRH$, ensuring that the functions are independent. -In addition to the inputs shown here, the first four bits $\mathtt{1100}$ -(i.e. a first byte of \textbf{0xC\dontcare}) are used to distinguish uses -of the full $\SHAOrig$ hash function -- see \crossref{comm} and \crossref{hsig}. +The first four bits --i.e. the least significant four bits of the first byte-- +are used to distinguish different uses of $\CRH$, ensuring that the functions +are independent. In addition to the inputs shown here, the bits $\mathtt{0111}$ +in this position are used to distinguish uses of the full $\SHAOrig$ hash function --- +see \crossref{comm}, \crossref{hsig}, and \crossref{inband}. +(The specific bit patterns chosen here are motivated by the possibility of future +extensions that either increase $\NOld$ and/or $\NNew$ to 3, or that add an +additional bit to $\AuthPrivate$ to encode a new key type, or that require an +additional PRF.) } @@ -510,9 +564,9 @@ \subsection{Payment Addresses and Spending Keys} case that a payee wishes to prevent this they should create a distinct \paymentAddress for each payer. -\subsection{Coins} +\subsection{\Coins} -A \coin (denoted $\Coin{}$) is a tuple $\changed{(\AuthPublic, \Value, +A \coin (denoted $\CoinTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, \CoinAddressRand, \CoinCommitRand)}$ which represents that a value $\Value$ is spendable by the recipient who holds the \spendingKey $\AuthPrivate$ corresponding to $\AuthPublic$, as described in the previous section. @@ -531,49 +585,53 @@ \subsection{Coins} 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} \label{comm} +\subsubsection{\CoinCommitments} \label{comm} The underlying $\Value$ and $\AuthPublic$ are blinded with $\CoinAddressRand$ and $\CoinCommitRand$ using the collision-resistant hash function \changed{$\FullHash$}. -The resulting hash $\cm = \CoinCommitment(\Coin{})$. +The resulting hash $\cm = \Commitment(\CoinTuple{})$. \newsavebox{\cmbox} \begin{lrbox}{\cmbox} \setchanged -\begin{bytefield}[bitwidth=0.042em]{776} - \bitbox{128}{8 bit $\CoinCommitmentLeadByte$} & - \bitbox{256}{256 bit $\AuthPublic$} & - \bitbox{128}{64 bit $\Value$} & - \bitbox{256}{256 bit $\CoinAddressRand$} - \bitbox{192}{192 bit $\CoinCommitRand$} & +\begin{bytefield}[bitwidth=0.039em]{776} + \bitbox{24}{0} & + \bitbox{24}{1} & + \bitbox{24}{1} & + \bitbox{24}{1} & + \bitbox{112}{4 bit $\CoinCommitmentLeadNibble$} & + \bitbox{256}{256 bit $\AuthPublic$} & + \bitbox{128}{64 bit $\Value$} & + \bitbox{256}{256 bit $\CoinAddressRand$} + \bitbox{192}{192 bit $\CoinCommitRand$} & \end{bytefield} \end{lrbox} \changed{ -\hskip 1.5em $\cm := \FullHashbox{\cmbox}$ +\hskip 1em $\cm := \FullHashbox{\cmbox}$ } -\subsubsection{Serial numbers} +\subsubsection{\SerialNumbers} -A \serialNumber (denoted $\sn$) equals -$\PRFsn{\AuthPrivate}(\CoinAddressRand)$. A \coin is spent by proving +A \serialNumber (denoted $\sn$) is derived from the $\CoinAddressRand$ component +of a \coin as $\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. +disclosing its \serialNumber $\sn$, allowing $\sn$ to be used to prevent double-spending. -\subsubsection{Coin plaintexts and memo fields} \label{coinpt} +\subsubsection{\CoinPlaintexts and \Memos} \label{coinpt} -Transmitted coins are stored on the blockchain in encrypted form, together with +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 +The \coinPlaintexts associated with a \pourDescription are encrypted to the respective \transmitKeypair keys $\TransmitPublicNew{\allNew}$, and the result forms part of a \coinsCiphertext (see \crossref{inband} for further details). Each \coinPlaintext (denoted $\CoinPlaintext{}$) consists of -$(\changed{\AuthPublic,\;}\Value, \CoinAddressRand, \CoinCommitRand\changed{, \Memo})$. +$(\Value, \CoinAddressRand, \CoinCommitRand\changed{, \Memo})$. -The first \changed{four} of these fields are as defined earlier. +The first three of these fields are as defined earlier. \changed{$\Memo$ is a 64-byte \memo associated with this \coin. The usage of the $\memo$ is by agreement between the sender and recipient of the @@ -588,9 +646,7 @@ \subsubsection{Coin plaintexts and memo fields} \label{coinpt} The encoding of a \coinPlaintext consists of, in order: \begin{equation*} \begin{bytefield}[bitwidth=0.035em]{1288} -\changed{ - \bitbox{256}{$\AuthPublic$ (32 bytes)}& - &}\bitbox{168}{$\Value$ (8 bytes)} & + \bitbox{168}{$\Value$ (8 bytes)} & \bitbox{256}{$\CoinAddressRand$ (32 bytes)} & \bitbox{192}{$\CoinCommitRand$ (\changed{24} bytes)} & \changed{\bitbox{512}{$\Memo$ (64 bytes)}} @@ -598,10 +654,7 @@ \subsubsection{Coin plaintexts and memo fields} \label{coinpt} \end{equation*} \begin{itemize} -\changed{ - \item 32 bytes specifying $\AuthPublic$. -} - \item 8 bytes specifying a big-endian encoding of $\Value$. + \item 8 bytes specifying $\Value$. \item 32 bytes specifying $\CoinAddressRand$. \item \changed{24} bytes specifying $\CoinCommitRand$. \changed{ @@ -610,38 +663,38 @@ \subsubsection{Coin plaintexts and memo fields} \label{coinpt} \end{itemize} -\subsection{Coin Commitment Tree} +\subsection{\CoinCommitment 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 +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 +after all of its constituent \pourDescriptions' \coinCommitments have been entered into the tree associated with the previous block. -\subsection{Spent Serials Map} +\subsection{\SpentSerials} -Transactions insert \serialNumbers into a \spentSerialsMap which is maintained +Transactions insert \serialNumbers into a \spentSerials 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.} +tx's and the ``good'' ones lead to the addition of \serialNumbers to the +\spentSerials.} -Transactions that attempt to insert a \serialNumber into this map that already +Transactions that attempt to insert a \serialNumber into this set 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.} +talk about ``attempts'' of transactions, and insertions of \serialNumbers into the +\spentSerials.} \subsection{The Blockchain} @@ -670,13 +723,13 @@ \subsection{The Blockchain} 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 +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 +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. +\pourDescription. } These conditions act as constraints on the blocks that a \fullnode will @@ -693,100 +746,139 @@ \subsection{The Blockchain} remove value from this pool. The remaining value in the pool is available to miners as a fee. -\section{Pour Transfers and Descriptions} \label{pourdesc} +\section{\PourTransfers and Descriptions} \label{pourdesc} -A \PourDescription is data included in a \block that describes a \PourTransfer, +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 +\Zcash-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{\allOld}$ and transparent input +A \pourTransfer spends $\NOld$ \coins $\cOld{\allOld}$ and transparent input $\vpubOld$, and creates $\NNew$ \coins $\cNew{\allNew}$ and transparent output -$\vpubNew$. \Zcash transactions have an additional field $\vpour$, which is -a \sequenceOfPourDescriptions. +$\vpubNew$. -Each \PourDescription consists of: - -\begin{list}{}{} \changed{ -\item $\vpubOldField$ which is a value $\vpubOld$ that the \PourTransfer removes -from the value pool. +\Zcash transactions have the following additional fields: + +\begin{center} +\begin{tabularx}{0.9\textwidth}{|c|l|l|X|} +\hline +Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ +\hhline{|=|=|=|=|} + +\Varies & $\npour$ & \type{compactSize uint} & The number of \pourDescriptions (i.e. +items in $\vpour$). \\ \hline + +$880 \times \npour$ & $\vpour$ & \type{XferDescription[$\npour$]} & The \sequenceOfPourDescriptions in +this \transaction. \\ \hline + +33 & $\pourPubKey$ & \type{char[33]} & An encoding of a ECDSA public verification key, +using the secp256k1 curve and parameters defined in \cite{sec2-ecdsa} and +\cite{secp256k1}. \\ \hline + +64 & $\pourSig$ & \type{char[64]} & A signature on part of the \transaction encoding, +to be verified using $\pourPubKey$. \\ \hline +\end{tabularx} +\end{center} + +The encoding of $\pourPubKey$ and the data to be signed are specified in +more detail in \crossref{nonmalleability}. } -\item $\vpubNewField$ which is a value $\vpubNew$ that the \PourTransfer inserts -into the value pool. +Each \type{XferDescription} consists of: -\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.} +\begin{center} +\begin{tabularx}{0.9\textwidth}{|c|l|l|X|} +\hline +Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ +\hhline{|=|=|=|=|} -\item $\pourPubKey$ which is an ECDSA public verification key using the secp256k1 -curve and parameters defined in \cite{sec2-ecdsa} and \cite{secp256k1}. +\setchanged 8 &\setchanged $\vpubOldField$ &\setchanged \type{int64\_t} &\mbox{}\setchanged +A value $\vpubOld$ that the \PourTransfer removes from the value pool. \\ \hline -\item $\pourSig$ which is a signature on the \transaction as specified in -\crossref{nonmalleability}, to be verified using $\pourPubKey$. +8 & $\vpubNewField$ & \type{int64\_t} & A value $\vpubNew$ that the \PourTransfer inserts +into the value pool. \\ \hline -\item $\serials$ which is an $\NOld$ size sequence of serials $\snOld{\allOld}$. +32 & $\anchorField$ & \type{char[32]} & A merkle root $\rt$ of the \coinCommitmentTree at +some block height in the past, or the merkle root produced by a previous \pourTransfer in +this transaction. \sean{We need to be more specific here.} \\ \hline -\item $\commitments$ which is a $\NNew$ size sequence of \coinCommitments -$\cmNew{\allNew}$. +64 & $\serials$ & \type{char[32][$\NOld$]} & A sequence of \serialNumbers of the input +\coins $\snOld{\allOld}$. \\ \hline -\item $\ephemeralKey$ which is a Curve25519 public key $\EphemeralPublic$. +64 & $\commitments$ & \type{char[32][$\NNew$]}. & A sequence of \coinCommitments for the +output \coins $\cmNew{\allNew}$. \\ \hline -\item $\encCiphertexts$ which is a $\NNew$ size sequence of ciphertext -components, $\TransmitCiphertext{\allNew}$. +32 & $\ephemeralKey$ & \type{char[32]} & A Curve25519 public key $\EphemeralPublic$. \\ \hline -\changed{ -(The preceding two fields form the \coinsCiphertext.) +288 & $\encCiphertexts$ & \type{char[144][$\NNew$]} & A sequence of ciphertext +components for the encrypted output \coins, $\TransmitCiphertext{\allNew}$. \\ \hline -\item $\randomSeed$ which is a 256-bit seed that must be chosen independently -at random for each \PourDescription. -} +\setchanged 32 &\setchanged $\randomSeed$ &\setchanged \type{char[32]} &\mbox{}\setchanged +A 256-bit seed that must be chosen independently at random for each \pourDescription. \\ \hline -\item $\vmacs$ which is a $\NOld$ size sequence of message authentication tags +64 & $\vmacs$ & \type{char[32][$\NOld$]} & A sequence of message authentication tags $\h{\allOld}$ that bind $\hSig$ to each $\AuthPrivate$ of the -$\PourDescription$. +$\pourDescription$. \\ \hline -\item $\zkproof$ which is an encoding, as determined by the libsnark library -\cite{libsnark}, of the zero-knowledge proof $\PourProof$. +288 & $\zkproof$ & \type{char[288]} & An encoding, as determined by the libsnark library +\cite{libsnark}, of the zero-knowledge proof $\PourProof$. \\ \hline + +\end{tabularx} +\end{center} -\end{list} +The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \coinsCiphertext. -\todo{Describe case where there are fewer than $\NOld$ real input coins.} +\todo{Describe case where there are fewer than $\NOld$ real input \coins.} \subsection{Computation of \hSigText} \label{hsig} \newsavebox{\hsigbox} \begin{lrbox}{\hsigbox} \setchanged -\begin{bytefield}[bitwidth=0.034em]{1064} - \bitbox{160}{8 bit $\hSigInputVersionByte$} & - \bitbox{256}{\hfill 256 bit $\snOld{\mathrm{1}}$\hfill...\;} & - \bitbox{256}{256 bit $\snOld{\NOld}$} & - \bitbox{256}{$\randomSeed$} - \bitbox{256}{$\pourPubKey$} +\begin{bytefield}[bitwidth=0.033em]{1064} + \bitbox{24}{0} & + \bitbox{24}{1} & + \bitbox{24}{1} & + \bitbox{24}{1} & + \bitbox{112}{4 bit $\hSigInputLeadNibble$} & + \bitbox{256}{\hfill 256 bit $\snOld{\mathrm{1}}$\hfill...\;} & + \bitbox{256}{256 bit $\snOld{\NOld}$} & + \bitbox{256}{$\randomSeed$} + \bitbox{256}{$\pourPubKey$} \end{bytefield} \end{lrbox} \changed{ -Given a \PourDescription, we define: +Given a \pourDescription, we define: -\hskip 1.5em $\hSig := \FullHashbox{\hsigbox}$ +\hskip 1em $\hSig := \FullHashbox{\hsigbox}$ } \subsection{Merkle root validity} -A \PourDescription is valid if $\rt$ is a \coinCommitmentTree root found in +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$. +of a previous \pourDescription in the transaction to the \coinCommitmentTree +identified by that previous \pourDescription's $\anchor$. \subsection{Non-malleability} \label{nonmalleability} -A \PourDescription is correctly signed if: +\changed{ +Let $\dataToBeSigned$ be the raw-format \cite{rawformat} encoding of the +\transaction excluding the $\pourPubKey$ and $\pourSig$ fields. + +In order to ensure that a \pourDescription is cryptographically bound to the +transparent inputs and outputs corresponding to $\vpubNew$ and $\vpubOld$, and +to the other \pourDescriptions in the same \transaction, an ephemeral ECDSA +key pair is generated for each \transaction, and the $\dataToBeSigned$ is +signed with the private signing key of this key pair. The corresponding public +verification key is included in the \transaction encoding as $\pourPubKey$. + +A \transaction is correctly signed if: \begin{itemize} \item $\pourSig$ can be verified as an encoding of a signature on -\todo{what precisely?}, using the ECDSA public key encoded as $\pourPubKey$; and +$\dataToBeSigned$, using the ECDSA public key encoded as $\pourPubKey$; and \item $\pourSig$ has an $\ECDSAs$ value in the lower half of the possible range (i.e. $\ECDSAs$ must be in the range from 0x1 to \linebreak 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0, @@ -794,9 +886,11 @@ \subsection{Non-malleability} \label{nonmalleability} \end{itemize} If $\ECDSAs$ is not in the given range, the signature is treated as invalid. +} \newsavebox{\sigbox} \begin{lrbox}{\sigbox} +\setchanged \begin{bytefield}[bitwidth=0.075em]{512} \bitbox{256}{256 bit $\ECDSAr$} \bitbox{256}{256 bit $\ECDSAs$} @@ -805,6 +899,7 @@ \subsection{Non-malleability} \label{nonmalleability} \newsavebox{\pubkeybox} \begin{lrbox}{\pubkeybox} +\setchanged \begin{bytefield}[bitwidth=0.075em]{264} \bitbox{64}{$\zeros{6}$} \bitbox{18}{1} @@ -813,32 +908,37 @@ \subsection{Non-malleability} \label{nonmalleability} \end{bytefield} \end{lrbox} +\changed{ The encoding of a signature is: - +} \begin{itemize} \item[] $\Justthebox{\sigbox}{-1.3ex}$ \end{itemize} +\changed{ where $\ECDSAr$ and $\ECDSAs$ are as defined in \cite{sec2-ecdsa}. The encoding of a public key is as defined in section E.2.3.2 of \cite{std1363} for a compressed elliptic curve point with $x$-coordinate $x_P$ and compressed $y$-coordinate $\tilde{y}_P$: - +} \begin{itemize} \item[] $\Justthebox{\pubkeybox}{-1.3ex}$ \end{itemize} +\changed{ Note that only compressed public keys are valid. +} -The condition \crossref{nonmalleablepour} in the \zkSNARK statement ensures -that a holder of all of $\AuthPrivateOld{\allOld}$ has authorized the use of -the private key corresponding to $\pourPubKey$ to sign this transaction. +The condition enforced by the \PourCircuit specified in \crossref{nonmalleablepour} +ensures that a holder of all of $\AuthPrivateOld{\allOld}$ for each +\pourDescription has authorized the use of the private key corresponding +to $\pourPubKey$ to sign this transaction. \subsection{Balance} -A \PourTransfer can be seen, from the perspective of the transaction, as +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 @@ -847,21 +947,22 @@ \subsection{Balance} \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. +a distinction between Mint and Pour operations. The addition of $\vpubOld$ to a +\pourDescription subsumes the functionality of both Mint and Pour. Also, +\pourDescriptions are indistinguishable regardless of the number of real input +\coins. } -\subsection{Commitments and Serial Numbers} +\subsection{\CoinCommitments and \SerialNumbers} -A \transaction that contains one or more \PourDescriptions, when entered into the +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. +\spentSerials of the \blockchainview \emph{and} \mempool. A \transaction is not +valid if it attempts to add a \serialNumber to the \spentSerials that already +exists in the set. -\subsection{Pour Circuit and Proofs} +\subsection{\PourCircuit and Proofs} In \Zcash, $\NOld$ and $\NNew$ are both $2$. @@ -876,7 +977,7 @@ \subsection{Pour Circuit and Proofs} \begin{itemize} \item[] $(\treepath{\allOld}, \cOld{\allOld}, \AuthPrivateOld{\allOld}, -\cpNew{\allNew}\changed{, \CoinAddressPreRand})$ +\cNew{\allNew}\changed{, \CoinAddressPreRand})$ \end{itemize} where: @@ -894,7 +995,7 @@ \subsection{Pour Circuit and Proofs} for each $i \in \setofOld$ \changed{$\mid$ $\vOld{i} \neq 0$}: $\treepath{i}$ must be a valid path of depth $\MerkleDepth$ from \linebreak -$\CoinCommitment(\cOld{i})$ to \coinCommitmentTree root $\rt$. +$\Commitment(\cOld{i})$ to \coinCommitmentTree root $\rt$. \subparagraph{Balance} @@ -924,7 +1025,7 @@ \subsection{Pour Circuit and Proofs} \subparagraph{Commitment integrity} -for each $i \in \setofNew$: $\cmNew{i}$ = $\CoinCommitment(\cNew{i})$. +for each $i \in \setofNew$: $\cmNew{i}$ = $\Commitment(\cNew{i})$. \section{In-band secret distribution} \label{inband} @@ -942,8 +1043,12 @@ \section{In-band secret distribution} \label{inband} \newsavebox{\kdfbox} \begin{lrbox}{\kdfbox} \setchanged -\begin{bytefield}[bitwidth=0.035em]{840} - \bitbox{160}{8 bit $\KDFLeadByte$} & +\begin{bytefield}[bitwidth=0.038em]{840} + \bitbox{24}{0} & + \bitbox{24}{1} & + \bitbox{24}{1} & + \bitbox{24}{1} & + \bitbox{112}{4 bit $\KDFLeadNibble$} & \bitbox{256}{256 bit $\DHSecret{i}$} & \bitbox{256}{256 bit $\EphemeralPublic$} & \bitbox{256}{256 bit $\TransmitPublicNew{i}$} & @@ -954,22 +1059,20 @@ \section{In-band secret distribution} \label{inband} \subsection{Encryption} \changed{ -Let $\SymEncrypt{\Key}(\Plaintext)$ be authenticated encryption using a variation -of $\SymSpecific$ \cite{rfc7539} encryption of plaintext $\Plaintext$, with empty -``associated data", all-zero nonce $\zeros{96}$, and 256-bit key $\Key$. The variation -is that the $\SymCipher$ keystream is used to encrypt the plaintext starting immediately -after the 32 bytes of the $\SymAuth$ key, without discarding 32 bytes as in \cite{rfc7539}. +Let $\SymEncrypt{\Key}(\Plaintext)$ be authenticated encryption using +$\SymSpecific$ \cite{rfc7539} encryption of plaintext $\Plaintext$, with empty +``associated data", all-zero nonce $\zeros{96}$, and 256-bit key $\Key$. -Similarly, let $\SymDecrypt{\Key}(\Ciphertext)$ be decryption using the same -$\SymSpecific$ variation of ciphertext $\Ciphertext$, with empty ``associated data", -all-zero nonce $\zeros{96}$, and 256-bit key $\Key$. The result is either the plaintext -byte sequence, or $\bot$ indicating failure to decrypt. +Similarly, let $\SymDecrypt{\Key}(\Ciphertext)$ be $\SymSpecific$ +decryption of ciphertext $\Ciphertext$, with empty ``associated data", +all-zero nonce $\zeros{96}$, and 256-bit key $\Key$. The result is either +the plaintext byte sequence, or $\bot$ indicating failure to decrypt. Define $\KDF(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i) :=$ {\parskip=0.3ex -\hskip 5em $\FullHashbox{\kdfbox}$. -\vskip 1ex} +\hskip 1.5em $\FullHashbox{\kdfbox}$. +\vskip 1.2ex} } Let $\TransmitPublicNew{\allNew}$ be the \changed{Curve25519} public keys @@ -999,28 +1102,31 @@ \subsection{Encryption} \subsection{Decryption by a Recipient} -Let $(\TransmitPublic, \TransmitPrivate)$ be the recipient's \changed{Curve25519} -(public, private) key pair, and let $\cmNew{\allNew}$ be the coin -commitments of each output coin. Then for each $i \in \setofNew$, the recipient -will attempt to decrypt that ciphertext component as follows: +Let $\PaymentAddress = (\AuthPublic, \TransmitPublic)$ be the recipient's +\paymentAddress, and let $\TransmitPrivate$ be the recipient's \changed{Curve25519} +private key. Let $\cmNew{\allNew}$ be the \coinCommitments of each output coin. +Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext +component as follows: \changed{ \begin{itemize} \item Let $\DHSecret{i} := \CurveMultiply(\TransmitPrivate, \EphemeralPublic)$. \item Let $\TransmitKey{i} := \KDF(\DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}, i)$. - \item Return $\DecryptCoin(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i}).$ + \item Return $\DecryptNote(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i}, +\AuthPublic).$ \end{itemize} -$\DecryptCoin(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i})$ is defined as follows: +$\DecryptNote(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i}, \AuthPublic)$ +is defined as follows: \begin{itemize} \item Let $\TransmitPlaintext{i} := \SymDecrypt{\TransmitKey{i}}(\TransmitCiphertext{i})$. \item If $\TransmitPlaintext{i} = \bot$, return $\bot$. - \item Extract $\CoinPlaintext{i} = (\AuthPublicNew{i}, \ValueNew{i}, + \item Extract $\CoinPlaintext{i} = (\ValueNew{i}, \CoinAddressRandNew{i}, \CoinCommitRandNew{i}, \Memo_i)$ from $\TransmitPlaintext{i}$. - \item If $\CoinCommitment((\AuthPublicNew{i}, \ValueNew{i}, \CoinAddressRandNew{i}, + \item If $\Commitment((\AuthPublic, \ValueNew{i}, \CoinAddressRandNew{i}, \CoinCommitRandNew{i})) \neq \cmNew{i}$, return $\bot$, else return $\CoinPlaintext{i}$. \end{itemize} } @@ -1033,9 +1139,9 @@ \subsection{Decryption by a Recipient} $\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, +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 +the transaction in which a \coin was output to no longer be on the consensus blockchain. @@ -1050,7 +1156,7 @@ \subsection{Commentary} \begin{itemize} \changed{ \item The same ephemeral key is used for all encryptions to the recipient keys - in a given \PourDescription. + in a given \pourDescription. \item In addition to the Diffie-Hellman secret, the KDF takes as input the public keys of both parties, and the index $i$. \item The nonce parameter to $\SymSpecific$ is not used. @@ -1080,7 +1186,7 @@ \subsection{Transparent Private Keys} These are encoded in the same way as in \Bitcoin \cite{Base58Check}. -\subsection{Private Payment Addresses} +\subsection{Protected Payment Addresses} A \paymentAddress consists of $\AuthPublic$ and $\TransmitPublic$. $\AuthPublic$ is a SHA-256 compression function output. @@ -1137,8 +1243,14 @@ \subsection{Spending Keys} \item \changed{252} bits specifying $\AuthPrivate$. \end{itemize} -Note that, consistent with big-endian encoding, the zero padding occupies -the high-order 4 bits of the second byte. +Consistent with little-endian encoding, the zero padding occupies the +low-order 4 bits of the second byte. + +\subparagraph{Note:} If an implementation represents $\AuthPrivate$ +internally as a sequence of 32 bytes with the 4 bits of zero padding +intact, it will be in the correct form for use as an input to +$\PRFaddr{}$, $\PRFsn{}$, and $\PRFpk{}$ without need for bit-shifting. +Future key representations may make use of these padding bits. \daira{check that this lead byte is distinct from other Bitcoin stuff, and produces a suitable Base58Check leading character.} @@ -1160,47 +1272,50 @@ \subsection{Transaction Structure} \label{trstructure} \Zcash-specific operations. This allows for the possibility of chaining transfers of protected -value in a single transaction, e.g. to spend a protected coin that -has just been created. (In \Zcash, we refer to value stored in UTXOs -as ``transparent'', and value stored in Pour output coins as ``protected''.) +value in a single \Zcash \transaction, e.g. to spend a protected \coin +that has just been created. (In \Zcash, we refer to value stored in +UTXOs as ``transparent'', and value stored in \pourTransfer output +\coins as ``protected''.) This was not possible in the \Zerocash design without using multiple transactions. It also allows transparent and protected transfers to happen atomically --- possibly under the control of nontrivial script conditions, at some cost in distinguishability. +\todo{Describe changes to signing.} + \subsection{Unification of Mints and Pours} In the original \Zerocash protocol, there were two kinds of transaction -relating to protected coins: +relating to protected \coins: \begin{itemize} \item a ``Mint'' transaction takes value from transparent UTXOs as -input and produces a new protected coin as output. +input and produces a new protected \coin as output. \item a ``Pour'' transaction takes up to $\NOld$ protected -coins as input, and produces up to $\NNew$ protected coins and a +\coins as input, and produces up to $\NNew$ protected \coins and a transparent UTXO as output. \end{itemize} Only ``Pour'' transactions included a \zkSNARK proof. -In \Zcash, the sequence of operations added to a transaction -(described in \crossref{trstructure}) consists only of Pours. -A Pour is generalized to take a transparent UTXO as input, allowing -Pours to subsume the functionality of Mints. An advantage of this -is that a transaction that takes input from an UTXO can produce -up to $\NNew$ output coins, improving the indistinguishability -properties of the protocol. A related change conceals the input -arity of the Pour: an unused (zero-value) input is -indistinguishable from an input that takes value from a coin. +In \Zcash, the sequence of operations added to a \transaction +(described in \crossref{trstructure}) consists only of \pourTransfers. +A \pourTransfer is a Pour operation generalized to take a transparent +UTXO as input, allowing \pourTransfers to subsume the functionality of +Mints. An advantage of this is that a \Zcash \transaction that takes +input from an UTXO can produce up to $\NNew$ output \coins, improving +the indistinguishability properties of the protocol. A related change +conceals the input arity of the \pourTransfer: an unused (zero-value) +input is indistinguishable from an input that takes value from a \coin. This unification also simplifies the fix to the Faerie Gold attack described below, since no special case is needed for Mints. -\subsection{Memo fields} +\subsection{\Memos} -\Zerocash adds a memo field sent from the creator of a Pour to -the recipient of each output coin. This feature is described in +\Zcash adds a \memo sent from the creator of a \pourDescription to +the recipient of each output \coin. This feature is described in more detail in \crossref{coinpt}. @@ -1216,8 +1331,8 @@ \subsection{Faerie Gold attack and fix} multiple \coins with different $\Value$ and $\CoinCommitRand$ (hence different \coinCommitments) but the same $\CoinAddressRand$. -An adversary can use this to mislead a coin recipient, by sending -two coins both of which are verified as valid by $\Receive$ (as +An adversary can use this to mislead a \coin recipient, by sending +two \coins both of which are verified as valid by $\Receive$ (as defined in Figure 2 of \cite{ZerocashOakland}), but only one of which can be spent. @@ -1255,7 +1370,7 @@ \subsection{Faerie Gold attack and fix} It would be possible to address the attack by requiring that a recipient remember all of the $\CoinAddressRand$ values for all -coins they have ever received, and reject duplicates (as proposed +\coins they have ever received, and reject duplicates (as proposed in \cite{GGM2016}). However, this requirement would interfere with the intended \Zcash feature that a holder of a \spendingKey can recover access to (and be sure that they are able to spend) all @@ -1264,27 +1379,27 @@ \subsection{Faerie Gold attack and fix} Instead, \Zcash enforces that an adversary must choose distinct values for each $\CoinAddressRand$, by making use of the fact that all of the -\serialNumbers in \PourDescriptions that appear in a valid \blockchainview +\serialNumbers in \pourDescriptions that appear in a valid \blockchainview must be distinct. The \serialNumbers are used as input to $\FullHash$ to derive a public value $\hSig$ which uniquely identifies the transaction, as described in \crossref{hsig}. ($\hSig$ was already used in \Zerocash in a way that requires it to be unique in order to maintain -indistinguishability of \PourDescriptions; adding the \serialNumbers +indistinguishability of \pourDescriptions; adding the \serialNumbers to the input of the hash used to calculate it has the effect of making this uniqueness property robust even if the \transaction creator is an adversary.) -The $\CoinAddressRand$ value for each output coin is then derived from +The $\CoinAddressRand$ value for each output \coin is then derived from a random private seed $\CoinAddressPreRand$ and $\hSig$ using $\PRFrho{\CoinAddressPreRand}$. The correct construction of -$\CoinAddressRand$ for each output coin is enforced by the circuit +$\CoinAddressRand$ for each output \coin is enforced by the circuit (see \crossref{uniquerho}). -Now even if the creator of a \PourDescription does not choose +Now even if the creator of a \pourDescription does not choose $\CoinAddressPreRand$ randomly, uniqueness of \serialNumbers and collision resistance of both $\FullHash$ and $\PRFrho{}$ will ensure that the derived $\CoinAddressRand$ values are unique, at least for -any two \PourDescriptions that get into a valid \blockchainview. +any two \pourDescriptions that get into a valid \blockchainview. This is sufficient to prevent the Faerie Gold attack. @@ -1302,7 +1417,7 @@ \subsection{Internal hash collision attack and fix} $2^{64}$, to find distinct values of $\CoinAddressRand$ with colliding outputs of the truncated hash, and therefore the same \coinCommitment. This would have allowed such an attacker to break the balance property -by double-spending coins, potentially creating arbitrary amounts of +by double-spending \coins, potentially creating arbitrary amounts of currency for themself. \Zcash uses a simpler construction with a single $\FullHash$ evaluation @@ -1310,13 +1425,13 @@ \subsection{Internal hash collision attack and fix} was to allow Mint transactions to be publically verified without requiring a ZK proof (as described under step 3 in section 1.3 of \cite{ZerocashOakland}). Since \Zcash combines ``Mint'' and ``Pour'' -transactions into a generalized Pour which always uses a ZK proof, it -does not require the nesting. A side benefit is that this reduces the +transactions into a generalized \pourTransfer which always uses a ZK proof, +it does not require the nesting. A side benefit is that this reduces the number of $\SHA$ evaluations needed to compute each \coinCommitment from three to two, saving a total of four $\SHA$ evaluations in the $\PourCircuit$. -Note that \Zcash coin commitments are not statistically hiding, and +Note that \Zcash \coinCommitments are not statistically hiding, and so \Zcash does not support the ``everlasting anonymity'' property described in section 8.1 of the \Zerocash paper \cite{ZerocashOakland}, even when used as described in that section. While it is possible to @@ -1338,12 +1453,12 @@ \subsection{In-band secret distribution} \subsection{Miscellaneous} \begin{itemize} - \item The paper defines a coin as a tuple $(\AuthPublic, \Value, + \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 did not use $\CoinCommitS$ (and neither does the -new instantiation of $\CoinCommitment$). $\cm$ can be computed from the other +new instantiation of $\Commitment$). $\cm$ can be computed from the other fields. \end{itemize} diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 8e80da337..b492321c9 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -71,6 +71,13 @@ @misc{secp256k1 note={Accessed: \mbox{2016-03-14}} } +@misc{rawformat, + key={BitcoinTransactionFormat}, + title={Raw {T}ransaction {F}ormat -- {B}itcoin {D}eveloper {R}eference}, + howpublished={\url{https://bitcoin.org/en/developer-reference#raw-transaction-format}}, + note={Accessed: \mbox{2016-03-15}} +} + @book{std1363, author={IEEE Computer Society}, publisher={IEEE},