zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

WIP 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2016-01-26 23:15:17 +00:00
parent cfa051d510
commit 75eb8a4099
4 changed files with 342 additions and 142 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
protocol/Makefile
View File

@ -1,5 +1,6 @@
protocol.pdf: protocol.tex incremental_merkle.pdf
pdflatex protocol.tex
# If pdflatex fails, touch an input so that 'make' won't think it is up-to-date next time.
pdflatex protocol.tex || touch incremental_merkle.pdf
.PHONY: clean
clean:

BIN
protocol/protocol.pdf
View File

Binary file not shown.

473
protocol/protocol.tex
View File

@ -3,6 +3,9 @@
\RequirePackage{bytefield}
\RequirePackage{graphicx}
\RequirePackage{newtxmath}
\RequirePackage{mathtools}
\RequirePackage{natbib}
\RequirePackage{xspace}
\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
@ -13,93 +16,134 @@
% terminology
\newcommand{\Zcash}{\textbf{Zcash} }
\newcommand{\Zerocash}{\textbf{Zerocash} }
%
\newcommand{\term}[1]{\textsl{#1}\xspace}
\newcommand{\termbf}[1]{\textbf{#1}\xspace}
\newcommand{\Zcash}{\termbf{Zcash}}
\newcommand{\Zerocash}{\termbf{Zerocash}}
\newcommand{\ZEC}{\termbf{ZEC}}
\newcommand{\zatoshi}{\term{zatoshi}}
\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{\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{\publicAddress}{\term{confidential address}}
\newcommand{\privateAddress}{\term{confidential address secret}}
\newcommand{\transmittedPlaintext}{\term{transmitted coin plaintext}}
\newcommand{\transmittedCiphertext}{\term{transmitted coin ciphertext}}
\newcommand{\transmitPublicAlgorithm}{\term{key-private encryption}}
\newcommand{\transmitPrivateAlgorithm}{\term{key-private decryption}}
\newcommand{\spendAuthority}{\term{spend authority}}
\newcommand{\incrementalMerkleTree}{\term{incremental merkle tree}}
\newcommand{\spentSerialsMap}{\term{spent serial numbers map}}
% key pairs:
\newcommand{\PublicAddress}{\mathsf{addr_{pk}}}
\newcommand{\PrivateAddress}{\mathsf{addr_{sk}}}
\newcommand{\PublicAddressName}{\emph{protected address}}
\newcommand{\PrivateAddressName}{\emph{protected address secret}}
\newcommand{\PublicAddressLeadByte}{\mathbf{0x92}}
\newcommand{\PrivateAddressLeadByte}{\mathbf{0x93}}
\newcommand{\SpendAuthorityPublic}{\mathsf{a_{pk}}}
\newcommand{\SpendAuthorityPrivate}{\mathsf{a_{sk}}}
\newcommand{\SpendAuthorityName}{\emph{spend authority}}
\newcommand{\SpendAuthorityPublicOld}[1]{\mathsf{a^{old}_{pk,\mathnormal{#1}}}}
\newcommand{\SpendAuthorityPrivateOld}[1]{\mathsf{a^{old}_{sk,\mathnormal{#1}}}}
\newcommand{\SpendAuthorityPublicNew}[1]{\mathsf{a^{new}_{pk,\mathnormal{#1}}}}
\newcommand{\SpendAuthorityPrivateNew}[1]{\mathsf{a^{new}_{sk,\mathnormal{#1}}}}
\newcommand{\TransmitPublic}{\mathsf{pk_{enc}}}
\newcommand{\TransmitPrivate}{\mathsf{sk_{enc}}}
\newcommand{\TransmitPublicName}{\emph{key-private encryption}}
\newcommand{\TransmitPrivateName}{\emph{key-private decryption}}
\newcommand{\Value}{\mathsf{v}}
%
% buckets
\newcommand{\Bucket}{\mathsf{b}}
\newcommand{\BucketRand}{\mathsf{r}}
\newcommand{\BucketAddressRand}{\mathsf{\uprho}}
\newcommand{\BucketPlaintextName}{\emph{transmitted bucket plaintext}}
\newcommand{\BucketCiphertextName}{\emph{transmitted bucket ciphertext}}
\newcommand{\BucketCommitmentName}{\emph{bucket commitment}}
\newcommand{\BucketPlaintextVersionByte}{\mathbf{0x00}}
\newcommand{\CRH}{\mathbf{CRH}}
\newcommand{\PRF}[2]{\mathbf{PRF_{#1}^{#2}}}
% Coins
\newcommand{\Coin}{\mathbf{c}}
\newcommand{\CoinCommitRand}{\mathsf{r}}
\newcommand{\CoinCommitRandOld}[1]{\mathsf{r^{old}_\mathnormal{#1}}}
\newcommand{\CoinCommitRandNew}[1]{\mathsf{r^{new}_\mathnormal{#1}}}
\newcommand{\CoinAddressRand}{\mathsf{\uprho}}
\newcommand{\CoinAddressRandOld}[1]{\mathsf{\uprho^{old}_\mathnormal{#1}}}
\newcommand{\CoinAddressRandNew}[1]{\mathsf{\uprho^{new}_\mathnormal{#1}}}
\newcommand{\TransmitPlaintextVersionByte}{\mathbf{0x00}}
\newcommand{\CRH}{\mathsf{CRH}}
\newcommand{\PRF}[2]{\mathsf{{PRF}^{#2}_\mathnormal{#1}}}
\newcommand{\PRFaddr}[1]{\PRF{#1}{addr}}
\newcommand{\PRFsn}[1]{\PRF{#1}{sn}}
\newcommand{\PRFpk}[2]{\PRF{#1}{pk_{#2}}}
\newcommand{\PRFpk}[2]{\PRF{#1}{pk,{\mathnormal{#2}}}}
\newcommand{\SHA}{\mathtt{SHA256Compress}}
\newcommand{\SHAName}{\emph{SHA-256 compression}}
\newcommand{\SHAOrig}{\emph{SHA-256}}
\newcommand{\bm}{\mathbf{\mathtt{bm}}}
\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}}
% merkle tree
\newcommand{\MerkleDepth}{\mathsf{d}}
\newcommand{\PourTx}{\mathtt{PourTx}}
\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{\vpubOld}{\mathtt{vpub\_old}}
\newcommand{\vpubNew}{\mathtt{vpub\_new}}
\newcommand{\anchor}{\mathtt{anchor}}
\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{\bucketCiphertexts}{\mathtt{bucketCiphertexts}}
\newcommand{\TransmitCiphertexts}{\mathtt{ciphertexts}}
\newcommand{\rt}{\mathsf{rt}}
% pour
\newcommand{\hSig}{\mathsf{h_{Sig}}}
\newcommand{\Nold}{N_{Old}}
\newcommand{\Nnew}{N_{New}}
\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{vpub_{old}}}
\newcommand{\vpubnew}{\mathsf{vpub_{new}}}
\newcommand{\bOld}[1]{\mathsf{b_{#1}^{old}}}
\newcommand{\bNew}[1]{\mathsf{b_{#1}^{new}}}
\newcommand{\vOld}[1]{\mathsf{v_{#1}^{old}}}
\newcommand{\vNew}[1]{\mathsf{v_{#1}^{new}}}
\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{\path}[1]{\mathsf{path_{#1}}}
\newcommand{\path}[1]{\mathsf{path}_{#1}}
\newcommand{\COMM}[1]{\mathsf{COMM}_{#1}}
\newcommand{\COMMSeed}{\mathsf{COMM} seed}
\newcommand{\CoinCommitment}[1]{\mathtt{CoinCommitment}(#1)}
% TODO: COMM is used in the zerocash paper. We should use it
% where applicable. (The paper treats bm as a COMM, when it really
% isn't anymore after changes made by the academics that weren't
% included in the paper).
%\newcommand{\COMM}[1]{\mathbf{COMM_{#1}}}
%eli macros
\usepackage{color}
\RequirePackage[usenames,dvipsnames]{xcolor}
% https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips
\newcommand{\eli}[1]{{\color{magenta}\sf{Eli: #1}}}
\newcommand{\sean}[1]{{\color{blue}\sf{Sean: #1}}}
\newcommand{\taylor}[1]{{\color{red}\sf{Taylor: #1}}}
\newcommand{\daira}[1]{{\color{green}\sf{Daira: #1}}}
\newcommand{\BucketCommitment}[1]{\mathtt{BucketCommitment(#1)}}
\newcommand{\daira}[1]{{\color{RedOrange}\sf{Daira: #1}}}
\newcommand{\nathan}[1]{{\color{ForestGreen}\sf{Nathan: #1}}}
\begin{document}
@ -110,7 +154,12 @@
\maketitle
\section{Introduction}
\Zcash is an implementation of the \emph{decentralized anonymous payment} (DAP) scheme \Zerocash with minor adjustments to terminology, functionality and performance. It bridges the existing value transfer scheme used by Bitcoin with an anonymous payment scheme protected by zero-knowledge succinct non-interactive arguments of knowledge (\textbf{zk-SNARK}s). \sean{I want to make sure we add citations here for the original paper}
\Zcash is an implementation of the \term{decentralized anonymous payment} (DAP)
scheme \Zerocash \cite{ZerocashOakland} with minor 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
(\textbf{zk-SNARK}s).
\section{Concepts}
@ -128,11 +177,18 @@ crypto libraries the \Zcash implementation uses.
\subparagraph{}
$\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.
$\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.
\subparagraph{}
$\PRF{x}{}$ is a pseudo-random function seeded by $x$. Three \textit{independent} $\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFsn{x}$, and $\PRFpk{x}{i}$. It is required that $\PRFsn{x}$ be collision-resistant. In \Zcash, the $\SHAName$ function is used to seed all three of these functions. The bits $\mathtt{00}$, $\mathtt{01}$ and $\mathtt{10}$ are included (respectively) within the blocks that are hashed, ensuring that the functions are independent.
$\PRF{x}{}$ is a pseudo-random function seeded by $x$. Three \emph{independent}
$\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFsn{x}$, and
$\PRFpk{x}{i}$. It is required that $\PRFsn{x}$ be collision-resistant. In \Zcash,
the $\SHAName$ function is used to construct all three of these functions. The bits
$\mathtt{00}$, $\mathtt{01}$ and $\mathtt{10}$ are included (respectively) within
the blocks that are hashed, ensuring that the functions are independent.
\begin{equation*}
\SpendAuthorityPublic = \PRFaddr{\SpendAuthorityPrivate}(0) = \CRH\left(
@ -148,13 +204,13 @@ $\PRF{x}{}$ is a pseudo-random function seeded by $x$. Three \textit{independent
\end{equation*}
\begin{equation*}
\sn = \PRFsn{\SpendAuthorityPrivate}(\BucketAddressRand) = \CRH\left(
\sn = \PRFsn{\SpendAuthorityPrivate}(\CoinAddressRand) = \CRH\left(
\;
\begin{bytefield}[bitwidth=0.07em]{512}
\bitbox{242}{256 bit $\SpendAuthorityPrivate$} &
\bitbox{14}{0} &
\bitbox{14}{1} &
\bitbox{242}{254 bit truncated $\BucketAddressRand$} &
\bitbox{242}{254 bit truncated $\CoinAddressRand$} &
\end{bytefield}
\enspace
\right)
@ -162,7 +218,7 @@ $\PRF{x}{}$ is a pseudo-random function seeded by $x$. Three \textit{independent
\begin{equation*}
h_i = \PRFpk{\SpendAuthorityPrivate}{i}(\hSig) = \CRH\left(
\h{i} = \PRFpk{\SpendAuthorityPrivate}{i}(\hSig) = \CRH\left(
\;
\begin{bytefield}[bitwidth=0.07em]{512}
\bitbox{242}{256 bit $\SpendAuthorityPrivate$} &
@ -179,25 +235,51 @@ h_i = \PRFpk{\SpendAuthorityPrivate}{i}(\hSig) = \CRH\left(
\subparagraph{}
A key pair $(\PublicAddress, \PrivateAddress)$ is generated by users who wish to receive coins under this scheme. The public $\PublicAddress$ is called a $\PublicAddressName$ and is a tuple $(\SpendAuthorityPublic, \TransmitPublic)$ which are the public components of a $\SpendAuthorityName$ key pair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\TransmitPublicName$ key pair $(\TransmitPublic, \TransmitPrivate)$. The private $\PrivateAddress$ is called a $\PrivateAddressName$ and is a tuple $(\SpendAuthorityPrivate, \TransmitPrivate)$ which are the respective \textit{private} components of the aforementioned $\SpendAuthorityName$ and $\TransmitPublicName$ key pairs.
A key pair $(\PublicAddress, \PrivateAddress)$ is generated by users who wish to
receive coins under this scheme. The public $\PublicAddress$ is called a
$\publicAddress$ and is a tuple $(\SpendAuthorityPublic, \TransmitPublic)$
consisting of the public components of a $\spendAuthority$ key pair
$(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\transmitPublicAlgorithm$ key
pair $(\TransmitPublic, \TransmitPrivate)$. The private $\PrivateAddress$ is called
a $\privateAddress$ and is a tuple $(\SpendAuthorityPrivate, \TransmitPrivate)$
consisting of the respective \emph{private} components of the aforementioned
$\spendAuthority$ and $\transmitPublicAlgorithm$ key pairs.
\subparagraph{}
Although users can accept payment from multiple parties with a single $\PublicAddress$ without either party being aware, it is still recommended to generate a new address for each expected transaction to maximize privacy in the event that multiple sending parties are compromised or collude.
Although users can accept payment from multiple parties with a single
$\PublicAddress$ without either party being aware, it is still recommended to
generate a new address for each expected transaction to maximize privacy in the
event that multiple sending parties are compromised or collude.
\subsection{Buckets}
\subsection{Coins}
\subparagraph{}
A bucket (denoted $\Bucket$) is a tuple $(\Value, \SpendAuthorityPublic, \BucketRand, \BucketAddressRand)$ which represents that a value $\Value$ is spendable by the recipient who holds the $\SpendAuthorityName$ key pair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ such that $\SpendAuthorityPublic=\PRFaddr{\SpendAuthorityPrivate}(0)$. $\BucketRand$ and $\BucketAddressRand$ are randomly generated tokens by the sender. Only a hash of these values is disclosed publicly, which allows these random tokens to blind the value and recipient \textit{except} to those who possess these tokens.
A \coin (denoted $\Coin$) is a tuple $(\SpendAuthorityPublic, \Value,
\CoinAddressRand, \CoinCommitRand)$ which represents that a value $\Value$ is
spendable by the recipient who holds the $\spendAuthority$ key pair
$(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ such that
$\SpendAuthorityPublic = \PRFaddr{\SpendAuthorityPrivate}(0)$. $\CoinAddressRand$ and
$\CoinCommitRand$ are tokens randomly generated by the sender. Only a hash of
these values is disclosed publicly, which allows these random tokens to blind the
value and recipient \emph{except} to those who possess these tokens.
\subparagraph{In-band secret distribution}
In order to send the secret $\Value$, $\BucketRand$ and $\BucketAddressRand$ to the recipient (necessary for the recipient to later spend) \textit{without} requiring an out-of-band communication channel, the $\TransmitPublicName$ public key $\TransmitPublic$ is used to encrypt these secrets to form an \BucketCiphertextName. The recipient's possession of the associated $(\PublicAddress, \PrivateAddress)$ (which contains both $\SpendAuthorityPublic$ and $\TransmitPrivate$) is used to reconstruct the original bucket.
In order to transmit the secret $\Value$, $\CoinAddressRand$ and $\CoinCommitRand$
to the recipient (necessary for the recipient to later spend) \emph{without}
requiring an out-of-band communication channel, the $\transmitPublicAlgorithm$
public key $\TransmitPublic$ is used to encrypt these secrets to form a
\transmittedCiphertext. The recipient's possession of the associated
$(\PublicAddress, \PrivateAddress)$ (which contains both $\SpendAuthorityPublic$ and
$\TransmitPrivate$) is used to reconstruct the original \coin.
\subparagraph{Bucket commitments}
\subparagraph{Coin Commitments}
The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRand$ and $\BucketAddressRand$ using the collision-resistant hash function $\CRH$ in a multi-layered process. The resulting hash $\bm = \BucketCommitment{\Bucket}$.
The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\CoinAddressRand$
and $\CoinCommitRand$ using the collision-resistant hash function $\CRH$ in a
multi-layered process. The resulting hash $\cm = \CoinCommitment{\Coin}$.
% TODO: this appears to be ineffective
\begin{flushright}
@ -207,7 +289,7 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
\;
\begin{bytefield}[bitwidth=0.07em]{512}
\bitbox{256}{256 bit $\SpendAuthorityPublic$} &
\bitbox{256}{256 bit $\BucketAddressRand$}
\bitbox{256}{256 bit $\CoinAddressRand$}
\end{bytefield}
\enspace
\right)
@ -217,7 +299,7 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
\InternalHashK := \CRH\left(
\;
\begin{bytefield}[bitwidth=0.07em]{512}
\bitbox{256}{256 bit $\BucketRand$} &
\bitbox{256}{256 bit $\CoinCommitRand$} &
\bitbox{256}{256 bit $\InternalHash$}
\end{bytefield}
\enspace
@ -225,7 +307,7 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
\end{equation*}
\begin{equation*}
\bm := \CRH\left(
\cm := \CRH\left(
\;
\begin{bytefield}[bitwidth=0.07em]{512}
\bitbox{64}{64 bit $\Value$} &
@ -240,9 +322,12 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
\subparagraph{Serials}
A serial number (denoted $\sn$) equals $\PRFsn{\SpendAuthorityPrivate}(\BucketAddressRand)$. Buckets are spent by proving knowledge of $\BucketAddressRand$ and $\SpendAuthorityPrivate$ in zero-knowledge while disclosing $\sn$, allowing $\sn$ to be used to prevent double-spending.
A \serialNumber (denoted $\sn$) equals
$\PRFsn{\SpendAuthorityPrivate}(\CoinAddressRand)$. A \coin is spent by proving
knowledge of $\CoinAddressRand$ and $\SpendAuthorityPrivate$ in zero knowledge while
disclosing $\sn$, allowing $\sn$ to be used to prevent double-spending.
\subsection{Bucket Commitment Tree}
\subsection{Coin Commitment Tree}
\begin{center}
\includegraphics[scale=.4]{incremental_merkle}
@ -250,54 +335,131 @@ A serial number (denoted $\sn$) equals $\PRFsn{\SpendAuthorityPrivate}(\BucketAd
\subparagraph{}
The bucket commitment tree is an \textit{incremental merkle tree} of depth $\MerkleDepth$ used to store bucket commitments that transactions produce. Just as the \textit{unspent transaction output set} (UTXO) used in Bitcoin proper, it is used to express the existence of value and the capability to spend it. However, unlike the UTXO, it is \textit{not} the job of this tree to protect against double-spending, as it is append-only.
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.
\subparagraph{}
Blocks in the blockchain are associated (by all nodes) with the root of this tree after all of its constituent transactions' bucket commitments have been entered into the tree associated with the previous block.
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}
\subparagraph{}
\eli{Would be good to formally define the structure of a transaction, similar to the way a bucket is defined (as a quadruple).}
Transactions insert \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.} serials into a \textit{spent serials map} which is maintained alongside the UTXO by all nodes. Transactions that attempt to insert a serial into this map that already exists within it are invalid as they are attempting to double-spend. \eli{After defining \emph{transaction}, one should define what a \emph{legal tx} is (this definition depends on a particular blockchain) and only then can one talk about ``attempts'' of transactions, and insertions of serial numbers into the spent serials map.}
\subsection{Bitcoin Transactions}
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 preceding \block.
\item The input \treestate of each subsequent \transaction in a \block is the
output \treestate of the 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 sequence of \PourDescriptions. TODO They also have
a transparent value flow that interacts with the Pour $\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 first \PourDescription in a \transaction must refer to another
\block's final \treestate.
The \anchor of each subsequent \PourDescription may refer either to another \block's
final \treestate, or to the output \treestate of the preceding Pour.
In a given \blockchainview, for a \block $Q$ to contain a \transaction with a
\PourDescription \anchor referring to the final \treestate of another \block $P$, $P$
must precede $Q$ in that \blockchainview.
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{}
\eli{Please formally define what a tx is. I don't think it's merely a sequence of inputs and outputs. The outputs are probably buckets (as defined above) and maybe the inputs are, too. Perhaps one should talk about a tx-bucket (which is unhidden) and a tx which is mostly hashed-stuff + a SNARK)}
Bitcoin transactions consist of a vector \eli{sequence? vector implies ``vector space'' which doens't exist here} of inputs ($\mathtt{vin}$) and a vector of outputs ($\mathtt{vout}$). Inputs and outputs are associated with a value \eli{assuing a tx-bucket is a pair of sequences --- an input-sequence and an output-sequence, and each sequence is a sequence of buckets, one should define the in-value of the tx-bucket as the sum of values in the in-buckets (ditto for out-value) and the remaining value is their difference}. The total value of the outputs must not exceed the total value of the inputs.
\subparagraph{Value pool}
Transaction inputs insert value into a \textit{value pool}, and transaction outputs remove value from this pool. The remaining value in the pool is available to miners as a fee.
Transaction inputs insert value into a \textit{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 Transactions ($\PourTx$)}
\section{Pour Transfers and Descriptions}
\eli{Hmm, I think things are starting to get confused here, let's try to clarify the theory/crypto. Informally, buckets and transactions are \emph{data}, whereas Pour is best thought of as a \emph{circuit} that outputs either $1$ (``true'') or $0$ (``false''). The theory of SNARKs (as supported by libsnark) is such that if the circuit outputs ``true'' then you can generate a SNARK for that set of inputs, and otherwise you can't (its cryptographically infeasible to do so). So we should describe formally what the \emph{inputs} to the Pour circuit are, and then define the \emph{computation preformed} by the Pour circuit, i.e., describe how it decides whether to output $0$ or $1$. More below}
\subparagraph{}
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
sequence of \PourDescriptions.
Each \PourDescription consists of:
$\PourTx$s are the primary operations \eli{In the academic paper, a Pour is a circuit (that defines an NP-language), and that circuit is the most crucial part of the construction. So if you want to use ``Pour'' to describe the algorithm that generates a tx, you'll be (i) deviating from the academic paper in a rather confusing way and (ii) you still need to define the ``Pour-circuit'' which is at the heart of the construction} performed by transactions that interact with our scheme. In principle, it is the action of spending $\Nold$ buckets $\bOld{}$ and creating $\Nnew$ buckets $\bNew{}$. \Zcash transactions have an additional field $\vpour$, which is a vector of $\PourTx$s. Each $\PourTx$ consists of:
\eli{reached here}
\begin{list}{}{}
\item $\vpubOld$ which is a value $\vpubold$ that the pour removes from the value pool.
\item $\vpubOldField$ which is a value $\vpubOld$ that the \PourTransfer removes
from the value pool.
\item $\vpubNew$ which is a value $\vpubnew$ that the pour inserts into the value pool.
\item $\vpubNewField$ which is a value $\vpubNew$ that the \PourTransfer inserts
into the value pool.
\item $\anchor$ which is a merkle root $\rt$ of the bucket commitment tree 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 $\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 Bitcoin script which creates conditions for acceptance of a $\PourTx$ in a transaction. The $\SHA$ hash of this value is $\hSig$.
\item $\scriptSig$ which is a \script that creates conditions for acceptance of a
\PourDescription in a transaction. The $\SHA$ hash of this value is $\hSig$.
\item $\scriptPubKey$ which is a Bitcoin script used to satisfy the conditions of the $\scriptSig$.
\daira{Why $\SHA$ and not $\SHAOrig$? The script is variable-length.}
\item $\serials$ which is an $\Nold$ size vector of serials $\sn^{old}_{1}, \sn^{old}_{2}, ..., \sn^{old}_{\Nold}$.
\item $\scriptPubKey$ which is a \script used to satisfy the conditions of the
$\scriptSig$.
\item $\commitments$ which is a $\Nnew$ size vector of bucket commitments $\bm^{new}_{1}, \bm^{new}_{2}, ..., \bm^{new}_{\Nnew}$.
\item $\serials$ which is an $\NOld$ size sequence of serials $\snOld{1..\NOld}$.
\item $\bucketCiphertexts$ which is a $\Nnew$ size vector each element of which is a \BucketCiphertextName.
\item $\commitments$ which is a $\NNew$ size sequence of \coinCommitments
$\cmNew{1..\NNew}$.
\item $\vmacs$ which is a $\Nold$ size vector of message authentication codes $h$ which bind $\hSig$ to each $\SpendAuthorityPrivate$ of the $\PourTx$.
\item $\TransmitCiphertexts$ which is a $\NNew$ size sequence each element of which
is a \transmittedCiphertext.
\item $\vmacs$ which is a $\NOld$ size sequence of message authentication tags
$\h{1..\NOld}$ that bind $\hSig$ to each $\SpendAuthorityPrivate$ of the
$\PourDescription$.
\item $\zkproof$ which is the zero-knowledge proof $\PourProof$.
@ -305,35 +467,54 @@ $\PourTx$s are the primary operations \eli{In the academic paper, a Pour is a ci
\subparagraph{Merkle root validity}
A $\PourTx$ is valid if $\rt$ is a bucket commitment tree root found in either the blockchain or a merkle root produced by inserting the bucket commitments of a previous $\PourTx$ in the transaction to the bucket commitment tree identified by that previous $\PourTx$'s $\anchor$.
A $\PourDescription$ is valid if $\rt$ is a Coin commitment tree root found in
either the blockchain or a merkle root produced by inserting the Coin commitments
of a previous $\PourDescription$ in the transaction to the Coin commitment tree
identified by that previous $\PourDescription$'s $\anchor$.
\subparagraph{Non-malleability}
A $\PourTx$ is valid if the script formed by appending $\scriptPubKey$ to $\scriptSig$ returns $true$. The $\scriptSig$ is cryptographically bound to $\PourProof$.
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 $\PourTx$ can be seen, from the perspective of the transaction, as an input and an output simultaneously. $\vpubOld$ takes value from the value pool and $\vpubNew$ adds value to the value pool. As a result, $\vpubOld$ is treated like an \textit{output} value, whereas $\vpubNew$ is treated like an \textit{input} value.
A \PourTransfer can be seen, from the perspective of the transaction, as an
input and an output simultaneously. $\vpubOld$ takes value from the value pool and
$\vpubNew$ adds value to the value pool. As a result, $\vpubOld$ is treated like an
\emph{output} value, whereas $\vpubNew$ is treated like an \emph{input} value.
\subparagraph{Commitments and Serials}
Transactions which contain $\PourTx$s, when entered into the blockchain, append to the bucket commitment tree with all constituent bucket commitments. All of the constituent serials are also entered into the spent serials map of the blockchain \textit{and} mempool. Transactions are not valid if they attempt to add a serial to the spent serials map that already exists.
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{$\PourProof$}
\subsection{Pour Circuit and Proofs}
\subparagraph{}
In \Zcash, $\Nold$ and $\Nnew$ are both $2$.
In \Zcash, $\NOld$ and $\NNew$ are both $2$.
\subparagraph{}
A valid instance of $\PourProof$ assures that given a \textit{primary input} ($\rt$, $\sn^{old}_{1}$, $\sn^{old}_{2}$, $\bm^{new}_{1}$, $\bm^{new}_{2}$, $\vpubold$, $\vpubnew$, $\hSig$, $h_1$, $h_2$), a witness of \textit{auxiliary input} ($\path{1}$, $\path{2}$, $\bOld{1}$, $\bOld{2}$, $\SpendAuthorityPrivate^{old}_1$, $\SpendAuthorityPrivate^{old}_2$, $\bNew{1}$, $\bNew{2}$) exists, where:
A valid instance of $\PourProof$ assures that given a \textit{primary input}
$(\rt, \snOld{1..\NOld}, \cmNew{1..\NNew}, \vpubOld, \vpubNew, \hSig, \h{1..\NOld})$,
a witness of \textit{auxiliary input}
$(\path{1..\NOld}, \cOld{1..\NOld}, \SpendAuthorityPrivateOld{1..\NOld}, \cNew{1..\NNew})$
exists, where:
\begin{list}{}{}
\item for each $i \in \{1, 2\}$: $\bOld{i}$ = $(\vOld{i}, \SpendAuthorityPublic^{old}_i, \BucketRand^{old}_i, \BucketAddressRand^{old}_i)$
\item for each $i \in \{1..\NOld\}$: $\cOld{i}$ = $(\vOld{i},
\SpendAuthorityPublicOld{i}, \CoinCommitRandOld{i}, \CoinAddressRandOld{i})$
\item for each $i \in \{1, 2\}$: $\bNew{i}$ = $(\vNew{i}, \SpendAuthorityPublic^{new}_i, \BucketRand^{new}_i, \BucketAddressRand^{new}_i)$.
\item for each $i \in \{1..\NNew\}$: $\cNew{i}$ = $(\vNew{i},
\SpendAuthorityPublicNew{i}, \CoinCommitRandNew{i}, \CoinAddressRandNew{i})$.
\item The following conditions hold:
@ -341,37 +522,41 @@ A valid instance of $\PourProof$ assures that given a \textit{primary input} ($\
\subparagraph{Merkle path validity}
for each $i \in \{1, 2\}$ $\mid$ $\vOld{i} \neq 0$: $\path{i}$ must be a valid path of depth $\MerkleDepth$ from \linebreak $\BucketCommitment{\bOld{i}}$ to bucket commitment merkle tree root $\rt$.
for each $i \in \{1..\NOld\}$ $\mid$ $\vOld{i} \neq 0$: $\path{i}$ must be a valid path
of depth $\MerkleDepth$ from \linebreak $\CoinCommitment{\cOld{i}}$ to Coin
commitment merkle tree root $\rt$.
\subparagraph{Balance}
$\vpubold + \vOld{1} + \vOld{2} = \vpubnew + \vNew{1} + \vNew{2}$.
$\vpubOld + \vsum{i=1}{\NOld} \vOld{i} = \vpubNew + \vsum{i=1}{\NNew} \vNew{i}$.
\subparagraph{Serial integrity}
for each $i \in \{1, 2\}$: $\PRFsn{\SpendAuthorityPrivate^{old}_{i}}(\BucketAddressRand^{old}_{i})$ = $\sn^{old}_{i}$.
for each $i \in \{1..\NNew\}$:
$\snOld{i} = \PRFsn{\SpendAuthorityPrivateOld{i}}(\CoinAddressRandOld{i})$.
\subparagraph{Spend authority}
for each $i \in \{1, 2\}$: $\SpendAuthorityPublic^{old}_{i}$ = $\PRFaddr{\SpendAuthorityPrivate^{old}_{i}}(0)$.
for each $i \in \{1..\NOld\}$:
$\SpendAuthorityPublicOld{i} = \PRFaddr{\SpendAuthorityPrivateOld{i}}(0)$.
\subparagraph{Non-malleability}
% TODO: protocol is really gross here, let's clarify the
% indices and use of PRFpk independence from other h sdfhjgahsdjkgfas
for each $i \in \{1, 2\}$: $h_i$ = $\PRFpk{\SpendAuthorityPrivate^{old}_i}{i-1}(\hSig)$
for each $i \in \{1..\NOld\}$: $\h{i}$ = $\PRFpk{\SpendAuthorityPrivateOld{i}}{i}(\hSig)$
\subparagraph{Commitment integrity}
for each $i \in \{1, 2\}$: $\bm^{new}_i$ = $\BucketCommitment{\bNew{i}}$
for each $i \in \{1..\NNew\}$: $\cmNew{i}$ = $\CoinCommitment{\cNew{i}}$
\section{Encoding addresses, private keys, buckets, and pours}
\section{Encoding Addresses, Private keys, Coins, and Pour descriptions}
This section describes how \Zcash encodes public addresses, private keys,
buckets, and pours.
coins, and \PourDescriptions.
Addresses, keys, and buckets, can be encoded as a byte string; this is called
the \emph{raw encoding}. This byte string can then be further encoded using
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.
@ -380,25 +565,25 @@ bytes.
The language consisting of the following encoding possibilities is prefix-free.
\subsection{Cleartext Public Addresses}
\subsection{Transparent Public Addresses}
TBD. Identical to Bitcoin?
\subsection{Cleartext Private Keys}
\subsection{Transparent Private Keys}
TBD. Identical to Bitcoin?
\subsection{Protected Public Addresses}
\subsection{Confidential Public Addresses}
A protected address consists of $\SpendAuthorityPublic$ and $\TransmitPublic$.
A confidential address consists of $\SpendAuthorityPublic$ and $\TransmitPublic$.
$\SpendAuthorityPublic$ is a SHA-256 compression function output.
$\TransmitPublic$ is an encryption public key (currently ECIES, but this may
change to Curve25519/crypto\_box), which represents an equivalence class of
two points sharing an $x$ coordinate on an elliptic curve.
change to Curve25519/crypto\_box\_seal), which represents an equivalence class
of two points sharing an $x$ coordinate on an elliptic curve.
\subsubsection{Raw Encoding}
The raw encoding of a protected address consists of:
The raw encoding of a confidential address consists of:
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{520}
@ -422,23 +607,23 @@ The raw encoding of a protected address consists of:
matter which of the two points with the same $x$ coordinate is used.]
\end{itemize}
\textbf{TODO: check that this lead byte is distinct from other Bitcoin stuff,
\daira{check that this lead byte is distinct from other Bitcoin stuff,
and produces `z' as the Base58Check leading character.}
\textbf{TODO: what about the network version byte?}
\nathan{what about the network version byte?}
\textbf{TODO: add bibliographic references for the IEEE standards.}
\daira{add bibliographic references for the IEEE standards.}
\subsection{Protected Address Secrets}
\subsection{Confidential Address Secrets}
A protected address secret consists of $\SpendAuthorityPrivate$ and
A confidential address secret consists of $\SpendAuthorityPrivate$ and
$\TransmitPrivate$. $\SpendAuthorityPrivate$ is a SHA-256 compression function
output. $\TransmitPrivate$ is an encryption private key (currently ECIES), which
is an integer.
\subsubsection{Raw Encoding}
The raw encoding of a protected address secret consists of, in order:
The raw encoding of a confidential address secret consists of, in order:
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{520}
@ -455,49 +640,51 @@ The raw encoding of a protected address secret consists of, in order:
\item 32 bytes specifying a big-endian encoding of $\TransmitPrivate$.
\end{itemize}
\textbf{TODO: check that this lead byte is distinct from other Bitcoin stuff,
\daira{check that this lead byte is distinct from other Bitcoin stuff,
and produces `z' as the Base58Check leading character.}
\textbf{TODO: what about the network version byte?}
\nathan{what about the network version byte?}
\subsection{Buckets}
\subsection{Coins}
Transmitted buckets are stored on the blockchain in encrypted form, together with
a \BucketCommitmentName $\bm$.
Transmitted coins are stored on the blockchain in encrypted form, together with
a \coinCommitment $\cm$.
A \BucketCiphertextName is an ECIES key-private encryption of a \BucketPlaintextName
to a \TransmitPublicName key $\TransmitPublic$.
A \transmittedCiphertext is an ECIES encryption of a \transmittedPlaintext to a
\transmitPublicAlgorithm key $\TransmitPublic$.
A \BucketPlaintextName consists of $(\Value, \BucketAddressRand, \BucketRand)$, where:
A \transmittedPlaintext consists of $(\Value, \CoinAddressRand, \CoinCommitRand)$,
where:
\begin{itemize}
\item $\Value$ is a 64-bit unsigned integer representing the value of the
bucket in zatoshi.
\item $\BucketAddressRand$ is a 32-byte $\PRFsn{\SpendAuthorityPrivate}$ seed.
\item $\BucketRand$ is a 32-byte COMM trapdoor.
\coin in \zatoshi (1 \ZEC = $10^8$ \zatoshi).
\item $\CoinAddressRand$ is a 32-byte $\PRFsn{\SpendAuthorityPrivate}$ seed.
\item $\CoinCommitRand$ is a 32-byte $\COMMSeed$.
\end{itemize}
Note that the value $s$ described as being part of a bucket/coin in the Zerocash
Note that the value $\mathsf{s}$ described as being part of a coin in the \Zerocash
paper is not encoded because it is fixed to zero.
\subsection{Raw Encoding}
The raw encoding of a \BucketPlaintextName consists of, in order:
The raw encoding of a \transmittedPlaintext consists of, in order:
\begin{equation*}
\begin{bytefield}[bitwidth=0.05em]{200}
\bitbox{80}{$\BucketPlaintextVersionByte$} &
\bitbox{80}{$\TransmitPlaintextVersionByte$} &
\bitbox{230}{$\Value$ (8 bytes, big endian)} &
\bitbox{230}{$\BucketAddressRand$ (32 bytes)} &
\bitbox{230}{$\BucketRand$ (32 bytes)} &
\bitbox{230}{$\CoinAddressRand$ (32 bytes)} &
\bitbox{230}{$\CoinCommitRand$ (32 bytes)} &
\end{bytefield}
\end{equation*}
\begin{itemize}
\item A byte $\BucketPlaintextVersionByte$ indicating this version of the raw encoding of a \BucketPlaintextName.
\item A byte $\TransmitPlaintextVersionByte$ indicating this version of the raw
encoding of a \transmittedPlaintext.
\item 8 bytes specifying a big-endian encoding of $\Value$.
\item 32 bytes specifying $\BucketAddressRand$.
\item 32 bytes specifying $\BucketRand$.
\item 32 bytes specifying $\CoinAddressRand$.
\item 32 bytes specifying $\CoinCommitRand$.
\end{itemize}
\section{Pours (within a transaction on the blockchain)}
@ -508,4 +695,8 @@ TBD.
TBD.
\section{References}
\bibliography{zcash}
\end{document}

8
protocol/zcash.bib Normal file
View File

@ -0,0 +1,8 @@
@inproceedings{ZerocashOakland,
author={Eli Ben-Sasson and Alessandro Chiesa and Christina Garman and Matthew Green and Ian Miers and Eran Tromer and Madars Virza},
year={2014},
title={Zerocash: Decentralized Anonymous Payments from Bitcoin},
booktitle={Proceedings of the IEEE Symposium on Security & Privacy (Oakland) 2014},
pages={459-474},
publisher={IEEE}
}