mirror of https://github.com/zcash/zips.git
Improve pagination.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
1982700426
commit
963f042eb9
|
@ -15,6 +15,8 @@
|
|||
\RequirePackage{hhline}
|
||||
\RequirePackage[usestackEOL]{stackengine}
|
||||
\RequirePackage{comment}
|
||||
\RequirePackage{needspace}
|
||||
\RequirePackage[nobottomtitles]{titlesec}
|
||||
|
||||
\RequirePackage[style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=iso8601,backref=true,backrefstyle=none,backend=biber]{biblatex}
|
||||
\addbibresource{zcash.bib}
|
||||
|
@ -57,12 +59,18 @@
|
|||
\setlength{\textwidth}{7in}
|
||||
\setlength{\topmargin}{-0.75in}
|
||||
\setlength{\textheight}{9.2in}
|
||||
\setlength{\parskip}{1.5ex}
|
||||
\setlength{\parindent}{0ex}
|
||||
\renewcommand{\arraystretch}{1.4}
|
||||
\overfullrule=2cm
|
||||
|
||||
\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,after=\vspace{1.5ex}}
|
||||
\renewcommand{\bottomtitlespace}{8ex}
|
||||
|
||||
% Use rubber lengths between paragraphs to improve default pagination.
|
||||
% https://tex.stackexchange.com/questions/17178/vertical-spacing-pagination-and-ideal-results
|
||||
\setlength{\parskip}{1.5ex plus 1pt minus 1pt}
|
||||
|
||||
\setlist[enumerate]{before=\vspace{-1ex}}
|
||||
\setlist[itemize]{itemsep=0.5ex,topsep=0.2ex,before=\vspace{-1ex},after=\vspace{1.5ex}}
|
||||
|
||||
\newlist{formulae}{itemize}{3}
|
||||
\setlist[formulae]{itemsep=0.2ex,topsep=0ex,leftmargin=1.5em,label=,before=\vspace{-1ex},after=\vspace{1.5ex}}
|
||||
|
@ -92,6 +100,8 @@
|
|||
\newcommand{\nsubsection}[1]{\subsection{\nstrut{#1}}}
|
||||
\newcommand{\nsubsubsection}[1]{\subsubsection{\nstrut{#1}}}
|
||||
|
||||
\newcommand{\introlist}{\needspace{15ex}}
|
||||
|
||||
\mathchardef\mhyphen="2D
|
||||
|
||||
% http://tex.stackexchange.com/a/309445/78411
|
||||
|
@ -632,12 +642,12 @@
|
|||
\newcommand{\EnforceCommit}[1]{\mathsf{enforce}_{#1}}
|
||||
|
||||
|
||||
\newcommand{\consensusrule}[1]{\subparagraph{Consensus rule:}{#1}}
|
||||
\newenvironment{consensusrules}{\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}}
|
||||
\newcommand{\securityrequirement}[1]{\subparagraph{Security requirement:}{#1}}
|
||||
\newenvironment{securityrequirements}{\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}}
|
||||
\newcommand{\consensusrule}[1]{\needspace{3ex}\subparagraph{Consensus rule:}{#1}}
|
||||
\newenvironment{consensusrules}{\introlist\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}}
|
||||
\newcommand{\securityrequirement}[1]{\needspace{3ex}\subparagraph{Security requirement:}{#1}}
|
||||
\newenvironment{securityrequirements}{\introlist\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}}
|
||||
\newcommand{\pnote}[1]{\subparagraph{Note:}{#1}}
|
||||
\newenvironment{pnotes}{\subparagraph{Notes:}\begin{itemize}}{\end{itemize}}
|
||||
\newenvironment{pnotes}{\introlist\subparagraph{Notes:}\begin{itemize}}{\end{itemize}}
|
||||
|
||||
|
||||
\begin{document}
|
||||
|
@ -678,6 +688,8 @@ document are to be interpreted as described in \cite{RFC-2119} when they
|
|||
appear in \ALLCAPS. These words may also appear in this document in
|
||||
lower case as plain English words, absent their normative meanings.
|
||||
|
||||
\vspace{2ex}
|
||||
\introlist
|
||||
This specification is structured as follows:
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -737,6 +749,7 @@ this \spendingKey. An unspent valid \note, at a given point on the \blockchain,
|
|||
is one for which the \noteCommitment has been publically revealed on the
|
||||
\blockchain prior to that point, but the \nullifier has not.
|
||||
|
||||
\introlist
|
||||
A \transaction can contain \transparent inputs, outputs, and scripts, which all
|
||||
work as in \Bitcoin \cite{Bitcoin-Protocol}. It also contains a sequence of zero or
|
||||
more \joinSplitDescriptions. Each of these describes a \joinSplitTransfer\hairspace\footnote{
|
||||
|
@ -940,6 +953,7 @@ an adversary would have to know $\TransmitPublic$ in order to exploit a
|
|||
hypothetical weakness in that cryptosystem.
|
||||
}
|
||||
|
||||
\needspace{20ex}
|
||||
\nsubsection{\Notes}
|
||||
|
||||
A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value,
|
||||
|
@ -1022,6 +1036,7 @@ a \noteCommitmentTree state given the assumed security properties of the Merkle
|
|||
hash function. Since the \nullifierSet is always updated together with the
|
||||
\noteCommitmentTree, this also identifies a particular state of the \nullifierSet.
|
||||
|
||||
\introlist
|
||||
In a given node's \blockchainview, \treestates are chained as follows:
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -1150,6 +1165,7 @@ the Equihash parameters $n$ and $k$, are written subscripted.
|
|||
It is instantiated in \crossref{equihashgen}.
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{\PseudoRandomFunctions} \label{abstractprfs}
|
||||
|
||||
$\PRF{x}{}$ is a \pseudoRandomFunction keyed by $x$. \changed{Four} \emph{independent}
|
||||
|
@ -1251,6 +1267,7 @@ independently at random from $\KAPrivate$.
|
|||
|
||||
Let $\TransmitPublicSup{j} := \KADerivePublic(\TransmitPrivateSup{j})$.
|
||||
|
||||
\introlist
|
||||
An adversary can adaptively query a function
|
||||
$Q \typecolon \range{1}{2} \times \hSigType \rightarrow
|
||||
\KAPublic \times \Keyspace_{\allNew}$ where $Q_j(\hSig)$ is defined as follows:
|
||||
|
@ -1279,6 +1296,7 @@ This is not considered to be a significant security weakness.
|
|||
}
|
||||
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{Signatures} \label{abstractsig}
|
||||
|
||||
A signature scheme $\Sig$ defines:
|
||||
|
@ -1329,10 +1347,12 @@ pair without access to the signing key.
|
|||
\end{pnotes}
|
||||
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{Commitment} \label{abstractcomm}
|
||||
|
||||
A \commitmentScheme is a function that, given a random \commitmentTrapdoor
|
||||
and an input, can be used to commit to the input in such a way that:
|
||||
|
||||
\begin{itemize}
|
||||
\item no information is revealed about it without the \trapdoor (``hiding''),
|
||||
\item given the \trapdoor and input, the commitment can be verified to ``open''
|
||||
|
@ -1357,6 +1377,7 @@ in zero knowledge --- that is, without revealing information about the
|
|||
\auxiliaryInputs other than that implied by the \statement. The type of
|
||||
\zeroKnowledgeProvingSystem needed by \Zcash is a \ppzkSNARK.
|
||||
|
||||
\introlist
|
||||
A \ppzkSNARK instance $\ZK$ defines:
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -1414,6 +1435,7 @@ Let $\KA$ be a \keyAgreementScheme, instantiated in \crossref{concretekeyagreeme
|
|||
A new \spendingKey $\AuthPrivate$ is generated by choosing a bit string
|
||||
uniformly at random from $\bitseq{\AuthPrivateLength}$.
|
||||
|
||||
\introlist
|
||||
\changed{
|
||||
$\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived from
|
||||
$\AuthPrivate$
|
||||
|
@ -1437,6 +1459,7 @@ Each \transaction includes a sequence of zero or more \joinSplitDescriptions.
|
|||
When this sequence is non-empty, the \transaction also includes encodings of a
|
||||
$\JoinSplitSig$ public verification key and signature.
|
||||
|
||||
\introlist
|
||||
Each \joinSplitDescription consists of $(\vpubOld, \vpubNew, \rt,
|
||||
\nfOld{\allOld}, \cmNew{\allNew}, \EphemeralPublic, \RandomSeed,
|
||||
\h{\allOld}, \JoinSplitProof, \TransmitCiphertext{\allNew})$
|
||||
|
@ -1472,6 +1495,7 @@ where
|
|||
|
||||
The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphertext.
|
||||
|
||||
\introlist
|
||||
The value $\hSig$ is also computed from \changed{$\RandomSeed$, $\nfOld{\allOld}$, and} the
|
||||
$\joinSplitPubKey$ of the containing \transaction:
|
||||
|
||||
|
@ -1491,6 +1515,7 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}.
|
|||
\vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof_{\JoinSplit}) = 1$.
|
||||
\end{consensusrules}
|
||||
|
||||
\introlist
|
||||
\nsubsection{Sending \Notes} \label{send}
|
||||
|
||||
In order to send \shielded value, the sender constructs a \transaction
|
||||
|
@ -1501,12 +1526,14 @@ a new $\JoinSplitSig$ key pair:
|
|||
\item $(\joinSplitPrivKey, \joinSplitPubKey) \leftarrowR \JoinSplitSigGen()$.
|
||||
\end{formulae}
|
||||
|
||||
\introlist
|
||||
For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at
|
||||
random on $\bitseq{\RandomSeedLength}$, and selects
|
||||
the input \notes. At this point there is sufficient information to compute $\hSig$,
|
||||
as described in the previous section. \changed{The sender also chooses $\NoteAddressPreRand$
|
||||
uniformly at random on $\bitseq{\NoteAddressPreRandLength}$.}
|
||||
Then it creates each output \note with index $i \typecolon \setofNew$ as follows:
|
||||
|
||||
\begin{itemize}
|
||||
\item Choose $\NoteCommitRandNew{i}$ uniformly at random on $\bitseq{\NoteCommitRandLength}$.
|
||||
\changed{
|
||||
|
@ -1522,6 +1549,7 @@ of the input \notes and of the output \notes. Other considerations relating to
|
|||
information leakage from the structure of \transactions are beyond the
|
||||
scope of this specification.
|
||||
|
||||
\introlist
|
||||
After generating all of the \joinSplitDescriptions, the sender obtains the
|
||||
$\dataToBeSigned$ (\crossref{nonmalleability}), and signs it with
|
||||
the private \joinSplitSigningKey:
|
||||
|
@ -1539,9 +1567,11 @@ The fields in a \joinSplitDescription allow for $\NOld$ input \notes, and
|
|||
$\NNew$ output \notes. In practice, we may wish to encode a \joinSplitTransfer
|
||||
with fewer input or output \notes. This is achieved using \dummyNotes.
|
||||
|
||||
\introlist
|
||||
\changed{
|
||||
A \dummy input \note, with index $i$ in the \joinSplitDescription, is constructed
|
||||
as follows:
|
||||
|
||||
\begin{itemize}
|
||||
\item Generate a new random \spendingKey $\AuthPrivateOld{i}$ and derive its
|
||||
\payingKey $\AuthPublicOld{i}$.
|
||||
|
@ -1578,6 +1608,7 @@ When a \noteCommitment is added to the tree, it occupies the \merkleLeafNode
|
|||
It is assumed to be infeasible to find a preimage \note $\NoteTuple{}$ such that
|
||||
$\NoteCommit(\NoteTuple{}) = \Uncommitted$.
|
||||
|
||||
\introlist
|
||||
The \merkleNodes at \merkleLayers $0$ to $\MerkleDepth-1$ inclusive are called
|
||||
\merkleInternalNodes, and are associated with $\MerkleCRH$ outputs.
|
||||
\MerkleInternalNodes are computed from their children in the next \merkleLayer
|
||||
|
@ -1587,6 +1618,7 @@ as follows: for $0 \leq h < \MerkleDepth$ and $0 \leq i < 2^h$,
|
|||
\item $\MerkleNode{h}{i} := \MerkleCRH(\MerkleNode{h+1}{2i}, \MerkleNode{h+1}{2i+1})$.
|
||||
\end{formulae}
|
||||
|
||||
\introlist
|
||||
A \merklePath from \merkleLeafNode $\MerkleNode{\MerkleDepth}{i}$ in the
|
||||
\incrementalMerkleTree is the sequence
|
||||
|
||||
|
@ -1679,6 +1711,7 @@ exists in the set.
|
|||
|
||||
\nsubsection{\JoinSplitStatement} \label{jsstatement}
|
||||
|
||||
\introlist
|
||||
A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}:
|
||||
|
||||
\begin{formulae}
|
||||
|
@ -1692,6 +1725,7 @@ A valid instance of $\JoinSplitProof$ assures that given a \term{primary input}:
|
|||
\h{\allOld} \typecolon \typeexp{\PRFOutput}{\NOld})$,
|
||||
\end{formulae}
|
||||
|
||||
\introlist
|
||||
the prover knows an \term{auxiliary input}:
|
||||
|
||||
\begin{formulae}
|
||||
|
@ -1704,6 +1738,7 @@ the prover knows an \term{auxiliary input}:
|
|||
\EnforceCommit{\allOld} \typecolon \bitseq{\NOld}})$,
|
||||
\end{formulae}
|
||||
|
||||
\introlist
|
||||
where:
|
||||
|
||||
\begin{formulae}
|
||||
|
@ -1713,6 +1748,7 @@ where:
|
|||
\vNew{i}, \NoteAddressRandNew{i}, \NoteCommitRandNew{i})$
|
||||
\end{formulae}
|
||||
|
||||
\introlist
|
||||
such that the following conditions hold:
|
||||
|
||||
\subparagraph{Merkle path validity} \label{merklepathvalidity}
|
||||
|
@ -1776,7 +1812,9 @@ the original \note \changed{ and \memo}.
|
|||
|
||||
All of the resulting ciphertexts are combined to form a \notesCiphertext.
|
||||
|
||||
\introlist
|
||||
For both encryption and decryption,
|
||||
|
||||
\begin{itemize}
|
||||
\item Let $\Sym$ be the \encryptionScheme instantiated in \crossref{concretesym}.
|
||||
\item Let $\KDF$ be the \keyDerivationFunction instantiated in \crossref{concretekdf}.
|
||||
|
@ -1791,7 +1829,9 @@ for the intended recipient addresses of each new \note.
|
|||
|
||||
Let $\NotePlaintext{\allNew}$ be the \notePlaintexts as defined in \crossref{notept}.
|
||||
|
||||
\introlist
|
||||
Then to encrypt:
|
||||
|
||||
\begin{itemize}
|
||||
\changed{
|
||||
\item Generate a new $\KA$ (public, private) key pair
|
||||
|
@ -1829,6 +1869,7 @@ Let $\PaymentAddress = (\AuthPublic, \TransmitPublic)$ be the recipient's
|
|||
|
||||
Let $\cmNew{\allNew}$ be the \noteCommitments of each output coin.
|
||||
|
||||
\introlist
|
||||
Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext
|
||||
component as follows:
|
||||
|
||||
|
@ -1841,6 +1882,7 @@ component as follows:
|
|||
\AuthPublic).$
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
$\DecryptNote(\TransmitKey{i}, \TransmitCiphertext{i}, \cmNew{i}, \AuthPublic)$
|
||||
is defined as follows:
|
||||
|
||||
|
@ -1951,6 +1993,7 @@ For example, the following diagrams are all equivalent:
|
|||
and represent the byte sequence $[\hexint{D2}, \hexint{BC}, \hexint{3A}, \hexint{12}]$.
|
||||
\end{comment}
|
||||
|
||||
\introlist
|
||||
\nsubsection{Constants} \label{constants}
|
||||
|
||||
Define:
|
||||
|
@ -1976,6 +2019,7 @@ Define:
|
|||
\end{formulae}
|
||||
|
||||
|
||||
\introlist
|
||||
\nsubsection{Concrete Cryptographic Functions}
|
||||
|
||||
\nsubsubsection{Merkle Tree Hash Function} \label{merklecrh}
|
||||
|
@ -2006,6 +2050,7 @@ $\SHA$ must be collision-resistant, and it must be infeasible to find a preimage
|
|||
such that $\SHA(x) = \zeros{256}$.
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{\hSigText{} Hash Function} \label{hsigcrh}
|
||||
|
||||
\newsavebox{\hsigbox}
|
||||
|
@ -2043,6 +2088,7 @@ block.
|
|||
$\Blake{256}(\ascii{ZcashComputehSig}, x)$ must be collision-resistant.
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{Equihash Generator} \label{equihashgen}
|
||||
|
||||
$\EquihashGen{n, k}$ is a specialized hash function that maps an input
|
||||
|
@ -2069,6 +2115,7 @@ Let $\powtag := \Justthebox{\powtagbox}$.
|
|||
Let $\powcount(g) := \Justthebox{\powcountbox}$.
|
||||
|
||||
\vspace{2ex}
|
||||
\introlist
|
||||
% Blech. Dijkstra was right \cite{EWD831}.
|
||||
Let $\EquihashGen{n, k}(S, i) := T_{h+1\hairspace..\hairspace h+n}$, where
|
||||
\begin{formulae}
|
||||
|
@ -2098,6 +2145,7 @@ the number of calls to $\BlakeGeneric$ can be reduced by a factor of $\floor{\fr
|
|||
in the best case (which is a factor of 2 for $n = 200$).
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{\PseudoRandomFunctions} \label{concreteprfs}
|
||||
|
||||
The \changed{four} independent PRFs described in \crossref{abstractprfs} are
|
||||
|
@ -2242,6 +2290,7 @@ Define $\KAFormatPrivate(x) := \Clamp(x)$.
|
|||
Define $\KAAgree(n, q) := \CurveMultiply(n, q)$.
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{\KeyDerivation} \label{concretekdf}
|
||||
|
||||
\newsavebox{\kdftagbox}
|
||||
|
@ -2309,6 +2358,7 @@ $\JoinSplitSigSpecific$ is defined as using $\JoinSplitSigHashName$ internally.
|
|||
\end{bytefield}
|
||||
\end{lrbox}
|
||||
|
||||
\introlist
|
||||
\changed{
|
||||
The encoding of a signature is:
|
||||
}
|
||||
|
@ -2322,6 +2372,7 @@ where $\EdDSAR$ and $\EdDSAS$ are as defined in \cite{BDL+2012}.
|
|||
The encoding of a public key is as defined in \cite{BDL+2012}.
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{Commitment} \label{concretecomm}
|
||||
|
||||
\newsavebox{\cmbox}
|
||||
|
@ -2372,8 +2423,10 @@ $(\Value, \NoteAddressRand, \NoteCommitRand\changed{, \Memo})$.
|
|||
The first three of these fields are as defined earlier.
|
||||
\changed{$\Memo$ is a 512-byte \memo associated with this \note.
|
||||
|
||||
\introlist
|
||||
The usage of the \memo is by agreement between the sender and recipient of the
|
||||
\note. The \memo{} \SHOULD be encoded either as:
|
||||
|
||||
\begin{itemize}
|
||||
\item a UTF-8 human-readable string \cite{Unicode}, padded by appending zero bytes; or
|
||||
\item an arbitrary sequence of 512 bytes starting with a byte value of $\hexint{F5}$
|
||||
|
@ -2391,7 +2444,9 @@ A start byte of $\hexint{F6}$ or greater is reserved for use in future \Zcash
|
|||
protocol extensions.
|
||||
}
|
||||
|
||||
\introlist
|
||||
The encoding of a \notePlaintext consists of, in order:
|
||||
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.029em]{1608}
|
||||
\changed{
|
||||
|
@ -2436,6 +2491,7 @@ The language consisting of the following encoding possibilities is prefix-free.
|
|||
\xTransparent payment addresses are either P2SH (Pay to Script Hash) \cite{BIP-13}
|
||||
or P2PKH (Pay to Public Key Hash) \cite{Bitcoin-P2PKH} addresses.
|
||||
|
||||
\introlist
|
||||
The raw encoding of a P2SH address consists of:
|
||||
|
||||
\begin{equation*}
|
||||
|
@ -2455,6 +2511,7 @@ The raw encoding of a P2SH address consists of:
|
|||
\item 160 bits specifying a script hash \cite{Bitcoin-P2SH}.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
The raw encoding of a P2PKH address consists of:
|
||||
|
||||
\begin{equation*}
|
||||
|
@ -2501,6 +2558,7 @@ $\TransmitPublic$ is a $\KAPublic$ key (see \crossref{concretekeyagreement}),
|
|||
for use with the encryption scheme defined in \crossref{inband}. These
|
||||
components are derived from a \spendingKey as described in \crossref{keycomponents}.
|
||||
|
||||
\introlist
|
||||
The raw encoding of a \paymentAddress consists of:
|
||||
|
||||
\begin{equation*}
|
||||
|
@ -2538,6 +2596,7 @@ cause the first two characters of the Base58Check encoding to be fixed as
|
|||
A \spendingKey consists of $\AuthPrivate$, which is a sequence of \changed{252} bits
|
||||
(see \crossref{keycomponents}).
|
||||
|
||||
\introlist
|
||||
The raw encoding of a \spendingKey consists of, in order:
|
||||
|
||||
\begin{equation*}
|
||||
|
@ -2589,6 +2648,7 @@ the systems in \cite{PGHR2013} and \cite{BCGTV2013}.
|
|||
|
||||
The pairing implementation is $\BNImpl$.
|
||||
|
||||
\introlist
|
||||
Let $q = 21888242871839275222246405745257275088696311157297823662689037894645226208583$.
|
||||
|
||||
Let $r = 21888242871839275222246405745257275088548364400416034343698204186575808495617$.
|
||||
|
@ -2597,7 +2657,9 @@ Let $b = 3$.
|
|||
|
||||
($q$ and $r$ are prime.)
|
||||
|
||||
\introlist
|
||||
The pairing is of type $\GroupG{1} \times \GroupG{2} \rightarrow \GroupG{T}$, where:
|
||||
|
||||
\begin{itemize}
|
||||
\item $\GroupG{1}$ is a Barreto--Naehrig curve over $\GF{q}$ with equation
|
||||
$y^2 = x^3 + b$. This curve has embedding degree 12 with respect to $r$.
|
||||
|
@ -2609,6 +2671,7 @@ irreducible polynomial $t^2 + 1$.
|
|||
$\GFstar{q^{12}}$.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
Let $\PointP{1} \typecolon \GroupG{1} = (1, 2)$.
|
||||
|
||||
\begin{tabular}{@{}l@{}r@{}l@{}}
|
||||
|
@ -2681,7 +2744,9 @@ Define $\ItoOSP{} \typecolon (k \typecolon \Nat) \times \range{0}{256^k\!-\!1} \
|
|||
\typeexp{\range{0}{255}}{k}$ such that $\ItoOSP{\ell}(n)$ is the sequence of $\ell$ bytes
|
||||
representing $n$ in big-endian order.
|
||||
|
||||
\introlist
|
||||
For a point $P \typecolon \GroupG{1} = (x_P, y_P)$:
|
||||
|
||||
\begin{itemize}
|
||||
\item The field elements $x_P$ and $y_P \typecolon \GF{q}$ are represented as
|
||||
integers $x$ and $y \typecolon \range{0}{q\!-\!1}$.
|
||||
|
@ -2689,7 +2754,9 @@ For a point $P \typecolon \GroupG{1} = (x_P, y_P)$:
|
|||
\item $P$ is encoded as $\Justthebox{\gonebox}$.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
For a point $P \typecolon \GroupG{2} = (x_P, y_P)$:
|
||||
|
||||
\begin{itemize}
|
||||
\item A field element $w \typecolon \GF{q^2}$ is represented as
|
||||
a polynomial $a_{w,1} \mult t + a_{w,0} \typecolon \GF{q}[t]$ modulo $t^2 + 1$.
|
||||
|
@ -2703,7 +2770,9 @@ For a point $P \typecolon \GroupG{2} = (x_P, y_P)$:
|
|||
\item $P$ is encoded as $\Justthebox{\gtwobox}$.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{Non-normative notes:}
|
||||
|
||||
\begin{itemize}
|
||||
\item The use of big-endian byte order is different from the encoding
|
||||
of most other integers in this protocol. The above encodings are consistent
|
||||
|
@ -2722,6 +2791,7 @@ When computing square roots in $\GF{q}$ or $\GF{q^2}$ in order to decompress
|
|||
a point encoding, the implementation \MUSTNOT assume that the square root
|
||||
exists, or that the encoding represents a point on the curve.
|
||||
|
||||
\introlist
|
||||
\nsubsubsection{Encoding of \ZeroKnowledgeProofs} \label{proofencoding}
|
||||
|
||||
\newsavebox{\proofbox}
|
||||
|
@ -2748,9 +2818,10 @@ A proof is encoded by concatenating the encodings of its elements:
|
|||
The resulting proof size is 296 bytes.
|
||||
|
||||
\vspace{0.8ex}
|
||||
|
||||
\introlist
|
||||
In addition to the steps to verify a proof given in \cite[Appendix B]{BCTV2015}, the
|
||||
verifier \MUST check, for the encoding of each element, that:
|
||||
|
||||
\begin{itemize}
|
||||
\item the lead byte is of the required form;
|
||||
\item the remaining bytes encode a big-endian representation of an integer
|
||||
|
@ -2760,6 +2831,7 @@ verifier \MUST check, for the encoding of each element, that:
|
|||
the subgroup $\GroupG{2}$).
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\nsubsection{\JoinSplitParameters} \label{jsparameters}
|
||||
|
||||
For the \Zcash production \blockchain and testnet, the $\FullHashName$ hashes of the
|
||||
|
@ -2774,6 +2846,7 @@ format, are:
|
|||
These parameters were obtained by a multi-party computation described in \cite{GitHub-mpc}.
|
||||
|
||||
|
||||
\needspace{30ex}
|
||||
\nsection{Consensus Changes from \Bitcoin}
|
||||
|
||||
\nsubsection{Encoding of \Transactions} \label{txnencoding}
|
||||
|
@ -2822,7 +2895,9 @@ $\versionField > 1$ and $\nJoinSplit > 0$.
|
|||
The encoding of $\joinSplitPubKey$ and the data to be signed are specified in
|
||||
\crossref{nonmalleability}.
|
||||
|
||||
\introlist
|
||||
The changes relative to \Bitcoin version 1 transactions as described in \cite{Bitcoin-Format} are:
|
||||
|
||||
\begin{itemize}
|
||||
\item The \transactionVersionNumber{} can be either 1 or 2. A version 1 \transaction is
|
||||
equivalent to a version 2 \transaction with $\nJoinSplit = 0$. Software that parses
|
||||
|
@ -2843,6 +2918,7 @@ it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY} as specified in
|
|||
9, 112 and 113.
|
||||
}
|
||||
|
||||
\introlist
|
||||
\nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
|
||||
|
||||
An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in
|
||||
|
@ -2938,7 +3014,9 @@ according to \crossref{equihash}. \\ \hline
|
|||
\end{tabularx}
|
||||
\end{center}
|
||||
|
||||
\introlist
|
||||
The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are:
|
||||
|
||||
\begin{itemize}
|
||||
\item The \blockVersionNumber{} \MUST be 4. Previous versions are not supported. Software
|
||||
that parses blocks \MUSTNOT assume, when an encoded \block starts with an $\nVersion$
|
||||
|
@ -2964,7 +3042,9 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-
|
|||
changing the Proof of Work from \SHAd used by \Bitcoin are described
|
||||
in \cite{WG2016}.
|
||||
|
||||
\introlist
|
||||
A \block satisfies the Proof of Work if and only if:
|
||||
|
||||
\begin{itemize}
|
||||
\item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}.
|
||||
\item The \blockHeader satisfies the difficulty check according to \crossref{difficulty}.
|
||||
|
@ -2982,6 +3062,7 @@ The Generalized Birthday Problem is defined as follows: given a sequence
|
|||
$X_{1..\mathrm{N}}$ of $n$-bit strings, find $2^k$ distinct $X_{i_j}$ such that
|
||||
$\vxor{j=1}{2^k} X_{i_j} = 0$.
|
||||
|
||||
\introlist
|
||||
In Equihash, $\mathrm{N} = 2^{\frac{n}{k+1}+1}$, and the sequence $X_{1..\mathrm{N}}$ is
|
||||
derived from the \blockHeader and a nonce:
|
||||
|
||||
|
@ -3017,6 +3098,7 @@ $\vxor{j=1}{2^k} X_{i_j} = 0$.
|
|||
|
||||
\subparagraph{Algorithm Binding conditions}
|
||||
|
||||
\introlist
|
||||
For all $r \in \range{1}{k\!-\!1}$, for all $w \in \range{0}{2^{k-r}\!-\!1}$:
|
||||
\begin{itemize}
|
||||
\item $\vxor{j=1}{2^r} X_{i_{w \mult 2^r + j}}$ has $\frac{n \mult r}{k+1}$ leading zeroes; and
|
||||
|
@ -3028,6 +3110,7 @@ This does not include a difficulty condition, because here we are defining valid
|
|||
of an Equihash solution independent of difficulty.
|
||||
}
|
||||
|
||||
\introlist
|
||||
An Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\solution$
|
||||
field of a \blockHeader as follows:
|
||||
|
||||
|
@ -3067,7 +3150,7 @@ field of a \blockHeader as follows:
|
|||
\item $\Justthebox{\solutionbox}$
|
||||
\end{formulae}
|
||||
|
||||
\vspace{1ex}
|
||||
\introlist
|
||||
Recall from \crossref{boxnotation} that bits in the above diagram are
|
||||
ordered from most to least significant in each byte.
|
||||
For example, if the first 3 elements of $i$ are $[69, 42, 2^{21}]$,
|
||||
|
@ -3136,6 +3219,7 @@ one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHei
|
|||
|
||||
\renewcommand{\arraystretch}{0.95}
|
||||
|
||||
\introlist
|
||||
For the production network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is:
|
||||
|
||||
\begin{tabular}{@{\hskip 2.5em}l@{\;}l}
|
||||
|
@ -3165,6 +3249,7 @@ For the production network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddress
|
|||
& \ascii{t3R3Y5vnBLrEn8L6wFjPjBLnxSUQsKnmFpv}, \ascii{t3Pcm737EsVkGTbhsu2NekKtJeG92mvYyoN}\, ]
|
||||
\end{tabular}
|
||||
|
||||
\introlist
|
||||
For the test network, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is:
|
||||
|
||||
\begin{tabular}{@{\hskip 2.5em}l@{\;}l}
|
||||
|
@ -3201,6 +3286,7 @@ P2SH multisig address.
|
|||
|
||||
Let $\SlowStartShift$ be defined as in the previous section.
|
||||
|
||||
\introlist
|
||||
Define:
|
||||
|
||||
\begin{formulae}
|
||||
|
@ -3325,10 +3411,12 @@ the recipient of each output \note. This feature is described in
|
|||
more detail in \crossref{notept}.
|
||||
|
||||
|
||||
\introlist
|
||||
\nsubsection{Unification of Mints and Pours}
|
||||
|
||||
In the original \Zerocash protocol, there were two kinds of transaction
|
||||
relating to \shieldedNotes:
|
||||
|
||||
\begin{itemize}
|
||||
\item a ``Mint'' transaction takes value from \transparent UTXOs as
|
||||
input and produces a new \shieldedNote as output.
|
||||
|
@ -3375,6 +3463,7 @@ legends in which faeries pay mortals in what appears to be gold,
|
|||
but which soon after reveals itself to be leaves, gorse blossoms,
|
||||
gingerbread cakes, or other less valuable things \cite{LG2004}.
|
||||
|
||||
\introlist
|
||||
This attack does not violate the security definitions given in
|
||||
\cite{BCG+2014}. The issue could be framed as a problem
|
||||
either with the definition of Completeness, or the definition of
|
||||
|
@ -3489,9 +3578,11 @@ to 254 bits in the input to $\PRFsn{}$ (which corresponds to $\PRFnf{}$ in \Zcas
|
|||
Also, $\hSig$ is truncated from 256 to 253 bits in the input to $\PRFpk{}$.
|
||||
These truncations are not taken into account in the security proofs.
|
||||
|
||||
\introlist
|
||||
Both truncations affect the validity of the proof sketch for Lemma D.2 in
|
||||
the proof of Ledger Indistinguishability in \cite[Appendix D]{BCG+2014}.
|
||||
In more detail:
|
||||
|
||||
\begin{itemize}
|
||||
\item In the argument relating $\mathbf{H}$ and $\Game_2$, it is stated that in $\Game_2$,
|
||||
``for each $i \in \setof{1, 2}, \mathsf{sn}_i := \PRFsn{\AuthPrivate}(\NoteAddressRand)$
|
||||
|
@ -3549,6 +3640,7 @@ changed to a scheme based on Curve25519 key agreement, and the authenticated
|
|||
encryption algorithm $\SymSpecific$. This scheme is still loosely based on ECIES,
|
||||
and on the $\CryptoBoxSeal$ scheme defined in libsodium \cite{libsodium-Seal}.
|
||||
|
||||
\introlist
|
||||
The motivations for this change were as follows:
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3633,6 +3725,7 @@ The \joinSplitStatements are still valid because they can only
|
|||
check that the $\AuthPrivate$ in the witness is \emph{some} preimage of
|
||||
the $\AuthPublic$ used in the \noteCommitment.
|
||||
|
||||
\introlist
|
||||
The error is in the proof of Balance in \cite[Appendix D.3]{BCG+2014}.
|
||||
For the ``$\Adversary$ violates Condition I'' case, the proof says:
|
||||
|
||||
|
@ -3717,6 +3810,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\crossref{truncation} were also found by Daira Hopwood.
|
||||
|
||||
|
||||
\introlist
|
||||
\nsection{Change history}
|
||||
|
||||
\subparagraph{2016.0-beta-1.13}
|
||||
|
@ -3725,6 +3819,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Define $\PRFaddr{}$ in \crossref{keycomponents}.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.12}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3734,6 +3829,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Add acknowledgements for Filippo Valsorda and Zaki Manian.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.11}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3742,6 +3838,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
follow \cite{BIP-34}.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.10}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3751,6 +3848,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Clarify the discussion of proof size in ``Differences from the \Zerocash paper''.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.9}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3758,6 +3856,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Change \quotedterm{protected} terminology to \quotedterm{shielded}.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.8}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3774,6 +3873,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\type{uint32\_t}.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.7}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3781,6 +3881,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
response to an issue raised by the NCC audit.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.6}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3798,6 +3899,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
Jay Graber, and Jack Gavigan.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.5}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3805,6 +3907,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Add some clarifications based on Eli Ben-Sasson's review.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.4}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3814,6 +3917,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
``$\typeexp{T}{\ell}$'' for sequence types) to avoid ambiguity.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.3}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3824,6 +3928,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
and for the NCC Group and Coinspect security audits.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.2}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3832,6 +3937,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Correct the security requirement for $\EquihashGen{}$.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1.1}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3841,6 +3947,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
than as a distribution of parameters.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-beta-1}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3882,18 +3989,21 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Terminology changes.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-alpha-3.1}
|
||||
|
||||
\begin{itemize}
|
||||
\item Change main font to Quattrocento.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2016.0-alpha-3}
|
||||
|
||||
\begin{itemize}
|
||||
\item Change version numbering convention (no other changes).
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2.0-alpha-3}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3902,6 +4012,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Add change history.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2.0-alpha-2}
|
||||
|
||||
\begin{itemize}
|
||||
|
@ -3916,6 +4027,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
|
|||
\item Changes to terminology around keys.
|
||||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\subparagraph{2.0-alpha-1}
|
||||
|
||||
\begin{itemize}
|
||||
|
|
Loading…
Reference in New Issue