|
|
@ -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 |
|
|
|