\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).
\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}
\section{Concepts}
@ -121,7 +122,7 @@ $\CRH$ is a collision-resistant hash function. In \Zcash, the $\SHAName$ functio
\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 order to prevent a double-spending attack \eli{I don't see how to use a collision to double spend. If anything, a collision in $\PRFpk{x}{i}$ seems more usable to double spend}. 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 \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 order to prevent a double-spending attack \eli{I don't see how to use a collision to double spend. If anything, a collision in $\PRFpk{x}{i}$ seems more usable to double spend}\sean{If you could create two $\BucketAddressRand$ such that there is a collision you could spend the same bucket twice. The original paper makes the claim that this must 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.
A keypair $(\PublicAddress, \PrivateAddress)$ is generated by a user any time they wish to receive value from another in the system \eli{The previous sentence seems to imply that a fresh pair is needed for each new receive, but this isn't the case. Perhaps change to ``To receive/pay values in the system, a user must set-up a key pair \ldots; differing from Bitcoin, replacing keys is not needed to protect privacy.''}. The public $\PublicAddress$ is called a $\PublicAddressName$ and is a tuple $(\SpendAuthorityPublic, \TransmitPublic)$ which are the public components of a $\SpendAuthorityName$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\TransmitName$ keypair $(\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 $\TransmitName$ keypairs.
A keypair $(\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$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\TransmitName$ keypair $(\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 $\TransmitName$ keypairs.
\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.
\subsection{Buckets}
\subparagraph{}
A bucket (denoted $\Bucket$) is a tuple $(\Value, \SpendAuthorityPublic_{i}, \BucketRand, \BucketAddressRand)$\eli{subscript $i$ should be removed from bucket} which represents that a value $\Value$ is spendable by the recipient who holds the $\SpendAuthorityName$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$\eli{more precise: any user that knows $\SpendAuthorityPrivate$ such that $\SpendAuthorityPublic=\PRFaddr{\SpendAuthorityPrivate}(0)$}. $\BucketRand$ and $\BucketAddressRand$ are randomly generated tokens which are used to blind the value and recipient \textit{except} to those who possess these tokens. \eli{last sentence unclear. Zcash transactions contain only hashes of financial information
(like $\Value$ and $\SpendAuthorityPublic$) and $\BucketRand$ and $\BucketAddressRand$ are used to hide this data.}
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$ keypair $(\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.
\subparagraph{In-band secret distribution}
@ -183,7 +187,7 @@ In order to send the secret $\Value$, $\BucketRand$ and $\BucketAddressRand$ to
\subparagraph{Bucket 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$ is called a \textit{bucket commitment}.
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}$.
% TODO: this appears to be ineffective
\begin{flushright}
@ -224,12 +228,9 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
\end{flushright}
We say that the bucket commitment of a bucket $\Bucket$ is $\bm=\BucketCommitment{\Bucket}$.
\subparagraph{Serials}
A serial $\sn$\eli{serial serial number?} is produced by \eli{equals?}$\PRFsn{\SpendAuthorityPrivate}(\BucketAddressRand)$. Part of the process of spending a bucket is disclosing this serial without disclosing either $\BucketAddressRand$ or $\SpendAuthorityPrivate$. This allows it to be used to prevent double-spending. \eli{More precise: \emph{Knowledge} of $\BucketAddressRand$ and $\SpendAuthorityPrivate$ is required to spend a bucket. Knowledge of $\BucketAddressRand$ and $\SpendAuthorityPrivate$ is proved without revealing it explicitly via a
zero-knowledge (zk)SNARK.}
A serial number (denoted $\sn$) equals $\PRFsn{\SpendAuthorityPrivate}(\BucketAddressRand)$. Buckets are spent by proving knowledge of $\BucketAddressRand$ or $\SpendAuthorityPrivate$ in zero-knowledge while disclosing $\sn$, allowing $\sn$ to be used to prevent double-spending.
\subsection{Bucket Commitment Tree}
@ -261,12 +262,12 @@ Bitcoin transactions consist of a vector \eli{sequence? vector implies ``vector
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}
\section{Pour Transactions ($\PourTx$)}
\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{}
$\Pour$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 $\Pour$s. Each $\Pour$ 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}{}{}
@ -276,7 +277,7 @@ $\Pour$s are the primary operations \eli{In the academic paper, a Pour is a circ
\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. \textbf{(TODO: clarify this)}
\item$\scriptSig$ which is a Bitcoin script which creates conditions for acceptance of a $\Pour$ in a transaction. The $\SHA$ hash of this value is $\hSig$.
\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$\scriptPubKey$ which is a Bitcoin script used to satisfy the conditions of the $\scriptSig$.
@ -286,7 +287,7 @@ $\Pour$s are the primary operations \eli{In the academic paper, a Pour is a circ
\item$\encryptedBuckets$ which is a $\Nnew$ size vector of encrypted buckets.
\item$\vmacs$ which is a $\Nold$ size vector of message authentication codes $h$ which bind $\hSig$ to each $\SpendAuthorityPrivate$ of the $\Pour$.
\item$\vmacs$ which is a $\Nold$ size vector of message authentication codes $h$ which bind $\hSig$ to each $\SpendAuthorityPrivate$ of the $\PourTx$.
\item$\zkproof$ which is the zero-knowledge proof $\PourProof$.
@ -294,19 +295,19 @@ $\Pour$s are the primary operations \eli{In the academic paper, a Pour is a circ
\subparagraph{Merkle root validity}
A $\Pour$ 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 $\Pour$ in the transaction to the bucket commitment tree identified by that previous $\Pour$'s $\anchor$.
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$.
\subparagraph{Non-malleability}
A $\Pour$ is valid if the script formed by appending $\scriptPubKey$ to $\scriptSig$ returns $true$. The $\scriptSig$ is cryptographically bound to $\PourProof$.
A $\PourTx$ is valid if the script formed by appending $\scriptPubKey$ to $\scriptSig$ returns $true$. The $\scriptSig$ is cryptographically bound to $\PourProof$.
\subparagraph{Balance}
A $\Pour$ 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 $\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.
\subparagraph{Commitments and Serials}
Transactions which contain $\Pour$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.
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.
Sean Bowe
9 years ago