zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Cosmetics and improvements to indexing. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2022-03-18 01:02:24 +00:00
parent 8f77f6f1df
commit c506a972ac
1 changed files with 65 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

115
protocol/protocol.tex
View File

@ -1007,6 +1007,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\xConsensusBranchID}{\termx{consensus branch ID}}
\newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
\newcommand{\coinbaseTransactions}{\terms{coinbase transaction}}
\newcommand{\prevout}{\termandindex{prevout}{prevout (previous output)}}
\newcommand{\prevouts}{\termandindex{prevouts}{prevout (previous output)}}
\newcommand{\transparent}{\term{transparent}}
\newcommand{\xTransparent}{\termx{transparent}}
\newcommand{\transparentAddress}{\term{transparent address}}
@ -1737,7 +1739,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\halvingInterval}{\term{halving interval}}
\newcommand{\halving}{\term{halving}}
\newcommand{\halvings}{\terms{halving}}
\newcommand{\utxoSet}{\term{unspent transaction output set}}
\newcommand{\utxoSet}{\termandindex{UTXO set}{UTXO (unspent transaction output) set}}
\newcommand{\utxoSetFull}{\term{UTXO (unspent transaction output) set}}
\newcommand{\utxo}{\termandindex{UTXO}{UTXO (unspent transaction output)}}
\newcommand{\utxos}{\termandindex{UTXOs}{UTXO (unspent transaction output)}}
\newcommand{\utxosFull}{\termandindex{UTXOs (unspent transaction outputs)}{UTXO (unspent transaction output)}}
\newcommand{\fundingStream}{\term{funding stream}}
\newcommand{\fundingStreams}{\terms{funding stream}}
@ -1929,7 +1935,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\nConsensusBranchId}{\mathtt{nConsensusBranchId}}
\newcommand{\txInCount}{\mathtt{tx\_in\_count}}
\newcommand{\txIn}{\mathtt{tx\_in}}
\newcommand{\prevout}{\mathtt{prevout}}
\newcommand{\prevoutField}{\mathtt{prevout}}
\newcommand{\txOutCount}{\mathtt{tx\_out\_count}}
\newcommand{\txOut}{\mathtt{tx\_out}}
\newcommand{\lockTime}{\mathtt{lock\_time}}
@ -3394,9 +3400,8 @@ for \Sprout\sapling{ and for \Sapling}\nufive{ and for \Orchard}. \sapling{Each}
\end{itemize}
\vspace{-1ex}
Validation state associated with \transparent inputs and outputs, such as the UTXO
(Unspent Transaction Output) set, is not described in this document; it is
used in essentially the same way as in \Bitcoin.
Validation state associated with \transparent inputs and outputs, such as the \utxoSetFull,
is not described in this document; it is used in essentially the same way as in \Bitcoin.
An \defining{\anchor} is a Merkle tree root of a \noteCommitmentTree\sapling{ (either the
\Sprout tree or the \Sapling tree\nufive{ or the \Orchard tree})}. It uniquely identifies
@ -3433,8 +3438,8 @@ a \defining{\joinSplitTransfer}, i.e.\ a \shielded value transfer.
In \Sprout, this kind of value transfer was the primary \Zcash-specific operation
performed by \transactions.
A \joinSplitTransfer spends $\NOld$ \notes $\nOld{\allOld}$ and \transparent input
$\vpubOld$, and creates $\NNew$ \notes $\nNew{\allNew}$ and \transparent output
A \joinSplitTransfer spends $\NOld$ \notes $\nOld{\allOld}$ and \transparentInput
$\vpubOld$, and creates $\NNew$ \notes $\nNew{\allNew}$ and \transparentOutput
$\vpubNew$.
It is associated with a \joinSplitStatement instance (\crossref{joinsplitstatement}),
for which it provides a \zkSNARKProof.
@ -3599,14 +3604,14 @@ defined in \crossref{constants}.
\begin{center}
\includegraphics[scale=.4]{incremental_merkle}
\end{center}
\vspace{-2ex}
\vspace{-1ex}
\defining{A \noteCommitmentTree is an \incrementalMerkleTree} of fixed depth used to store
\noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers}\nufive{ or \actionTransfers}
produce. Just as the \defining{\utxoSet} (UTXO set) used in \Bitcoin,
it is used to express the existence 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.
produce. Just as the \defining{\utxoSetFull} used in \Bitcoin, it is used to express
the existence of value and the capability to spend it. However, unlike the \utxoSet,
it is \emph{not} the job of this tree to protect against double-spending, as it is
append-only.
A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate
(\crossref{transactions}).
@ -4208,7 +4213,7 @@ pair without access to the \signingKey.
\introsection
\lsubsubsubsection{Signature with Re-Randomizable Keys}{abstractsigrerand}
\vspace{-1ex}
\vspace{-2ex}
A \defining{\rerandomizableSignatureScheme} $\Sig$ is a \signatureScheme that
additionally defines:
@ -4220,21 +4225,22 @@ additionally defines:
\item a distinguished ``identity'' \randomizer $\SigRandomizerId \typecolon \SigRandom$
\end{itemize}
\vspace{-1.5ex}
\vspace{-1.6ex}
such that:
\vspace{1ex}
\vspace{0.8ex}
\begin{itemize}
\item for any $\SigRandomizer \typecolon \SigRandom$,
$\SigRandomizePrivate_{\SigRandomizer} \typecolon \SigPrivate \rightarrow \SigPrivate$
is injective and easily invertible;
\item $\SigRandomizePrivate_{\SigRandomizerId}$ is the identity function on $\SigPrivate$.
\vspace{0.3ex}
\item for any $\sk \typecolon \SigPrivate$,
\begin{formulae}
\item $\SigRandomizePrivate(\SigRandomizer, \sk) : \SigRandomizer \leftarrowR \SigGenRandom()$
\end{formulae}
\vspace{-1.5ex} is identically distributed to $\SigGenPrivate()$.
\vspace{0.5ex}
\vspace{0.3ex}
\item for any $\sk \typecolon \SigPrivate$ and $\SigRandomizer \typecolon \SigRandom$,
\begin{formulae}
\item $\SigRandomizePublic(\SigRandomizer, \SigDerivePublic(\sk)) =
@ -4242,7 +4248,7 @@ such that:
\end{formulae}
\end{itemize}
\vspace{-1ex}
\vspace{-1.5ex}
The following security requirement for such \signatureSchemes is based on that
given in \cite[section 3]{FKMSSS2016}. Note that we require Strong Unforgeability
with Re-randomized Keys, not Existential Unforgeability with Re-randomized Keys
@ -4254,6 +4260,7 @@ original key pair can be re-randomized for multiple \notes, and also it can happ
that multiple \transactions spending the same \note are revealed to an adversary.)
\introlist
\vspace{-0.5ex}
\securityrequirement{\textbf{Strong Unforgeability with Re-randomized Keys under adaptive Chosen Message Attack (SURK-CMA)}
For any $\sk \typecolon \SigPrivate$, let
@ -4277,20 +4284,23 @@ infeasible for an adversary given $\vk$ and a new instance of $\Oracle_{\sk}$ to
$(m', \sigma', \SigRandomizer')$ such that
$\SigValidate{\SigRandomizePublic(\SigRandomizer', \vk)}(m', \sigma') = 1$ and
$(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$.
}
} %securityrequirement
\begin{nnotes}
\item The \randomizer and key arguments to $\SigRandomizePrivate$ and $\SigRandomizePublic$
are swapped relative to \cite[section 3]{FKMSSS2016}.
\vspace{-0.5ex}
\item The requirement for the identity \randomizer $\SigRandomizerId$ simplifies the
definition of SURK-CMA by removing the need for two oracles (because the oracle for
original keys, called $\Oracle_1$ in \cite{FKMSSS2016}, is a special case of the
oracle for randomized keys).
\vspace{-0.5ex}
\item Since $\SigRandomizePrivate(\SigRandomizer, \sk) :
\SigRandomizer \leftarrowR \SigRandom$ has an identical distribution to $\SigGenPrivate()$,
and since $\SigDerivePublic$ is a deterministic function, the combination of a re-randomized
\validatingKey and signature(s) under that key do not reveal the key from which it was
re-randomized.
\vspace{-0.5ex}
\item Since $\SigRandomizePrivate_{\SigRandomizer}$ is injective and
easily invertible, knowledge of $\SigRandomizePrivate(\SigRandomizer, \sk)$
\emph{and} $\SigRandomizer$ implies knowledge of $\sk$.
@ -4300,8 +4310,10 @@ $(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$.
\sapling{
\introlist
\vspace{-3ex}
\lsubsubsubsection{Signature with Signing Key to Validating Key Monomorphism}{abstractsigmono}
\vspace{-2ex}
A \defining{\keyMonomorphicSignatureScheme} $\Sig$ is a \signatureScheme that
additionally defines:
@ -4314,14 +4326,14 @@ additionally defines:
identity $\combzero$.
\end{itemize}
\vspace{-1.2ex}
\vspace{-1.5ex}
such that for any $\sk_{\oneto{2}} \typecolon \SigPrivate$,
$\SigDerivePublic(\sk_1 \grpplus \sk_2) = \SigDerivePublic(\sk_1)\, \combplus \SigDerivePublic(\sk_2)$.
In other words, $\SigDerivePublic$ is a \defining{\monomorphism (that is, an injective homomorphism)} from the
\signingKey group to the \validatingKey group.
\vspace{1ex}
\vspace{0.5ex}
\introlist
For $\rmN \typecolon \PosInt$,
\begin{itemize}
@ -4338,12 +4350,13 @@ and $\sk_1 \grpminus \sk_2$ means $\sk_1 \grpplus\, (\grpneg \sk_2)$.
$\combneg \vk$ means the \validatingKey such that $(\combneg \vk) \combplus \vk = \combzero$,
and $\vk_1 \combminus \vk_2$ means $\vk_1 \combplus\, (\combneg \vk_2)$.
\vspace{2ex}
\vspace{1ex}
With a change of notation from $\mu$ to $\SigDerivePublic$, $+$ to $\grpplus$, and $\mult$ to $\combplus$,
this is similar to the definition of a \quotedtermnoindex{Signature with Secret Key to Public Key Homomorphism}
in \cite[Definition 13]{DS2016}, except for an additional requirement for the homomorphism to be injective.
\introlist
\vspace{-1ex}
\securityrequirement{
For any $\sk_1 \typecolon \SigPrivate$, and an unknown $\sk_2 \leftarrowR \SigGenPrivate()$
chosen independently of $\sk_1$, the distribution of $\sk_1 \grpplus \sk_2$ is
@ -4356,8 +4369,10 @@ when at least one of $\sk_{\alln}$ is unknown.)
\introlist
\vspace{-1ex}
\lsubsubsection{Commitment}{abstractcommit}
\vspace{-1ex}
\defining{
A \commitmentScheme is a function that, given a \commitmentTrapdoor generated at
random and an input, can be used to commit to the input in such a way that:
@ -5108,7 +5123,7 @@ The \diversifiedPaymentAddress with \diversifierIndex $0$ is called the \definin
uniform on $\GF{\ParamP{r}}$ and $\GF{\ParamP{q}}$ respectively when applied to
random input, by a similar argument to that used in \crossref{saplingkeycomponents}.
\item The output of $\CommitIvk{}$ is the \affineSW $x$-coordinate of a \pallasCurve point,
which we then use as a $\KA{Orchard}$ private key $\InViewingKey$ for \note encryption.
which we then use as a $\KA{Orchard}$ \privateKey $\InViewingKey$ for \note encryption.
The fact that $\InViewingKey$ is non-uniform on $\GF{\ParamP{r}}$ (since it can
only take on roughly half of the possible values) is not expected to cause any
security issue.
@ -5609,7 +5624,7 @@ performs the following steps:
\item Let $\cm = \NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase},
\reprJ\Of{\DiversifiedTransmitPublic},
\Value)$.
\vspace{-0.25ex}
\vspace{-0.15ex}
\item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$.
\vspace{-0.25ex}
\item Encrypt $\NotePlaintext{}$ to the recipient
@ -6128,7 +6143,7 @@ to $\joinSplitPubKey$ to sign this \transaction.
\vspace{-1ex}
In \Bitcoin, all inputs to and outputs from a \transaction are transparent.
The total value of \transparentOutputs{} must not exceed the total value of
The total value of \transparentOutputs must not exceed the total value of
\transparentInputs. The net value of \transparentInputs minus \transparentOutputs
is transferred to the miner of the \block containing the \transaction; it is added
to the \minerSubsidy in the \coinbaseTransaction of the \block.
@ -6684,6 +6699,7 @@ $\NoteUniqueRandRepr = \reprJ(\NoteUniqueRand)$.
\vspace{2ex}
\nufive{
\introlist
The derivation of \nullifiers for \Orchard \notes is a little more complicated.
Let $\GroupP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.
@ -6709,7 +6725,6 @@ where $\NullifierKey$ is the \nullifierDerivingKey associated with the \note;
$\NoteUniqueRand$ and $\NoteNullifierRand$ are part of the \note; and $\cm$ is
the \noteCommitment.
\vspace{-1ex}
\pnote{The addition of $\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand)$ and $\NoteNullifierRand$
is intentionally done modulo $\ParamP{q}$, even though the scalar multiplication is on the \pallasCurve
which has scalar field $\GF{\ParamP{r}}$.}
@ -8650,7 +8665,7 @@ See \crossref{cctmixinghash} for efficient circuit implementation of this functi
\vspace{-2ex}
\lsubsubsubsection{Sinsemilla Hash Function}{concretesinsemillahash}
\vspace{-1ex}
\vspace{-2ex}
\defining{$\SinsemillaHash$} is an algebraic \hashFunction with
\collisionResistance (for fixed input length) derived from assumed hardness
of the \xDiscreteLogarithmProblem. It is designed by Sean Bowe and Daira Hopwood.
@ -12302,11 +12317,11 @@ $\barerange{1}{4}$ & $4$ & $\headerField$ & \type{uint32} & Contains: \begin{com
\setoverwinter $\barerange{3}{4}$ &\setoverwinter $4$ &\setoverwinter $\nVersionGroupId\!$ &\overwintertype{uint32} &\setoverwinter
Version group ID (nonzero).\! \\ \hline
$\barerange{1}{4}$ & \Varies & $\txInCount$ & \type{compactSize} & Number of \transparent inputs.\! \\ \hline
$\barerange{1}{4}$ & \Varies & $\txInCount$ & \type{compactSize} & Number of \transparentInputs.\! \\ \hline
$\barerange{1}{4}$ & \Varies & $\txIn$ & $\txIn$ & \xTransparent inputs, encoded as in \Bitcoin.\! \\ \hline
$\barerange{1}{4}$ & \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparent outputs.\! \\ \hline
$\barerange{1}{4}$ & \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparentOutputs.\! \\ \hline
$\barerange{1}{4}$ & \Varies & $\txOut$ & $\txOut$ & \xTransparent outputs, encoded as in \Bitcoin.\! \\ \hline
@ -12411,11 +12426,11 @@ A \blockHeight after which the \transaction will expire, or $0$ to disable expir
\smash{\cite{ZIP-203}}\! \\
\hhline{|=====|}
& \Varies & $\txInCount$ & \type{compactSize} & Number of \transparent inputs.\! \\ \hline
& \Varies & $\txInCount$ & \type{compactSize} & Number of \transparentInputs.\! \\ \hline
& \Varies & $\txIn$ & $\txIn$ & \xTransparent inputs, encoded as in \Bitcoin.\! \\ \hline
& \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparent outputs.\! \\ \hline
& \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparentOutputs.\! \\ \hline
& \Varies & $\txOut$ & $\txOut$ & \xTransparent outputs, encoded as in \Bitcoin.\! \\
\hhline{|=====|}
@ -12547,8 +12562,8 @@ in \cite{ZIP-239}.
$(\nActionsOrchard > 0$ and $\enableOutputsOrchard = 1)$.}
\nufiveonwarditem{If $\effectiveVersion \geq 5$ and $\nActionsOrchard > 0$, then at least one of
$\enableSpendsOrchard$ and $\enableOutputsOrchard$ \MUST be $1$.}
\item A \transaction with one or more \transparent inputs from \coinbaseTransactions \MUST have no
\transparent outputs (i.e.\ \txOutCount{} \MUST be $0$). Inputs from
\item A \transaction with one or more \transparentInputs from \coinbaseTransactions \MUST have no
\transparentOutputs (i.e.\ \txOutCount{} \MUST be $0$). Inputs from
\coinbaseTransactions include \foundersReward outputs\canopy{ and \fundingStream outputs}.
\item If $\effectiveVersion \geq 2$ and $\nJoinSplit > 0$, then:
\begin{itemize}
@ -12606,8 +12621,8 @@ in \cite{ZIP-239}.
the encoding used by \Bitcoin in the implementation of \cite{BIP-34} (but the description here
is to be considered normative).
\item %\consensuslink{bad-txns-premature-spend-of-coinbase}
A \transaction \MUSTNOT spend a \transparent output of a \coinbaseTransaction
from a \block less than 100 \blocks prior to the spend. Note that \transparent outputs of
A \transaction \MUSTNOT spend a \transparentOutput of a \coinbaseTransaction
from a \block less than 100 \blocks prior to the spend. Note that \transparentOutputs of
\coinbaseTransactions include \foundersReward outputs \canopy{and \transparent \fundingStream outputs}.
\item A \transaction \MUSTNOT spend an output of the \genesisBlock \coinbaseTransaction. (There is one
such zero-valued output, on each of \Testnet and \Mainnet.)
@ -12666,7 +12681,7 @@ each \spendDescription\, (\crossref{spendencodingandconsensus}),\,\notnufive{ an
fields alone may be insufficient to determine the format to be used for parsing.}
\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
as specified in \cite{BIP-68}. \Zcash was forked from \BitcoinCore v0.11.2
and does not currently support BIP 68.
\saplingonwarditem{Because \coinbaseTransactions have no
\spendDescriptions\notheartwood{ or \outputDescriptions}, the $\valueBalance{Sapling}$
@ -12676,7 +12691,7 @@ each \spendDescription\, (\crossref{spendencodingandconsensus}),\,\notnufive{ an
\heartwood{
\item Prior to the \Heartwood \networkUpgrade, it was not possible for \coinbaseTransactions
to have \shielded outputs, and therefore the ``coinbase maturity'' rule and the requirement
to spend coinbase outputs only in \transactions with no \transparent outputs, applied to
to spend coinbase outputs only in \transactions with no \transparentOutputs, applied to
\emph{all} coinbase outputs.
} %heartwood
\canopyonwarditem{The rule that \Sapling outputs in \coinbaseTransactions \MUST decrypt to a \notePlaintext
@ -12733,7 +12748,7 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B
$\nActionsOrchard$, $\vActionsOrchard$, $\flagsOrchard$, $\valueBalance{Orchard}$,
$\anchorField{Orchard}$, $\sizeProofsOrchard$, $\proofsOrchard$, $\bindingSig{Orchard}$, and
$\vSpendAuthSigs{Orchard}$.}
\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 \transparentInputs, provided
at least one of $\nJoinSplit$\sapling{, $\nSpendsSapling$,\notnufive{ and}
$\nOutputsSapling$}\nufive{, and $\nActionsOrchard$} are nonzero.
\item A consensus rule limiting \transaction size has been added. In \Bitcoin there is
@ -13524,8 +13539,8 @@ and $\FoundersFraction$ be as defined in \crossref{constants}.
\introsection
\lsubsection{Payment of Founders' Reward}{foundersreward}
The \foundersReward is paid by a \transparent output in the \coinbaseTransaction, to
one of $\NumFounderAddresses$ \transparent addresses, depending on the \blockHeight.
The \foundersReward is paid by a \transparentOutput in the \coinbaseTransaction, to
one of $\NumFounderAddresses$ \transparentAddresses, depending on the \blockHeight.
\renewcommand{\arraystretch}{1}
@ -13865,7 +13880,7 @@ which is extended to contain a sequence of zero or more
This allows for the possibility of chaining transfers of \shielded
value in a single \Zcash \transaction, e.g.\ to spend a \shielded \note
that has just been created. (In \Zcash, we refer to value stored in
UTXOs as \transparent, and value stored in output \notes of
\utxos as \transparent, and value stored in output \notes of
\joinSplitTransfers\sapling{ or \outputTransfers)} as \shielded.)
This was not possible in the \Zerocash design without using multiple
transactions. It also allows \transparent and \shielded transfers to
@ -13892,11 +13907,11 @@ In the original \Zerocash protocol, there were two kinds of transaction
relating to \shielded \notes:
\begin{itemize}
\item a ``Mint'' transaction takes value from \transparent UTXOs as
input and produces a new \shielded \note as output.
\item a ``Mint'' transaction takes value from \utxosFull as input and
produces a new \shielded \note as output.
\item a ``Pour'' transaction takes up to $\NOld$ \shielded \notes
as input, and produces up to $\NNew$ \shielded \notes and a
\transparent UTXO as output.
as input, and produces up to $\NNew$ \shielded \notes and a
\utxo as output.
\end{itemize}
Only ``Pour'' transactions included a \zkSNARK proof.
@ -13904,10 +13919,10 @@ Only ``Pour'' transactions included a \zkSNARK proof.
\presapling{
In \Zcash, the sequence of operations added to a \transaction
(see \crossref{trstructure}) consists only of \joinSplitTransfers.
A \joinSplitTransfer is a Pour operation generalized to take a \transparent
UTXO as input, allowing \joinSplitTransfers to subsume the functionality of
A \joinSplitTransfer is a Pour operation generalized to take a \utxo
as input, allowing \joinSplitTransfers to subsume the functionality of
Mints. An advantage of this is that a \Zcash \transaction that takes
input from an UTXO can produce up to $\NNew$ output \notes, improving
input from a \utxo can produce up to $\NNew$ output \notes, improving
the indistinguishability properties of the protocol. A related change
conceals the input arity of the \joinSplitTransfer: an unused (zero-value)
input is indistinguishable from an input that takes value from a \note.
@ -14971,7 +14986,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Clarify that the change to use \hashBlockCommitments{} in a \blockHeader for \NUFive is a
consensus rule.
\item Clarify that \transparentInputs are prohibited in \coinbaseTransactions only if they have
a non-null $\prevout$ field.
a non-null $\prevoutField$ field.
\item Caveat how the result of \cite{GG2015} applies to analysis of $\PRFnf{Orchard}{}$ in
\crossref{concreteprfs}.
\item Unlinkability of \diversifiedPaymentAddresses depends on the \xDecisionalDiffieHellmanProblem,
@ -15007,7 +15022,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct errors in the definitions of $\ExtractP$ and $\ExtractPbot$ in \crossref{concreteextractorpallas}:
$\ExtractP(\ZeroP)$ should be $0$, and $\ExtractPbot(\bot)$ should be $\bot$.
\item Change the type of $\KA{Orchard}$ public keys and shared secrets to $\GroupPstar$ (i.e.\ exclude
$\ZeroP$), and the type of $\KA{Orchard}$ private keys to $\GFstar{\ParamP{r}}$ (i.e.\ exclude $0$).
$\ZeroP$), and the type of $\KA{Orchard}$ \privateKeys to $\GFstar{\ParamP{r}}$ (i.e.\ exclude $0$).
\item Change the type of an \Orchard $\InViewingKey$ to $\InViewingKeyTypeOrchard$ (i.e.\ exclude $0$).
\item Change the types of $\DiversifiedTransmitPublicOld$, $\cmOld{}$ and $\AuthSignPublicPoint$ to
$\GroupPstar$ in the \auxiliaryInputs to the \actionStatement.
@ -16449,7 +16464,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
it is the sequences of indices that are sorted, not the sequences of
hashes.
\item Correct the number of bytes in the encoding of $\solutionSize$.
\item Update the section on encoding of \transparent addresses.
\item Update the section on encoding of \transparentAddresses.
(The precise prefixes are not decided yet.)
\item Clarify why $\BlakeTwob{\ell}$ is different from truncated $\BlakeTwob{512}$.
\item Clarify a note about SU-CMA security for signatures.