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{\spendAuthPrivateKeys}{\term{spend authorization private key}}
\newcommand{\spendAuthSignatureScheme}{\term{spend authorization signature scheme}}
\newcommand{\spendingAuthority}{\term{spending authority}}
\newcommand{\outputDescription}{\term{Output description}}
\newcommand{\outputDescriptions}{\terms{Output description}}
\newcommand{\outputTransfer}{\term{Output transfer}}
@ -2683,7 +2684,7 @@ intended recipient, who can use the \receivingKey to scan the \blockChain for
\sapling{
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
\outputDescription\nufive{ or \actionDescription}.
}
@ -3008,7 +3009,7 @@ case that a payee wishes to prevent this they should create a distinct
\saplingonward{
\notnufive{\Sapling provides}\notbeforenufive{\Sapling and \Orchard provide}
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
addresses as needed does not increase the cost of scanning the \blockChain for
relevant \transactions.
@ -4846,9 +4847,8 @@ the \incomingViewingKey $\InViewingKey \typecolon \InViewingKeyTypeSapling$ are
If $\InViewingKey = 0$, discard this key and repeat with a new $\SpendingKey$.
As explained in \crossref{addressesandkeys}, \Sapling allows the efficient
creation of multiple \diversifiedPaymentAddresses with the same spending
authority. A group of such addresses shares the same \fullViewingKey and
\incomingViewingKey.
creation of multiple \diversifiedPaymentAddresses with the same \spendingAuthority.
A group of such addresses shares the same \fullViewingKey and \incomingViewingKey.
\introlist
To create a new \diversifiedPaymentAddress given an \incomingViewingKey
@ -5025,9 +5025,9 @@ as follows:
\end{algorithm}
As explained in \crossref{addressesandkeys}, \Orchard allows the efficient
creation of multiple \diversifiedPaymentAddresses with the same spending
authority. A group of such addresses shares the same \fullViewingKey,
\incomingViewingKey, and \outgoingViewingKey.
creation of multiple \diversifiedPaymentAddresses with the same \spendingAuthority.
A group of such addresses shares the same \fullViewingKey, \incomingViewingKey, and
\outgoingViewingKey.
\introlist
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$;
this allows also deriving the $\NullifierKey$ component of the \fullViewingKey. \nufive{(In
\Orchard, that party needs the $\NullifierKey$ directly to make the \zkSNARKProof.)} Together
$\AuthSignPublic$ and $\NullifierKey$ are sufficient to recognize spent \notes and to
recognize and decrypt incoming \notes. However, the other party will not obtain spending
authority for other \transactions, since it is not able to create a \spendAuthSignature by itself.
$\AuthSignPublic$ and $\NullifierKey$ are sufficient to recognize spent \notes and to recognize
and decrypt incoming \notes. However, the other party will not obtain \spendingAuthority for other
\transactions, since it is not able to create a \spendAuthSignature by itself.
} %pnote
} %sapling
@ -8397,8 +8397,8 @@ the third address was derived from.
\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
additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs
with the same spend authority as an existing \shieldedPaymentAddress, since they
additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs with
the same \spendingAuthority as an existing \shieldedPaymentAddress, since they
could also create such pairs on their own. This justifies only considering
two \shieldedPaymentAddresses in the security definition.