initial comments in tex file

protocol/protocol.tex

@@ -81,8 +81,15 @@
 % included in the paper).
 %\newcommand{\COMM}[1]{\mathbf{COMM_{#1}}}
 
+%eli macros
+\usepackage{color}
+\newcommand{\eli}[1]{{\color{magenta}\sf{Eli: #1}}}
+
+
+
 \newcommand{\BucketCommitment}[1]{\mathtt{BucketCommitment(#1)}}
 
+
 \begin{document}
 
 \title{Zcash Protocol Specification}
@@ -107,7 +114,7 @@ $\CRH$ is a collision-resistant hash function. In \Zcash, the $\SHAName$ functio
 
 \subparagraph{}
 
-$\PRF{x}{}$ is a pseudo-random function seeded by $x$. Three \textit{independent} $\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFsn{x}$, and $\PRFpk{x}{i}$. It is required that $\PRFsn{x}$ be collision-resistant in order to prevent a double-spending attack. In \Zcash, the $\SHAName$ function is used to seed all three of these functions. The bits $\mathtt{00}$, $\mathtt{01}$ and $\mathtt{10}$ are included (respectively) within the blocks that are hashed, ensuring that the functions are independent.
+$\PRF{x}{}$ is a pseudo-random function seeded by $x$. Three \textit{independent} $\PRF{x}{}$ are needed in our scheme: $\PRFaddr{x}$, $\PRFsn{x}$, and $\PRFpk{x}{i}$. It is required that $\PRFsn{x}$ be collision-resistant in order to prevent a double-spending attack \eli{I don't see how to use a collision to double spend. If anything, a collision in $\PRFpk{x}{i}$ seems more usable to double spend}. In \Zcash, the $\SHAName$ function is used to seed all three of these functions. The bits $\mathtt{00}$, $\mathtt{01}$ and $\mathtt{10}$ are included (respectively) within the blocks that are hashed, ensuring that the functions are independent.
 
 \begin{equation*}
 \SpendAuthorityPublic = \PRFaddr{\SpendAuthorityPrivate}(0) = \CRH\left(
@@ -154,13 +161,14 @@ h_i = \PRFpk{\SpendAuthorityPrivate}{i}(\hSig) = \CRH\left(
 
 \subparagraph{}
 
-A keypair $(\PublicAddress, \PrivateAddress)$ is generated by a user any time they wish to receive value from another in the system. The public $\PublicAddress$ is called a $\PublicAddressName$ and is a tuple $(\SpendAuthorityPublic, \TransmitPublic)$ which are the public components of a $\SpendAuthorityName$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\TransmitName$ keypair $(\TransmitPublic, \TransmitPrivate)$. The private $\PrivateAddress$ is called a $\PrivateAddressName$ and is a tuple $(\SpendAuthorityPrivate, \TransmitPrivate)$ which are the respective \textit{private} components of the aforementioned $\SpendAuthorityName$ and $\TransmitName$ keypairs.
+A keypair $(\PublicAddress, \PrivateAddress)$ is generated by a user any time they wish to receive value from another in the system \eli{The previous sentence seems to imply that a fresh pair is needed for each new receive, but this isn't the case. Perhaps change to ``To receive/pay values in the system, a user must set-up a key pair \ldots; differing from Bitcoin, replacing keys is not needed to protect privacy.''}. The public $\PublicAddress$ is called a $\PublicAddressName$ and is a tuple $(\SpendAuthorityPublic, \TransmitPublic)$ which are the public components of a $\SpendAuthorityName$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ and a $\TransmitName$ keypair $(\TransmitPublic, \TransmitPrivate)$. The private $\PrivateAddress$ is called a $\PrivateAddressName$ and is a tuple $(\SpendAuthorityPrivate, \TransmitPrivate)$ which are the respective \textit{private} components of the aforementioned $\SpendAuthorityName$ and $\TransmitName$ keypairs.
 
 \subsection{Buckets}
 
 \subparagraph{}
 
-A bucket (denoted $\Bucket$) is a tuple $(\Value, \SpendAuthorityPublic_{i}, \BucketRand, \BucketAddressRand)$ which represents that a value $\Value$ is spendable by the recipient who holds the $\SpendAuthorityName$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$. $\BucketRand$ and $\BucketAddressRand$ are randomly generated tokens which are used to blind the value and recipient \textit{except} to those who possess these tokens.
+A bucket (denoted $\Bucket$) is a tuple $(\Value, \SpendAuthorityPublic_{i}, \BucketRand, \BucketAddressRand)$ \eli{subscript $i$ should be removed from bucket} which represents that a value $\Value$ is spendable by the recipient who holds the $\SpendAuthorityName$ keypair $(\SpendAuthorityPublic, \SpendAuthorityPrivate)$ \eli{more precise: any user that knows $\SpendAuthorityPrivate$ such that $\SpendAuthorityPublic=\PRFaddr{\SpendAuthorityPrivate}(0)$}. $\BucketRand$ and $\BucketAddressRand$ are randomly generated tokens which are used to blind the value and recipient \textit{except} to those who possess these tokens. \eli{last sentence unclear. Zcash transactions contain only hashes of financial information
+(like $\Value$ and $\SpendAuthorityPublic$) and $\BucketRand$ and $\BucketAddressRand$ are used to hide this data.}
 
 \subparagraph{In-band secret distribution}
 
@@ -209,11 +217,12 @@ The underlying $\Value$ and $\SpendAuthorityPublic$ are blinded with $\BucketRan
 
 \end{flushright}
 
-We say that the bucket commitment of a bucket $\Bucket$ = $\BucketCommitment{\Bucket}$.
+We say that the bucket commitment of a bucket $\Bucket$ = $\BucketCommitment{\Bucket}$.\eli{circular definition: $b=f(b)$?}
 
 \subparagraph{Serials}
 
-A serial $\sn$ is produced by $\PRFsn{\SpendAuthorityPrivate}(\BucketAddressRand)$. Part of the process of spending a bucket is disclosing this serial without disclosing either $\BucketAddressRand$ or $\SpendAuthorityPrivate$. This allows it to be used to prevent double-spending.
+A serial $\sn$ \eli{serial serial number?} is produced by \eli{equals?} $\PRFsn{\SpendAuthorityPrivate}(\BucketAddressRand)$. Part of the process of spending a bucket is disclosing this serial without disclosing either $\BucketAddressRand$ or $\SpendAuthorityPrivate$. This allows it to be used to prevent double-spending. \eli{More precise: \emph{Knowledge} of $\BucketAddressRand$ and $\SpendAuthorityPrivate$ is required to spend a bucket. Knowledge of $\BucketAddressRand$ and $\SpendAuthorityPrivate$ is proved without revealing it explicitly via a 
+zero-knowledge (zk)SNARK.}
 
 \subsection{Bucket Commitment Tree}
 
@@ -232,14 +241,14 @@ Blocks in the blockchain are associated (by all nodes) with the root of this tre
 \subsection{Spent Serials Map}
 
 \subparagraph{}
-
-Transactions insert serials into a \textit{spent serials map} which is maintained alongside the UTXO by all nodes. Transactions that attempt to insert a serial into this map that already exists within it are invalid as they are attempting to double-spend.
+\eli{Would be good to formally define the structure of a transaction, similar to the way a bucket is defined (as a quadruple).}
+Transactions insert \eli{a tx is just a string, so it doesn't insert anything. Rather, nodes process tx's and the ``good'' ones lead to the addition of serials to the spent serials map.} serials into a \textit{spent serials map} which is maintained alongside the UTXO by all nodes. Transactions that attempt to insert a serial into this map that already exists within it are invalid as they are attempting to double-spend. \eli{After defining \emph{transaction}, one should define what a \emph{legal tx} is (this definition depends on a particular blockchain) and only then can one talk about ``attempts'' of transactions, and insertions of serial numbers into the spent serials map.}
 
 \subsection{Bitcoin Transactions}
 
 \subparagraph{}
-
-Bitcoin transactions consist of a vector of inputs ($\mathtt{vin}$) and a vector of outputs ($\mathtt{vout}$). Inputs and outputs are associated with a value. The total value of the outputs must not exceed the total value of the inputs.
+\eli{Please formally define what a tx is. I don't think it's merely a sequence of inputs and outputs. The outputs are probably buckets (as defined above) and maybe the inputs are, too. Perhaps one should talk about a tx-bucket (which is unhidden) and a tx which is mostly hashed-stuff + a SNARK)}
+Bitcoin transactions consist of a vector \eli{sequence? vector implies ``vector space'' which doens't exist here} of inputs ($\mathtt{vin}$) and a vector of outputs ($\mathtt{vout}$). Inputs and outputs are associated with a value \eli{assuing a tx-bucket is a pair of sequences --- an input-sequence and an output-sequence, and each sequence is a sequence of buckets, one should define the in-value of the tx-bucket as the sum of values in the in-buckets (ditto for out-value) and the remaining value is their difference}. The total value of the outputs must not exceed the total value of the inputs.
 
 \subparagraph{Value pool}
 
@@ -247,10 +256,11 @@ Transaction inputs insert value into a \textit{value pool}, and transaction outp
 
 \section{Pour}
 
+\eli{Hmm, I think things are starting to get confused here, let's try to clarify the theory/crypto. Informally, buckets and transactions are \emph{data}, whereas Pour is best thought of as a \emph{circuit} that outputs either $1$ (``true'') or $0$ (``false''). The theory of SNARKs (as supported by libsnark) is such that if the circuit outputs ``true'' then you can generate a SNARK for that set of inputs, and otherwise you can't (its cryptographically infeasible to do so). So we should describe formally what the \emph{inputs} to the Pour circuit are, and then define the \emph{computation preformed} by the Pour circuit, i.e., describe how it decides whether to output $0$ or $1$. More below}
 \subparagraph{}
 
-$\Pour$s are the primary operations performed by transactions that interact with our scheme. In principle, it is the action of spending $\Nold$ buckets $\bOld{}$ and creating $\Nnew$ buckets $\bNew{}$. \Zcash transactions have an additional field $\vpour$, which is a vector of $\Pour$s. Each $\Pour$ consists of:
-
+$\Pour$s are the primary operations \eli{In the academic paper, a Pour is a circuit (that defines an NP-language), and that circuit is the most crucial part of the construction. So if you want to use ``Pour'' to describe the algorithm that generates a tx, you'll be (i) deviating from the academic paper in a rather confusing way and (ii) you still need to define the ``Pour-circuit'' which is at the heart of the construction} performed by transactions that interact with our scheme. In principle, it is the action of spending $\Nold$ buckets $\bOld{}$ and creating $\Nnew$ buckets $\bNew{}$. \Zcash transactions have an additional field $\vpour$, which is a vector of $\Pour$s. Each $\Pour$ consists of:
+\eli{reached here}
 \begin{list}{}{}
 
 \item $\vpubOld$ which is a value $\vpubold$ that the pour removes from the value pool.