Reference the extended Zerocash paper, not the conference version.

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

protocol/protocol.tex

@@ -419,7 +419,7 @@
 \nsection{Introduction}
 
 \Zcash is an implementation of the \term{Decentralized Anonymous Payment}
-scheme \Zerocash \cite{ZerocashOakland} with some adjustments to terminology,
+scheme \Zerocash \cite{Zerocash} with some adjustments to terminology,
 functionality and performance. It bridges the existing \emph{transparent}
 payment scheme used by \Bitcoin with a \emph{confidential} payment scheme
 protected by zero-knowledge succinct non-interactive arguments of knowledge
@@ -437,7 +437,7 @@ This specification is structured as follows:
   \item Concrete Protocol | how the functions and encodings of the abstract
         protocol are instantiated;
   \item Differences from the \Zerocash protocol | a summary of changes from the
-        protocol in \cite{ZerocashOakland}.
+        protocol in \cite{Zerocash}.
 \end{itemize}
 
 
@@ -1068,7 +1068,7 @@ treated like an \emph{output} value, whereas} $\vpubNew$ is treated like an
 \emph{input} value.
 
 \changed{
-Note that unlike original \Zerocash \cite{ZerocashOakland}, \Zcash does not have
+Note that unlike original \Zerocash \cite{Zerocash}, \Zcash does not have
 a distinction between Mint and Pour operations. The addition of $\vpubOld$ to a
 \joinSplitDescription subsumes the functionality of both Mint and Pour. Also,
 \joinSplitDescriptions are indistinguishable regardless of the number of real input
@@ -1127,7 +1127,7 @@ $\treepath{i}$ must be a valid \merklePath of depth $\MerkleDepth$, as defined i
 \crossref{merkle}, from $\Commitment(\nOld{i})$ to \noteCommitmentTree root $\rt$.
 
 \textbf{Note:} Merkle path validity covers both conditions 1. (a) and 1. (d) of the NP statement
-given in section 4.2 of \cite{ZerocashOakland}.
+given in section 4.2 of \cite{Zerocash}.
 
 \subparagraph{Balance}
 
@@ -1247,7 +1247,7 @@ is defined as follows:
 }
 
 Note that this corresponds to step 3 (b) i. and ii. (first bullet point) of the
-$\Receive$ algorithm shown in Figure 2 of \cite{ZerocashOakland}.
+$\Receive$ algorithm shown in Figure 2 of \cite{Zerocash}.
 
 To test whether a \note is unspent in a particular \blockchainview also requires
 the \spendingKey $\AuthPrivate$; the coin is unspent if and only if
@@ -1858,7 +1858,7 @@ multiple \notes with different $\Value$ and $\NoteCommitRand$
 
 An adversary can use this to mislead a \note recipient, by sending
 two \notes both of which are verified as valid by $\Receive$ (as
-defined in Figure 2 of \cite{ZerocashOakland}), but only one of
+defined in Figure 2 of \cite{Zerocash}), but only one of
 which can be spent.
 
 We call this a ``Faerie Gold'' attack --- referring to various Celtic
@@ -1867,7 +1867,7 @@ but which soon after reveals itself to be leaves, gorse blossoms,
 gingerbread cakes, or other less valuable things \cite{LG2004}.
 
 This attack does not violate the security definitions given in
-\cite{ZerocashOakland}. The issue could be framed as a problem
+\cite{Zerocash}. The issue could be framed as a problem
 either with the definition of Completeness, or the definition of
 Balance:
 
@@ -1949,7 +1949,7 @@ currency for themself. \cite{fixingvulns}
 for the commitment. The motivation for the nested construction in \Zerocash
 was to allow Mint transactions to be publically verified without requiring
 a ZK proof (as described under step 3 in section 1.3 of
-\cite{ZerocashOakland}). Since \Zcash combines ``Mint'' and ``Pour''
+\cite{Zerocash}). Since \Zcash combines ``Mint'' and ``Pour''
 transactions into a generalized \joinSplitTransfer which always uses a ZK proof,
 it does not require the nesting. A side benefit is that this reduces the
 number of $\SHA$ evaluations needed to compute each \noteCommitment from
@@ -1958,7 +1958,7 @@ three to two, saving a total of four $\SHA$ evaluations in the
 
 Note that \Zcash \noteCommitments are not statistically hiding, and
 so \Zcash does not support the ``everlasting anonymity'' property
-described in section 8.1 of the \Zerocash paper \cite{ZerocashOakland},
+described in section 8.1 of the \Zerocash paper \cite{Zerocash},
 even when used as described in that section. While it is possible to
 define a statistically hiding, computationally binding commitment scheme
 for this use at a 128-bit security level, the overhead of doing so
@@ -2024,6 +2024,8 @@ of $\PRFaddr{}$ was found by Daira Hopwood.
           relating to the in-band secret distribution.
     \item Add various citations: the ``Fixing Vulnerabilities in the Zcash
           Protocol'' blog post, and several crypto papers for security definitions.
+    \item Reference the extended version of the \Zerocash paper rather than the
+          Oakland proceedings version.
     \item Add \joinSplitTransfers to the Concepts section.
     \item Add a section on Coinbase Transactions.
     \item Add type declarations for functions.

protocol/zcash.bib

@@ -1,10 +1,10 @@
-@inproceedings{ZerocashOakland,
+@misc{Zerocash,
    author={Eli Ben-Sasson and Alessandro Chiesa and Christina Garman and Matthew Green and Ian Miers and Eran Tromer and Madars Virza},
-   year={2014},
-   title={Zerocash: Decentralized {A}nonymous {P}ayments from {B}itcoin},
-   booktitle={Proceedings of the IEEE Symposium on Security and Privacy (Oakland) 2014},
-   pages={459-474},
-   publisher={IEEE}
+   title={Zerocash: Decentralized {A}nonymous {P}ayments from {B}itcoin (extended version)},
+   howpublished={\url{http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf}.
+Accessed: \mbox{2016-08-06}.
+A condensed version appeared in \textsl{Proceedings of the IEEE Symposium on Security and Privacy (Oakland) 2014},
+pages 459--474; IEEE, 2014.}
 }
 
 @misc{Base58Check,