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

Cosmetics. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2018-06-04 17:10:49 +01:00
parent ce35640ec0
commit 11163742b7
1 changed files with 30 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
protocol/protocol.tex
View File

@ -396,7 +396,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\ALLCAPS}{\conformance{ALL CAPS}} \newcommand{\ALLCAPS}{\conformance{ALL CAPS}}
\newcommand{\collisionResistant}{collision\hyp resistant } \newcommand{\collisionResistant}{collision\hyp resistant }
\newcommand{\collisionResistance}{collision\hyp resistance } \newcommand{\collisionResistance}{collision resistance }
\newcommand{\note}{\term{note}} \newcommand{\note}{\term{note}}
\newcommand{\notes}{\term{notes}} \newcommand{\notes}{\term{notes}}
@ -2874,11 +2874,11 @@ with $\KASapling$ and derives keys for $\SymEncrypt{}$.
} %sapling } %sapling
\begin{securityrequirements} \begin{securityrequirements}
\item The asymmetric encryption scheme in \crossref{sproutinband} constructed \item The asymmetric encryption scheme in \crossref{sproutinband}, constructed
from $\KASprout$, $\KDFSprout$ and $\Sym$, is required to be IND-CCA2-secure from $\KASprout$, $\KDFSprout$ and $\Sym$, is required to be IND-CCA2-secure
and key-private. and key-private.
\item \sapling{ \item \sapling{
The asymmetric encryption scheme in \crossref{saplinginband} constructed The asymmetric encryption scheme in \crossref{saplinginband}, constructed
from $\KASapling$, $\KDFSapling$ and $\Sym$, is required to be IND-CCA2-secure from $\KASapling$, $\KDFSapling$ and $\Sym$, is required to be IND-CCA2-secure
and key-private. and key-private.
} %sapling } %sapling
@ -3372,6 +3372,7 @@ the \statement;
\item a verifying algorithm $\ZKVerify{} \typecolon \ZKVerifyingKey \times \ZKPrimary \times \ZKProof \rightarrow \bit$; \item a verifying algorithm $\ZKVerify{} \typecolon \ZKVerifyingKey \times \ZKPrimary \times \ZKProof \rightarrow \bit$;
\end{itemize} \end{itemize}
\introlist
The security requirements below are supposed to hold with overwhelming The security requirements below are supposed to hold with overwhelming
probability for $(\pk, \vk) \leftarrowR \ZKGen()$. probability for $(\pk, \vk) \leftarrowR \ZKGen()$.
@ -3471,6 +3472,7 @@ Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concretep
Let $\KASprout$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}. Let $\KASprout$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}.
\vspace{0.5ex}
A new \SproutOrNothing \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence A new \SproutOrNothing \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence
uniformly at random from $\bitseq{\AuthPrivateLength}$. uniformly at random from $\bitseq{\AuthPrivateLength}$.
@ -3480,6 +3482,7 @@ $\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived from
$\AuthPrivate$ $\AuthPrivate$
as follows:} as follows:}
\vspace{-0.5ex}
\begin{tabular}{@{\hskip 2em}r@{\;}l} \begin{tabular}{@{\hskip 2em}r@{\;}l}
$\AuthPublic$ &$:= \changed{\PRFaddr{\AuthPrivate}(0)}$ \\ $\AuthPublic$ &$:= \changed{\PRFaddr{\AuthPrivate}(0)}$ \\
$\TransmitPrivate$ &$:= \changed{\KASproutFormatPrivate(\PRFaddr{\AuthPrivate}(1))}$ \\ $\TransmitPrivate$ &$:= \changed{\KASproutFormatPrivate(\PRFaddr{\AuthPrivate}(1))}$ \\
@ -3538,9 +3541,10 @@ are derived as follows:
\end{lrbox} \end{lrbox}
\sapling{ \sapling{
\introlist \vspace{1ex}
$\AuthSignPublic$, $\AuthProvePublic$, and $\InViewingKey$ are then derived as: $\AuthSignPublic$, $\AuthProvePublic$, and $\InViewingKey$ are then derived as:
\vspace{-0.5ex}
\begin{tabular}{@{\hskip 1.7em}r@{\;}l} \begin{tabular}{@{\hskip 1.7em}r@{\;}l}
$\AuthSignPublic$ &$:= \SpendAuthSigDerivePublic(\AuthSignPrivate)$ \\ $\AuthSignPublic$ &$:= \SpendAuthSigDerivePublic(\AuthSignPrivate)$ \\
$\AuthProvePublic$ &$:= \scalarmult{\AuthProvePrivate}{\AuthProveBase}$ \\ $\AuthProvePublic$ &$:= \scalarmult{\AuthProvePrivate}{\AuthProveBase}$ \\
@ -3647,8 +3651,7 @@ $\JoinSplitSig$ public verification key and signature.
\introlist \introlist
A \joinSplitDescription consists of $(\vpubOld, \vpubNew, \rt, \nfOld{\allOld}, A \joinSplitDescription consists of $(\vpubOld, \vpubNew, \rt, \nfOld{\allOld},
\cmNew{\allNew}, \EphemeralPublic, \RandomSeed, \h{\allOld}, \ProofJoinSplit, \cmNew{\allNew}, \EphemeralPublic, \RandomSeed, \h{\allOld}, \ProofJoinSplit,
\TransmitCiphertext{\allNew})$ \TransmitCiphertext{\allNew})$ \\
where where
\begin{itemize} \begin{itemize}
\item \changed{$\vpubOld \typecolon \range{0}{\MAXMONEY}$ is \item \changed{$\vpubOld \typecolon \range{0}{\MAXMONEY}$ is
@ -3697,8 +3700,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}.
above (for example: $0 \leq \vpubOld \leq \MAXMONEY$ and $0 \leq \vpubNew \leq \MAXMONEY$). above (for example: $0 \leq \vpubOld \leq \MAXMONEY$ and $0 \leq \vpubNew \leq \MAXMONEY$).
\item Either $\vpubOld$ or $\vpubNew$ \MUST be zero. \item Either $\vpubOld$ or $\vpubNew$ \MUST be zero.
\item The proof $\Proof{\JoinSplit}$ \MUST be valid given a \primaryInput formed \item The proof $\Proof{\JoinSplit}$ \MUST be valid given a \primaryInput formed
from the relevant other fields and $\hSig$. from the relevant other fields and $\hSig$ --- i.e.\ $\JoinSplitVerify{}((\rt, \nfOld{\allOld},
I.e.\ it must be the case that $\JoinSplitVerify{}((\rt, \nfOld{\allOld},
\cmNew{\allNew},\changed{\vpubOld,} \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}) = 1$. \cmNew{\allNew},\changed{\vpubOld,} \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}) = 1$.
\end{consensusrules} \end{consensusrules}
@ -3719,8 +3721,8 @@ Let $\ValueCommitOutput$ be as defined in \crossref{abstractcommit}.
\introlist \introlist
A \spendDescription consists of $(\cv, \rt, \nf, \AuthSignRandomizedPublic, \ProofSpend, \spendAuthSig)$ A \spendDescription consists of $(\cv, \rt, \nf, \AuthSignRandomizedPublic, \ProofSpend, \spendAuthSig)$
where where
\vspace{1ex}
\begin{itemize} \begin{itemize}
\item $\cv \typecolon \ValueCommitOutput$ is the \valueCommitment to the value of the input \note; \item $\cv \typecolon \ValueCommitOutput$ is the \valueCommitment to the value of the input \note;
\item $\rt \typecolon \MerkleHashSapling$ is an \anchor, as defined in \item $\rt \typecolon \MerkleHashSapling$ is an \anchor, as defined in
@ -3761,8 +3763,8 @@ There are no signatures associated with \outputDescriptions.
\introlist \introlist
An \outputDescription consists of $(\cv, \cmU, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \ProofOutput)$ An \outputDescription consists of $(\cv, \cmU, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \ProofOutput)$
where where
\vspace{1ex}
\begin{itemize} \begin{itemize}
\item $\cv \typecolon \ValueCommitOutput$ is the \valueCommitment to the value of the output \note; \item $\cv \typecolon \ValueCommitOutput$ is the \valueCommitment to the value of the output \note;
\item $\cmU \typecolon \MerkleHashSapling$ is the result of applying $\ExtractJ$ (defined \item $\cmU \typecolon \MerkleHashSapling$ is the result of applying $\ExtractJ$ (defined
@ -3782,8 +3784,8 @@ where
\begin{consensusrules} \begin{consensusrules}
\item Elements of an \outputDescription{} \MUST have the types given above. \item Elements of an \outputDescription{} \MUST have the types given above.
\item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed
from the other fields except $\TransmitCiphertext{}$ and $\OutCiphertext{}$. from the other fields except $\TransmitCiphertext{}$ and $\OutCiphertext{}$ ---
I.e.\ it must be the case that $\SpendVerify{}((\cv, \cm, \EphemeralPublic), \Proof{\Output}) = 1$. i.e.\ $\SpendVerify{}((\cv, \cm, \EphemeralPublic), \Proof{\Output}) = 1$.
\end{consensusrules} \end{consensusrules}
} %sapling } %sapling
@ -4081,6 +4083,7 @@ all of the $\AuthPrivateOld{\allOld}$ for every \joinSplitDescription in the
to $\joinSplitPubKey$ to sign this \transaction. to $\joinSplitPubKey$ to sign this \transaction.
\introsection
\subsection{Balance\pSproutOrNothing} \label{joinsplitbalance} \subsection{Balance\pSproutOrNothing} \label{joinsplitbalance}
In \Bitcoin, all inputs to and outputs from a \transaction are transparent. In \Bitcoin, all inputs to and outputs from a \transaction are transparent.
@ -4191,6 +4194,7 @@ Instead, validators calculate the \txBindingVerificationKey as:
(This key is not encoded explicitly in the \transaction and must be recalculated.) (This key is not encoded explicitly in the \transaction and must be recalculated.)
\introlist \introlist
\vspace{1ex}
The signer knows $\ValueCommitRandOld{\alln}$ and $\ValueCommitRandNew{\allm}$, and so can The signer knows $\ValueCommitRandOld{\alln}$ and $\ValueCommitRandNew{\allm}$, and so can
calculate the corresponding signing key as: calculate the corresponding signing key as:
\begin{formulae} \begin{formulae}
@ -4249,6 +4253,7 @@ $\BindingPrivate'$ (as needed to create a valid \bindingSignature), then $(\vBad
and $(0, \BindingPrivate')$ would be distinct openings of $\BindingPublic$ to different values, and $(0, \BindingPrivate')$ would be distinct openings of $\BindingPublic$ to different values,
breaking the binding property of the \valueCommitmentScheme. breaking the binding property of the \valueCommitmentScheme.
\introlist
The above argument shows only that $\Value^* = 0 \pmod{\ParamJ{r}}$; in order to show that The above argument shows only that $\Value^* = 0 \pmod{\ParamJ{r}}$; in order to show that
$\vSum = 0$, we also need to demonstrate that it does not overflow $\ValueCommitType$. $\vSum = 0$, we also need to demonstrate that it does not overflow $\ValueCommitType$.
@ -4264,7 +4269,6 @@ the individual values of the \spendDescriptions and \outputDescriptions being re
In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em-sum of the \valueCommitment In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em-sum of the \valueCommitment
randomnesses, authorized a \transaction with the given \sighashTxHash by signing $\SigHash$. randomnesses, authorized a \transaction with the given \sighashTxHash by signing $\SigHash$.
\vspace{-1ex}
\pnote{ \pnote{
The spender \MAY reveal any strict subset of the \valueCommitment randomnesses to The spender \MAY reveal any strict subset of the \valueCommitment randomnesses to
other parties that are cooperating to create the \transaction. If all of the other parties that are cooperating to create the \transaction. If all of the
@ -4272,7 +4276,6 @@ other parties that are cooperating to create the \transaction. If all of the
\outputDescriptions of the \transaction. \outputDescriptions of the \transaction.
} %pnote } %pnote
\vspace{-1ex}
\nnote{ \nnote{
The technique of checking signatures using a public key derived from a sum of The technique of checking signatures using a public key derived from a sum of
\xPedersenCommitments is also used in the \Mimblewimble protocol \cite{Jedusor2016}. \xPedersenCommitments is also used in the \Mimblewimble protocol \cite{Jedusor2016}.
@ -4292,6 +4295,7 @@ The motivation for a separate signature is to allow devices that are limited in
and computational capacity, such as hardware wallets, to authorize a shielded spend. and computational capacity, such as hardware wallets, to authorize a shielded spend.
Typically such devices cannot create, and may not be able to verify, \zkSNARKProofs. Typically such devices cannot create, and may not be able to verify, \zkSNARKProofs.
\vspace{2ex}
The verifying key of the signature must be revealed in the \spendDescription so that The verifying key of the signature must be revealed in the \spendDescription so that
the signature can be checked by validators. To ensure that the verifying key cannot the signature can be checked by validators. To ensure that the verifying key cannot
be linked to the \paymentAddress or \spendingKey from which the \note was spent, we be linked to the \paymentAddress or \spendingKey from which the \note was spent, we
@ -4318,6 +4322,7 @@ For each \spendDescription, the signer uses a fresh \spendAuthRandomizer $\AuthS
\item Let $\spendAuthSig = \SpendAuthSigSign{\AuthSignRandomizedPrivate}(\SigHash)$. \item Let $\spendAuthSig = \SpendAuthSigSign{\AuthSignRandomizedPrivate}(\SigHash)$.
\end{enumerate} \end{enumerate}
\introlist
The $\spendAuthSig$ and $\ProofSpend$ are included in the \spendDescription. The $\spendAuthSig$ and $\ProofSpend$ are included in the \spendDescription.
\pnote{ \pnote{
@ -4343,9 +4348,11 @@ All of the constituent \nullifiers are also entered into the
would have added a \nullifier to the \nullifierSet that already exists in the set would have added a \nullifier to the \nullifierSet that already exists in the set
(see \crossref{nullifierset}). (see \crossref{nullifierset}).
\vspace{2ex}
\sprout{Each}\notsprout{In \Sprout, each} \note has a $\NoteAddressRand$ component. \sprout{Each}\notsprout{In \Sprout, each} \note has a $\NoteAddressRand$ component.
\sapling{ \sapling{
\vspace{2ex}
\introlist \introlist
In \Sapling, each \positionedNote has an associated $\NoteAddressRand$ value which In \Sapling, each \positionedNote has an associated $\NoteAddressRand$ value which
is computed from its \noteCommitment $\cm$ and \notePosition $\NotePosition$ is computed from its \noteCommitment $\cm$ and \notePosition $\NotePosition$
@ -4358,8 +4365,10 @@ as follows:
$\MixingPedersenHash$ is defined in \crossref{concretemixinghash}. $\MixingPedersenHash$ is defined in \crossref{concretemixinghash}.
} %sapling } %sapling
\vspace{2ex}
Let $\PRFnf{}{}$\sapling{ and $\PRFnfSapling{}{}$} be as instantiated in \crossref{concreteprfs}. Let $\PRFnf{}{}$\sapling{ and $\PRFnfSapling{}{}$} be as instantiated in \crossref{concreteprfs}.
\vspace{2ex}
\sprout{The \nullifier of a \note}\notsprout{For a \Sprout{} \note, the \nullifier} \sprout{The \nullifier of a \note}\notsprout{For a \Sprout{} \note, the \nullifier}
is derived as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$, where $\AuthPrivate$ is the is derived as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$, where $\AuthPrivate$ is the
\spendingKey associated with the \note. \spendingKey associated with the \note.
@ -4554,7 +4563,7 @@ $\DiversifiedTransmitPublic = \scalarmult{\InViewingKey}{\DiversifiedTransmitBas
\begin{formulae} \begin{formulae}
\item $\InViewingKey = \CRHivk(\AuthSignPublicRepr, \AuthProvePublicRepr)$ \item $\InViewingKey = \CRHivk(\AuthSignPublicRepr, \AuthProvePublicRepr)$
\vspace{-1ex} \vspace{-1ex}
\item $\AuthSignPublicRepr = \reprJOf{\AuthSignPublic}$. \item $\AuthSignPublicRepr = \reprJOf{\AuthSignPublic}$\,.
\end{formulae} \end{formulae}
\vspace{1ex} \vspace{1ex}
@ -5412,6 +5421,7 @@ Define
\item $\DiversifyHash(\Diversifier) := \GroupJHash{\NotUpMySleeve}(\ascii{Zcash\_gd}, \LEBStoOSPOf{\DiversifierLength}{\Diversifier})$ \item $\DiversifyHash(\Diversifier) := \GroupJHash{\NotUpMySleeve}(\ascii{Zcash\_gd}, \LEBStoOSPOf{\DiversifierLength}{\Diversifier})$
\end{formulae} \end{formulae}
\vspace{-2ex}
\securityrequirement{ \securityrequirement{
$\DiversifyHash$ must satisfy the Discrete Logarithm Independence property $\DiversifyHash$ must satisfy the Discrete Logarithm Independence property
described in \crossref{abstractgrouphash}. described in \crossref{abstractgrouphash}.
@ -5423,7 +5433,7 @@ described in \crossref{abstractgrouphash}.
\introlist \introlist
\subsubsubsection{\PedersenHashFunction} \label{concretepedersenhash} \subsubsubsection{\PedersenHashFunction} \label{concretepedersenhash}
$\PedersenHash$ is an algebraic hash function with collision resistance $\PedersenHash$ is an algebraic \hashFunction with \collisionResistance
(for fixed input length) derived from assumed hardness of the (for fixed input length) derived from assumed hardness of the
Discrete Logarithm Problem on the \jubjubCurve. Discrete Logarithm Problem on the \jubjubCurve.
It is based on the work of David Chaum, Ivan Damgård, Jeroen van de Graaf, It is based on the work of David Chaum, Ivan Damgård, Jeroen van de Graaf,
@ -6181,7 +6191,7 @@ $\BindingSig$ and $\SpendAuthSig$.
Let $\RedJubjub$ be as defined in \crossref{concreteredjubjub}. Let $\RedJubjub$ be as defined in \crossref{concreteredjubjub}.
Let $\AuthSignBase = \FindGroupJHashOf{\ascii{Zcash\_G\_}, \ascii{}}$. Define $\AuthSignBase := \FindGroupJHashOf{\ascii{Zcash\_G\_}, \ascii{}}$.
$\SpendAuthSig$ is instantiated as $\RedJubjub$ with key re-randomization, and $\SpendAuthSig$ is instantiated as $\RedJubjub$ with key re-randomization, and
with generator $\GenG{} = \AuthSignBase$. with generator $\GenG{} = \AuthSignBase$.
@ -6645,6 +6655,7 @@ $\GroupJ$ has order $\ParamJ{h} \smult \ParamJ{r}$.
Let $\ellJ := 256$. Let $\ellJ := 256$.
\introlist
Define $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$ Define $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$
as in \crossref{endian}. as in \crossref{endian}.
@ -8359,7 +8370,7 @@ as its $\scriptPubKey$.
\subsection{Changes to the Script System} \label{scripts} \subsection{Changes to the Script System} \label{scripts}
The \ScriptOP{CODESEPARATOR} opcode has been disabled. This opcode also no longer The \ScriptOP{CODESEPARATOR} opcode has been disabled. This opcode also no longer
affects the calculation of signature hashes. affects the calculation of \sighashTxHashes.
\subsection{Bitcoin Improvement Proposals} \label{bips} \subsection{Bitcoin Improvement Proposals} \label{bips}
@ -9484,7 +9495,7 @@ found by Brian Warner.
and reencode the testnet \foundersReward addresses. and reencode the testnet \foundersReward addresses.
\item Add a section on which BIPs apply to \Zcash. \item Add a section on which BIPs apply to \Zcash.
\item Specify that \ScriptOP{CODESEPARATOR} has been disabled, and \item Specify that \ScriptOP{CODESEPARATOR} has been disabled, and
no longer affects signature hashes. no longer affects \sighashTxHashes.
\item Change the representation type of $\vpubOldField$ and $\vpubNewField$ \item Change the representation type of $\vpubOldField$ and $\vpubNewField$
to \type{uint64}. (This is not a consensus change because the type of to \type{uint64}. (This is not a consensus change because the type of
$\vpubOld$ and $\vpubNew$ was already specified to be $\range{0}{\MAXMONEY}$; $\vpubOld$ and $\vpubNew$ was already specified to be $\range{0}{\MAXMONEY}$;