mirror of https://github.com/zcash/zips.git
Protected -> shielded.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
11e373a33b
commit
a3aba45fa5
|
@ -127,6 +127,7 @@
|
|||
\newcommand{\term}[1]{\textsl{#1}\kern 0.05em\xspace}
|
||||
\newcommand{\titleterm}[1]{#1}
|
||||
\newcommand{\termbf}[1]{\textbf{#1}\xspace}
|
||||
\newcommand{\quotedterm}[1]{``~\!\!\term{#1}''}
|
||||
\newcommand{\conformance}[1]{\textbnx{#1}\xspace}
|
||||
|
||||
\newcommand{\Zcash}{\termbf{Zcash}}
|
||||
|
@ -222,11 +223,11 @@
|
|||
\newcommand{\xTransparent}{\term{Transparent}}
|
||||
\newcommand{\Transparent}{\titleterm{Transparent}}
|
||||
\newcommand{\transparentValuePool}{\term{transparent value pool}}
|
||||
\newcommand{\xprotected}{\term{protected}}
|
||||
\newcommand{\protectedNote}{\term{protected note}}
|
||||
\newcommand{\protectedNotes}{\term{protected notes}}
|
||||
\newcommand{\xProtected}{\term{Protected}}
|
||||
\newcommand{\Protected}{\titleterm{Protected}}
|
||||
\newcommand{\shielded}{\term{shielded}}
|
||||
\newcommand{\shieldedNote}{\term{shielded note}}
|
||||
\newcommand{\shieldedNotes}{\term{shielded notes}}
|
||||
\newcommand{\xShielded}{\term{Shielded}}
|
||||
\newcommand{\Shielded}{\titleterm{Shielded}}
|
||||
\newcommand{\blockchainview}{\term{block chain view}}
|
||||
\newcommand{\blockchain}{\term{block chain}}
|
||||
\newcommand{\mempool}{\term{mempool}}
|
||||
|
@ -651,7 +652,7 @@
|
|||
scheme \Zerocash \cite{BCG+2014}, with some security fixes and adjustments
|
||||
to terminology, functionality and performance. It bridges the existing
|
||||
\emph{transparent} payment scheme used by \Bitcoin \cite{Naka2008} with a
|
||||
\emph{protected} payment scheme secured by zero-knowledge succinct
|
||||
\emph{shielded} payment scheme secured by zero-knowledge succinct
|
||||
non-interactive arguments of knowledge (\zkSNARKs).
|
||||
|
||||
Changes from the original \Zerocash are explained in \crossref{differences},
|
||||
|
@ -706,9 +707,9 @@ behind the protocol, for an audience already familiar with \blockchain-based
|
|||
cryptocurrencies such as \Bitcoin. It is imprecise in some aspects and is not
|
||||
part of the normative protocol specification.
|
||||
|
||||
Value in \Zcash is either \transparent or \xprotected. Transfers of \transparent
|
||||
Value in \Zcash is either \transparent or \shielded. Transfers of \transparent
|
||||
value work essentially as in \Bitcoin and have the same privacy properties.
|
||||
\xProtected value is carried by \notes\hairspace\footnote{\label{notesandnullifiers}
|
||||
\xShielded value is carried by \notes\hairspace\footnote{\label{notesandnullifiers}
|
||||
In \Zerocash \cite{BCG+2014}, \notes were called ``coins'', and \nullifiers
|
||||
were called ``serial numbers''.},
|
||||
which specify an amount and a \payingKey. The \payingKey is part of
|
||||
|
@ -1032,7 +1033,7 @@ views of valid \blocks, and therefore of the sequence of \treestates in those
|
|||
\nsubsection{\JoinSplitTransfers{} and Descriptions} \label{joinsplit}
|
||||
|
||||
A \joinSplitDescription is data included in a \transaction that describes a \joinSplitTransfer,
|
||||
i.e.\ a \xprotected value transfer. This kind of value transfer is the primary
|
||||
i.e.\ a \shielded value transfer. This kind of value transfer is the primary
|
||||
\Zcash-specific operation performed by \transactions; it uses, but should not be
|
||||
confused with, the \joinSplitStatement used for the \zkSNARK proof and verification.
|
||||
|
||||
|
@ -1479,7 +1480,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}.
|
|||
|
||||
\nsubsection{Sending \Notes} \label{send}
|
||||
|
||||
In order to send \xprotected value, the sender constructs a \transaction
|
||||
In order to send \shielded value, the sender constructs a \transaction
|
||||
containing one or more \joinSplitDescriptions. This involves first generating
|
||||
a new $\JoinSplitSig$ key pair:
|
||||
|
||||
|
@ -2461,7 +2462,7 @@ The raw encoding of a P2PKH address consists of:
|
|||
These are encoded in the same way as in \Bitcoin \cite{Bitcoin-Base58},
|
||||
for both the production and test networks.
|
||||
|
||||
\nsubsubsection{\Protected{} Payment Addresses} \label{paymentaddrencoding}
|
||||
\nsubsubsection{\Shielded{} Payment Addresses} \label{paymentaddrencoding}
|
||||
|
||||
A \paymentAddress consists of $\AuthPublic$ and $\TransmitPublic$.
|
||||
$\AuthPublic$ is a $\SHAName$ output.
|
||||
|
@ -3237,13 +3238,13 @@ In \Zcash, there is only the original \Bitcoin transaction type,
|
|||
which is extended to contain a sequence of zero or more
|
||||
\Zcash-specific operations.
|
||||
|
||||
This allows for the possibility of chaining transfers of \xprotected
|
||||
value in a single \Zcash \transaction, e.g.\ to spend a \protectedNote
|
||||
This allows for the possibility of chaining transfers of \shielded
|
||||
value in a single \Zcash \transaction, e.g.\ to spend a \shieldedNote
|
||||
that has just been created. (In \Zcash, we refer to value stored in
|
||||
UTXOs as \transparent, and value stored in \joinSplitTransfer output
|
||||
\notes as \xprotected.)
|
||||
\notes as \shielded.)
|
||||
This was not possible in the \Zerocash design without using multiple
|
||||
transactions. It also allows \transparent and \xprotected transfers to
|
||||
transactions. It also allows \transparent and \shielded transfers to
|
||||
happen atomically --- possibly under the control of nontrivial script
|
||||
conditions, at some cost in distinguishability.
|
||||
|
||||
|
@ -3260,12 +3261,12 @@ more detail in \crossref{notept}.
|
|||
\nsubsection{Unification of Mints and Pours}
|
||||
|
||||
In the original \Zerocash protocol, there were two kinds of transaction
|
||||
relating to \protectedNotes:
|
||||
relating to \shieldedNotes:
|
||||
\begin{itemize}
|
||||
\item a ``Mint'' transaction takes value from \transparent UTXOs as
|
||||
input and produces a new \protectedNote as output.
|
||||
\item a ``Pour'' transaction takes up to $\NOld$ \protectedNotes
|
||||
as input, and produces up to $\NNew$ \protectedNotes and a
|
||||
input and produces a new \shieldedNote as output.
|
||||
\item a ``Pour'' transaction takes up to $\NOld$ \shieldedNotes
|
||||
as input, and produces up to $\NNew$ \shieldedNotes and a
|
||||
\transparent UTXO as output.
|
||||
\end{itemize}
|
||||
|
||||
|
@ -3287,7 +3288,7 @@ described below, since no special case is needed for Mints.
|
|||
|
||||
\nsubsection{Faerie Gold attack and fix} \label{faeriegold}
|
||||
|
||||
When a \protectedNote is created in \Zerocash, the creator is
|
||||
When a \shieldedNote is created in \Zerocash, the creator is
|
||||
supposed to choose a new $\NoteAddressRand$ value at random.
|
||||
The \nullifier of the \note is derived from its \spendingKey
|
||||
($\AuthPrivate$) and $\NoteAddressRand$. The \noteCommitment
|
||||
|
@ -3647,6 +3648,12 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
|
||||
\nsection{Change history}
|
||||
|
||||
\subparagraph{2016.0-beta-1.9}
|
||||
|
||||
\begin{itemize}
|
||||
\item Change \quotedterm{protected} terminology to \quotedterm{shielded}.
|
||||
\end{itemize}
|
||||
|
||||
\subparagraph{2016.0-beta-1.8}
|
||||
|
||||
\begin{itemize}
|
||||
|
|
Loading…
Reference in New Issue