Explain the use of interstitial treestates in chained JoinSplits. fixes #82

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

protocol/protocol.tex

@@ -1192,7 +1192,8 @@ In a given \blockchain, \treestates are chained as follows:
         \transaction.
 \end{itemize}
 
-\todo{\joinSplitDescriptions also have input and output \treestates.}
+\joinSplitDescriptions also have interstitial input and output \treestates, explained
+in the following section.
 
 
 \nsubsection{\JoinSplitTransfers{} and Descriptions} \label{joinsplit}
@@ -1211,12 +1212,28 @@ Each \transaction is associated with a \sequenceOfJoinSplitDescriptions.
 The \changed{total $\vpubNew$ value adds to, and the total} $\vpubOld$
 value subtracts from the \transparentValuePool of the containing \transaction.
 
+The \anchor of each \joinSplitDescription in a \transaction{} refers to a
+\treestate. For the first \joinSplitDescription, this \MUST be the output
+\treestate of a previous \block.
+
+\changed{
+For each \joinSplitDescription in a \transaction, an interstitial output \treestate is
+constructed which adds the \noteCommitments and \nullifiers specified in that
+\joinSplitDescription to the input \treestate referred to by its \anchor.
+This interstitial output \treestate is available for use as the \anchor of subsequent
+\joinSplitDescriptions in the same \transaction.
+
+Interstitial \treestates are necessary because when a \transaction is constructed,
+it is not known where it will eventually appear in a mined \block. Therefore the
+\anchors that it uses must be independent of its eventual position.
+}
+
 \begin{consensusrules}
   \item The input and output values of each \joinSplitTransfer{} \MUST balance
         exactly.
 \changed{
   \item The \anchor of each \joinSplitDescription in a \transaction{} \MUST refer
-        to either some earlier \block's final \treestate, or to the output
+        to either some earlier \block's final \treestate, or to the interstitial output
         \treestate of any prior \joinSplitDescription in the same \transaction.
 }
 \end{consensusrules}
@@ -1233,10 +1250,8 @@ transaction output set} (UTXO set) used in \Bitcoin, it is used to express the e
 of value and the capability to spend it. However, unlike the UTXO set, it is \emph{not}
 the job of this tree to protect against double-spending, as it is append-only.
 
-Blocks in the \blockchain are associated (by all nodes) with the \merkleRoot of this tree
-after all of its constituent \joinSplitDescriptions' \noteCommitments have been
-entered into the \noteCommitmentTree associated with the previous \block.
-\todo{Make this more precise.}
+A \merkleRoot of this tree is associated with each \treestate, as described in
+\crossref{transactions}.
 
 Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash of
 size $\MerkleHashLength$ bits.
@@ -4091,6 +4106,7 @@ The errors in the proof of Ledger Indistinguishability mentioned in
     \item Specify the security requirements on the $\SHAName$ function in order
           for the scheme in \crossref{concretecomm} to be a secure commitment.
     \item Specify $\GroupG{2}$ more precisely.
+    \item Explain the use of interstitial \treestates in chained \joinSplitTransfers.
 \end{itemize}
 
 \introlist