mirror of https://github.com/zcash/zips.git
Merge branch 'nathan-wip' of github.com:Electric-Coin-Company/zips into daira-wip
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
commit
c080e5eda2
Binary file not shown.
|
@ -52,6 +52,7 @@
|
|||
\newcommand{\serialNumber}{\term{serial number}}
|
||||
\newcommand{\serialNumbers}{\term{serial numbers}}
|
||||
\newcommand{\publicAddress}{\term{confidential address}}
|
||||
% Let's rename ``privateAddress'' to something else, since it sounds like an oxymoron to me. (This is related to a code naming issue #602 and we might want to update both at the same time.)
|
||||
\newcommand{\privateAddress}{\term{confidential private key}}
|
||||
\newcommand{\transmittedPlaintext}{\term{transmitted coin plaintext}}
|
||||
\newcommand{\transmittedCiphertext}{\term{transmitted coin ciphertext}}
|
||||
|
@ -171,7 +172,7 @@ protected by zero-knowledge succinct non-interactive arguments of knowledge
|
|||
|
||||
\section{Concepts}
|
||||
|
||||
\subsection{Integers and Endianness}
|
||||
\subsection{Integers, Bit Sequences, and Endianness}
|
||||
|
||||
All integers visible in \Zcash-specific encodings are unsigned, have a fixed
|
||||
bit length, and are encoded as big-endian.
|
||||
|
@ -182,6 +183,9 @@ a sequence of bits using big endian order. The bit sequences are then
|
|||
concatenated in the order shown from left to right, and the result is converted
|
||||
to a sequence of bytes, again using big-endian order.
|
||||
|
||||
\nathan{An example would help here. It would be illustrative if it had
|
||||
a few differently-sized fields.}
|
||||
|
||||
$\Leading{k}(x)$, where $k$ is an integer and $x$ is a bit sequence, returns
|
||||
the leading (initial) $k$ bits of its input.
|
||||
|
||||
|
@ -236,6 +240,9 @@ independent.
|
|||
\end{bytefield}
|
||||
\end{lrbox}
|
||||
|
||||
\nathan{Note: If we change input arity (i.e. $\NOld$), we need to be aware of how it
|
||||
is associated with this bit-packing.}
|
||||
|
||||
\begin{equation*}
|
||||
\begin{aligned}
|
||||
\SpendAuthorityPublic &:= \PRFaddr{\SpendAuthorityPrivate}(0) &= \CRHbox{\addrbox} \\
|
||||
|
@ -249,20 +256,33 @@ independent.
|
|||
|
||||
\subsection{Confidential Addresses and Private Keys}
|
||||
|
||||
A key pair $(\PublicAddress, \PrivateAddress)$ is generated by users who wish to
|
||||
receive coins under this scheme. The public $\PublicAddress$ is called a
|
||||
$\publicAddress$ and is a tuple $(\SpendAuthorityPublic, \TransmitPublic)$
|
||||
consisting of the public components of a $\spendAuthority$ key pair
|
||||
$(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\transmitPublicAlgorithm$ key
|
||||
pair $(\TransmitPublic, \TransmitPrivate)$. The private $\PrivateAddress$ is called
|
||||
a $\privateAddress$ and is a tuple $(\SpendAuthorityPrivate, \TransmitPrivate)$
|
||||
consisting of the respective \emph{private} components of the aforementioned
|
||||
$\spendAuthority$ and $\transmitPublicAlgorithm$ key pairs.
|
||||
\nathan{This term, \publicAddress, may be confusing by comparison to
|
||||
a ``private key''. In the latter case the adjective is reminding a
|
||||
user of their responsibility to protect its privacy, but in the case
|
||||
of \publicAddress we want users to know ``transfers to this address
|
||||
are confidential, but the address itself *may* be published or kept
|
||||
confidential depending on your needs. Two different people can compare
|
||||
addresses to know they have the same \publicAddress.''}
|
||||
|
||||
Although users can accept payment from multiple parties with a single
|
||||
$\PublicAddress$ without either party being aware, it is still recommended to
|
||||
generate a new address for each expected transaction to maximize privacy in the
|
||||
event that multiple sending parties are compromised or collude.
|
||||
A key pair $(\PublicAddress, \PrivateAddress)$ is generated by
|
||||
users who wish to receive coins under this scheme. The tuple parts
|
||||
embody two distinct keypairs used for different purposes called
|
||||
the \spendAuthority and the \transmitPublicAlgorithm keypair. The
|
||||
\publicAddress $\PublicAddress$ is a tuple $(\SpendAuthorityPublic,
|
||||
\TransmitPublic)$, containing the public components of the \spendAuthority
|
||||
and \transmitPublicAlgorithm respectively. The $\PrivateAddress$ is
|
||||
a tuple $(\SpendAuthorityPrivate, \TransmitPrivate)$, containing the
|
||||
secret components respectively.
|
||||
|
||||
\nathan{A diagram could really help here.}
|
||||
|
||||
Users can accept payment from multiple parties with a single
|
||||
$\PublicAddress$ and the fact that these payments are destined to
|
||||
the same payee is not revealed on the blockchain, even to the
|
||||
paying parties. \emph{However} if two parties collude to compare a
|
||||
$\PublicAddress$ they can trivially determine they are the same. In the
|
||||
case that a payee wishes to prevent this they should create a distinct
|
||||
\publicAddress for each payer.
|
||||
|
||||
\subsection{Coins}
|
||||
|
||||
|
@ -564,7 +584,7 @@ These are encoded in the same way as in \Bitcoin \cite{Base58Check}.
|
|||
|
||||
\subsection{Confidential Public Addresses}
|
||||
|
||||
A confidential address consists of $\SpendAuthorityPublic$ and $\TransmitPublic$.
|
||||
A \publicAddress consists of $\SpendAuthorityPublic$ and $\TransmitPublic$.
|
||||
$\SpendAuthorityPublic$ is a SHA-256 compression function output.
|
||||
$\TransmitPublic$ is an encryption public key (currently ECIES, but this may
|
||||
change to Curve25519/crypto\_box\_seal), which represents an equivalence class
|
||||
|
|
Loading…
Reference in New Issue