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

Make consistent use of "spending authority", and add this term to the index. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-10-12 19:05:47 +01:00
parent 4da403f470
commit 089a9cb8be
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
protocol/protocol.tex
View File

@ -829,6 +829,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\spendAuthPrivateKey}{\term{spend authorization private key}} \newcommand{\spendAuthPrivateKey}{\term{spend authorization private key}}
\newcommand{\spendAuthPrivateKeys}{\term{spend authorization private key}} \newcommand{\spendAuthPrivateKeys}{\term{spend authorization private key}}
\newcommand{\spendAuthSignatureScheme}{\term{spend authorization signature scheme}} \newcommand{\spendAuthSignatureScheme}{\term{spend authorization signature scheme}}
\newcommand{\spendingAuthority}{\term{spending authority}}
\newcommand{\outputDescription}{\term{Output description}} \newcommand{\outputDescription}{\term{Output description}}
\newcommand{\outputDescriptions}{\terms{Output description}} \newcommand{\outputDescriptions}{\terms{Output description}}
\newcommand{\outputTransfer}{\term{Output transfer}} \newcommand{\outputTransfer}{\term{Output transfer}}
@ -2683,7 +2684,7 @@ intended recipient, who can use the \receivingKey to scan the \blockChain for
\sapling{ \sapling{
In \SaplingAndOrchard, for each \spendingKey there is a \fullViewingKey that allows In \SaplingAndOrchard, for each \spendingKey there is a \fullViewingKey that allows
recognizing both incoming and outgoing \notes without having spend authority. recognizing both incoming and outgoing \notes without having \spendingAuthority.
This is implemented by an additional ciphertext in each This is implemented by an additional ciphertext in each
\outputDescription\nufive{ or \actionDescription}. \outputDescription\nufive{ or \actionDescription}.
} }
@ -3008,7 +3009,7 @@ case that a payee wishes to prevent this they should create a distinct
\saplingonward{ \saplingonward{
\notnufive{\Sapling provides}\notbeforenufive{\Sapling and \Orchard provide} \notnufive{\Sapling provides}\notbeforenufive{\Sapling and \Orchard provide}
a mechanism to allow the efficient creation of \diversifiedPaymentAddresses a mechanism to allow the efficient creation of \diversifiedPaymentAddresses
with the same spending authority. A group of such addresses shares the same with the same \spendingAuthority. A group of such addresses shares the same
\fullViewingKey and \incomingViewingKey\!\!, and so creating as many unlinkable \fullViewingKey and \incomingViewingKey\!\!, and so creating as many unlinkable
addresses as needed does not increase the cost of scanning the \blockChain for addresses as needed does not increase the cost of scanning the \blockChain for
relevant \transactions. relevant \transactions.
@ -4846,9 +4847,8 @@ the \incomingViewingKey $\InViewingKey \typecolon \InViewingKeyTypeSapling$ are
If $\InViewingKey = 0$, discard this key and repeat with a new $\SpendingKey$. If $\InViewingKey = 0$, discard this key and repeat with a new $\SpendingKey$.
As explained in \crossref{addressesandkeys}, \Sapling allows the efficient As explained in \crossref{addressesandkeys}, \Sapling allows the efficient
creation of multiple \diversifiedPaymentAddresses with the same spending creation of multiple \diversifiedPaymentAddresses with the same \spendingAuthority.
authority. A group of such addresses shares the same \fullViewingKey and A group of such addresses shares the same \fullViewingKey and \incomingViewingKey.
\incomingViewingKey.
\introlist \introlist
To create a new \diversifiedPaymentAddress given an \incomingViewingKey To create a new \diversifiedPaymentAddress given an \incomingViewingKey
@ -5025,9 +5025,9 @@ as follows:
\end{algorithm} \end{algorithm}
As explained in \crossref{addressesandkeys}, \Orchard allows the efficient As explained in \crossref{addressesandkeys}, \Orchard allows the efficient
creation of multiple \diversifiedPaymentAddresses with the same spending creation of multiple \diversifiedPaymentAddresses with the same \spendingAuthority.
authority. A group of such addresses shares the same \fullViewingKey, A group of such addresses shares the same \fullViewingKey, \incomingViewingKey, and
\incomingViewingKey, and \outgoingViewingKey. \outgoingViewingKey.
\introlist \introlist
To create a new \diversifiedPaymentAddress given an \incomingViewingKey To create a new \diversifiedPaymentAddress given an \incomingViewingKey
@ -6582,9 +6582,9 @@ to a different party that is capable of performing the \zkSNARKProof. In this ca
lost to that party since it needs $\AuthSignPublic$ and the \authProvingKey $\AuthProvePrivate$; lost to that party since it needs $\AuthSignPublic$ and the \authProvingKey $\AuthProvePrivate$;
this allows also deriving the $\NullifierKey$ component of the \fullViewingKey. \nufive{(In this allows also deriving the $\NullifierKey$ component of the \fullViewingKey. \nufive{(In
\Orchard, that party needs the $\NullifierKey$ directly to make the \zkSNARKProof.)} Together \Orchard, that party needs the $\NullifierKey$ directly to make the \zkSNARKProof.)} Together
$\AuthSignPublic$ and $\NullifierKey$ are sufficient to recognize spent \notes and to $\AuthSignPublic$ and $\NullifierKey$ are sufficient to recognize spent \notes and to recognize
recognize and decrypt incoming \notes. However, the other party will not obtain spending and decrypt incoming \notes. However, the other party will not obtain \spendingAuthority for other
authority for other \transactions, since it is not able to create a \spendAuthSignature by itself. \transactions, since it is not able to create a \spendAuthSignature by itself.
} %pnote } %pnote
} %sapling } %sapling
@ -8397,8 +8397,8 @@ the third address was derived from.
\item Informally, the random self-reducibility property of DDH implies that an \item Informally, the random self-reducibility property of DDH implies that an
adversary would gain no advantage from being able to query an oracle for adversary would gain no advantage from being able to query an oracle for
additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs with
with the same spend authority as an existing \shieldedPaymentAddress, since they the same \spendingAuthority as an existing \shieldedPaymentAddress, since they
could also create such pairs on their own. This justifies only considering could also create such pairs on their own. This justifies only considering
two \shieldedPaymentAddresses in the security definition. two \shieldedPaymentAddresses in the security definition.