diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 1f2b6211..cab0ed3a 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -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.