mirror of https://github.com/zcash/zips.git
Highlight changes from original Zerocash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
55c631d37f
commit
f169514c65
Binary file not shown.
|
@ -18,6 +18,19 @@
|
|||
|
||||
\mathchardef\mhyphen="2D
|
||||
|
||||
\RequirePackage[usenames,dvipsnames]{xcolor}
|
||||
% https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips
|
||||
\newcommand{\eli}[1]{{\color{JungleGreen}\sf{Eli: #1}}}
|
||||
\newcommand{\sean}[1]{{\color{blue}\sf{Sean: #1}}}
|
||||
\newcommand{\taylor}[1]{{\color{red}\sf{Taylor: #1}}}
|
||||
\newcommand{\daira}[1]{{\color{RedOrange}\sf{Daira: #1}}}
|
||||
\newcommand{\nathan}[1]{{\color{ForestGreen}\sf{Nathan: #1}}}
|
||||
\newcommand{\todo}[1]{{\color{Sepia}\sf{TODO: #1}}}
|
||||
|
||||
\newcommand{\changedcolor}{magenta}
|
||||
\newcommand{\setchanged}{\color{\changedcolor}}
|
||||
\newcommand{\changed}[1]{{\setchanged{#1}}}
|
||||
|
||||
% terminology
|
||||
|
||||
\newcommand{\term}[1]{\textsl{#1}\xspace}
|
||||
|
@ -36,6 +49,7 @@
|
|||
\newcommand{\coinCommitmentTree}{\term{coin commitment tree}}
|
||||
\newcommand{\PourDescription}{\term{Pour description}}
|
||||
\newcommand{\PourDescriptions}{\term{Pour descriptions}}
|
||||
\newcommand{\sequenceOfPourDescriptions}{\changed{sequence of} \PourDescription\changed{\term{s}}}
|
||||
\newcommand{\PourTransfer}{\term{Pour transfer}}
|
||||
\newcommand{\PourTransfers}{\term{Pour transfers}}
|
||||
\newcommand{\fullnode}{\term{full node}}
|
||||
|
@ -171,14 +185,6 @@
|
|||
\newcommand{\COMMtrapdoor}{\term{\textsf{COMM} trapdoor}}
|
||||
\newcommand{\CoinCommitment}[1]{\mathtt{CoinCommitment}(#1)}
|
||||
|
||||
\RequirePackage[usenames,dvipsnames]{xcolor}
|
||||
% https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips
|
||||
\newcommand{\eli}[1]{{\color{magenta}\sf{Eli: #1}}}
|
||||
\newcommand{\sean}[1]{{\color{blue}\sf{Sean: #1}}}
|
||||
\newcommand{\taylor}[1]{{\color{red}\sf{Taylor: #1}}}
|
||||
\newcommand{\daira}[1]{{\color{RedOrange}\sf{Daira: #1}}}
|
||||
\newcommand{\nathan}[1]{{\color{ForestGreen}\sf{Nathan: #1}}}
|
||||
|
||||
|
||||
\begin{document}
|
||||
|
||||
|
@ -196,6 +202,8 @@ payment scheme used by \Bitcoin with a \emph{confidential} payment scheme
|
|||
protected by zero-knowledge succinct non-interactive arguments of knowledge
|
||||
(\zkSNARKs).
|
||||
|
||||
Changes from the original \Zerocash are highlighted in \changed{\changedcolor}.
|
||||
|
||||
\section{Concepts}
|
||||
|
||||
\subsection{Integers, Bit Sequences, and Endianness}
|
||||
|
@ -310,8 +318,8 @@ case that a payee wishes to prevent this they should create a distinct
|
|||
|
||||
\subsection{Coins}
|
||||
|
||||
A \coin (denoted $\Coin$) is a tuple $(\SpendAuthorityPublic, \Value,
|
||||
\CoinAddressRand, \CoinCommitRand)$ which represents that a value $\Value$ is
|
||||
A \coin (denoted $\Coin$) is a tuple $\changed{(\SpendAuthorityPublic, \Value,
|
||||
\CoinAddressRand, \CoinCommitRand)}$ which represents that a value $\Value$ is
|
||||
spendable by the recipient who holds the $\spendAuthority$ key pair
|
||||
$(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ such that
|
||||
$\SpendAuthorityPublic = \PRFaddr{\SpendAuthorityPrivate}(0)$. $\CoinAddressRand$ and
|
||||
|
@ -322,18 +330,21 @@ value and recipient \emph{except} to those who possess these tokens.
|
|||
\subsubsection{In-band secret distribution}
|
||||
|
||||
In order to transmit the secret $\Value$, $\CoinAddressRand$, and $\CoinCommitRand$
|
||||
(necessary for the recipient to later spend) and also a \memo to the recipient
|
||||
\emph{without} requiring an out-of-band communication channel, the
|
||||
(necessary for the recipient to later spend) \changed{and also a \memo} to the
|
||||
recipient \emph{without} requiring an out-of-band communication channel, the
|
||||
$\transmitPublicAlgorithm$ public key $\TransmitPublic$ is used to encrypt these
|
||||
secrets to form a \coinsCiphertext. The recipient's possession of the associated
|
||||
$(\PublicAddress, \PrivateAddress)$ (which contains both $\SpendAuthorityPublic$ and
|
||||
$\TransmitPrivate$) is used to reconstruct the original \coin and \memo.
|
||||
$\TransmitPrivate$) is used to reconstruct the original \coin \changed{ and \memo}.
|
||||
|
||||
\changed{
|
||||
The encryption algorithm is defined in terms of $\CryptoBox$ (i.e.
|
||||
$\CryptoBoxSpecific$) \cite{cryptobox} as follows.
|
||||
}
|
||||
|
||||
\newsavebox{\prenoncebox}
|
||||
\begin{lrbox}{\prenoncebox}
|
||||
\setchanged
|
||||
\begin{bytefield}[bitwidth=0.05em]{520}
|
||||
\bitbox{120}{64 bit $i-1$} &
|
||||
\bitbox{256}{256 bit $\EphemeralPublic$}
|
||||
|
@ -343,16 +354,18 @@ $\CryptoBoxSpecific$) \cite{cryptobox} as follows.
|
|||
|
||||
\newsavebox{\noncebox}
|
||||
\begin{lrbox}{\noncebox}
|
||||
\setchanged
|
||||
\begin{bytefield}[bitwidth=0.085em]{192}
|
||||
\bitbox{128}{$\Leading{128}(\Prenonce)$} &
|
||||
\bitbox{72}{64 bit $i-1$}
|
||||
\end{bytefield}
|
||||
\end{lrbox}
|
||||
|
||||
Let $\TransmitPublicNew{\mathrm{1}..\NNew}$ be the Curve25519 public keys for the intended
|
||||
recipient addresses of each new \coin, and let $\Plaintext{1..\NNew}$ be their
|
||||
\coinPlaintexts.
|
||||
Let $\TransmitPublicNew{\mathrm{1}..\NNew}$ be the \changed{Curve25519} public keys
|
||||
for the intended recipient addresses of each new \coin, and let $\Plaintext{1..\NNew}$
|
||||
be their \coinPlaintexts.
|
||||
|
||||
\changed{
|
||||
Define:
|
||||
\begin{equation*}
|
||||
\begin{aligned}
|
||||
|
@ -360,9 +373,11 @@ Define:
|
|||
\Nonce(i, \EphemeralPublic, \TransmitPublicNew{i}) &:= \Justthebox{\noncebox}
|
||||
\end{aligned}
|
||||
\end{equation*}
|
||||
}
|
||||
|
||||
Then to encrypt:
|
||||
|
||||
\changed{
|
||||
\begin{itemize}
|
||||
\item Generate a new Curve25519 (public, private) key pair $(\EphemeralPublic, \EphemeralPrivate)$.
|
||||
\item For $i$ in $\{1..\NNew\}$, let $\Ciphertext{i} = \CryptoBox(\Plaintext{i}, \TransmitPublicNew{i}, \EphemeralPrivate,
|
||||
|
@ -370,23 +385,27 @@ Then to encrypt:
|
|||
\item Let $\TransmitEncrypt{\TransmitPublicNew{1..\NNew}}(\Plaintext{1..\NNew}) =
|
||||
(\EphemeralPublic, \Ciphertext{1..\NNew})$.
|
||||
\end{itemize}
|
||||
}
|
||||
|
||||
Let $(\TransmitPublic, \TransmitPrivate)$ be the recipient's Curve25519
|
||||
(public, private) key pair, and let $(\EphemeralPublic, \Ciphertext{1..\NNew})$
|
||||
be the \coinsCiphertext.
|
||||
Let $(\TransmitPublic, \TransmitPrivate)$ be the recipient's \changed{Curve25519}
|
||||
(public, private) key pair, and let $\changed{(\EphemeralPublic,}\;
|
||||
\Ciphertext{1..\NNew}\changed{)}$ be the \coinsCiphertext.
|
||||
|
||||
Then for each $i$ in $\{1..\NNew\}$, the recipient will attempt to decrypt that
|
||||
ciphertext component as follows:
|
||||
|
||||
\changed{
|
||||
\begin{itemize}
|
||||
\item $\TransmitDecrypt{\TransmitPrivate}(i, \EphemeralPublic, \Ciphertext{i}) =
|
||||
\CryptoBoxOpen(\Ciphertext{i}, \EphemeralPublic, \TransmitPrivate,
|
||||
\Nonce(i, \EphemeralPublic, \TransmitPublic))$
|
||||
\end{itemize}
|
||||
}
|
||||
|
||||
Any ciphertext components that fail to decrypt with a given recipient's private key
|
||||
will be ignored.
|
||||
|
||||
\changed{
|
||||
This is a variation on the $\CryptoBoxSeal$ algorithm defined in libsodium
|
||||
\cite{cryptoboxseal}, but with a single ephemeral key used for all encryptions in a
|
||||
given \PourDescription, and with the nonce for each ciphertext component depending
|
||||
|
@ -394,6 +413,7 @@ on the index $i$. Also, $\CryptoBoxSealHash$ (the full hash, not the compression
|
|||
function) is used instead of $\mathsf{blake2b}$. The particular nonce construction
|
||||
is chosen so that a known-nonce distinguisher for $\mathsf{Salsa20}$ would not
|
||||
directly lead to a break of the IK-CCA (key privacy) property.
|
||||
}
|
||||
|
||||
\subsubsection{Coin Commitments}
|
||||
|
||||
|
@ -494,18 +514,21 @@ 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 sequence of \PourDescriptions. TODO They also have
|
||||
a transparent value flow that interacts with the Pour $\vpubOld$ and $\vpubNew$.
|
||||
Each \transaction is associated with a \sequenceOfPourDescriptions.
|
||||
\todo{They also have a transparent value flow that interacts with the Pour
|
||||
\changed{$\vpubOld$ and} $\vpubNew$.}
|
||||
Inputs and outputs are associated with a value.
|
||||
|
||||
The total value of the outputs must not exceed the total value of the inputs.
|
||||
|
||||
The \anchor of the first \PourDescription in a \transaction must refer to some
|
||||
earlier \block's final \treestate.
|
||||
The \anchor of the \changed{first} \PourDescription in a \transaction must refer to
|
||||
some earlier \block's final \treestate.
|
||||
|
||||
\changed{
|
||||
The \anchor of each subsequent \PourDescription may refer either to some earlier
|
||||
\block's final \treestate, or to the output \treestate of the immediately preceding
|
||||
\PourDescription.
|
||||
}
|
||||
|
||||
These conditions act as constraints on the blocks that a \fullnode will
|
||||
accept into its \blockchainview.
|
||||
|
@ -529,15 +552,16 @@ i.e. a confidential value transfer. This kind of value transfer is the primary
|
|||
confused with, the \PourCircuit used for the \zkSNARK proof and verification.
|
||||
|
||||
A \PourTransfer spends $\NOld$ \coins $\cOld{1..\NOld}$ and creates $\NNew$ \coins
|
||||
$\cNew{1..\NNew}$. \Zcash transactions have an additional field $\vpour$, which is a
|
||||
sequence of \PourDescriptions.
|
||||
$\cNew{1..\NNew}$. \Zcash transactions have an additional field $\vpour$, which is
|
||||
a \sequenceOfPourDescriptions.
|
||||
|
||||
Each \PourDescription consists of:
|
||||
|
||||
\begin{list}{}{}
|
||||
|
||||
\changed{
|
||||
\item $\vpubOldField$ which is a value $\vpubOld$ that the \PourTransfer removes
|
||||
from the value pool.
|
||||
}
|
||||
|
||||
\item $\vpubNewField$ which is a value $\vpubNew$ that the \PourTransfer inserts
|
||||
into the value pool.
|
||||
|
@ -559,10 +583,12 @@ $\scriptSig$.
|
|||
\item $\commitments$ which is a $\NNew$ size sequence of \coinCommitments
|
||||
$\cmNew{1..\NNew}$.
|
||||
|
||||
\changed{
|
||||
\item $\ephemeralKey$ which is a Curve25519 public key $\EphemeralPublic$.
|
||||
}
|
||||
|
||||
\item $\ciphertexts$ which is a $\NNew$ size sequence of ciphertext components.
|
||||
($\ephemeralKey$ and $\ciphertexts$ together form the \coinsCiphertext.)
|
||||
(\changed{$\ephemeralKey$ and} $\ciphertexts$ together form the \coinsCiphertext.)
|
||||
|
||||
\item $\vmacs$ which is a $\NOld$ size sequence of message authentication tags
|
||||
$\h{1..\NOld}$ that bind $\hSig$ to each $\SpendAuthorityPrivate$ of the
|
||||
|
@ -574,23 +600,32 @@ $\PourDescription$.
|
|||
|
||||
\subparagraph{Merkle root validity}
|
||||
|
||||
A $\PourDescription$ is valid if $\rt$ is a Coin commitment tree root found in
|
||||
either the blockchain or a merkle root produced by inserting the Coin commitments
|
||||
of a previous $\PourDescription$ in the transaction to the Coin commitment tree
|
||||
A \PourDescription is valid if $\rt$ is a \coinCommitmentTree root found in
|
||||
either the blockchain or a merkle root produced by inserting the \coinCommitments
|
||||
of a previous $\PourDescription$ in the transaction to the \coinCommitmentTree
|
||||
identified by that previous $\PourDescription$'s $\anchor$.
|
||||
|
||||
\subparagraph{Non-malleability}
|
||||
|
||||
A $\PourDescription$ is valid if the script formed by appending $\scriptPubKey$ to
|
||||
A \PourDescription is valid if the script formed by appending $\scriptPubKey$ to
|
||||
$\scriptSig$ returns $true$. The $\scriptSig$ is cryptographically bound to
|
||||
$\PourProof$.
|
||||
|
||||
\subparagraph{Balance}
|
||||
|
||||
A \PourTransfer can be seen, from the perspective of the transaction, as an
|
||||
input and an output simultaneously. $\vpubOld$ takes value from the value pool and
|
||||
$\vpubNew$ adds value to the value pool. As a result, $\vpubOld$ is treated like an
|
||||
\emph{output} value, whereas $\vpubNew$ is treated like an \emph{input} value.
|
||||
A \PourTransfer can be seen, from the perspective of the transaction, 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
|
||||
\emph{input} value.
|
||||
|
||||
\changed{
|
||||
Note that unlike original \Zerocash \cite{ZerocashOakland}, \Zcash does not have
|
||||
a distinction between Mint and Pour transfers. The addition of $\vpubOld$ to a
|
||||
\PourDescription subsumes the functionality of Mint. Also, \PourDescriptions
|
||||
are indistinguishable regardless of the number of real input \coins.
|
||||
}
|
||||
|
||||
\subparagraph{Commitments and Serials}
|
||||
|
||||
|
@ -606,10 +641,10 @@ exists in the map.
|
|||
In \Zcash, $\NOld$ and $\NNew$ are both $2$.
|
||||
|
||||
A valid instance of $\PourProof$ assures that given a \term{primary input}
|
||||
$(\rt, \snOld{1..\NOld}, \cmNew{1..\NNew}, \vpubOld, \vpubNew, \hSig, \h{1..\NOld})$,
|
||||
a witness of \term{auxiliary input}
|
||||
$(\treepath{1..\NOld}, \cOld{1..\NOld}, \SpendAuthorityPrivateOld{1..\NOld}, \cNew{1..\NNew})$
|
||||
exists, where:
|
||||
$(\rt, \snOld{\mathrm{1}..\NOld}, \cmNew{1..\NNew}, \changed{\vpubOld,\;}
|
||||
\vpubNew, \hSig, \h{1..\NOld})$, a witness of \term{auxiliary input}
|
||||
$(\treepath{1..\NOld}, \cOld{1..\NOld}, \SpendAuthorityPrivateOld{\mathrm{1}..\NOld},
|
||||
\cNew{1..\NNew})$ exists, where:
|
||||
|
||||
\begin{list}{}{}
|
||||
|
||||
|
@ -625,13 +660,13 @@ exists, where:
|
|||
|
||||
\subparagraph{Merkle path validity}
|
||||
|
||||
for each $i \in \{1..\NOld\}$ $\mid$ $\vOld{i} \neq 0$: $\treepath{i}$ must be a valid path
|
||||
for each $i \in \{1..\NOld\}$ \changed{$\mid$ $\vOld{i} \neq 0$}: $\treepath{i}$ must be a valid path
|
||||
of depth $\MerkleDepth$ from \linebreak $\CoinCommitment{\cOld{i}}$ to Coin
|
||||
commitment merkle tree root $\rt$.
|
||||
|
||||
\subparagraph{Balance}
|
||||
|
||||
$\vpubOld + \vsum{i=1}{\NOld} \vOld{i} = \vpubNew + \vsum{i=1}{\NNew} \vNew{i}$.
|
||||
$\changed{\vpubOld +} \vsum{i=1}{\NOld} \vOld{i} = \vpubNew + \vsum{i=1}{\NNew} \vNew{i}$.
|
||||
|
||||
\subparagraph{Serial integrity}
|
||||
|
||||
|
@ -678,8 +713,8 @@ These are encoded in the same way as in \Bitcoin \cite{Base58Check}.
|
|||
|
||||
A \publicAddress consists of $\SpendAuthorityPublic$ and $\TransmitPublic$.
|
||||
$\SpendAuthorityPublic$ is a SHA-256 compression function output.
|
||||
$\TransmitPublic$ is a Curve25519 public key, for use with the encryption
|
||||
scheme defined in section ``In-band secret distribution".
|
||||
$\TransmitPublic$ is a \changed{Curve25519} public key, for use with the
|
||||
encryption scheme defined in section ``In-band secret distribution".
|
||||
|
||||
\subsubsection{Raw Encoding}
|
||||
|
||||
|
@ -687,18 +722,20 @@ The raw encoding of a confidential address consists of:
|
|||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.07em]{520}
|
||||
\bitbox{48}{$\PublicAddressLeadByte$} &
|
||||
\bitbox{48}{\changed{$\PublicAddressLeadByte$}} &
|
||||
\bitbox{256}{$\SpendAuthorityPublic$ (32 bytes)} &
|
||||
\bitbox{256}{A 32-byte encoding of $\TransmitPublic$}
|
||||
\bitbox{256}{A \changed{32-byte} encoding of $\TransmitPublic$}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\begin{itemize}
|
||||
\changed{
|
||||
\item A byte, $\PublicAddressLeadByte$, indicating this version of the
|
||||
raw encoding of a \Zcash public address.
|
||||
}
|
||||
\item 32 bytes specifying $\SpendAuthorityPublic$.
|
||||
\item 32 bytes specifying $\TransmitPublic$, using the normal encoding
|
||||
of a Curve25519 public key \cite{Curve25519}.
|
||||
\item \changed{32 bytes} specifying $\TransmitPublic$, \changed{using the
|
||||
normal encoding of a Curve25519 public key \cite{Curve25519}}.
|
||||
\end{itemize}
|
||||
|
||||
\daira{check that this lead byte is distinct from other Bitcoin stuff,
|
||||
|
@ -710,8 +747,8 @@ and produces `z' as the Base58Check leading character.}
|
|||
|
||||
A confidential address secret consists of $\SpendAuthorityPrivate$ and
|
||||
$\TransmitPrivate$. $\SpendAuthorityPrivate$ is a SHA-256 compression function
|
||||
output. $\TransmitPrivate$ is a Curve25519 private key, for use with the
|
||||
encryption scheme defined in section ``In-band secret distribution".
|
||||
output. $\TransmitPrivate$ is a \changed{Curve25519} private key, for use with
|
||||
the encryption scheme defined in section ``In-band secret distribution".
|
||||
|
||||
\subsubsection{Raw Encoding}
|
||||
|
||||
|
@ -719,15 +756,17 @@ The raw encoding of a confidential address secret consists of, in order:
|
|||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.07em]{520}
|
||||
\bitbox{48}{$\PrivateAddressLeadByte$} &
|
||||
\bitbox{48}{\changed{$\PrivateAddressLeadByte$}} &
|
||||
\bitbox{256}{$\SpendAuthorityPrivate$ (32 bytes)} &
|
||||
\bitbox{256}{$\TransmitPrivate$ (32 bytes)}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\begin{itemize}
|
||||
\changed{
|
||||
\item A byte $\PrivateAddressLeadByte$ indicating this version of the
|
||||
raw encoding of a \Zcash private key.
|
||||
}
|
||||
\item 32 bytes specifying $\SpendAuthorityPrivate$.
|
||||
\item 32 bytes specifying $\TransmitPrivate$.
|
||||
\end{itemize}
|
||||
|
@ -743,10 +782,10 @@ Transmitted coins are stored on the blockchain in encrypted form, together with
|
|||
a \coinCommitment $\cm$.
|
||||
|
||||
The \coinPlaintexts associated with a \PourDescription are encrypted to the
|
||||
respective \transmitPublicAlgorithm keys $\TransmitPublicNew{1..\NNew}$, and the
|
||||
result forms a \coinsCiphertext.
|
||||
respective \transmitPublicAlgorithm keys $\TransmitPublicNew{\mathrm{1}..\NNew}$,
|
||||
and the result forms a \coinsCiphertext.
|
||||
|
||||
Each \coinPlaintext consists of $(\Value, \CoinAddressRand, \CoinCommitRand, \Memo)$,
|
||||
Each \coinPlaintext consists of $(\Value, \CoinAddressRand, \CoinCommitRand\changed{, \Memo})$,
|
||||
where:
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -754,9 +793,12 @@ where:
|
|||
\coin in \zatoshi (1 \ZEC = $10^8$ \zatoshi).
|
||||
\item $\CoinAddressRand$ is a 32-byte $\PRFsn{\SpendAuthorityPrivate}$ preimage.
|
||||
\item $\CoinCommitRand$ is a 48-byte \COMMtrapdoor.
|
||||
\changed{
|
||||
\item $\Memo$ is a 64-byte \memo associated with this \coin.
|
||||
}
|
||||
\end{itemize}
|
||||
|
||||
\changed{
|
||||
The usage of the $\memo$ is by agreement between the sender and recipient of the
|
||||
\coin. It should be encoded as a UTF-8 human-readable string \cite{Unicode}, padded
|
||||
with zero bytes. Wallet software is expected to strip any trailing zero bytes and
|
||||
|
@ -764,6 +806,7 @@ then display the resulting UTF-8 string to the recipient user, where applicable.
|
|||
Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters
|
||||
(\ReplacementCharacter). This does not preclude uses of the \memo by automated
|
||||
software, but specification of such usage is not in the scope of this document.
|
||||
}
|
||||
|
||||
Note that the value $\CoinCommitS$ described as being part of a \coin in the
|
||||
\Zerocash paper is not encoded because the instantiation of $\COMM{\CoinCommitS}$
|
||||
|
@ -775,32 +818,39 @@ The raw encoding of a \coinPlaintext consists of, in order:
|
|||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.035em]{1224}
|
||||
\bitbox{80}{$\TransmitPlaintextVersionByte$} &
|
||||
\bitbox{80}{\changed{$\TransmitPlaintextVersionByte$}} &
|
||||
\bitbox{144}{$\Value$ (8 bytes)} &
|
||||
\bitbox{256}{$\CoinAddressRand$ (32 bytes)} &
|
||||
\bitbox{384}{$\CoinCommitRand$ (48 bytes)} &
|
||||
\bitbox{512}{$\Memo$ (64 bytes)}
|
||||
\changed{\bitbox{512}{$\Memo$ (64 bytes)}}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\begin{itemize}
|
||||
\changed{
|
||||
\item A byte $\TransmitPlaintextVersionByte$ indicating this version of the raw
|
||||
encoding of a \coinPlaintext.
|
||||
}
|
||||
\item 8 bytes specifying a big-endian encoding of $\Value$.
|
||||
\item 32 bytes specifying $\CoinAddressRand$.
|
||||
\item 48 bytes specifying $\CoinCommitRand$.
|
||||
\changed{
|
||||
\item 64 bytes specifying $\Memo$.
|
||||
}
|
||||
\end{itemize}
|
||||
|
||||
\section{Pours (within a transaction on the blockchain)}
|
||||
|
||||
TBD.
|
||||
|
||||
\changed{Describe case where there are fewer than $\NOld$ real input coins.}
|
||||
|
||||
\section{Transactions}
|
||||
|
||||
TBD.
|
||||
|
||||
|
||||
\changed{
|
||||
\section{Differences from the Zerocash paper}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -814,6 +864,7 @@ This is just a clarification, because the instantiation of $\COMM{\CoinCommitS}$
|
|||
in section 5.1 of the paper does not use $\CoinCommitS$, and $\cm$ can be computed
|
||||
from the other fields.
|
||||
\end{itemize}
|
||||
}
|
||||
|
||||
|
||||
\section{References}
|
||||
|
|
Loading…
Reference in New Issue