diff --git a/protocol/protocol.pdf b/protocol/protocol.pdf index cf7e078..575d3ef 100644 Binary files a/protocol/protocol.pdf and b/protocol/protocol.pdf differ diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 0da9b46..2f19dc4 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -310,6 +310,18 @@ \section{Introduction} +\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 a \noteCommitment $\cm$. +\eli{next paragraph mentions ``note plainext'', ``joinsplit description'', + ``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 respective \transmitKeypair keys $\TransmitPublicNew{\allNew}$, 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?}: \begin{center} \begin{tabularx}{0.9\textwidth}{|c|l|p{10.49em}|X|} @@ -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$. \subsection{Non-malleability} \label{nonmalleability} + +\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 -exists in the set. +exists in the set. \subsection{\JoinSplitCircuit and Proofs}