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

Cosmetics and small wording changes. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2016-09-04 01:08:02 +01:00
parent 7218bfe7e5
commit 8d16a496ec
1 changed files with 77 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

143
protocol/protocol.tex
View File

@ -144,8 +144,8 @@
\newcommand{\note}{\term{note}}
\newcommand{\notes}{\term{notes}}
\newcommand{\Note}{Note}
\newcommand{\Notes}{Notes}
\newcommand{\Note}{\titleterm{Note}}
\newcommand{\Notes}{\titleterm{Notes}}
\newcommand{\commitmentScheme}{\term{commitment scheme}}
\newcommand{\commitmentTrapdoor}{\term{commitment trapdoor}}
\newcommand{\commitmentTrapdoors}{\term{commitment trapdoors}}
@ -155,6 +155,7 @@
\newcommand{\NoteCommitment}{\titleterm{Note Commitment}}
\newcommand{\NoteCommitments}{\titleterm{Note Commitments}}
\newcommand{\noteCommitmentTree}{\term{note commitment tree}}
\newcommand{\NoteCommitmentTree}{\titleterm{Note Commitment Tree}}
\newcommand{\noteTraceabilitySet}{\term{note traceability set}}
\newcommand{\noteTraceabilitySets}{\term{note traceability sets}}
\newcommand{\joinSplitDescription}{\term{JoinSplit description}}
@ -169,6 +170,7 @@
\newcommand{\joinSplitStatement}{\term{JoinSplit statement}}
\newcommand{\joinSplitStatements}{\term{JoinSplit statements}}
\newcommand{\JoinSplitStatement}{\titleterm{JoinSplit Statement}}
\newcommand{\joinSplitProof}{\term{JoinSplit proof}}
\newcommand{\statement}{\term{statement}}
\newcommand{\zeroKnowledgeProof}{\term{zero-knowledge proof}}
\newcommand{\ZeroKnowledgeProofs}{\titleterm{Zero-Knowledge Proofs}}
@ -176,8 +178,12 @@
\newcommand{\zeroKnowledgeProvingSystem}{\term{zero-knowledge proving system}}
\newcommand{\ZeroKnowledgeProvingSystem}{\titleterm{Zero-Knowledge Proving System}}
\newcommand{\ppzkSNARK}{\term{preprocessing zk-SNARK}}
\newcommand{\provingKey}{\term{proving key}}
\newcommand{\zkProvingKeys}{\term{zero-knowledge proving keys}}
\newcommand{\verifyingKey}{\term{verifying key}}
\newcommand{\zkVerifyingKeys}{\term{zero-knowledge verifying keys}}
\newcommand{\joinSplitParameters}{\term{JoinSplit parameters}}
\newcommand{\JoinSplitParameters}{\titleterm{JoinSplit Parameters}}
\newcommand{\arithmeticCircuit}{\term{arithmetic circuit}}
\newcommand{\rankOneConstraintSystem}{\term{Rank 1 Constraint System}}
\newcommand{\primary}{\term{primary}}
@ -202,7 +208,12 @@
\newcommand{\transactionVersionNumber}{\term{transaction version number}}
\newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
\newcommand{\coinbaseTransactions}{\term{coinbase transactions}}
\newcommand{\transparent}{\term{transparent}}
\newcommand{\transparentValuePool}{\term{transparent value pool}}
\newcommand{\xprotected}{\term{protected}}
\newcommand{\protectedNote}{\term{protected note}}
\newcommand{\protectedNotes}{\term{protected notes}}
\newcommand{\xProtected}{\term{Protected}}
\newcommand{\blockchainview}{\term{block chain view}}
\newcommand{\blockchain}{\term{block chain}}
\newcommand{\mempool}{\term{mempool}}
@ -531,8 +542,11 @@
\newcommand{\Receive}{\mathsf{Receive}}
\newcommand{\consensusrule}[1]{\subparagraph{Consensus rule:}{#1}}
\newenvironment{consensusrules}{\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}}
\newcommand{\securityrequirement}[1]{\subparagraph{Security requirement:}{#1}}
\newenvironment{securityrequirements}{\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}}
\newcommand{\pnote}[1]{\subparagraph{Note:}{#1}}
\newenvironment{pnotes}{\subparagraph{Notes:}\begin{itemize}}{\end{itemize}}
\begin{document}
@ -554,7 +568,7 @@
scheme \Zerocash \cite{BCG+2014}, with some security fixes and adjustments
to terminology, functionality and performance. It bridges the existing
\emph{transparent} payment scheme used by \Bitcoin \cite{Naka2008} with a
\emph{confidential} payment scheme protected by zero-knowledge succinct
\emph{protected} payment scheme protected by zero-knowledge succinct
non-interactive arguments of knowledge (\zkSNARKs).
Changes from the original \Zerocash are explained in \crossref{differences},
@ -618,16 +632,16 @@ between \notes, \noteCommitments, and \nullifiers). However, it is infeasible
to correlate a commitment with its \nullifier without knowledge of the \note.
Computing the \nullifier requires the associated private \spendingKey. An
unspent valid \note, at a given point on the \blockchain, is one for which
the \noteCommitment has been publicly revealed on the \blockchain prior to
the \noteCommitment has been publically revealed on the \blockchain prior to
that point, but the \nullifier has not.
A \transaction can contain ``transparent'' inputs, outputs, and scripts, which
all work basically as in \Bitcoin. They also contain a sequence of zero or
A \transaction can contain \transparent inputs, outputs, and scripts,
which all work as in \Bitcoin. They also contain a sequence of zero or
more \joinSplitDescriptions. Each of these describes a \joinSplitTransfer\hairspace\footnote{
\joinSplitTransfers in \Zcash generalize ``Mint'' and ``Pour'' \transactions
in \Zerocash; see \crossref{trstructure} for the differences.}
which takes in a transparent value and up to two input \notes, and produces a
transparent value and up to two output \notes. The \nullifiers of the input
which takes in a \transparent value and up to two input \notes, and produces a
\transparent value and up to two output \notes. The \nullifiers of the input
\notes are revealed (preventing them from being spent again) and the
commitments of the output \notes are revealed (allowing them to be spent in
future). Each \joinSplitDescription also includes a computationally sound
@ -726,9 +740,8 @@ remainder on dividing $a$ by $q$.
The notation $a \xor b$ means the bitwise exclusive-or of $a$ and $b$,
defined either on integers or bit sequences depending on context.
The notation $\vsum{i=1}{\mathrm{N}} a_i$ means the sum of $a_{\allN{}}$.
The notation $\vxor{i=1}{\mathrm{N}} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$.
The notation $\vsum{i=1}{\mathrm{N}} a_i$ means the sum of $a_{\allN{}}$.\;
$\vxor{i=1}{\mathrm{N}} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$.
The notation $\floor{x}$ means the largest integer $\leq x$.
$\ceiling{x}$ means the smallest integer $\geq x$.
@ -804,14 +817,17 @@ spendable by the recipient who holds the \spendingKey $\AuthPrivate$ correspondi
to $\AuthPublic$, as described in the previous section.
\begin{itemize}
\item $\AuthPublic \typecolon \bitseq{\PRFOutputLength}$ represents
the \payingKey of the recipient.
\item $\Value \typecolon \range{0}{\MAXMONEY}$ represents the value of the
\note in \zatoshi ($1$ \ZEC = $10^8$ \zatoshi).
\item $\NoteAddressRand \typecolon \bitseq{\PRFOutputLength}$ is
used as input to $\PRFnf{\AuthPrivate}$ to obtain the \note's \nullifier.
\item $\NoteCommitRand \typecolon \bitseq{\NoteCommitRandLength}$ is a
\commitmentTrapdoor.
\item $\AuthPublic \typecolon \PRFOutput$ is the
\payingKey of the recipient;
\item $\Value \typecolon \range{0}{\MAXMONEY}$ is an integer
representing the value of the \note in \zatoshi
($1$ \ZEC = $10^8$ \zatoshi);
\item $\NoteAddressRand \typecolon \PRFOutput$
is used as input to $\PRFnf{\AuthPrivate}$ to derive the
\nullifier of the \note;
\item $\NoteCommitRand \typecolon \bitseq{\NoteCommitRandLength}$
is a random bit sequence used as a \commitmentTrapdoor as
defined in \crossref{abstractcomm}.
\end{itemize}
$\NoteCommitRand$ is randomly generated by the sender. \changed{$\NoteAddressRand$
@ -832,9 +848,10 @@ scheme.
\nsubsubsection{\Nullifiers}
A \nullifier (denoted $\nf$) is derived from the $\NoteAddressRand$ component
of a \note as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$. A \note is spent by proving
knowledge of $\NoteAddressRand$ and $\AuthPrivate$ in zero knowledge while
disclosing its \nullifier $\nf$, allowing $\nf$ to be used to prevent double-spending.
of a \note and the recipient's \spendingKey, as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$.
A \note is spent by proving knowledge of $\NoteAddressRand$ and $\AuthPrivate$ in
zero knowledge while publically disclosing its \nullifier $\nf$, allowing $\nf$ to
be used to prevent double-spending.
\nsubsubsection{\NotePlaintexts{} and \Memos}
@ -862,7 +879,7 @@ $\Memo$ represents a \memo associated with this \note. The usage of the
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. To each \transaction there is associated an initial \treestate,
which consists of a \noteCommitmentTree (\crossref{merkle}), \nullifierSet
which consists of a \noteCommitmentTree (\crossref{merkletree}), \nullifierSet
(\crossref{nullifierset}), and data structures associated with \Bitcoin such as
the UTXO (Unspent Transaction Output) set.
@ -901,8 +918,8 @@ 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
confused with, the \joinSplitStatement used for the \zkSNARK proof and verification.
A \joinSplitTransfer spends $\NOld$ \notes $\nOld{\allOld}$ and transparent input
$\vpubOld$, and creates $\NNew$ \notes $\nNew{\allNew}$ and transparent output
A \joinSplitTransfer spends $\NOld$ \notes $\nOld{\allOld}$ and \transparent input
$\vpubOld$, and creates $\NNew$ \notes $\nNew{\allNew}$ and \transparent output
$\vpubNew$.
Each \transaction is associated with a \sequenceOfJoinSplitDescriptions.
@ -911,7 +928,7 @@ The inputs and outputs of each \joinSplitTransfer{} \MUST balance exactly.
The \changed{total $\vpubNew$ value adds to, and the total} $\vpubOld$
value subtracts from the \transparentValuePool of the containing \transaction.
\todo{Describe the interaction of transparent value flows with the \joinSplitDescription's
\todo{Describe the interaction of \transparent value flows with the \joinSplitDescription's
\changed{$\vpubOld$ and} $\vpubNew$.}
\changed{
@ -923,8 +940,7 @@ some earlier \block's final \treestate, or to the output \treestate of any prior
These conditions act as constraints on the blocks that a \fullnode will
accept into its \blockchainview.
\nsubsection{\NoteCommitment{} Tree} \label{merkle}
\nsubsection{\NoteCommitmentTree} \label{merkletree}
\begin{center}
\includegraphics[scale=.4]{incremental_merkle}
@ -974,7 +990,7 @@ included in this block.
\nsubsubsection{Coinbase outputs}
\todo{Coinbase maturity rule.}
\todo{Any tx with a coinbase input must have no transparent outputs (vout).}
\todo{Any tx with a coinbase input must have no \transparent outputs (vout).}
\nsection{Abstract Protocol}
@ -984,7 +1000,7 @@ included in this block.
\nsubsubsection{Hash Functions} \label{abstracthashes}
$\MerkleCRH \typecolon \MerkleHash \times \MerkleHash \rightarrow \MerkleHash$
is a collision-resistant hash function used in \crossref{merkletree}.
is a collision-resistant hash function used in \crossref{merklepath}.
It is instantiated in \crossref{merklecrh}.
\changed{
@ -1108,8 +1124,8 @@ $Q \typecolon \range{1}{2} \times \GeneralCRHOutput \rightarrow
\item Return $(\EphemeralPublic, \Key_{\allNew})$.
\end{enumerate}
Then the adversary must make another query to $Q$ with random $j \in \range{1}{2}$,
and guess $j$ with probability greater than chance.
Then the adversary must make another query to $Q_j$ with random unknown
$j \in \range{1}{2}$, and guess $j$ with probability greater than chance.
}
If the adversary's advantage is negligible, then the asymmetric encryption scheme
@ -1270,7 +1286,7 @@ where
\transaction.
\item $\nfOld{\allOld} \typecolon (\PRFOutput)^{\NOld}$ is
the sequence of \nullifiers for the input \notes;
\item $\cmNew{\allNew} \typecolon {\CommitOutput}^{\NNew}$ is
\item $\cmNew{\allNew} \typecolon (\CommitOutput)^{\NNew}$ is
the sequence of \noteCommitments for the output \notes;
\item \changed{$\EphemeralPublic \typecolon \KAPublic$ is
a key agreement public key, used to derive the key for encryption
@ -1283,7 +1299,7 @@ where
$\AuthPrivate$ of the input \notes;
\item $\JoinSplitProof \typecolon \ZKProof$ is
the \zeroKnowledgeProof for the \joinSplitStatement;
\item $\TransmitCiphertext{\allNew} \typecolon {\Ciphertext}^{\NNew}$ is
\item $\TransmitCiphertext{\allNew} \typecolon (\Ciphertext)^{\NNew}$ is
a sequence of ciphertext components for the encrypted output \notes.
\end{itemize}
@ -1325,15 +1341,12 @@ containing the field $\joinSplitPubKey$, we compute $\hSig$ for that
\end{equation*}
}
\nsubsubsection{Merkle root validity} \label{merkletree}
\daira{This paragraph is confusing and only describes one aspect of validity.}
A \joinSplitDescription is valid if $\rt$ is a \noteCommitmentTree root found in
either the blockchain or a merkle root produced by inserting the \noteCommitments
of a previous \joinSplitDescription in the \transaction to the \noteCommitmentTree
identified by that previous \joinSplitDescription's $\anchor$.
The depth of the \noteCommitmentTree is $\MerkleDepth$.
\nsubsection{Merkle path validity} \label{merklepath}
The depth of the \noteCommitmentTree is $\MerkleDepth$ (defined in \crossref{constants}).
Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash,
which is a byte sequence. The \merkleLayer numbered $h$, counting from
@ -1370,7 +1383,7 @@ where
Given such a \merklePath, it is possible to verify that \merkleLeafNode
$\MerkleNode{\MerkleDepth}{i}$ is in a tree with a given \merkleRoot $\rt = \MerkleNode{0}{0}$.
\nsubsubsection{Non-malleability} \label{nonmalleability}
\nsubsection{Non-malleability} \label{nonmalleability}
\changed{
\Bitcoin defines several \sighashTypes that cover various parts of a transaction.
@ -1388,7 +1401,7 @@ Let $\dataToBeSigned$ be the hash of the \transaction using the $\SIGHASHALL$
the non-\Zcash-specific parts of the \transaction.
In order to ensure that a \joinSplitDescription is cryptographically bound to the
transparent inputs and outputs corresponding to $\vpubNew$ and $\vpubOld$, and
\transparent inputs and outputs corresponding to $\vpubNew$ and $\vpubOld$, and
to the other \joinSplitDescriptions in the same \transaction, an ephemeral $\JoinSplitSigAlg$
key pair is generated for each \transaction, and the $\dataToBeSigned$ is
signed with the private signing key of this key pair. The corresponding public
@ -1436,7 +1449,7 @@ ensures that a holder of all of $\AuthPrivateOld{\allOld}$ for each
to $\joinSplitPubKey$ to sign this \transaction.
\nsubsubsection{Balance}
\nsubsection{Balance}
A \joinSplitTransfer can be seen, from the perspective of the \transaction, as
an input \changed{and an output simultaneously}.
@ -1461,7 +1474,7 @@ This restriction helps to avoid unnecessary distinctions between \transactions
according to client implementation.
}
\nsubsubsection{\NoteCommitments{} and \Nullifiers}
\nsubsection{\NoteCommitments{} and \Nullifiers}
A \transaction that contains one or more \joinSplitDescriptions, when entered into the
blockchain, appends to the \noteCommitmentTree with all constituent
@ -1470,7 +1483,7 @@ blockchain, appends to the \noteCommitmentTree with all constituent
valid if it attempts to add a \nullifier to the \nullifierSet that already
exists in the set.
\nsubsubsection{\JoinSplitStatement} \label{jsstatement}
\nsubsection{\JoinSplitStatement} \label{jsstatement}
A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}:
@ -1634,8 +1647,7 @@ the \spendingKey $\AuthPrivate$; the coin is unspent if and only if
$\nf = \PRFnf{\AuthPrivate}(\NoteAddressRand)$ is not in the \nullifierSet
for that \blockchainview.
\subparagraph{Notes:}
\begin{itemize}
\begin{pnotes}
\item A \note can change from being unspent to spent on a given \blockchainview,
as \transactions are added to that view. Also, blockchain reorganisations can cause
the \transaction in which a \note was output to no longer be on the consensus
@ -1644,7 +1656,7 @@ blockchain.
\item The ``IETF" definition of $\SymSpecific$ from \cite{RFC-7539} is
used; this uses a 32-bit block count and a 96-bit nonce, rather than a 64-bit
block count and 64-bit nonce as in the original definition of $\SymCipher$.
\end{itemize}
\end{pnotes}
See \crossref{inbandrationale} for further discussion of the security and
engineering rationale behind this encryption scheme.
@ -1652,7 +1664,7 @@ engineering rationale behind this encryption scheme.
\nsection{Concrete Protocol}
\nsubsection{Warning}
\nsubsection{Caution}
\todo{Explain the kind of things that can go wrong with linkage between
abstract and concrete protocol. E.g. \crossref{internalh}}
@ -1987,7 +1999,6 @@ where:
\todo{}
\nsubsection{Note Components}
\begin{itemize}
@ -2373,11 +2384,11 @@ Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
4 & $\versionField$ & \type{uint32\_t} & Transaction version number; either 1 or 2. \\ \hline
\Varies & $\txInCount$ & \type{compactSize uint} & Number of transparent inputs in this transaction. \\ \hline
\Varies & $\txInCount$ & \type{compactSize uint} & Number of \transparent inputs in this transaction. \\ \hline
\Varies & $\txIn$ & $\txIn$ & Transparent inputs, encoded as in \Bitcoin. \\ \hline
\Varies & $\txOutCount$ & \type{compactSize uint} & Number of transparent outputs in this transaction. \\ \hline
\Varies & $\txOutCount$ & \type{compactSize uint} & Number of \transparent outputs in this transaction. \\ \hline
\Varies & $\txOut$ & $\txOut$ & Transparent outputs, encoded as in \Bitcoin. \\ \hline
@ -2714,13 +2725,13 @@ In \Zcash, there is only the original \Bitcoin transaction type,
which is extended to contain a sequence of zero or more
\Zcash-specific operations.
This allows for the possibility of chaining transfers of protected
value in a single \Zcash \transaction, e.g.\ to spend a protected \note
This allows for the possibility of chaining transfers of \xprotected
value in a single \Zcash \transaction, e.g.\ to spend a \protectedNote
that has just been created. (In \Zcash, we refer to value stored in
UTXOs as ``transparent'', and value stored in \joinSplitTransfer output
\notes as ``protected''.)
UTXOs as \transparent, and value stored in \joinSplitTransfer output
\notes as \xprotected.)
This was not possible in the \Zerocash design without using multiple
transactions. It also allows transparent and protected transfers to
transactions. It also allows \transparent and \xprotected transfers to
happen atomically --- possibly under the control of nontrivial script
conditions, at some cost in distinguishability.
@ -2737,20 +2748,20 @@ more detail in \crossref{notept}.
\nsubsection{Unification of Mints and Pours}
In the original \Zerocash protocol, there were two kinds of transaction
relating to protected \notes:
relating to \protectedNotes:
\begin{itemize}
\item a ``Mint'' transaction takes value from transparent UTXOs as
input and produces a new protected \note as output.
\item a ``Pour'' transaction takes up to $\NOld$ protected
\notes as input, and produces up to $\NNew$ protected \notes and a
transparent UTXO as output.
\item a ``Mint'' transaction takes value from \transparent UTXOs as
input and produces a new \protectedNote as output.
\item a ``Pour'' transaction takes up to $\NOld$ \protectedNotes
as input, and produces up to $\NNew$ \protectedNotes and a
\transparent UTXO as output.
\end{itemize}
Only ``Pour'' transactions included a \zkSNARK proof.
In \Zcash, the sequence of operations added to a \transaction
(described in \crossref{trstructure}) consists only of \joinSplitTransfers.
A \joinSplitTransfer is a Pour operation generalized to take a transparent
A \joinSplitTransfer is a Pour operation generalized to take a \transparent
UTXO as input, allowing \joinSplitTransfers to subsume the functionality of
Mints. An advantage of this is that a \Zcash \transaction that takes
input from an UTXO can produce up to $\NNew$ output \notes, improving
@ -2764,7 +2775,7 @@ described below, since no special case is needed for Mints.
\nsubsection{Faerie Gold attack and fix} \label{faeriegold}
When a protected \note is created in \Zerocash, the creator is
When a \protectedNote is created in \Zerocash, the creator is
supposed to choose a new $\NoteAddressRand$ value at random.
The \nullifier of the \note is derived from its \spendingKey
($\AuthPrivate$) and $\NoteAddressRand$. The \noteCommitment