Correct the types and consensus rules for tx and block version numbers.

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

protocol/protocol.tex

@@ -174,6 +174,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\CryptoNote}{\termbf{CryptoNote}}
 \newcommand{\ZEC}{\termbf{ZEC}}
 \newcommand{\zatoshi}{\term{zatoshi}}
+\newcommand{\zcashd}{\textsf{zcashd}\,}
 
 \newcommand{\MUST}{\conformance{MUST}}
 \newcommand{\MUSTNOT}{\conformance{MUST NOT}}
@@ -249,6 +250,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\Blockheader}{\term{Block header}}
 \newcommand{\BlockHeader}{\titleterm{Block Header}}
 \newcommand{\blockVersionNumber}{\term{block version number}}
+\newcommand{\blockVersionNumbers}{\term{block version numbers}}
 \newcommand{\Blockversions}{\term{Block versions}}
 \newcommand{\blockTime}{\term{block time}}
 \newcommand{\blockHeight}{\term{block height}}
@@ -260,6 +262,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\transactionFee}{\term{transaction fee}}
 \newcommand{\transactionFees}{\term{transaction fees}}
 \newcommand{\transactionVersionNumber}{\term{transaction version number}}
+\newcommand{\transactionVersionNumbers}{\term{transaction version numbers}}
 \newcommand{\Transactionversion}{\term{Transaction version}}
 \newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
 \newcommand{\coinbaseTransactions}{\term{coinbase transactions}}
@@ -3035,7 +3038,7 @@ The \Zcash \transaction format is as follows:
 Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
 \hhline{|=|=|=|=|}
 
-4 & $\versionField$ & \type{uint32\_t} & Transaction version number; either 1 or 2. \\ \hline
+4 & $\versionField$ & \type{int32\_t} & Transaction version number; either 1 or 2. \\ \hline
 
 \Varies & $\txInCount$ & \compactSize & Number of \transparent inputs in this transaction. \\ \hline
 
@@ -3071,7 +3074,7 @@ The encoding of $\joinSplitPubKey$ and the data to be signed are specified in
 \crossref{nonmalleability}.
 
 \begin{consensusrules}
-  \item The \transactionVersionNumber{} \MUST be either 1 or 2.
+  \item The \transactionVersionNumber{} \MUST be greater than or equal to 1.
   \item A \transaction with one or more coinbase inputs \MUST have no \transparent outputs
         (i.e.\ \txOutCount{} \MUST be 0).
   \item If $\versionField = 1$ or $\nJoinSplit = 0$, then \txInCount{} \MUSTNOT be 0.
@@ -3081,16 +3084,33 @@ The encoding of $\joinSplitPubKey$ and the data to be signed are specified in
   \item \todo{Other rules inherited from \Bitcoin.}
 \end{consensusrules}
 
+\begin{pnotes}
+  \item The semantics of \transactions with \transactionVersionNumber{} not equal
+        to either 1 or 2 is not currently defined. Miners \MUSTNOT create \blocks
+        containing such \transactions.
+  \item The exclusion of \transactions with \transactionVersionNumber{}
+        \emph{greater than} 2 is not a consensus rule; such \transactions may
+        exist in the \blockchain and \MUST be treated identically to version 2
+        \transactions by \fullnodes. Note that a future hard fork might use
+        \transactionVersionNumber{} either greater than 2, or less than 1.
+        It is likely that such a hard fork will change the \transaction format,
+        and software that parses \transactions{} \SHOULD take this into account.
+  \item The $\versionField$ field is a signed integer. (It was incorrectly specified
+        as unsigned in a previous version of this specification.) A future hard fork
+        might use negative values for this field, or otherwise change its interpretation.
+  \item A \transactionVersionNumber of 2 does not have the same meaning as in
+        \Bitcoin, where it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY}
+        as specified in \cite{BIP-68}. \Zcash was forked from \Bitcoin v0.11.2
+        and does not currently support BIP 68, or the related BIPs 9, 112 and 113.
+\end{pnotes}
+
 \introlist
 The changes relative to \Bitcoin version 1 transactions as described in \cite{Bitcoin-Format} are:
 
 \begin{itemize}
-  \item \Transactionversion 0 is not supported. A version 1 \transaction is
+  \item \Transactionversion 0 is not supported.
-        equivalent to a version 2 \transaction with $\nJoinSplit = 0$. Software that parses
+  \item A version 1 \transaction is equivalent to a version 2 \transaction with
-        \transactions{} \MUSTNOT assume, when an encoded \transaction starts with a
+        $\nJoinSplit = 0$.
-        $\versionField$ field representing a value other than 1 or 2 (either the past \Bitcoin
-        version 0, or future versions introduced by hard forks), that it will be parseable
-        according to this format.
   \item The $\nJoinSplit$, $\vJoinSplit$, $\joinSplitPubKey$, and $\joinSplitSig$ fields
         have been added.
   \item In \Zcash it is permitted for a \transaction to have no \transparent inputs provided
