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

Delegate to ZIP 316 for the specification of unified payment addresses and unified viewing keys. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-05-07 09:18:18 +01:00
parent 38b740aad2
commit 00c39b73e0
1 changed files with 43 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
protocol/protocol.tex
View File

@ -1031,6 +1031,10 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\shieldedPaymentAddresses}{\termes{shielded payment address}} \newcommand{\shieldedPaymentAddresses}{\termes{shielded payment address}}
\newcommand{\unifiedPaymentAddress}{\term{unified payment address}} \newcommand{\unifiedPaymentAddress}{\term{unified payment address}}
\newcommand{\unifiedPaymentAddresses}{\termes{unified payment address}} \newcommand{\unifiedPaymentAddresses}{\termes{unified payment address}}
\newcommand{\unifiedIncomingViewingKey}{\term{unified incoming viewing key}}
\newcommand{\unifiedIncomingViewingKeys}{\terms{unified incoming viewing key}}
\newcommand{\unifiedFullViewingKey}{\term{unified full viewing key}}
\newcommand{\unifiedFullViewingKeys}{\terms{unified full viewing key}}
\newcommand{\Bech}{\term{Bech32}} \newcommand{\Bech}{\term{Bech32}}
\newcommand{\Bechm}{\term{Bech32m}} \newcommand{\Bechm}{\term{Bech32m}}
\newcommand{\BaseFiftyEightCheck}{\term{Base58Check}} \newcommand{\BaseFiftyEightCheck}{\term{Base58Check}}
@ -11687,79 +11691,50 @@ For \spendingKeys on \Testnet, the \humanReadablePart is \ascii{secret-spending-
\nufive{ \nufive{
\lsubsubsection{Unified and \OrchardText{} Encodings}{orchardencodings} \lsubsubsection{Unified and \OrchardText{} Encodings}{orchardencodings}
\lsubsubsubsection{Unified Payment Addresses}{unifiedpaymentaddrencoding} \vspace{-1ex}
\extralabel{unifiedpaymentaddrencoding}{\lsubsubsubsection{Unified Payment Addresses and Viewing Keys}{unifiedencodings}}
\vspace{-1ex} \vspace{-1ex}
Rather than defining a \Bech string encoding of \Orchard \shieldedPaymentAddresses, we instead define Rather than defining a \Bech string encoding of \Orchard \shieldedPaymentAddresses, we instead define,
a \unifiedPaymentAddress format that is able to encode a set of \paymentAddresses of different in \cite{ZIP-316}, a \unifiedPaymentAddress format that is able to encode a set of \paymentAddresses
types. This enables the consumer of an address to choose the best address type it supports, of different types. This enables the consumer of an address to choose the best address type it supports,
providing a better user experience as new formats are added in the future. providing a better user experience as new formats are added in the future.
\introlist Similarly, \unifiedIncomingViewingKeys and \unifiedFullViewingKeys are defined to encode sets of
Assume that we are given a set of one or more \rawEncodings of \paymentAddresses of distinct \incomingViewingKeys and \fullViewingKeys respectively.
types. That is, the set may optionally contain one of each of the \paymentAddress types
in the following list: Since \cite{ZIP-316} includes a full specification of encoding, decoding, and other processing of
\unifiedPaymentAddresses, \unifiedIncomingViewingKeys, and \unifiedFullViewingKeys, we give only a
summary here.
\introlist
A \unifiedPaymentAddress includes zero or one address of each type in the following Priority List:
\vspace{0.5ex}
\begin{itemize} \begin{itemize}
\item typecode $\hexint{03}$ -- \crossref{orchardpaymentaddrencoding}; \item typecode $\hexint{03}$ -- \crossref{orchardpaymentaddrencoding};
\item typecode $\hexint{02}$ -- \crossref{saplingpaymentaddrencoding}; \item typecode $\hexint{02}$ -- \crossref{saplingpaymentaddrencoding};
\item typecode $\hexint{01}$ -- \transparent P2SH address, \emph{or} typecode $\hexint{00}$ -- \transparent P2PKH address. \item typecode $\hexint{01}$ -- \transparent P2SH address, \emph{or} typecode $\hexint{00}$ -- \transparent P2PKH address.
\end{itemize} \end{itemize}
\vspace{-1.5ex} \vspace{-2ex}
A \unifiedPaymentAddress \MUST contain at least one \shieldedPaymentAddress (typecodes $\geq \hexint{02})$. with the restrictions that there \MUST be at least one \shieldedPaymentAddress (typecodes $\geq \hexint{02})$,
and that both P2SH and P2PKH cannot be present.
\vspace{0.5ex} When sending a payment, the consumer of a \unifiedPaymentAddress \MUST use the most preferred address
The intended semantics is that the consumer of a \unifiedPaymentAddress \SHOULD take the type that it supports from the set, i.e.\ the first in the above list. See \cite{ZIP-316} for additional
``best'' address type that it supports from the set, i.e.\ the first in the requirements, and for discussion of \unifiedIncomingViewingKeys and \unifiedFullViewingKeys.
above list. For example, if the \unifiedPaymentAddress includes an \Orchard address, and
the consumer supports sending funds to \Orchard addresses, and no more recent address
format has been defined at the time of use, then the \Orchard address \SHOULD be used.
The raw encoding of a \unifiedPaymentAddress is a concatenation of Note that there is intentionally no typecode defined for a \Sprout \shieldedPaymentAddress
$(\typecodeField, \lengthField, \addrField)$ encodings of the consituent addresses: (or \Sprout viewing keys).
Since it is no longer possible (since activation of \cite{ZIP-211} in the \Canopy \networkUpgrade)
to send funds into the \Sprout \chainValuePool, this would not be generally useful.
\begin{itemize} The format uses \Bechm \cite{BIP-350} (ignoring any length restrictions) for the checksum
\item $\typecodeField \typecolon \byte$ -- the typecode from the above list; algorithm and string encoding. This is chosen over \Bech in order for the checksum to better
\item $\lengthField \typecolon \byte$ -- the length in bytes of $\addrField$; handle variable-length inputs.
\vspace{-0.5ex}
\item $\addrField \typecolon \byteseq{\text{\scriptsize\lengthField}}$ -- the raw encoding
of a \shieldedPaymentAddress, or the $160$-bit script hash of a P2SH address
\cite{Bitcoin-P2SH}, or the $160$-bit \validatingKey hash of a P2PKH address
\cite{Bitcoin-P2PKH}.
\end{itemize}
\vspace{-1ex} A ``jumbling'' algorithm is used in order to mitigate address replacement attacks given that
The result of the concatenation is then encoded with \Bechm \cite{BIP-350}, ignoring any a user might only check part of the address. See \cite{ZIP-316} for full details.
length restrictions. This is chosen over \Bech in order to better handle variable-length inputs.
\vspace{1ex}
For \unifiedPaymentAddresses on \Mainnet, the \defining{\humanReadablePart} (as defined in
\cite{ZIP-173}) is \ascii{u}. For \unifiedPaymentAddresses on \Testnet, the \humanReadablePart
is \ascii{utest}.
\vspace{1ex}
\begin{pnotes}
\item The $\lengthField$ field is always encoded as a single byte, \emph{not} as a
\type{compactSize}.
\item For \transparentAddresses, the $\addrField$ field does not include the first
two bytes of a \rawEncoding.
\item There is intentionally no typecode defined for a \Sprout \shieldedPaymentAddress.
Since it is no longer possible (since activation of \cite{ZIP-211} in the
\Canopy \networkUpgrade) to send funds into the \Sprout \chainValuePool,
this would not be generally useful.
\item Consumers \MUST ignore constituent addresses with typecodes they do not
recognize.
\item Consumers \MUST reject \unifiedPaymentAddresses in which the same typecode
appears more than once, or that include both P2SH and P2PKH \transparentAddresses,
or that contain only a \transparentAddress.
\item Producers \SHOULD order the constituent addresses in the same order as the
list of address types above. However, consumers \MUSTNOT assume this ordering,
and it does not affect which address should be used by a consumer.
\item There \MUSTNOT be additional bytes at the end of the encoding that cannot be
interpreted as specified above.\!
\end{pnotes}
} %nufive } %nufive
@ -11801,13 +11776,13 @@ When decoding the representation of $\DiversifiedTransmitPublic$, the address \M
considered invalid if $\abstP$ returns $\bot$ or $\ZeroP$. considered invalid if $\abstP$ returns $\bot$ or $\ZeroP$.
There is no \Bech encoding defined for an individual \Orchard \shieldedPaymentAddress; There is no \Bech encoding defined for an individual \Orchard \shieldedPaymentAddress;
instead use a \unifiedPaymentAddress as defined in \crossref{unifiedpaymentaddrencoding}. instead use a \unifiedPaymentAddress as defined in \cite{ZIP-316}.
} %nufive } %nufive
\nufive{ \nufive{
\vspace{-1ex} \vspace{-1ex}
\lsubsubsubsection{\OrchardText{} Incoming Viewing Keys}{orchardinviewingkeyencoding} \lsubsubsubsection{\OrchardText{} Raw Incoming Viewing Keys}{orchardinviewingkeyencoding}
\vspace{-1ex} \vspace{-1ex}
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}. Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.
@ -11840,14 +11815,14 @@ $\InViewingKey$ \MUST be in the range $\InViewingKeyTypeOrchard$ as specified
in \crossref{orchardkeycomponents}. That is, a decoded \incomingViewingKey \MUST be in \crossref{orchardkeycomponents}. That is, a decoded \incomingViewingKey \MUST be
considered invalid if $\InViewingKey$ is not in this range. considered invalid if $\InViewingKey$ is not in this range.
For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zivko}. There is no \Bech encoding defined for an individual \Orchard \incomingViewingKey;
For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zivktestorchard}. instead use a \unifiedIncomingViewingKey as defined in \cite{ZIP-316}.
} %nufive } %nufive
\nufive{ \nufive{
\vspace{-1ex} \vspace{-1ex}
\lsubsubsubsection{\OrchardText{} Full Viewing Keys}{orchardfullviewingkeyencoding} \lsubsubsubsection{\OrchardText{} Raw Full Viewing Keys}{orchardfullviewingkeyencoding}
\vspace{-1ex} \vspace{-1ex}
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}. Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.
@ -11889,8 +11864,8 @@ When decoding this representation, the key \MUST be considered invalid if $\Auth
$\NullifierKey$, or $\CommitIvkRandom$ are not canonically encoded elements of their respective $\NullifierKey$, or $\CommitIvkRandom$ are not canonically encoded elements of their respective
fields, or if $\AuthSignPublic \not\in \GroupPx$. fields, or if $\AuthSignPublic \not\in \GroupPx$.
For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviewo}. There is no \Bech encoding defined for an individual \Orchard \fullViewingKey;
For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestorchard}. instead use a \unifiedFullViewingKey as defined in \cite{ZIP-316}.
} %nufive } %nufive
@ -14266,6 +14241,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Include $\NoteUniqueRand$ as an input to the derivation of \item Include $\NoteUniqueRand$ as an input to the derivation of
$\NoteNullifierRand$, $\EphemeralPrivate$, and $\NoteCommitRand$ in \Orchard. $\NoteNullifierRand$, $\EphemeralPrivate$, and $\NoteCommitRand$ in \Orchard.
This was originally intended and as described in \cite[Section 3.5 Nullifiers]{Zcash-Orchard}. This was originally intended and as described in \cite[Section 3.5 Nullifiers]{Zcash-Orchard}.
\item Delegate to \cite{ZIP-316} for the specification of \unifiedPaymentAddresses,
\unifiedIncomingViewingKeys, and \unifiedFullViewingKeys (\crossref{unifiedencodings}).
\item Specify that \diversifierIndices for \Orchard \paymentAddresses should be chosen \item Specify that \diversifierIndices for \Orchard \paymentAddresses should be chosen
uniquely, not randomly. uniquely, not randomly.
\item Vanity \diversifiers are not an issue for \Orchard given that it does not have its own \item Vanity \diversifiers are not an issue for \Orchard given that it does not have its own
@ -14411,7 +14388,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Update specification of $\Poseidon$. \item Update specification of $\Poseidon$.
\item Fix errors in \Orchard due to cut-and-paste from \Sapling. \item Fix errors in \Orchard due to cut-and-paste from \Sapling.
\item Add references to \cite{Zcash-halo2}. \item Add references to \cite{Zcash-halo2}.
\item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the description of $\lengthField$ in \crossref{unifiedencodings}.
\item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}.
\item Various rationale updates for \NUFive. \item Various rationale updates for \NUFive.
\item Other fixes to the \Orchard specification, including generation of \dummyNotes and output \notes. \item Other fixes to the \Orchard specification, including generation of \dummyNotes and output \notes.