mirror of https://github.com/zcash/zips.git
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:
parent
4da403f470
commit
089a9cb8be
|
@ -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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue