more comments

protocol/protocol.tex

@@ -625,7 +625,7 @@
 \newcommand{\concern}[1]{\eli{Concern}{#1}}
 \newcommand{\reorder}[1]{\eli{Suggested reordering}{#1}}
 \newcommand{\improve}[1]{\eli{Suggested improvement}{#1}}
-
+\newcommand{\general}[1]{\eli{General comment}{#1}}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%% end Eli macros
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -644,6 +644,8 @@
 
 
 \nsection{Introduction}
+\general{Who is the intended reader of this document? Someone who wishes to build a node/miner/wallet?
+In particular, what's the relation between this document and the existing code?}
 \Zcash is an implementation of the \term{Decentralized Anonymous Payment}
 scheme \Zerocash \cite{BCG+2014}, with some security fixes and adjustments
 to terminology, functionality and performance. It bridges the existing
@@ -682,7 +684,10 @@ This specification is structured as follows:
 
 \nsubsection{Caution}
 
-\concern{Shouldn't this document, or even this section, contain some legal boilerplate suggested by ZECC legal counsel?}
+\concern{Shouldn't this document, or even this section, also contain some legal boilerplate suggested by ZECC legal counsel?
+This could prevent readers from claiming wrong-doing because of internal inconsistencies in the paper and/or inconsistencies
+between this paper and the released code (DAO should serve as a reminder of the potential outcomes of such discrepancies).}
+
 
 \Zcash security depends on consensus. Should a program interacting with the
 \Zcash network diverge from consensus, its security will be weakened or destroyed.
@@ -714,7 +719,7 @@ were called ``serial numbers''.},
 which specify an amount and a \payingKey. The \payingKey is part of
 a \paymentAddress, which is a destination to which \notes can be sent.
 As in \Bitcoin, this is associated with a private key
-\typo{private key->spending key here? This would
+\typo{private key perhaps should be spending key here? This would
 remove the need for last snippet in this paragraph}
 that can be used to
 spend \notes sent to the address; in \Zcash this
@@ -1027,14 +1032,23 @@ As in \Bitcoin, the remaining value in the pool is
 available to miners as a fee. \reorder{This last paragraph should likely go elsewhere, it stops the
 discussion of trees and feels out of place here.}
 
-An \anchor is a Merkle tree root of a \noteCommitmentTree. \question{Later (page 23)
-an anchor is defined as one of two possible things, please clarify} It uniquely identifies
+An \anchor is a Merkle tree root of a \noteCommitmentTree.
+\question{In \crossref{joinsplitencoding} an anchor is defined as one of two possible things, needs clarification. See suggestion next.}
+\improve{Given a sequence $S=(c_1,\ldots, c_n)$ of coin commitments, let $h(S)$ be its Merkle-tree based hash.
+Given a transaction containing an ordered sequence $JS_1,\ldots, JS_m$ of JoinSplit descriptions,
+an \anchor is defined inductively thus: the anchor of $JS_1$ must be $h(S_1)$ for some prefix $S_1$ of the block-chain
+and for $i\in \{2,\ldots, m\}$ an \anchor is $h(S_i)$ where $S_i$ must be either some prefix of the block-chain,
+or a sequence $S_{i'}\circ JS_{i'}$ for some $i'<i$ where $\circ$ denotes sequence-concatenation.}
+It uniquely identifies
 a \noteCommitmentTree state given the assumed security properties of the Merkle tree's
 hash function. Since the \nullifierSet is always updated together with the
 \noteCommitmentTree, this also identifies a particular state of the \nullifierSet.
 
 In a given node's \blockchainview, \treestates are chained \question{What does chained mean?
-I think you want to say ``defined inductively'' instead}
+I think you want to say ``defined inductively'' instead. }
+\improve{Since there is a unique mapping from a sequence (of blocks/transactions) to a hash,
+I think it would simplify things to explain once this mapping, later talk about $HASH(sequence)$,
+this can simplify, e.g., the interstitial JS reference.}
 as follows:
 
 \begin{itemize}
@@ -1102,12 +1116,7 @@ Blocks in the \blockchain are associated (by all nodes) with the \merkleRoot of
 after all of its constituent \joinSplitDescriptions' \noteCommitments have been
 entered into the \noteCommitmentTree associated with the previous \block.
 \todo{Make this more precise.}
-\question{Is this what's going on: each transaction corresponds to
-a Merkle tree of a fixed depth (what is it?) that is
-created by a \emph{payer}; later on, \emph{miners} place
-the roots of these trees at leaves of the block-chain tree. Notice the
-length of authentication paths will thus be the sum of depths of
-the two trees.}
+\improve{Using the deterministic mapping from a sequence to a hash value can help simplify exposition here.}
 
 Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash of
 size $\MerkleHashLength$ bytes.
@@ -1130,7 +1139,10 @@ it would otherwise result in a double-spend.
 
 \nsubsection{Block Subsidy and Founders' Reward} \label{subsidyconcepts}
 
-Like \Bitcoin, \Zcash creates currency when \blocks are mined. The value created on
+Like \Bitcoin, \Zcash creates currency when \blocks are mined.
+\typo{At some point in time this
+subsidy ends, right? the sentence above implies subsidy continues indefinitely}
+The value created on
 mining a \block is called the \blockSubsidy. It is composed of a \minerSubsidy and a
 \foundersReward. As in \Bitcoin, the miner of a \block also receives \transactionFees.
 
@@ -1483,8 +1495,10 @@ where
         a key agreement public key, used to derive the key for encryption
         of the \notesCiphertext (\crossref{inband})};
   \item \changed{$\RandomSeed \typecolon \RandomSeedType$ is
-        a seed that must \typo{hmm, its not clear how to enforce
-this, so perhaps must-> should} be chosen independently at random for each
+        a seed that must
+        \typo{its not clear how to enforce
+this, so perhaps must $\to$ should}
+be chosen independently at random for each
         \joinSplitDescription};
   \item $\h{\allOld} \typecolon \typeexp{\PRFOutput}{\NOld}$ is
         a sequence of tags that bind $\hSig$ to each
@@ -2029,7 +2043,7 @@ sequences.
 \securityrequirement{
 \typo{It sounds strange to require something that is formally
 false ($\SHA$ is a fixed function so cannot be
-formally collision resistant). How about requirement->assumption?}
+formally collision resistant). How about requirement $\to$ assumption?}
 $\SHA$ must be collision-resistant, and it must be infeasible to find a preimage $x$
 such that $\SHA(x) = \zeros{256}$.
 }
@@ -3080,13 +3094,20 @@ $\MaxBlockSubsidy$, and $\FoundersFraction$ are instantiated in \crossref{consta
 \todo{Any tx with a coinbase input must have no \transparent outputs (vout).}
 
 The \foundersReward is paid by a \transparent output in the \coinbaseTransaction, to
-one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHeight.
+one
+\typo{any one? presumably there will be some deterministic schedule according to which payments are rotated?}
+of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHeight.
+\question{what about miner subsidy? How is it paid?}
+\concern{This is one section that the legal team should look at. What happens if things change
+in the code, what's the correct version --- this paper or the code (recall DAO)?}
 
 Let $\SlowStartShift$ be defined as in the previous section.
 
 \renewcommand{\arraystretch}{0.95}
 
 For mainnet, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is \todo{}.
+\question{This description refers to a static list that is not updated with time.
+How will changes in ownership among stakeholders going to be reflected in this process?}
 
 For testnet, $\FounderAddressList_{\mathrm{1}..\NumFounderAddresses}$ is:
 
@@ -3130,7 +3151,9 @@ transaction type of the cryptocurrency on which it is based
 
 In \Zcash, there is only the original \Bitcoin transaction type,
 which is extended to contain a sequence of zero or more
-\Zcash-specific operations.
+\Zcash-specific operations. \typo{In many places (like the paragraph above) it would be
+better to talk about \emph{Basecoin} instead of \Bitcoin because the latter refers also to a particular
+payment system that is currently separated from \Zcash.}
 
 This allows for the possibility of chaining transfers of \xprotected
 value in a single \Zcash \transaction, e.g.\ to spend a \protectedNote