mirror of https://github.com/zcash/zips.git
Cosmetics.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
d0caaa2ee9
commit
205b2f5861
|
|
@ -4220,7 +4220,7 @@ random and an input, can be used to commit to the input in such a way that:
|
|||
\begin{itemize}
|
||||
\item no information is revealed about it without the \trapdoor (\quotedHiding); and
|
||||
\item given the \trapdoor and input, the commitment can be verified to \quotedtermandindex{open}{open (a commitment)}
|
||||
to that input and no other (\quotedBinding).\!\!
|
||||
to that input and no other (\quotedBinding)\rlap{.}
|
||||
\end{itemize}
|
||||
} %defining
|
||||
|
||||
|
|
@ -4808,7 +4808,7 @@ if this happens, discard the key and repeat with a different $\SpendingKey$.
|
|||
has length $252$ bits. It follows that the distribution of $\AuthSignPrivate$,
|
||||
i.e.\ $\PRFexpand{\SpendingKey}([0]) : \SpendingKey \leftarrowR \SpendingKeyType$,
|
||||
is computationally indistinguishable from $\SpendAuthSigGenPrivate{Sapling}()$ defined
|
||||
in \crossref{concretespendauthsig}.\!\!
|
||||
in \crossref{concretespendauthsig}\rlap{.}
|
||||
\vspace{-0.5ex}
|
||||
\item The distribution of $\AuthProvePrivate$, i.e.\
|
||||
$\ToScalar{Sapling}\big(\PRFexpand{\SpendingKey}([1])\kern-0.1em\big) : \SpendingKey \leftarrowR \SpendingKeyType$,
|
||||
|
|
@ -7515,12 +7515,12 @@ from $\TransmitPlaintext{}$
|
|||
\item A previous version of this specification did not have the requirement for the decoded point
|
||||
$\DiversifiedTransmitPublic$ of a \Sapling \note to be in the subgroup
|
||||
\smash{$\SubgroupJ$ (i.e.\ ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJ$}, return $\bot$'').
|
||||
That did not match the implementation in \zcashd.\!\!\introlist\vspace{-0.5ex}
|
||||
That did not match the implementation in \zcashd\rlap{.}\introlist\vspace{-0.5ex}
|
||||
\item As explained in the note in \crossref{jubjub}, $\abstJ$ accepts \nonCanonicalPoint
|
||||
compressed encodings of \jubjubCurve points. Therefore, an implementation \MUST use the original
|
||||
$\ephemeralKey$ field as encoded in the \transaction as input to $\PRFock{}{}$ and $\KDF{Sapling}$,
|
||||
and in the comparison against
|
||||
$\reprG{}\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$.\!\!\nufive{\; For
|
||||
$\reprG{}\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$\rlap{.}\nufive{\; For
|
||||
consistency this is also what is specified for \Orchard.}\vspace{-0.5ex}
|
||||
\prenufiveitem{$\DiversifiedTransmitPublicRepr$ can also be \nonCanonicalPoint. Since $\bot$ is returned
|
||||
if $\DiversifiedTransmitBase \not\in \SubgroupJ$, the only accepted \nonCanonicalPoint encoding for
|
||||
|
|
@ -8667,13 +8667,12 @@ discrete logarithm relation, and similarly for $\SinsemillaHash(D, M) = \Sinsemi
|
|||
Without loss of generality we can restrict to the case where $\ell$ is a multiple of $k$:
|
||||
since $\pad_n$ is injective on inputs of a given bit length, \collisionResistance for
|
||||
$\ell = n \mult k$ bits implies \collisionResistance for each length that pads to $n \mult k$ bits.
|
||||
|
||||
Since $\ell \in \range{0}{k \mult c}$ we have $n \in \range{0}{c}$. Then:
|
||||
\vspace{-1ex}
|
||||
\vspace{-0.75ex}
|
||||
\begin{formulae}
|
||||
\item $\SinsemillaHashToPoint(M) = \scalarmult{2^n}{\SinsemillaGenInit(D)} + \vsum{j=0}{2^k - 1} \scalarmult{\chi(m)_{j+1}}{\SinsemillaGenBase(j)}$,\, where $m = \pad_n(M)$.
|
||||
\item $\SinsemillaHashToPoint(M) = \scalarmult{2^n}{\SinsemillaGenInit(D)} + \ssum{j=0}{2^k - 1} \scalarmult{\chi(m)_{j+1}}{\SinsemillaGenBase(j)}$,\, where $m = \pad_n(M)$.
|
||||
\end{formulae}
|
||||
\vspace{-1.5ex}
|
||||
\vspace{-1.25ex}
|
||||
(The $j+1$ is just because sequence indices are $1$-based.)
|
||||
|
||||
\introlist
|
||||
|
|
@ -8700,17 +8699,18 @@ So either $\SinsemillaHashToPoint(D, M) = \SinsemillaHashToPoint(D, M')$ (in whi
|
|||
hash proof) or $\SinsemillaHashToPoint(D, M) = -\SinsemillaHashToPoint(D, M')$. In the latter case, let
|
||||
$m = \pad_n(M)$ and $m' = \pad_n(M')$, then we have
|
||||
|
||||
\vspace{-0.75ex}
|
||||
\begin{tabular}{@{\hskip 1.5em}r@{\;}l}
|
||||
$ \scalarmult{2^n}{\SinsemillaGenInit(D)} + \ssum{j=0}{{2^k}-1} \scalarmult{\chi(m)_{j+1}}{\SinsemillaGenBase(j)} = $&$ -\kern-0.1em\Big(\scalarmult{2^n}{\SinsemillaGenInit(D)} + \ssum{j'=0}{{2^k}-1} \scalarmult{\chi(m')_{j'+1}}{\SinsemillaGenBase(j')}\kern-0.15em\Big)$ \\
|
||||
$\scalarmult{2^{n+1}}{\SinsemillaGenInit(D)} + \ssum{j=0}{{2^k}-1} \scalarmult{\chi(m)_{j+1} + \chi(m')_{j+1}}{\SinsemillaGenBase(j)} = $&$ 0$
|
||||
\end{tabular}
|
||||
|
||||
\vspace{0.5ex}
|
||||
\vspace{0.25ex}
|
||||
Because $2^{n+1} \leq \ParamP{r}-1$, the coefficients $\!\!\pmod{\ParamP{r}}$ are not all zero, and therefore
|
||||
this is a nontrivial discrete logarithm relation between independent bases.
|
||||
\end{proof}
|
||||
|
||||
\vspace{-1.5ex}
|
||||
\vspace{-2.5ex}
|
||||
\begin{nnotes}
|
||||
\item The above theorem easily extends to the case where additional scalar multiplication terms with
|
||||
independent bases may be added to the $\SinsemillaHashToPoint$ output before applying $\ExtractPbot$.
|
||||
|
|
@ -8718,7 +8718,7 @@ this is a nontrivial discrete logarithm relation between independent bases.
|
|||
\crossref{concretesinsemillacommit}. It is also needed to show security of \nullifier derivation
|
||||
defined in \crossref{commitmentsandnullifiers} against Faerie Gold attacks, as described in
|
||||
\crossref{faeriegold}.
|
||||
\vspace{-0.25ex}
|
||||
\vspace{-1ex}
|
||||
\item Assuming that $\GroupGHash$ acts as a \randomOracle, it can also be proven that $\SinsemillaHashToPoint$
|
||||
and $\SinsemillaHash$ are \collisionResistant across different personalization inputs (regardless of input length).
|
||||
\end{nnotes}
|
||||
|
|
@ -8734,10 +8734,11 @@ intermediate values of $\Acc$:
|
|||
|
||||
\begin{formulae}
|
||||
\item let $\Acc_0 \leftarrow \SinsemillaGenInit(D)$
|
||||
\vspace{-0.25ex}
|
||||
\item for $i$ from $1$ up to $n$:
|
||||
\vspace{-0.5ex}
|
||||
\vspace{-1ex}
|
||||
\item \tab set $\Acc_i \leftarrow \big(\Acc_{i-1} \incompleteadd \SinsemillaGenBase(m_i)\kern-0.1em\big) \incompleteadd \Acc_{i-1}$
|
||||
\item \vspace{-4ex}
|
||||
\item \vspace{-4.5ex}
|
||||
\item return $\Acc_n$.
|
||||
\end{formulae}
|
||||
|
||||
|
|
@ -9151,8 +9152,10 @@ PRF when keyed by its first argument, with its second argument as input.
|
|||
|
||||
|
||||
\introsection
|
||||
\vspace{-1ex}
|
||||
\lsubsubsection{Symmetric Encryption}{concretesym}
|
||||
|
||||
\vspace{-1ex}
|
||||
Let $\Keyspace := \bitseq{256}$, $\Plaintext := \byteseqs$, and $\Ciphertext := \byteseqs$.
|
||||
|
||||
Let the \symmetricEncryptionScheme $\SymEncrypt{\Key}(\Ptext)$ be authenticated encryption using
|
||||
|
|
@ -10927,7 +10930,7 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type
|
|||
encodes $\DST$ in the hash inputs instead.
|
||||
\vspace{-0.25ex}
|
||||
\item The conversion from bytes to field elements uses big-endian order, again in order
|
||||
to follow the Internet Draft.\!\!
|
||||
to follow the Internet Draft\rlap{.}
|
||||
\vspace{-0.25ex}
|
||||
\item A minor optimization is to cache the state of the $\BlakeTwob{512}$ instance
|
||||
used to compute $b_0$ after processing $\zerobytes{128}$, since this state does
|
||||
|
|
@ -11603,8 +11606,10 @@ For addresses on \Testnet, the \humanReadablePart is \ascii{ztestsapling}.
|
|||
|
||||
|
||||
\sapling{
|
||||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\SaplingText{} Incoming Viewing Keys}{saplinginviewingkeyencoding}
|
||||
|
||||
\vspace{-2ex}
|
||||
Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}.
|
||||
|
||||
Let $\InViewingKeyLength{Sapling}$ be as defined in \crossref{constants}.
|
||||
|
|
@ -11617,19 +11622,20 @@ It is used with the encryption scheme defined in \crossref{saplinginband}.
|
|||
|
||||
\introlist
|
||||
The \rawEncoding of a \Sapling \incomingViewingKey consists of:
|
||||
\vspace{1ex}
|
||||
\vspace{0.5ex}
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.07em]{256}
|
||||
\sbitbox{256}{$256$-bit $\InViewingKey$}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\vspace{-1ex}
|
||||
\vspace{-1.5ex}
|
||||
\begin{itemize}
|
||||
\item $32$ bytes (little-endian) specifying $\InViewingKey$, padded with zeros in the most
|
||||
significant bits.
|
||||
\end{itemize}
|
||||
|
||||
\vspace{-1ex}
|
||||
$\InViewingKey$ \MUST be in the range $\InViewingKeyTypeSapling$ as specified
|
||||
in \crossref{saplingkeycomponents}. That is, a decoded \incomingViewingKey \MUST be
|
||||
considered invalid if $\InViewingKey$ is not in this range.
|
||||
|
|
@ -11640,8 +11646,10 @@ For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zivktests
|
|||
|
||||
|
||||
\sapling{
|
||||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\SaplingText{} Full Viewing Keys}{saplingfullviewingkeyencoding}
|
||||
|
||||
\vspace{-2ex}
|
||||
Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}.
|
||||
|
||||
A \Sapling{} \defining{\fullViewingKey} consists of $\AuthSignPublic \typecolon \SubgroupJstar$,
|
||||
|
|
@ -11652,7 +11660,7 @@ $\AuthSignPublic$ and $\NullifierKey$ are points on the \jubjubCurve
|
|||
|
||||
\introlist
|
||||
The \rawEncoding of a \Sapling \fullViewingKey consists of:
|
||||
\vspace{1ex}
|
||||
\vspace{0.5ex}
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.05em]{512}
|
||||
\sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignPublic}\kern 0.05em}$}
|
||||
|
|
@ -11661,7 +11669,7 @@ The \rawEncoding of a \Sapling \fullViewingKey consists of:
|
|||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\vspace{-1ex}
|
||||
\vspace{-1.5ex}
|
||||
\begin{itemize}
|
||||
\item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\AuthSignPublic$
|
||||
(see \crossref{jubjub}).
|
||||
|
|
@ -11669,6 +11677,7 @@ The \rawEncoding of a \Sapling \fullViewingKey consists of:
|
|||
\item $32$ bytes specifying the \outgoingViewingKey $\OutViewingKey$.
|
||||
\end{itemize}
|
||||
|
||||
\vspace{-1ex}
|
||||
When decoding this representation, the key \MUST be considered invalid if $\abstJ$ returns $\bot$
|
||||
for either $\AuthSignPublic$ or $\NullifierKey$, or if $\AuthSignPublic \notin \SubgroupJstar$,
|
||||
or if $\NullifierKey \notin \SubgroupJ$.
|
||||
|
|
@ -11679,30 +11688,35 @@ For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtest
|
|||
|
||||
|
||||
\sapling{
|
||||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\SaplingText{} Spending Keys}{saplingspendingkeyencoding}
|
||||
|
||||
\vspace{-2ex}
|
||||
A \Sapling{} \defining{\spendingKey} consists of $\SpendingKey \typecolon \SpendingKeyType$
|
||||
(see \crossref{saplingkeycomponents}).
|
||||
|
||||
\introlist
|
||||
The \rawEncoding of a \Sapling \spendingKey consists of:
|
||||
\vspace{1ex}
|
||||
\vspace{0.5ex}
|
||||
\begin{equation*}
|
||||
\begin{bytefield}[bitwidth=0.07em]{256}
|
||||
\sbitbox{256}{$\LEBStoOSPOf{256}{\SpendingKey}$}
|
||||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\vspace{-1.5ex}
|
||||
\begin{itemize}
|
||||
\item $32$ bytes specifying $\SpendingKey$.
|
||||
\end{itemize}
|
||||
|
||||
\vspace{-1ex}
|
||||
For \spendingKeys on \Mainnet, the \humanReadablePart is \ascii{secret-spending-key-main}.
|
||||
For \spendingKeys on \Testnet, the \humanReadablePart is \ascii{secret-spending-key-test}.
|
||||
} %sapling
|
||||
|
||||
|
||||
\nufive{
|
||||
\vspace{-1ex}
|
||||
\lsubsubsection{Unified and \OrchardText{} Encodings}{orchardencodings}
|
||||
|
||||
\vspace{-1ex}
|
||||
|
|
@ -11753,10 +11767,10 @@ a user might only check part of the address. See \cite{ZIP-316} for full details
|
|||
|
||||
|
||||
\nufive{
|
||||
\vspace{-2ex}
|
||||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\OrchardText{} Raw Payment Addresses}{orchardpaymentaddrencoding}
|
||||
|
||||
\vspace{-1ex}
|
||||
\vspace{-2ex}
|
||||
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.
|
||||
|
||||
An \Orchard{} \defining{\shieldedPaymentAddress} consists of $\Diversifier \typecolon \DiversifierType$
|
||||
|
|
@ -11778,14 +11792,14 @@ The \rawEncoding of an \Orchard \shieldedPaymentAddress consists of:
|
|||
\end{bytefield}
|
||||
\end{equation*}
|
||||
|
||||
\vspace{-0.5ex}
|
||||
\vspace{-1.5ex}
|
||||
\begin{itemize}
|
||||
\item $11$ bytes specifying $\Diversifier$.
|
||||
\item $32$ bytes specifying the \swCompressedEncoding of
|
||||
$\DiversifiedTransmitPublic$ (see \crossref{pallasandvesta}).\!\!
|
||||
$\DiversifiedTransmitPublic$ (see \crossref{pallasandvesta}\rlap{).}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{-2,5ex}
|
||||
\vspace{-1ex}
|
||||
When decoding the representation of $\DiversifiedTransmitPublic$, the address \MUST be
|
||||
considered invalid if $\abstP$ returns $\bot$ or $\ZeroP$.
|
||||
|
||||
|
|
@ -11798,7 +11812,7 @@ instead use a \unifiedPaymentAddress as defined in \cite{ZIP-316}.
|
|||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\OrchardText{} Raw Incoming Viewing Keys}{orchardinviewingkeyencoding}
|
||||
|
||||
\vspace{-1ex}
|
||||
\vspace{-2ex}
|
||||
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.
|
||||
|
||||
An \Orchard{} \defining{\incomingViewingKey} consists of a \diversifierKey $\DiversifierKey$,
|
||||
|
|
@ -11838,7 +11852,7 @@ instead use a \unifiedIncomingViewingKey as defined in \cite{ZIP-316}.
|
|||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\OrchardText{} Raw Full Viewing Keys}{orchardfullviewingkeyencoding}
|
||||
|
||||
\vspace{-1ex}
|
||||
\vspace{-2ex}
|
||||
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.
|
||||
|
||||
Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}.
|
||||
|
|
@ -11874,6 +11888,7 @@ The \rawEncoding of an \Orchard \fullViewingKey consists of:
|
|||
\end{itemize}
|
||||
|
||||
\introlist
|
||||
\vspace{-1ex}
|
||||
When decoding this representation, the key \MUST be considered invalid if $\AuthSignPublic$,
|
||||
$\NullifierKey$, or $\CommitIvkRandom$ are not canonically encoded elements of their respective
|
||||
fields, or if $\AuthSignPublic \not\in \GroupPx$.
|
||||
|
|
@ -11884,9 +11899,10 @@ instead use a \unifiedFullViewingKey as defined in \cite{ZIP-316}.
|
|||
|
||||
|
||||
\nufive{
|
||||
\vspace{-1ex}
|
||||
\lsubsubsubsection{\OrchardText{} Spending Keys}{orchardspendingkeyencoding}
|
||||
|
||||
\vspace{-1ex}
|
||||
\vspace{-2ex}
|
||||
An \Orchard{} \defining{\spendingKey} consists of $\SpendingKey \typecolon \SpendingKeyType$
|
||||
(see \crossref{orchardkeycomponents}).
|
||||
|
||||
|
|
@ -12198,7 +12214,7 @@ The \Zcash{} \defining{\transaction} format for \transactionVersion 5 is as foll
|
|||
|
||||
& $4$ & $\nConsensusBranchId\!$ & \type{uint32} & \xConsensusBranchID. \\ \hline
|
||||
|
||||
& $4$ & $\lockTime$ & \type{uint32} & Unix-epoch UTC time or \blockHeight, encoded as in \Bitcoin.\!\! \\ \hline
|
||||
& $4$ & $\lockTime$ & \type{uint32} & Unix-epoch UTC time or \blockHeight, encoded as in \Bitcoin\rlap{.} \\ \hline
|
||||
|
||||
& $4$ & $\nExpiryHeight$ & \type{uint32} &
|
||||
A \blockHeight in the range $\range{1}{499999999}$ after which the \transaction will expire, or $0$ to disable expiry.
|
||||
|
|
@ -12829,7 +12845,7 @@ preceding \blocks if there are fewer than $\PoWMedianBlockSpan$). The \medianTim
|
|||
\Sapling \treestate of this \block.}
|
||||
}
|
||||
\notbeforeheartwood{
|
||||
\saplingandblossomitem{$\hashLightClientRoot$ \MUST be $\LEBStoOSPOf{256}{\rt{Sapling}}$ where
|
||||
\saplingandblossomitem{$\hashLightClientRoot$ \MUST be $\LEBStoOSP{256}\big(\rt{Sapling}\big)$ where
|
||||
$\rt{Sapling}$ is the \merkleRoot of the \Sapling \noteCommitmentTree for the final
|
||||
\Sapling \treestate of this \block.}
|
||||
\heartwoodandcanopyitem{$\hashLightClientRoot$ \MUST be set to the $\hashChainHistoryRoot$
|
||||
|
|
@ -12846,8 +12862,10 @@ nondeterministic, and clock time varies between nodes. Also note that a \block t
|
|||
rejected by this rule at a given point in time may later be accepted.
|
||||
|
||||
\begin{pnotes}
|
||||
\vspace{-0.5ex}
|
||||
\item The semantics of blocks with \blockVersionNumber{} not equal to $4$
|
||||
is not currently defined. Miners \MUSTNOT create such \blocks.
|
||||
\vspace{-0.5ex}
|
||||
\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 \fullValidators.
|
||||
|
|
@ -12855,57 +12873,72 @@ rejected by this rule at a given point in time may later be accepted.
|
|||
greater than or less than $4$. It is likely that such an upgrade will
|
||||
change the \block header and/or \transaction format, and software that
|
||||
parses \blocks \SHOULD take this into account.
|
||||
\vspace{-0.5ex}
|
||||
\item The $\nVersion$ field is a signed integer. (It was specified
|
||||
as unsigned in a previous version of this specification.) A future
|
||||
upgrade might use negative values for this field, or otherwise change
|
||||
its interpretation.
|
||||
\vspace{-0.5ex}
|
||||
\item There is no relation between the values of the $\versionField$ field of a \transaction,
|
||||
and the $\nVersion$ field of a \blockHeader.
|
||||
\vspace{-0.5ex}
|
||||
\item Like other serialized fields of type $\type{compactSize}$, the $\solutionSize$ field \MUST
|
||||
be encoded with the minimum number of bytes ($3$ in this case), and other encodings
|
||||
\MUST be rejected. This is necessary to avoid a potential attack in which a miner
|
||||
could test several distinct encodings of each \Equihash solution against the difficulty
|
||||
filter, rather than only the single intended encoding.
|
||||
\vspace{-0.5ex}
|
||||
\item As in \Bitcoin, the $\nTimeField$ field \MUST represent a time \emph{strictly greater than}
|
||||
the median of the timestamps of the past $\PoWMedianBlockSpan$ \blocks. The
|
||||
Bitcoin Developer Reference \cite{Bitcoin-Block} was previously in error on this point,
|
||||
but has now been corrected.
|
||||
\vspace{-0.5ex}
|
||||
\item The rule limiting $\nTimeField$ to be no later than $90 \mult 60$ seconds after the
|
||||
\medianTimePast is a retrospective consensus change, applied as a soft fork in
|
||||
\zcashd v2.1.1-1. It had not been violated by any \block from the given \blockHeights
|
||||
in the consensus \blockChains of either \Mainnet or \Testnet.
|
||||
\overwinter{
|
||||
\vspace{-0.5ex}
|
||||
\item There are no changes to the \blockVersionNumber or format for \Overwinter.
|
||||
}
|
||||
} %overwinter
|
||||
\sapling{
|
||||
\vspace{-0.5ex}
|
||||
\item Although the \blockVersionNumber does not change for \Sapling,
|
||||
the previously reserved (and ignored) field $\hashReserved$ has been
|
||||
repurposed for $\hashFinalSaplingRoot$. There are no other format changes.
|
||||
}
|
||||
} %sapling
|
||||
\blossom{
|
||||
\vspace{-0.5ex}
|
||||
\item There are no changes to the \blockVersionNumber or format for \Blossom.
|
||||
}
|
||||
} %blossom
|
||||
\heartwood{
|
||||
\vspace{-0.5ex}
|
||||
\item For \Heartwood, the $\hashFinalSaplingRoot$ field is renamed to $\hashLightClientRoot$.
|
||||
Once \Heartwood activates, the meaning of this field changes according to \cite{ZIP-221}.
|
||||
}
|
||||
} %heartwood
|
||||
\canopy{
|
||||
\vspace{-0.5ex}
|
||||
\item There are no changes to the \blockVersionNumber or format for \Canopy.
|
||||
}
|
||||
} %canopy
|
||||
\nufive{
|
||||
\vspace{-0.5ex}
|
||||
\item For \NUFive, the $\hashLightClientRoot$ field is renamed to $\hashBlockCommitments$.
|
||||
Once \NUFive activates, the meaning of this field changes according to \cite{ZIP-244}.
|
||||
}
|
||||
} %nufive
|
||||
\end{pnotes}
|
||||
|
||||
\introlist
|
||||
The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are:
|
||||
|
||||
\begin{itemize}
|
||||
\vspace{-0.5ex}
|
||||
\item \Blockversions less than $4$ are not supported.
|
||||
\vspace{-0.5ex}
|
||||
\item The $\hashReserved$\sapling{ (or $\hashFinalSaplingRoot$)}, $\solutionSize$, and
|
||||
$\solution$ fields have been added.
|
||||
\vspace{-0.5ex}
|
||||
\item The type of the $\nNonce$ field has changed from \type{uint32} to \type{byte[32]}.
|
||||
\vspace{-0.5ex}
|
||||
\item The maximum \block size has been doubled to $2000000$ bytes.
|
||||
\end{itemize}
|
||||
|
||||
|
|
@ -13936,7 +13969,7 @@ does not follow from \collisionResistance of the original hash, even if the
|
|||
truncation is only by one bit. This motivated avoiding truncation along any
|
||||
path from the inputs to the computation of $\hSig$ to the uses of
|
||||
$\NoteUniqueRand$.
|
||||
}
|
||||
} %sproutspecific
|
||||
|
||||
\sproutspecific{
|
||||
Since the \xPRFs are instantiated using \shaCompress which has an input block
|
||||
|
|
@ -13947,7 +13980,7 @@ $\PRFaddr{}$, $\PRFnf{Sprout}{}$, and $\PRFpk{}$, and to $\NoteUniquePreRand$ (w
|
|||
does not exist in \Zerocash) for $\PRFrho{}$, and so those values have been
|
||||
reduced to $252$ bits. This is preferable to requiring reasoning about truncation,
|
||||
and $252$ bits is quite sufficient for security of these cryptovalues.
|
||||
}
|
||||
} %sproutspecific
|
||||
|
||||
\sapling{
|
||||
\Sapling uses \xPedersenHashes and $\BlakeTwosGeneric$ where \Sprout used \shaCompress.
|
||||
|
|
@ -13958,7 +13991,7 @@ via a personalization parameter distinct from the input. Therefore, there is
|
|||
no need for truncation in the inputs to any of these hashes. Note however that the
|
||||
\emph{output} of $\CRHivk$ is truncated, requiring a security assumption on
|
||||
$\BlakeTwosGeneric$ truncated to $251$ bits (see \crossref{concretecrhivk}).
|
||||
}
|
||||
} %sapling
|
||||
|
||||
\nufive{
|
||||
\Orchard replaces \xPedersenHashes by \xSinsemillaHashes which can also be efficiently
|
||||
|
|
|
|||
Loading…
Reference in New Issue