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

\serialNumber -> \nullifier and related macro changes. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2016-03-30 01:36:34 +01:00
parent 6897bebfe6
commit 674c5614f2
2 changed files with 49 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
protocol/protocol.pdf
View File

Binary file not shown.

98
protocol/protocol.tex
View File

@ -106,12 +106,12 @@
\newcommand{\mempool}{\term{mempool}}
\newcommand{\treestate}{\term{treestate}}
\newcommand{\treestates}{\term{treestates}}
\newcommand{\serialNumber}{\term{nullifier}}
\newcommand{\serialNumbers}{\term{nullifiers}}
\newcommand{\SerialNumber}{\titleterm{Nullifier}}
\newcommand{\SerialNumbers}{\titleterm{Nullifiers}}
\newcommand{\spentSerials}{\term{nullifier set}}
\newcommand{\SpentSerials}{\titleterm{Nullifier Set}}
\newcommand{\nullifier}{\term{nullifier}}
\newcommand{\nullifiers}{\term{nullifiers}}
\newcommand{\Nullifier}{\titleterm{Nullifier}}
\newcommand{\Nullifiers}{\titleterm{Nullifiers}}
\newcommand{\nullifierSet}{\term{nullifier set}}
\newcommand{\NullifierSet}{\titleterm{Nullifier Set}}
% Daira: This doesn't adequately distinguish between zk stuff and transparent stuff
\newcommand{\paymentAddress}{\term{payment address}}
\newcommand{\paymentAddresses}{\term{payment addresses}}
@ -191,8 +191,8 @@
\newcommand{\NoteAddressRandNew}[1]{\mathsf{\uprho^{new}_\mathnormal{#1}}}
\newcommand{\NoteAddressPreRand}{\mathsf{\upvarphi}}
\newcommand{\NoteCommitS}{\mathsf{s}}
\newcommand{\sn}{\mathsf{nf}}
\newcommand{\snOld}[1]{\sn^\mathsf{old}_\mathnormal{#1}}
\newcommand{\nf}{\mathsf{nf}}
\newcommand{\nfOld}[1]{\nf^\mathsf{old}_\mathnormal{#1}}
\newcommand{\hSigInputLeadNibble}{\mathbf{1}}
\newcommand{\Memo}{\mathsf{memo}}
\newcommand{\CurveMultiply}{\mathsf{Curve25519}}
@ -218,7 +218,7 @@
\newcommand{\Clamp}{\mathsf{clamp_{Curve25519}}}
\newcommand{\PRF}[2]{\mathsf{{PRF}^{#2}_\mathnormal{#1}}}
\newcommand{\PRFaddr}[1]{\PRF{#1}{addr}}
\newcommand{\PRFsn}[1]{\PRF{#1}{\sn}}
\newcommand{\PRFnf}[1]{\PRF{#1}{\nf}}
\newcommand{\PRFpk}[1]{\PRF{#1}{pk}}
\newcommand{\PRFrho}[1]{\PRF{#1}{\NoteAddressRand}}
\newcommand{\PRFdk}[1]{\PRF{#1}{dk}}
@ -245,7 +245,7 @@
\newcommand{\joinSplitSig}{\mathtt{joinSplitSig}}
\newcommand{\joinSplitPubKey}{\mathtt{joinSplitPubKey}}
\newcommand{\dataToBeSigned}{\mathtt{dataToBeSigned}}
\newcommand{\serials}{\mathtt{nullifiers}}
\newcommand{\nullifiersField}{\mathtt{nullifiers}}
\newcommand{\commitments}{\mathtt{commitments}}
\newcommand{\ephemeralKey}{\mathtt{ephemeralKey}}
\newcommand{\encCiphertexts}{\mathtt{encCiphertexts}}
@ -420,12 +420,12 @@ different from the $\FullHashName$ function, which hashes arbitrary-length seque
\cite{sha2}
$\PRF{x}{}$ is a pseudo-random function seeded by $x$. \changed{Four} \emph{independent}
$\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFsn{x}$, $\PRFpk{x}$\changed{,
$\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFnf{x}$, $\PRFpk{x}$\changed{,
and $\PRFrho{x}$}.
It is required that $\PRFsn{x}$ \changed{and $\PRFrho{x}$} be collision-resistant
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 $\PRFsn{x}(y) = \PRFsn{x'}(y')$\changed{, and similarly for $\PRFrho{}$}.
such that $\PRFnf{x}(y) = \PRFnf{x'}(y')$\changed{, and similarly for $\PRFrho{}$}.
In \Zcash, the $\SHAName$ function is used to construct all of these
functions. $\KDFHashName$ is also used to construct a Key Derivation Function.
@ -446,8 +446,8 @@ functions. $\KDFHashName$ is also used to construct a Key Derivation Function.
\end{bytefield}
\end{lrbox}
\newsavebox{\snbox}
\begin{lrbox}{\snbox}
\newsavebox{\nfbox}
\begin{lrbox}{\nfbox}
\setchanged
\begin{bytefield}[bitwidth=0.06em]{512}
\bitbox{18}{1} &
@ -488,7 +488,7 @@ functions. $\KDFHashName$ is also used to construct a Key Derivation Function.
\begin{equation*}
\begin{aligned}
&\setchanged \PRFaddr{x}(t) &\setchanged := \CRHbox{\addrbox} \\
\sn =\;& \PRFsn{\AuthPrivate}(\NoteAddressRand) &:= \CRHbox{\snbox} \\
\nf =\;& \PRFnf{\AuthPrivate}(\NoteAddressRand) &:= \CRHbox{\nfbox} \\
\h{i} =\;& \PRFpk{\AuthPrivate}(i, \hSig) &:= \CRHbox{\pkbox} \\
\setchanged \NoteAddressRandNew{i} =\;&\setchanged \PRFrho{\NoteAddressPreRand}(i, \hSig)
&\setchanged := \CRHbox{\rhobox}
@ -583,7 +583,7 @@ to $\AuthPublic$, as described in the previous section.
\item $\AuthPublic$ is a 32-byte \authKeypair public key 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 $\PRFsn{\AuthPrivate}$ preimage.
\item $\NoteAddressRand$ is a 32-byte $\PRFnf{\AuthPrivate}$ preimage.
\item $\NoteCommitRand$ is a 32-byte \COMMtrapdoor.
\end{itemize}
@ -619,12 +619,12 @@ The resulting hash $\cm = \Commitment(\NoteTuple{})$.
\hskip 1em $\cm := \FullHashbox{\cmbox}$
}
\subsubsection{\SerialNumbers}
\subsubsection{\Nullifiers}
A \serialNumber (denoted $\sn$) is derived from the $\NoteAddressRand$ component
of a \note as $\PRFsn{\AuthPrivate}(\NoteAddressRand)$. A \note is spent by proving
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 \serialNumber $\sn$, allowing $\sn$ to be used to prevent double-spending.
disclosing its \nullifier $\nf$, allowing $\nf$ to be used to prevent double-spending.
\subsubsection{\NotePlaintexts and \Memos} \label{notept}
@ -697,22 +697,22 @@ Blocks in the blockchain are associated (by all nodes) with the root of this tre
after all of its constituent \joinSplitDescriptions' \noteCommitments have been
entered into the tree associated with the previous block.
\subsection{\SpentSerials}
\subsection{\NullifierSet}
Transactions insert \serialNumbers into a \spentSerials which is maintained
Transactions insert \nullifiers into a \nullifierSet 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 \serialNumbers to the
\spentSerials.}
tx's and the ``good'' ones lead to the addition of \nullifiers to the
\nullifierSet.}
Transactions that attempt to insert a \serialNumber into this set that already
Transactions that attempt to insert a \nullifier into this set 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 \serialNumbers into the
\spentSerials.}
talk about ``attempts'' of transactions, and insertions of \nullifiers into the
\nullifierSet.}
\subsection{The Blockchain}
@ -824,8 +824,8 @@ into the value pool. \\ \hline
some block height in the past, or the merkle root produced by a previous \joinSplitTransfer in
this \transaction. \sean{We need to be more specific here.} \\ \hline
64 & $\serials$ & \type{char[32][$\NOld$]} & A sequence of \serialNumbers of the input
\notes $\snOld{\allOld}$. \\ \hline
64 & $\nullifiersField$ & \type{char[32][$\NOld$]} & A sequence of \nullifiers of the input
\notes $\nfOld{\allOld}$. \\ \hline
64 & $\commitments$ & \type{char[32][$\NNew$]}. & A sequence of \noteCommitments for the
output \notes $\cmNew{\allNew}$. \\ \hline
@ -864,8 +864,8 @@ The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphert
\bitbox{24}{1} &
\bitbox{24}{1} &
\bitbox{112}{4 bit $\hSigInputLeadNibble$} &
\bitbox{256}{\hfill 256 bit $\snOld{\mathrm{1}}$\hfill...\;} &
\bitbox{256}{256 bit $\snOld{\NOld}$} &
\bitbox{256}{\hfill 256 bit $\nfOld{\mathrm{1}}$\hfill...\;} &
\bitbox{256}{256 bit $\nfOld{\NOld}$} &
\bitbox{256}{$\randomSeed$}
\bitbox{256}{$\joinSplitPubKey$}
\end{bytefield}
@ -982,13 +982,13 @@ This restriction helps to avoid unnecessary distinctions between \transactions
according to client implementation.
}
\subsection{\NoteCommitments and \SerialNumbers}
\subsection{\NoteCommitments and \Nullifiers}
A \transaction that contains one or more \joinSplitDescriptions, when entered into the
blockchain, appends to the \noteCommitmentTree with all constituent
\noteCommitments. All of the constituent \serialNumbers are also entered into the
\spentSerials of the \blockchainview \emph{and} \mempool. A \transaction is not
valid if it attempts to add a \serialNumber to the \spentSerials that already
\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.
\subsection{\JoinSplitCircuit and Proofs}
@ -998,7 +998,7 @@ In \Zcash, $\NOld$ and $\NNew$ are both $2$.
A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}:
\begin{itemize}
\item[] $(\rt, \snOld{\allOld}, \cmNew{\allNew}, \changed{\vpubOld,\;}
\item[] $(\rt, \nfOld{\allOld}, \cmNew{\allNew}, \changed{\vpubOld,\;}
\vpubNew, \hSig, \h{\allOld})$,
\end{itemize}
@ -1030,10 +1030,10 @@ $\Commitment(\cOld{i})$ to \noteCommitmentTree root $\rt$.
$\changed{\vpubOld\; +} \vsum{i=1}{\NOld} \vOld{i} = \vpubNew + \vsum{i=1}{\NNew} \vNew{i}$.
\subparagraph{Serial integrity}
\subparagraph{\Nullifier integrity}
for each $i \in \setofNew$:
$\snOld{i} = \PRFsn{\AuthPrivateOld{i}}(\NoteAddressRandOld{i})$.
$\nfOld{i} = \PRFnf{\AuthPrivateOld{i}}(\NoteAddressRandOld{i})$.
\subparagraph{Spend authority}
@ -1165,7 +1165,7 @@ $\Receive$ algorithm shown in Figure 2 of \cite{ZerocashOakland}.
To test whether a \note is unspent in a particular \blockchainview also requires
the \authKeypair private key $\AuthPrivate$; the coin is unspent if and only if
$\sn = \PRFsn{\AuthPrivate}(\NoteAddressRand)$ is not in the \spentSerials
$\nf = \PRFnf{\AuthPrivate}(\NoteAddressRand)$ is not in the \nullifierSet
for that \blockchainview.
Note that a \note may change from being unspent to spent on a given \blockchainview,
@ -1278,7 +1278,7 @@ low-order 4 bits of the second byte.
\subparagraph{Note:} If an implementation represents $\AuthPrivate$
internally as a sequence of 32 bytes with the 4 bits of zero padding
intact, it will be in the correct form for use as an input to
$\PRFaddr{}$, $\PRFsn{}$, and $\PRFpk{}$ without need for bit-shifting.
$\PRFaddr{}$, $\PRFnf{}$, and $\PRFpk{}$ without need for bit-shifting.
Future key representations may make use of these padding bits.
\daira{check that this lead byte is distinct from other Bitcoin stuff,
@ -1352,7 +1352,7 @@ more detail in \crossref{notept}.
When a protected \note is created in \Zerocash, the creator is
supposed to choose a new $\NoteAddressRand$ value at random.
The \serialNumber of the \note is derived from its \spendingKey
The \nullifier of the \note is derived from its \spendingKey
($\AuthPrivate$) and $\NoteAddressRand$. The \noteCommitment
is derived from the recipient address component $\AuthPublic$,
the value $\Value$, and the commitment trapdoor $\NoteCommitRand$,
@ -1377,11 +1377,11 @@ Balance:
\begin{itemize}
\item The Completeness property asserts that a validly received
\note can be spent provided that its \serialNumber does not appear
\note can be spent provided that its \nullifier does not appear
on the ledger. This does not take into account the possibility
that distinct \notes, which are validly received, could have the
same \serialNumber. That is, the security definition depends on
a protocol detail --\serialNumbers-- that is not part of the
same \nullifier. That is, the security definition depends on
a protocol detail --\nullifiers-- that is not part of the
intended abstract security property, and that could be implemented
incorrectly.
\item The Balance property only asserts that an adversary cannot
@ -1408,12 +1408,12 @@ of their funds, even if they have forgotten everything but the
Instead, \Zcash enforces that an adversary must choose distinct values
for each $\NoteAddressRand$, by making use of the fact that all of the
\serialNumbers in \joinSplitDescriptions that appear in a valid \blockchainview
must be distinct. The \serialNumbers are used as input to $\FullHash$
\nullifiers in \joinSplitDescriptions that appear in a valid \blockchainview
must be distinct. The \nullifiers are used as input to $\FullHash$
to derive a public value $\hSig$ which uniquely identifies the transaction,
as described in \crossref{hsig}. ($\hSig$ was already used in \Zerocash
in a way that requires it to be unique in order to maintain
indistinguishability of \joinSplitDescriptions; adding the \serialNumbers
indistinguishability of \joinSplitDescriptions; adding the \nullifiers
to the input of the hash used to calculate it has the effect of making
this uniqueness property robust even if the \transaction creator is an
adversary.)
@ -1425,7 +1425,7 @@ $\NoteAddressRand$ for each output \note is enforced by the circuit
(see \crossref{uniquerho}).
Now even if the creator of a \joinSplitDescription does not choose
$\NoteAddressPreRand$ randomly, uniqueness of \serialNumbers and
$\NoteAddressPreRand$ randomly, uniqueness of \nullifiers and
collision resistance of both $\FullHash$ and $\PRFrho{}$ will ensure
that the derived $\NoteAddressRand$ values are unique, at least for
any two \joinSplitDescriptions that get into a valid \blockchainview.