Improve description of key structures taking into account ZIP 32. fixes #187

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-05-27 15:53:09 +01:00
parent 3ce628ab73
commit c8e08b0e96
1 changed files with 39 additions and 17 deletions

View File

@ -961,6 +961,10 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\spendingKey}{\term{spending key}}
\newcommand{\spendingKeys}{\terms{spending key}}
\newcommand{\SpendingKeys}{\titleterms{Spending Key}}
\newcommand{\expandedSpendingKey}{\term{expanded spending key}}
\newcommand{\expandedSpendingKeys}{\terms{expanded spending key}}
\newcommand{\extendedSpendingKey}{\term{extended spending key}}
\newcommand{\extendedSpendingKeys}{\terms{extended spending key}}
\newcommand{\payingKey}{\term{paying key}}
\newcommand{\transmissionKey}{\term{transmission key}}
\newcommand{\transmissionKeys}{\terms{transmission key}}
@ -974,8 +978,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\authRandomizedVerifyingKeys}{\terms{randomized spend verifying key}}
\newcommand{\authProvingKey}{\term{proof authorizing key}}
\newcommand{\authProvingKeys}{\terms{proof authorizing key}}
\newcommand{\authNullifierKey}{\term{nullifier private key}}
\newcommand{\authNullifierKeys}{\terms{nullifier private key}}
\newcommand{\nullifierKey}{\term{nullifier deriving key}}
\newcommand{\nullifierKeys}{\terms{nullifier deriving key}}
\newcommand{\hdWallet}{\term{Hierarchical Deterministic Wallet}}
\newcommand{\humanReadablePart}{\term{Human-Readable Part}}
\newcommand{\notePlaintext}{\term{note plaintext}}
\newcommand{\notePlaintexts}{\terms{note plaintext}}
@ -2602,11 +2609,8 @@ coordinates (see \crossref{jubjub}).
\lsubsection{Payment Addresses and Keys}{addressesandkeys}
\defining{Users who wish to receive payments in the \Zcash protocol first generate a
random \spendingKey\sprout{ $\AuthPrivate$}.}
\notsprout{In \Sprout this is called $\AuthPrivate$ \sapling{and in \Sapling it is
called $\SpendingKey$.\footnote{\sapling{The current \zcashd implementation actually uses
``extended spending keys'' --defined in \cite{ZIP-32}-- instead for \Sapling.}}}}
\defining{Users who wish to receive payments in the \Zcash protocol must have a
\paymentAddress, which is generated from a \spendingKey.}
\introlist
The following diagram depicts the relations between key
@ -2621,27 +2625,44 @@ abstractions.
\end{center}
\sproutspecific{
\defining{The \receivingKey $\TransmitPrivate$, the \incomingViewingKey
$\InViewingKey = (\AuthPublic, \TransmitPrivate)$, and the \paymentAddress
$\PaymentAddress = (\AuthPublic, \TransmitPublic)$ are derived from
$\AuthPrivate$, as described in \crossref{sproutkeycomponents}.}
\defining{The \receivingKey $\TransmitPrivate$, \incomingViewingKey
$\InViewingKey = (\AuthPublic, \TransmitPrivate)$, and \paymentAddress
$\PaymentAddress = (\AuthPublic, \TransmitPublic)$ are derived from the
\spendingKey $\AuthPrivate$, as described in \crossref{sproutkeycomponents}.}
} %sproutspecific
\saplingonward{
\defining{The \authSigningKey $\AuthSignPrivate$,
\authProvingKey $(\AuthSignPublic, \AuthProvePrivate)$,
\fullViewingKey $(\AuthSignPublic, \AuthProvePublic, \OutViewingKey)$,
\incomingViewingKey $\InViewingKey$, and
each \diversifiedPaymentAddress $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$
are derived from $\SpendingKey$, as described in \crossref{saplingkeycomponents}.}
\defining{An \expandedSpendingKey is composed of a \authSigningKey $\AuthSignPrivate$,
a \authNullifierKey $\AuthProvePrivate$, and an \outgoingViewingKey $\OutViewingKey$.
From these components we can derive an \authProvingKey $(\AuthSignPublic, \AuthProvePrivate)$,
a \fullViewingKey $(\AuthSignPublic, \AuthProvePublic, \OutViewingKey)$,
an \incomingViewingKey $\InViewingKey$, and a set of \diversifiedPaymentAddresses
$\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$,
as described in \crossref{saplingkeycomponents}.
The consensus protocol does not depend on how an \expandedSpendingKey is constructed.
Two methods of doing so are defined:
\begin{enumerate}
\item Generate a \spendingKey $\SpendingKey$ at random and derive the \expandedSpendingKey
$(\AuthSignPrivate, \AuthProvePrivate, \OutViewingKey)$ from it, as shown in the
diagram above and described in \crossref{saplingkeycomponents}.
\item Obtain an \extendedSpendingKey as specified in \cite{ZIP-32}; this includes a superset
of the components of an \expandedSpendingKey. This method is used in the context of a
\hdWallet.
\end{enumerate}
} %saplingonward
\vspace{-2ex}
\nnote{In \zcashd, all \Sapling keys and addresses are derived according to \cite{ZIP-32}.}
} %saplingonward
\vspace{2ex}
The composition of \paymentAddresses, \changed{\incomingViewingKeys,}
\sapling{\fullViewingKeys,} and \spendingKeys is a cryptographic protocol
detail that should not normally be exposed to users. However, user-visible
operations should be provided to obtain a
\paymentAddress\changed{ or \incomingViewingKey}\sapling{ or \fullViewingKey}
from a \spendingKey.
from a \spendingKey or \extendedSpendingKey.
Users can accept payment from multiple parties with a single \paymentAddress
and the fact that these payments are destined to
@ -10375,6 +10396,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\historyentry{2020.1.4}{}
\begin{itemize}
\item Reference \cite{BIP-32} and \cite{ZIP-32} when describing keys and their encodings.
\item Improve LaTeX portability of this specification.
\end{itemize}
@ -10488,7 +10510,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct the packing of $\nfOld{}$ into input elements in \crossref{cctsaplingspend}.
\item Add an epigraph from \cite{Carroll1876} to the start of \crossref{jubjub}.
\item Clarify how the constant $c$ in \crossref{concretepedersenhash} is obtained.
\item Add a footnote that \zcashd uses \cite{ZIP-32} extended spending keys instead of
\item Add a footnote that \zcashd uses \cite{ZIP-32} \extendedSpendingKeys instead of
the derivation from $\SpendingKey$ in \crossref{addressesandkeys}.
} %sapling
\item Remove ``optimized'' \Makefile targets (which actually produced