duke
/
zips
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Browse Source

Improve pagination. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
memo-field-specification
Daira Hopwood 7 years ago
parent
1982700426
commit
963f042eb9
1 changed files with 121 additions and 9 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 130
      protocol/protocol.tex

130
protocol/protocol.tex
View File

@ -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}

Write Preview
Loading…
Cancel
Save