@@ -3100,14 +3120,7 @@ The changes relative to \Bitcoin version 1 transactions as described in \cite{Bi
 Software that creates \transactions{} \SHOULD use version 1 for \transactions with no
 \joinSplitDescriptions.
 
-\pnote{
+\introsection
-A \transactionVersionNumber of 2 does not have the same meaning as in \Bitcoin, where
-it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY} as specified in \cite{BIP-68}.
-\Zcash was forked from \Bitcoin v0.11.2 and does not currently support BIP 68, or the related BIPs
-9, 112 and 113.
-}
-
-\introlist
 \nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
 
 An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in
@@ -3176,7 +3189,7 @@ The \Zcash \blockHeader format is as follows:
 Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
 \hhline{|=|=|=|=|}
 
-4 & $\nVersion$ & \type{uint32\_t} & The \blockVersionNumber indicates which set of
+4 & $\nVersion$ & \type{int32\_t} & The \blockVersionNumber indicates which set of
 \block validation rules to follow. The current and only defined \blockVersionNumber
 for \Zcash is $4$. \\ \hline
 
@@ -3207,11 +3220,15 @@ started hashing the \header (according to the miner). \\ \hline
 \end{tabularx}
 \end{center}
 
+A \block consists of a \blockHeader and a sequence of \transactions. How transactions
+are encoded in a \block is part of the Zcash peer-to-peer protocol but not part of
+the consensus protocol.
+
 Let $\ThresholdBits$ be as defined in \crossref{diffadjustment}, and let $\PoWMedianBlockSpan$
 be the constant defined in \crossref{constants}.
 
 \begin{consensusrules}
-  \item The \blockVersionNumber{} \MUST be 4.
+  \item The \blockVersionNumber{} \MUST be greater than or equal to 4.
   \item For a \block at \blockHeight $\BlockHeight$, \nBitsField{} \MUST be equal to
         $\ThresholdBits(\BlockHeight)$.
   \item The \block{} \MUST pass the difficulty filter defined in \crossref{difficulty}.
@@ -3227,20 +3244,21 @@ in the future according to its clock. This is not strictly a consensus rule beca
 nondeterministic, and clock time varies between nodes. Also note that a \block that is
 rejected by this rule at a given point in time may later be accepted.
 
-\introlist
-The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are:
-
-\begin{itemize}
-  \item \Blockversions prior to 4 are not supported. Software that parses \blocks{} \MUSTNOT
-        assume, when an encoded \block starts with an $\nVersion$ field representing a value
-        other than 4 (either past \Bitcoin versions, or future versions potentially introduced
-        by hard forks), that it will be parseable according to this format.
-  \item The $\hashReserved$, $\solutionSize$, and $\solution$ fields have been added.
-  \item The type of the $\nNonce$ field has changed from \type{uint32\_t} to \type{char[32]}.
-  \item The maximum \block size has been doubled to 2000000 bytes.
-\end{itemize}
-
 \begin{pnotes}
+  \item The semantics of blocks with \blockVersionNumber{} not equal to 4
+        is not currently defined. Miners \MUSTNOT create such \blocks, and
+        \SHOULDNOT mine other blocks on top of them.
+  \item The exclusion of \blocks with \blockVersionNumber{} \emph{greater than} 4
+        is not a consensus rule; such \blocks may exist in the \blockchain
+        and \MUST be treated identically to version 4 \blocks by \fullnodes.
+        Note that a future hard fork might use \blockVersionNumber{} either
+        greater than or less than 4. It is likely that such a hard fork will
+        change the \block header and/or \transaction format, and software that
+        parses \blocks{} \SHOULD take this into account.
+  \item The $\nVersion$ field is a signed integer. (It was incorrectly specified
+        as unsigned in a previous version of this specification.) A future
+        hard fork might use negative values for this field, or otherwise change
+        its interpretation.
   \item There is no relation between the values of the $\versionField$ field of a \transaction,
         and the $\nVersion$ field of a \blockHeader.
   \item Like other serialized fields of type $\compactSize$, the $\solutionSize$ field \MUST
@@ -3254,6 +3272,17 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-
         but has now been corrected.
 \end{pnotes}
 
+\introlist
+The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are:
+
+\begin{itemize}
+  \item \Blockversions less than 4 are not supported.
+  \item The $\hashReserved$, $\solutionSize$, and $\solution$ fields have been added.
+  \item The type of the $\nNonce$ field has changed from \type{uint32\_t} to \type{char[32]}.
+  \item The maximum \block size has been doubled to 2000000 bytes.
+\end{itemize}
+
+
 \nsubsection{Proof of Work}
 
 \Zcash uses Equihash \cite{BK2016} as its Proof of Work. Motivations for
@@ -4157,6 +4186,9 @@ The errors in the proof of Ledger Indistinguishability mentioned in
 \subparagraph{2017.0-beta-2.7}
 
 \begin{itemize}
+    \item Correct the types and consensus rules for \transactionVersionNumbers
+          and \blockVersionNumbers. (Again, the implementation in \zcashd was as
+          intended.)
     \item Clarify the computation of $\h{i}$ in a \joinSplitStatement.
 \end{itemize}