\eli{A few general comments that will re-appear numerous times:
\begin{itemize}
\item The ``intended usage'' explanations are confusing: What happens if some player does not play as intended? Suggest using standard Crypto terminology: the algorithms specified in the paper refer to the \emph{honest} player(s). Any deviation is treated non-honest. Some
deviations harm only their perpetrator, and we should state this;
other deviations threaten other honest players
and we should explain how these are mitigated.
\item Suggest having two separate parts: first (i) an abstract functionality, stated in terms
of crypto primitives with a paramaterized security parameter, and (ii)
concrete instantiations. I'll call these ``abstract'' and ``instantiation'' later on.
\end{itemize}
}
\Zcash is an implementation of the \term{Decentralized Anonymous Payment}
scheme \Zerocash\cite{ZerocashOakland} with some adjustments to terminology,
functionality and performance. It bridges the existing \emph{transparent}
@ -321,7 +333,7 @@ Changes from the original \Zerocash are highlighted in \changed{\changedcolor}.
\section{Caution}
\eli{Should this section appear in this paper? This paper describes \emph{our implementation} so what does divergence mean? Perhaps this refers to non-honest players?}
\Zcash security depends on consensus. Should your program diverge from
consensus, its security is weakened or destroyed. The cause of the divergence
doesn't matter: it could be a bug in your program, it could be an error in
@ -330,6 +342,9 @@ everything right but other software on the network behaves unexpectedly. The
specific cause will not matter to the users of your software whose wealth is
lost.
\eli{I don't understand what indended behavior means?
This paper specifies how an \emph{honest player} should act, and whenever
there's deviation we should have something that mitigates it.}
Having said that, a specification of \emph{intended} behaviour is essential
for security analysis, understanding of the protocol, and maintenance of
Zcash Core and related software. If you find any mistake in this specification,
@ -341,6 +356,7 @@ the mistake may indicate a security weakness.
\section{Conventions}
\subsection{Integers, Bit Sequences, and Endianness}
\eli{Suggest this subsection be moved to ``instantiation''}
All integers in \emph{\Zcash-specific} encodings are unsigned, have a fixed
bit length, and are encoded in little-endian byte order. \changed{The definition of
@ -431,6 +447,12 @@ The symbol $\bot$ is used to indicate unavailable information or a failed decryp
\subsection{Cryptographic Functions}
\eli{Would be good to start with ``abstract'', using only a single security parameter $\lambda$ and multiples of it, and then in ``instantiations'' have
the specific details. In more detail, in ``abstract'' we'll have
only $\CRH$ with security $\lambda$, and multiple $\PRF{a}{b}$'s all with same (?) security $\lambda$, and we demand that the PRFs are ``computationally pairwise independent'', i.e.,
$\PRF{a}{b}$ is pseudorandom given $\PRF{a'}{b'}$ whenever
$(a,b)\neq(a',b')$.}
$\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 $\FullHashName$ function, which hashes arbitrary-length sequences.
@ -442,7 +464,10 @@ and $\PRFrho{x}$}.
It is required that $\PRFnf{x}$\changed{and $\PRFrho{x}$} be collision-resistant
across all $x$ --- i.e. it should not be feasible to find $(x, y)\neq(x', y')$
such that $\PRFnf{x}(y)=\PRFnf{x'}(y')$\changed{, and similarly for $\PRFrho{}$}.
such that $\PRFnf{x}(y)=\PRFnf{x'}(y')$\changed{, and similarly for $\PRFrho{}$}. \eli{we likely need more than just not having a collision. Likely
various bad things would happen if $\PRF{x}{y}$ can be predicted given
$\PRF{x'}{y'}$. So we really need them to be pairwise distinct pseudorandom
functions.}
In \Zcash, the $\SHAName$ function is used to construct all of these
functions.
@ -536,28 +561,31 @@ string $p$ and input $x$, as defined in \cite{blake2}.
\subsection{Payment Addresses and Spending Keys}
A \keyTuple$(\SpendingKey, \PaymentAddress)$ is
generated by users who wish to receive payments under this scheme.
The \paymentAddress$\PaymentAddress$ is derived from the \spendingKey
generated by users \eli{``who wish to receive payments'' is an intended usage explanation, suggest removing}who wish to receive payments under this scheme.
The \paymentAddress$\PaymentAddress$ is derived \eli{it's not clear what ``derived'' means, suggest putting the formal derivations right away here}from the \spendingKey
$\SpendingKey$.
The following diagram depicts the relations between key components.
Arrows point from a component to any other component(s) that can be derived
from it.
from it. \eli{formally, any $a$ can be derived from any $b$ as long as ``derived'' remains undefined, hence think the
derivation rule should be explicitly stated here}
\begin{center}
\includegraphics[scale=.8]{key_components}
\end{center}
\eli{following sentence is an intended usage explanation, and its very confusing: what happens if a player deviates? will it ruin the system?
Additionally, its not clear what happens in our system, how is it ``not explosed to users''?}
The composition of \paymentAddresses and \spendingKeys
is a cryptographic protocol detail that should not normally be
exposed to users. However, user-visible operations should be provided
exposed to users. However, user-visible operations \eli{what's a user-visible operation? what's an operation? how is it provided?}should be provided
to obtain a \paymentAddress or \viewingKey from a \spendingKey.
\changed{$\AuthPrivate$ is 252 bits.}
$\AuthPublic$, $\TransmitPrivate$, and $\TransmitPublic$, are each 256 bits.
\changed{$\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived
as follows:}
as follows:\eli{this be moved up. Additionally, the clamp/curve stuff is an ``instantiation'' and here we should have abstract PKC functionality (public key, private key)}}
{\hfuzz=50pt
\begin{equation*}
\begin{aligned}
@ -586,6 +614,7 @@ such that bit $b$ has numeric weight $2^b$.
\end{itemize}
}
\eli{following paragraph talks about intended usage, hence confusing. }
Users can accept payment from multiple parties with a single
$\PaymentAddress$ and the fact that these payments are destined to
the same payee is not revealed on the blockchain, even to the
@ -597,28 +626,31 @@ case that a payee wishes to prevent this they should create a distinct
\subsection{\Notes}
A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value,
\NoteAddressRand, \NoteCommitRand)}$ which represents that a value $\Value$ is
\NoteAddressRand, \NoteCommitRand)}$\eli{shouldn't $\NoteCommitRand$ be part of the note commitment, not the note?}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.
\eli{following list mixes abstract and instantiation stuff}
\begin{itemize}
\item$\AuthPublic$ is a 32-byte \authKeypair public key of the recipient.
\item$\AuthPublic$ is a 32-byte \authKeypair public key \eli{this should have been defined in the previous section}of the recipient.
\item$\Value$ is a 64-bit unsigned integer representing the value of the
\note in \zatoshi (1 \ZEC = $10^8$\zatoshi).
\item$\NoteAddressRand$ is a 32-byte $\PRFnf{\AuthPrivate}$ preimage.
\item$\NoteCommitRand$ is a 32-byte \COMMtrapdoor.
\end{itemize}
$\NoteCommitRand$ is randomly generated by the sender. \changed{$\NoteAddressRand$
$\NoteCommitRand$ is randomly generated by the sender. \eli{previous and next sentence should be merged into bullets above}\changed{$\NoteAddressRand$
is generated from a random seed $\NoteAddressPreRand$ using
$\PRFrho{\NoteAddressPreRand}$.} Only a commitment to these values is disclosed
publicly, which allows the tokens $\NoteCommitRand$ and $\NoteAddressRand$ to blind
the value and recipient \emph{except} to those who possess these tokens.
the value and recipient \emph{except} to those who possess these tokens \eli{inaccurate, even if you have these tokens you'd have to exhaustively try all address keys (not all of them are necessarily known to you) and values
to find the recipient}.
\subsubsection{\NoteCommitments}\label{comm}
The underlying $\Value$ and $\AuthPublic$ are blinded with $\NoteAddressRand$
and $\NoteCommitRand$\changed{using the collision-resistant hash function $\FullHash$}.
\eli{The note commitment of $\NoteTuple{}$, denoted $\cm$, is defined as \ldots}
The resulting hash $\cm=\Commitment(\NoteTuple{})$.
\newsavebox{\cmbox}
@ -656,9 +688,13 @@ disclosing its \nullifier $\nf$, allowing $\nf$ to be used to prevent double-spe
\subsubsection{\NotePlaintexts and \Memos}\label{notept}
\eli{what's a transmitted note? is it different from a note? and who encrypts
them? }
Transmitted \notes are stored on the blockchain in encrypted form, together with
``transmission keys'', ``transmitted notes cyphertext'' all of which are undefined yet. It seems the main thing defined here is the memo, and then a note-plaintext. In the ``abstract'' part both are easy to describe, and the rest of the details should likely be moved to ``instantiation''}
The \notePlaintexts associated with a \joinSplitDescription are encrypted to the
and the result forms part of a \notesCiphertext (see \crossref{inband}
@ -721,18 +757,22 @@ The encoding of a \notePlaintext consists of, in order:
\includegraphics[scale=.4]{incremental_merkle}
\end{center}
\eli{Prefer ``A \noteCommitmentTree'' because all that follows works for any tree and we expect it to dynamically change}
The \noteCommitmentTree is an \incrementalMerkleTree of depth $\MerkleDepth$ used to
store \noteCommitments that \joinSplitTransfers produce. Just as the \term{unspent
store \noteCommitments that \joinSplitTransfers produce\eli{undefined yet because \joinSplitTransfer. Why not define it just as in the figure, it's a merkle tree of note commitments.}. 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.
the job of this tree \eli{intended usage. particularly confusing because we now assign a job to a 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
\eli{more intendend usage: how does the honest player associate blocks with a tree? and what happens if a user deviates from this? We're going to describe the split-join circuit. For this purpose we only need to have defined a tree of commitments and define (or assume knowledge) of authentication paths in a merkle tree}Blocks in the blockchain are associated (by all nodes) with the root of this tree
after all of its constituent \joinSplitDescriptions' \noteCommitments have been
entered into the tree associated with the previous block.
\subsection{\NullifierSet}
\eli{intended usage. Prefer to have defined (i) a nullifier set and (ii) commitment tree, and now talk about join-split. Later we'll explain how these two objects are modified.}
\eli{tx undefined yet}
Transactions insert \nullifiers into a \nullifierSet which is maintained
alongside the UTXO by all nodes.
@ -748,11 +788,17 @@ exists within it are invalid as they are attempting to double-spend.
talk about ``attempts'' of transactions, and insertions of \nullifiers into the
\nullifierSet.}
\eli{suggest to move the discussion of the split-join circuit to here, so that we first completely discuss the single-tx level (with respect to some fixed comm-tree and nullifier set). Then we'll move to the topic of consensus and blockchain.}
\subsection{The Blockchain}
At a given point in time, the \blockchainview of each \fullnode consists of a
\eli{For the ``abstract'' part, all we care about is that each block-chain is converted to a merkle tree in a deterministic manner, so that all honest players agree on it's structure (assuming they see the same blockchain). so the particular way the ``canonical'' tree is constructed should appear in ``instantiation''.}
At a given point in time, the \blockchainview of each \fullnode\eli{undefined. So far we had ``users''. Are there several kinds?} 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
more \transactions. In a given node's \blockchainview, \treestates are chained
\eli{defined?} in an
obvious way:
\begin{itemize}
@ -768,10 +814,10 @@ obvious way:
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 \sequenceOfJoinSplitDescriptions.
Each \transaction is associated with a \sequenceOfJoinSplitDescriptions\eli{this is undefined yet. let's work bottom up: first define a join-split assuming a fixed tree}.
\todo{They also have a transparent value flow that interacts with the \joinSplitDescription's
\changed{$\vpubOld$ and}$\vpubNew$.}
Inputs and outputs are associated with a value.
Inputs and outputs are associated with a value.\eli{what're inputs/outputs of join-split?}
The total value of the outputs must not exceed the total value of the inputs.
@ -794,26 +840,29 @@ views of valid \blocks, and therefore of the sequence of \treestates in those
\subparagraph{Value pool}
\eli{who maintains the value pool? is this part of the specification? seems like
more intended usage?}\eli{tx undefined yet}
Transaction inputs insert value into a \term{value pool}, and transaction outputs
remove value from this pool. The remaining value in the pool is available to miners
as a fee.
\section{\JoinSplitTransfers and Descriptions}\label{pourdesc}
A \joinSplitDescription is data included in a \transaction that describes a \joinSplitTransfer,
A \joinSplitDescription is data included in a \transaction\eli{lets first define split-join, then tx}that describes a \joinSplitTransfer,
i.e. a confidential value transfer. This kind of value transfer is the primary
\Zcash-specific operation performed by \transactions; it uses, but should not be
\Zcash-specific operation performed by \transactions\eli{we keep referring to undefined tx. furthermore, it's not clear from last sentence if tx is a type of data or a process, as it performs something}; it uses, but should not be
confused with, the \JoinSplitCircuit used for the \zkSNARK proof and verification.
A \joinSplitTransfer spends $\NOld$\notes$\cOld{\allOld}$ and transparent input
A \joinSplitTransfer spends $\NOld$\notes$\cOld{\allOld}$\eli{confusing notation, usually one uses $x_1,\ldots, x_n$ for a sequence of $n$ objects, not $x_{1\ldots,n}$}and transparent input
$\vpubOld$, and creates $\NNew$\notes$\cNew{\allNew}$ and transparent output
$\vpubNew$.
\subparagraph{Consensus rule:}
Either $\vpubOld$ or $\vpubNew$\MUST be zero.
\subparagraph{Consensus rule:}\eli{what's a consensus rule? what happens if I deviate from it?}
Either $\vpubOld$ or $\vpubNew$\MUST be zero. \eli{why? what harm would follow
if we allow both nonzero?}
\changed{
\Zcash\transactions have the following additional fields:
\Zcash\transactions have the following additional fields\eli{additional to what?}:
@ -844,7 +893,7 @@ The encoding of $\joinSplitPubKey$ and the data to be signed are specified in
more detail in \crossref{nonmalleability}.
}
Each \type{JoinSplitDescription} consists of:
Each \type{JoinSplitDescription} consists of:\eli{maybe move this up, to beginning of section?}
\begin{center}
\begin{tabularx}{0.9\textwidth}{|c|l|l|X|}
@ -893,6 +942,8 @@ The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphert
\subsection{Computation of \hSigText}\label{hsig}
\eli{this is mostly ``instantiation'' but I notice we use a different crypto primitive instantiation (Blake) not mentioned previously. Let's use the ``abstract'' notation here: what is it? a CRH? PRF? requires different multiple of the security parameter $\lambda$? does it require special properties not needed by other instances of these that we used previously?}
\newsavebox{\hsigtagbox}
\begin{lrbox}{\hsigtagbox}
\setchanged
@ -930,13 +981,18 @@ identified by that previous \joinSplitDescription's $\anchor$.
\eli{mix of ``abstract'' and ``instantiation''. Can we first describe abstractly what's going on here? I got pretty lost pretty quickly. In particular, what
are the abstract functionalities of SIGHASH, SIGHASHALL, ECDSA,
the ``compressed elliptic curve point'', are they CRH and digital signature, respectively? what security (as multiple of $\lambda$?)}
\changed{
\Bitcoin defines several \sighashTypes that cover various parts of a transaction.
In \Zcash, all of these \sighashTypes are extended to cover the \Zcash-specific
fields $\nJoinSplit$, $\vJoinSplit$, and $\joinSplitPubKey$. They \emph{do not}
cover the field $\joinSplitSig$.
\subparagraph{Consensus rule:}
\subparagraph{Consensus rule:}\eli{what's a consensus rule?}
If $\nJoinSplit > 0$, the \transaction\MUSTNOT use \sighashTypes other than
$\SIGHASHALL$.
@ -1020,11 +1076,11 @@ to $\joinSplitPubKey$ to sign this \transaction.
\subsection{Balance}
A \joinSplitTransfer can be seen, from the perspective of the \transaction, as
A \joinSplitTransfer can be seen\eli{more intended usage}, from the perspective of the \transaction\eli{does a transaction ``see''?}, as
an input \changed{and an output simultaneously}.
\changed{$\vpubOld$ takes value from the value pool and}
$\vpubNew$ adds value to the value pool. As a result, \changed{$\vpubOld$ is
treated like an \emph{output} value, whereas}$\vpubNew$ is treated like an
treated \eli{by whom?}like an \emph{output} value, whereas}$\vpubNew$ is treated like an
\emph{input} value.
\changed{
@ -1044,12 +1100,12 @@ according to client implementation.
\subsection{\NoteCommitments and \Nullifiers}
A \transaction that contains one or more \joinSplitDescriptions, when entered into the
A \transaction\eli{undefined yet}that contains one or more \joinSplitDescriptions, when entered into the
blockchain, appends to the \noteCommitmentTree with all constituent
\noteCommitments. All of the constituent \nullifiers are also entered into the
\nullifierSet of the \blockchainview\emph{and}\mempool. A \transaction is not
valid if it attempts to add a \nullifier to the \nullifierSet that already
eli.ben.sasson
8 years ago