mirror of https://github.com/zcash/zips.git
merge
This commit is contained in:
commit
9fc091760e
|
@ -0,0 +1,2 @@
|
|||
protocol.pdf: protocol.tex incremental_merkle.pdf
|
||||
pdflatex protocol.tex
|
|
@ -38,6 +38,7 @@
|
|||
\newcommand{\PRFpk}[2]{\PRF{#1}{pk_{#2}}}
|
||||
\newcommand{\SHA}{\mathtt{SHA256Compress}}
|
||||
\newcommand{\SHAName}{\emph{SHA-256 compression}}
|
||||
\newcommand{\SHAOrig}{\emph{SHA-256}}
|
||||
\newcommand{\bm}{\mathbf{\mathtt{bm}}}
|
||||
\newcommand{\InternalHashK}{\mathsf{k}}
|
||||
\newcommand{\InternalHash}{\mathsf{InternalH}}
|
||||
|
@ -102,15 +103,21 @@
|
|||
|
||||
\section{Concepts}
|
||||
|
||||
\subsection{Endianness}
|
||||
\subsection{Integers and Endianness}
|
||||
|
||||
All numerical objects in Zcash are big endian.
|
||||
Abstractly, integers have a signedness (signed or unsigned), and a bit length.
|
||||
The limits are the same as for the usual two's compliment system. All integers
|
||||
in the publicly-visible \Zcash protocol are encoded in big endian two's
|
||||
compliment.
|
||||
|
||||
If unspecified, curve points, field elements, etc., are encoded according to the
|
||||
crypto libraries the \Zcash implementation uses.
|
||||
|
||||
\subsection{Cryptographic Functions}
|
||||
|
||||
\subparagraph{}
|
||||
|
||||
$\CRH$ is a collision-resistant hash function. In \Zcash, the $\SHAName$ function is used which takes a 512-bit block and produces a 256-bit hash.
|
||||
$\CRH$ is a collision-resistant hash function. In \Zcash, the $\SHAName$ function is used which takes a 512-bit block and produces a 256-bit hash. This is different from the $\SHAOrig$ function, which hashes arbitrary-length strings.
|
||||
|
||||
\subparagraph{}
|
||||
|
||||
|
@ -217,7 +224,7 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
|
|||
|
||||
\end{flushright}
|
||||
|
||||
We say that the bucket commitment of a bucket $\Bucket$ = $\BucketCommitment{\Bucket}$.\eli{circular definition: $b=f(b)$?}
|
||||
We say that the bucket commitment of a bucket $\Bucket$ is $\bm = \BucketCommitment{\Bucket}$.
|
||||
|
||||
\subparagraph{Serials}
|
||||
|
||||
|
@ -347,4 +354,146 @@ for each $i \in \{1, 2\}$: $h_i$ = $\PRFpk{\SpendAuthorityPrivate^{old}_i}{i-1}(
|
|||
|
||||
for each $i \in \{1, 2\}$: $\bm^{new}_i$ = $\BucketCommitment{\bNew{i}}$
|
||||
|
||||
\section{Encoding addresses, private keys, buckets, and pours}
|
||||
|
||||
This section describes how \Zcash encodes public addresses, private keys,
|
||||
buckets, and pours.
|
||||
|
||||
Addresses, keys, and buckets, can be encoded as a byte string; this is called
|
||||
the \emph{raw encoding}. This byte string can then be further encoded using
|
||||
Base58Check. The Base58Check layer is the same as for upstream Bitcoin
|
||||
addresses.
|
||||
|
||||
SHA-256 compression function outputs are always represented as strings of 32
|
||||
bytes.
|
||||
|
||||
The language consisting of the following encoding possibilities is prefix-free.
|
||||
|
||||
\subsection{Cleartext Public Addresses}
|
||||
|
||||
TBD. Identical to Bitcoin?
|
||||
|
||||
\subsection{Cleartext Private Keys}
|
||||
|
||||
TBD. Identical to Bitcoin?
|
||||
|
||||
\subsection{Protected Public Addresses}
|
||||
|
||||
A protected address 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), which is an elliptic curve point.
|
||||
|
||||
\subsubsection{Raw Encoding}
|
||||
|
||||
The raw encoding of a protected address consists of:
|
||||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.07em]{520}
|
||||
\bitbox{80}{0x??} &
|
||||
\bitbox{256}{$\SpendAuthorityPublic$ (32 bytes)} &
|
||||
\bitbox{256}{A 33-byte encoding of $\TransmitPublic$}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\begin{itemize}
|
||||
\item A byte, 0x??, indicating this version of the raw encoding of a \Zcash
|
||||
public address.
|
||||
\item 32 bytes specifying $\SpendAuthorityPublic$.
|
||||
\item An encoding of $\TransmitPublic$: The byte 0x01, followed by 32 bytes
|
||||
representing the x coordinate of the elliptic curve point according to
|
||||
the FE20SP primitive specified in section 5.5.4 of IEEE Std 1363-2000.
|
||||
[Non-normative note: Since the curve is over a prime field, this is just
|
||||
the 32-byte big-endian representation of the x coordinate. The
|
||||
overall encoding matches the EC20SP-X primitive specified in section
|
||||
5.5.6.3 of IEEE Std 1363a-2004.]
|
||||
\end{itemize}
|
||||
|
||||
\textbf{TODO: pick a version byte distinct from other Bitcoin stuff, and that
|
||||
produces the correct Base58 leading character}
|
||||
|
||||
\textbf{TODO: what about the network version byte?}
|
||||
|
||||
\subsection{Protected Address Secrets}
|
||||
|
||||
A protected address secret consists of $\SpendAuthorityPrivate$ and
|
||||
$\TransmitPrivate$. $\SpendAuthorityPrivate$ is a SHA-256 compression function
|
||||
output. $\TransmitPrivate$ is an encryption private key (currently ECIES), which
|
||||
is an integer.
|
||||
|
||||
\subsubsection{Raw Encoding}
|
||||
|
||||
The raw encoding of a protected address secret consists of, in order:
|
||||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.07em]{520}
|
||||
\bitbox{80}{0x??} &
|
||||
\bitbox{256}{$\SpendAuthorityPrivate$ (32 bytes)} &
|
||||
\bitbox{256}{$\TransmitPrivate$ (32 bytes)}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\begin{itemize}
|
||||
\item A byte 0x?? indicating this version of the raw encoding of a Zcash
|
||||
private key.
|
||||
\item 32 bytes specifying $\SpendAuthorityPrivate$.
|
||||
\item 32 bytes specifying a big-endian encoding of $\TransmitPrivate$.
|
||||
\end{itemize}
|
||||
|
||||
\textbf{TODO: pick a version byte distinct from other Bitcoin stuff, and that
|
||||
produces the correct Base58 leading character}
|
||||
|
||||
\textbf{TODO: what about the network version byte?}
|
||||
|
||||
\subsection{Buckets (on the blockchain)}
|
||||
|
||||
A bucket consists of $(\PublicAddress, \Value, \BucketAddressRand, \BucketRand,
|
||||
\bm)$, where:
|
||||
|
||||
\begin{itemize}
|
||||
\item $\PublicAddress$ is a \Zcash public address.
|
||||
\item $\Value$ is a 64-bit unsigned integer representing the value of the
|
||||
bucket in zatoshi.
|
||||
\item $\BucketAddressRand$ is a 32-byte $\PRFsn{\SpendAuthorityPrivate}$ seed.
|
||||
\item $\BucketRand$ is a 32-byte COMM trapdoor.
|
||||
\item $\bm$ is a commitment which is a SHA-256 compression function output.
|
||||
\end{itemize}
|
||||
|
||||
Note that the value $s$ described as being part of a bucket/coin in the Zerocash
|
||||
paper is not encoded because it is fixed to zero.
|
||||
|
||||
\subsection{Raw Encoding}
|
||||
|
||||
The raw encoding of a \Zcash bucket consists of, in order:
|
||||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.05em]{200}
|
||||
\bitbox{80}{0x??} &
|
||||
\bitbox{80}{$\PublicAddress$} &
|
||||
\bitbox{230}{$\Value$ (8 bytes, big endian)} &
|
||||
\bitbox{230}{$\BucketAddressRand$ (32 bytes)} &
|
||||
\bitbox{230}{$\BucketRand$ (32 bytes)} &
|
||||
\bitbox{230}{$\bm$ (32 bytes)} &
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\begin{itemize}
|
||||
\item A byte 0x?? indicating this version of the raw encoding of a \Zcash
|
||||
bucket.
|
||||
\item 65 bytes specifying the raw encoding of the \Zcash public address
|
||||
$\PublicAddress$ (defined above).
|
||||
\item 8 bytes specifying a big-endian encoding of $\Value$.
|
||||
\item 32 bytes specifying $\BucketAddressRand$.
|
||||
\item 32 bytes specifying $\BucketRand$.
|
||||
\item 32 bytes specifying $\bm$.
|
||||
\end{itemize}
|
||||
|
||||
\section{Pours (within a transaction on the blockchain)}
|
||||
|
||||
TBD.
|
||||
|
||||
\section{Transactions}
|
||||
|
||||
TBD.
|
||||
|
||||
\end{document}
|
||||
|
|
Loading…
Reference in New Issue