From 089a9cb8be3377d02a4354f24756241ccb015ce2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 12 Oct 2021 19:05:47 +0100 Subject: [PATCH] Make consistent use of "spending authority", and add this term to the index. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index d765ff12..e8fef3cd 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -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.