mirror of https://github.com/zcash/zips.git
Correct the types and consensus rules for tx and block version numbers.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
a197958131
commit
215aca1c15
|
@ -174,6 +174,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
|
||||||
\newcommand{\CryptoNote}{\termbf{CryptoNote}}
|
\newcommand{\CryptoNote}{\termbf{CryptoNote}}
|
||||||
\newcommand{\ZEC}{\termbf{ZEC}}
|
\newcommand{\ZEC}{\termbf{ZEC}}
|
||||||
\newcommand{\zatoshi}{\term{zatoshi}}
|
\newcommand{\zatoshi}{\term{zatoshi}}
|
||||||
|
\newcommand{\zcashd}{\textsf{zcashd}\,}
|
||||||
|
|
||||||
\newcommand{\MUST}{\conformance{MUST}}
|
\newcommand{\MUST}{\conformance{MUST}}
|
||||||
\newcommand{\MUSTNOT}{\conformance{MUST NOT}}
|
\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}{\term{Block header}}
|
||||||
\newcommand{\BlockHeader}{\titleterm{Block Header}}
|
\newcommand{\BlockHeader}{\titleterm{Block Header}}
|
||||||
\newcommand{\blockVersionNumber}{\term{block version number}}
|
\newcommand{\blockVersionNumber}{\term{block version number}}
|
||||||
|
\newcommand{\blockVersionNumbers}{\term{block version numbers}}
|
||||||
\newcommand{\Blockversions}{\term{Block versions}}
|
\newcommand{\Blockversions}{\term{Block versions}}
|
||||||
\newcommand{\blockTime}{\term{block time}}
|
\newcommand{\blockTime}{\term{block time}}
|
||||||
\newcommand{\blockHeight}{\term{block height}}
|
\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{\transactionFee}{\term{transaction fee}}
|
||||||
\newcommand{\transactionFees}{\term{transaction fees}}
|
\newcommand{\transactionFees}{\term{transaction fees}}
|
||||||
\newcommand{\transactionVersionNumber}{\term{transaction version number}}
|
\newcommand{\transactionVersionNumber}{\term{transaction version number}}
|
||||||
|
\newcommand{\transactionVersionNumbers}{\term{transaction version numbers}}
|
||||||
\newcommand{\Transactionversion}{\term{Transaction version}}
|
\newcommand{\Transactionversion}{\term{Transaction version}}
|
||||||
\newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
|
\newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
|
||||||
\newcommand{\coinbaseTransactions}{\term{coinbase transactions}}
|
\newcommand{\coinbaseTransactions}{\term{coinbase transactions}}
|
||||||
|
@ -3035,7 +3038,7 @@ The \Zcash \transaction format is as follows:
|
||||||
Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
|
Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
|
||||||
\hhline{|=|=|=|=|}
|
\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
|
\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}.
|
\crossref{nonmalleability}.
|
||||||
|
|
||||||
\begin{consensusrules}
|
\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
|
\item A \transaction with one or more coinbase inputs \MUST have no \transparent outputs
|
||||||
(i.e.\ \txOutCount{} \MUST be 0).
|
(i.e.\ \txOutCount{} \MUST be 0).
|
||||||
\item If $\versionField = 1$ or $\nJoinSplit = 0$, then \txInCount{} \MUSTNOT 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.}
|
\item \todo{Other rules inherited from \Bitcoin.}
|
||||||
\end{consensusrules}
|
\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
|
\introlist
|
||||||
The changes relative to \Bitcoin version 1 transactions as described in \cite{Bitcoin-Format} are:
|
The changes relative to \Bitcoin version 1 transactions as described in \cite{Bitcoin-Format} are:
|
||||||
|
|
||||||
\begin{itemize}
|
\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
|
\item The $\nJoinSplit$, $\vJoinSplit$, $\joinSplitPubKey$, and $\joinSplitSig$ fields
|
||||||
have been added.
|
have been added.
|
||||||
\item In \Zcash it is permitted for a \transaction to have no \transparent inputs provided
|
\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
|
Software that creates \transactions{} \SHOULD use version 1 for \transactions with no
|
||||||
\joinSplitDescriptions.
|
\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}
|
\nsubsection{Encoding of \JoinSplitDescriptions} \label{joinsplitencoding}
|
||||||
|
|
||||||
An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in
|
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} \\
|
Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
|
||||||
\hhline{|=|=|=|=|}
|
\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
|
\block validation rules to follow. The current and only defined \blockVersionNumber
|
||||||
for \Zcash is $4$. \\ \hline
|
for \Zcash is $4$. \\ \hline
|
||||||
|
|
||||||
|
@ -3207,11 +3220,15 @@ started hashing the \header (according to the miner). \\ \hline
|
||||||
\end{tabularx}
|
\end{tabularx}
|
||||||
\end{center}
|
\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$
|
Let $\ThresholdBits$ be as defined in \crossref{diffadjustment}, and let $\PoWMedianBlockSpan$
|
||||||
be the constant defined in \crossref{constants}.
|
be the constant defined in \crossref{constants}.
|
||||||
|
|
||||||
\begin{consensusrules}
|
\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
|
\item For a \block at \blockHeight $\BlockHeight$, \nBitsField{} \MUST be equal to
|
||||||
$\ThresholdBits(\BlockHeight)$.
|
$\ThresholdBits(\BlockHeight)$.
|
||||||
\item The \block{} \MUST pass the difficulty filter defined in \crossref{difficulty}.
|
\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
|
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.
|
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}
|
\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,
|
\item There is no relation between the values of the $\versionField$ field of a \transaction,
|
||||||
and the $\nVersion$ field of a \blockHeader.
|
and the $\nVersion$ field of a \blockHeader.
|
||||||
\item Like other serialized fields of type $\compactSize$, the $\solutionSize$ field \MUST
|
\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.
|
but has now been corrected.
|
||||||
\end{pnotes}
|
\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}
|
\nsubsection{Proof of Work}
|
||||||
|
|
||||||
\Zcash uses Equihash \cite{BK2016} as its Proof of Work. Motivations for
|
\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}
|
\subparagraph{2017.0-beta-2.7}
|
||||||
|
|
||||||
\begin{itemize}
|
\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.
|
\item Clarify the computation of $\h{i}$ in a \joinSplitStatement.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue