|
|
@ -48,8 +48,8 @@ |
|
|
\DefineBibliographyStrings{english}{ |
|
|
\DefineBibliographyStrings{english}{ |
|
|
page = {page}, |
|
|
page = {page}, |
|
|
pages = {pages}, |
|
|
pages = {pages}, |
|
|
backrefpage = {$\uparrow$ p\!}, |
|
|
backrefpage = {\mbox{$\uparrow$ p\!}}, |
|
|
backrefpages = {$\uparrow$ p\!} |
|
|
backrefpages = {\mbox{$\uparrow$ p\!}} |
|
|
} |
|
|
} |
|
|
|
|
|
|
|
|
\setlength{\oddsidemargin}{-0.25in} |
|
|
\setlength{\oddsidemargin}{-0.25in} |
|
|
@ -376,7 +376,7 @@ |
|
|
\newcommand{\EdDSAR}{\bytes{R}} |
|
|
\newcommand{\EdDSAR}{\bytes{R}} |
|
|
\newcommand{\EdDSAS}{\bytes{S}} |
|
|
\newcommand{\EdDSAS}{\bytes{S}} |
|
|
|
|
|
|
|
|
% merkle tree |
|
|
% Merkle tree |
|
|
\newcommand{\MerkleDepth}{\mathsf{d}} |
|
|
\newcommand{\MerkleDepth}{\mathsf{d}} |
|
|
\newcommand{\MerkleNode}[2]{\mathsf{M}^{#1}_{#2}} |
|
|
\newcommand{\MerkleNode}[2]{\mathsf{M}^{#1}_{#2}} |
|
|
\newcommand{\MerkleSibling}{\mathsf{sibling}} |
|
|
\newcommand{\MerkleSibling}{\mathsf{sibling}} |
|
|
@ -384,7 +384,7 @@ |
|
|
\newcommand{\MerkleHashLength}{\mathsf{\ell_{Merkle}}} |
|
|
\newcommand{\MerkleHashLength}{\mathsf{\ell_{Merkle}}} |
|
|
\newcommand{\MerkleHash}{\bitseq{\MerkleHashLength}} |
|
|
\newcommand{\MerkleHash}{\bitseq{\MerkleHashLength}} |
|
|
|
|
|
|
|
|
% bitcoin |
|
|
% Bitcoin |
|
|
\newcommand{\vin}{\mathtt{vin}} |
|
|
\newcommand{\vin}{\mathtt{vin}} |
|
|
\newcommand{\vout}{\mathtt{vout}} |
|
|
\newcommand{\vout}{\mathtt{vout}} |
|
|
\newcommand{\nJoinSplit}{\mathtt{nJoinSplit}} |
|
|
\newcommand{\nJoinSplit}{\mathtt{nJoinSplit}} |
|
|
@ -559,7 +559,7 @@ unspent valid \note, at a given point on the \blockchain, is one for which |
|
|
the \noteCommitment has been publicly revealed on the \blockchain prior to |
|
|
the \noteCommitment has been publicly revealed on the \blockchain prior to |
|
|
that point, but the \nullifier has not. |
|
|
that point, but the \nullifier has not. |
|
|
|
|
|
|
|
|
\Transactions can contain ``transparent'' inputs, outputs, and scripts, which |
|
|
A \transaction can contain ``transparent'' inputs, outputs, and scripts, which |
|
|
all work basically as in \Bitcoin. They also contain a sequence of zero or |
|
|
all work basically as in \Bitcoin. They also contain a sequence of zero or |
|
|
more \joinSplitDescriptions. Each of these describes a \joinSplitTransfer\hairspace\footnote{ |
|
|
more \joinSplitDescriptions. Each of these describes a \joinSplitTransfer\hairspace\footnote{ |
|
|
\joinSplitTransfers in \Zcash generalize ``Mint'' and ``Pour'' \transactions |
|
|
\joinSplitTransfers in \Zcash generalize ``Mint'' and ``Pour'' \transactions |
|
|
@ -635,9 +635,9 @@ The notation $\range{a}{b}$ means the set of integers from $a$ through |
|
|
$b$ inclusive. $k\range{a}{b}$ means the set containing integers $kn$ |
|
|
$b$ inclusive. $k\range{a}{b}$ means the set containing integers $kn$ |
|
|
for all $n \in \range{a}{b}$. |
|
|
for all $n \in \range{a}{b}$. |
|
|
|
|
|
|
|
|
The notation $[f(x)$ for $x$ from $a$ up to $b]$ means the sequence |
|
|
The notation $[f(x)$ for $x$ from $a$ up to $b\,]$ means the sequence |
|
|
formed by evaluating $f$ on each integer from $a$ to $b$ inclusive, in |
|
|
formed by evaluating $f$ on each integer from $a$ to $b$ inclusive, in |
|
|
ascending order. Similarly, $[f(x)$ for $x$ from $a$ down to $b]$ means |
|
|
ascending order. Similarly, $[f(x)$ for $x$ from $a$ down to $b\,]$ means |
|
|
the sequence formed by evaluating $f$ on each integer from $a$ to $b$ |
|
|
the sequence formed by evaluating $f$ on each integer from $a$ to $b$ |
|
|
inclusive, in descending order. |
|
|
inclusive, in descending order. |
|
|
|
|
|
|
|
|
@ -695,7 +695,7 @@ Arrows point from a component to any other component(s) that can be derived |
|
|
from it. |
|
|
from it. |
|
|
|
|
|
|
|
|
\begin{center} |
|
|
\begin{center} |
|
|
\includegraphics[scale=.8]{key_components} |
|
|
\includegraphics[scale=.7]{key_components} |
|
|
\end{center} |
|
|
\end{center} |
|
|
|
|
|
|
|
|
The composition of \paymentAddresses\changed{, \viewingKeys,} and \spendingKeys |
|
|
The composition of \paymentAddresses\changed{, \viewingKeys,} and \spendingKeys |
|
|
@ -727,7 +727,7 @@ hypothetical weakness in that cryptosystem. |
|
|
\nsubsection{\Notes} |
|
|
\nsubsection{\Notes} |
|
|
|
|
|
|
|
|
A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, |
|
|
A \note (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, |
|
|
\NoteAddressRand, \NoteCommitRand)}$ which represents that a value $\Value$ is |
|
|
\NoteAddressRand, \NoteCommitRand)}$. It represents that a value $\Value$ is |
|
|
spendable by the recipient who holds the \spendingKey $\AuthPrivate$ corresponding |
|
|
spendable by the recipient who holds the \spendingKey $\AuthPrivate$ corresponding |
|
|
to $\AuthPublic$, as described in the previous section. |
|
|
to $\AuthPublic$, as described in the previous section. |
|
|
|
|
|
|
|
|
@ -1233,8 +1233,8 @@ as follows: for $0 \leq h < \MerkleDepth$ and $0 \leq i < 2^h$, |
|
|
A \merklePath from \merkleLeafNode $\MerkleNode{\MerkleDepth}{i}$ in the |
|
|
A \merklePath from \merkleLeafNode $\MerkleNode{\MerkleDepth}{i}$ in the |
|
|
\incrementalMerkleTree is the sequence |
|
|
\incrementalMerkleTree is the sequence |
|
|
|
|
|
|
|
|
\hskip 2em $[\MerkleNode{h}{\MerkleSibling(h, i)} \text{ for } |
|
|
\hskip 2em $[\hairspace\MerkleNode{h}{\MerkleSibling(h, i)} \text{ for } |
|
|
h \text{ from } \MerkleDepth \text{ down to } 1]$, |
|
|
h \text{ from } \MerkleDepth \text{ down to } 1\hairspace]$, |
|
|
|
|
|
|
|
|
where |
|
|
where |
|
|
|
|
|
|
|
|
@ -2168,8 +2168,7 @@ For a point $P \typecolon \GroupG{2} = (x_P, y_P)$: |
|
|
\item $P$ is encoded as $\Justthebox{\gtwobox}$. |
|
|
\item $P$ is encoded as $\Justthebox{\gtwobox}$. |
|
|
\end{itemize} |
|
|
\end{itemize} |
|
|
|
|
|
|
|
|
\vspace{1ex} |
|
|
\subparagraph{Non-normative notes:} |
|
|
Non-normative notes: |
|
|
|
|
|
\begin{itemize} |
|
|
\begin{itemize} |
|
|
\item The use of big-endian byte order is different from the encoding |
|
|
\item The use of big-endian byte order is different from the encoding |
|
|
of other integers in this protocol. The above encodings are consistent |
|
|
of other integers in this protocol. The above encodings are consistent |
|
|
@ -2341,7 +2340,7 @@ Let $\ell := \frac{n}{k+1} + 1$. |
|
|
Let $m := \floor{\frac{512}{n}}$. |
|
|
Let $m := \floor{\frac{512}{n}}$. |
|
|
|
|
|
|
|
|
Let $T := \concatbits([\GeneralCRH{n m}(\powtag, \powinput(g))$ |
|
|
Let $T := \concatbits([\GeneralCRH{n m}(\powtag, \powinput(g))$ |
|
|
for $g$ from $0$ up to $\ceiling{\frac{N}{m}} - 1])$. |
|
|
for $g$ from $0$ up to $\ceiling{\frac{N}{m}} - 1\hairspace])$. |
|
|
|
|
|
|
|
|
% Blech. Dijkstra was right \cite{EWD831}. |
|
|
% Blech. Dijkstra was right \cite{EWD831}. |
|
|
For $h \in \range{1}{N}$, let $X_h = T_{n(h-1)+1..nh}$. |
|
|
For $h \in \range{1}{N}$, let $X_h = T_{n(h-1)+1..nh}$. |
|
|
|
Daira Hopwood
8 years ago
