mirror of https://github.com/zcash/zips.git
\serialNumber -> \nullifier and related macro changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
6897bebfe6
commit
674c5614f2
Binary file not shown.
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue