diff --git a/protocol/protocol.pdf b/protocol/protocol.pdf index 212851412..254d98c62 100644 Binary files a/protocol/protocol.pdf and b/protocol/protocol.pdf differ diff --git a/protocol/protocol.tex b/protocol/protocol.tex index aafc3ff7f..882d357c0 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -1894,6 +1894,7 @@ \newcommand{\MerkleHash}[1]{\bitseq{\MerkleHashLength{#1}}} \newcommand{\MerkleHashOrchard}{\GroupPx} \newcommand{\MerkleLayer}[1]{\range{0}{\MerkleDepth{#1}-1}} +\newcommand{\hash}{\mathsf{hash}} \newcommand{\layerInput}{\mathsf{layer}} \newcommand{\layerRepr}{{l\Repr}} \newcommand{\leftInput}{\mathsf{left}} @@ -3388,17 +3389,6 @@ \sapling{There is no equivalent of interstitial \treestates for \Sapling\nufive{ or for \Orchard}.} -\nufive{ -\vspace{1ex} -$\MerkleCRH{Orchard}$ can produce $\bot$ as output (with insignificant probability). -If either input is $\bot$, this is propagated to the output, and so if any \merkleNode -of a \noteCommitmentTree is $\bot$, then the \merkleRoot of that tree will be $\bot$. - -\vspace{-1ex} -\consensusrule{The \merkleRoot of the \Orchard \noteCommitmentTree \MUSTNOT be $\bot$ -in any (intermediate or output) \treestate created by a \block.} -} %nufive - \lsubsection{JoinSplit Transfers and Descriptions}{joinsplit} @@ -3767,13 +3757,12 @@ \begin{tabular}{@{\hskip 2em}l@{\;}l@{\;}l@{\;}l@{\;}l} $\MerkleCRH{Sprout}$ &$\typecolon\, \MerkleLayer{Sprout}$ &$\times\; \MerkleHash{Sprout}$ &$\times\; \MerkleHash{Sprout}$ &$\rightarrow \MerkleHash{Sprout}$ \\ \setsapling $\MerkleCRH{Sapling}$ &\setsapling $\typecolon\, \MerkleLayer{Sapling}$ &\setsapling $\times\; \MerkleHash{Sapling}$ &\setsapling $\times\; \MerkleHash{Sapling}$ &\setsapling $\rightarrow \MerkleHash{Sapling}$\notbeforenufive{ \\ -\setnufive $\MerkleCRH{Orchard}$ &\setnufive $\typecolon\, \MerkleLayer{Orchard}$ &\setnufive $\times\; \maybe{\MerkleHashOrchard}$ &\setnufive $\times\; \maybe{\MerkleHashOrchard}$ &\setnufive $\rightarrow \maybe{\MerkleHashOrchard}$}. +\setnufive $\MerkleCRH{Orchard}$ &\setnufive $\typecolon\, \MerkleLayer{Orchard}$ &\setnufive $\times\; \MerkleHashOrchard$ &\setnufive $\times\; \MerkleHashOrchard$ &\setnufive $\rightarrow \MerkleHashOrchard$}. \end{tabular} $\MerkleCRH{Sprout}$ is \collisionResistant except on its first argument. \sapling{$\MerkleCRH{Sapling}$\notnufive{ is}\nufive{ and $\MerkleCRH{Orchard}$ are} -\collisionResistant on all\notnufive{ its}\nufive{ their} arguments\nufive{ (restricted -to non-$\bot$ inputs in the case of $\MerkleCRH{Orchard}$)}.} +\collisionResistant on all\notnufive{ its}\nufive{ their} arguments.} These functions are instantiated in \crossref{merklecrh}. @@ -5938,22 +5927,31 @@ $\MerkleNode{\MerkleDepth{}}{i}$ is in a tree with a given \merkleRoot $\rt{} = \MerkleNode{0}{0}$. \sapling{ -\pnote{ -For \Sapling, Merkle \merkleHashes are specified to be encoded as bit sequences, but the -\merkleRoot $\rt{Sapling}$ is encoded for the \primaryInput of a \spendProof as an element -of $\GF{\ParamJ{q}}$, as specified in \crossref{cctsaplingspend}. The \spendCircuit allows -inputs to $\MerkleCRH{Sapling}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded, -as specified in \crossref{cctmerklepath}. -} %pnote -} %sapling - +\begin{pnotes} + \item For \Sapling, Merkle \merkleHashes are specified to be encoded as bit sequences, but the + \merkleRoot $\rt{Sapling}$ is encoded for the \primaryInput of a \spendProof as an element + of $\GF{\ParamJ{q}}$, as specified in \crossref{cctsaplingspend}. The \spendCircuit allows + inputs to $\MerkleCRH{Sapling}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded, + as specified in \crossref{cctmerklepath}. \nufive{ -\pnote{ -For \Orchard, Merkle \merkleHashes have type $\MerkleHashOrchard$ as defined in -\crossref{concreteextractorpallas}. Similarly to \Sapling, the \actionCircuit allows inputs -to $\MerkleCRH{Orchard}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded. -} %pnote + \item For \Orchard, Merkle \merkleHashes have type $\MerkleHashOrchard$ as defined in + \crossref{concreteextractorpallas}. Similarly to \Sapling, the \actionCircuit allows + inputs to $\MerkleCRH{Orchard}$ at each \merkleNode to be \nonCanonicallyFieldElement + encoded. + \item The \actionCircuit is permitted to be implemented in such a way that the \merklePath + validity check can pass if any \merkleHash on the path, including the \merkleRoot, is + $0$. This can only happen if $\SinsemillaHash$ returned $\bot$ for that hash, because + $0$ is not the $x$-coordinate of any point on the \pallasCurve (as shown in a note at + \crossref{concreteextractorpallas}), and $\SinsemillaHashToPoint$ cannot return + $\ZeroP$. Allowing the validity check to pass in that case models the fact that + incomplete addition is used to implement Sinsemilla in the circuit. As proven in + \theoremref{thmsinsemillaex}, a $\bot$ output from $\SinsemillaHash$ yields a + nontrivial discrete logarithm relation. Since we assume finding such a relation to be + infeasible, we can argue that it is safe to allow an adversary to create a proof that + passes the Merkle validity check in such a case. } %nufive +\end{pnotes} +} %sapling \lsubsection{SIGHASH Transaction Hashing}{sighash} @@ -7085,6 +7083,9 @@ \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its input bit sequence is a canonical encoding (in $\range{0}{\ParamP{q}-1}$) of the integer from the previous \merkleLayer. + \item As specified in \crossref{merklepath}, the validity check is permitted to be implemented in + such a way that it can pass if any $\MerkleCRH{Orchard}$ hash on the \merklePath outputs $0$. + This allows nondeterministic, incomplete addition to be used in the circuit for $\SinsemillaHash$. \item It is \emph{not} checked that $\ValueCommitRand{} < \ParamP{r}$ or that $\NoteCommitRandOld{} < \ParamP{r}$ or that $\NoteCommitRandNew{} < \ParamP{r}$. \item $\SpendAuthSigRandomizePublic{Orchard}(\AuthSignRandomizer, \AuthSignPublicPoint) = @@ -8139,29 +8140,29 @@ \vspace{-2ex} Let $\SinsemillaHash$ be as specified in \crossref{concretesinsemillahash}. -$\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \maybe{\MerkleHashOrchard} \times \maybe{\MerkleHashOrchard} -\rightarrow \maybe{\MerkleHashOrchard}$ is defined as follows: +$\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHashOrchard \times \MerkleHashOrchard +\rightarrow \MerkleHashOrchard$ is defined as follows: \begin{formulae} \item $\MerkleCRH{Orchard}(\layerInput, \leftInput, \rightInput) := \begin{cases} - \bot, &\caseif \leftInput = \bot \text{ or } \rightInput = \bot \\ - \Longunderstack[l]{$\SinsemillaHash(\ascii{z.cash:Orchard-MerkleCRH},$ \\ - $\hspace{6.7em} \layerRepr \bconcat \leftRepr \bconcat \rightRepr),$} &\Longunderstack{\\ \squash otherwise} + 0, &\caseif \hash = \bot \\ + \hash, &\caseotherwise \end{cases}$ - \item \begin{tabular}{l@{\;}r@{\;}l} - where &$\layerRepr$ &$= \ItoLEBSP{10}\big(\MerkleDepth{Orchard} - 1 - \layerInput\big)$ \\ - &$\leftRepr$ &$= \ItoLEBSP{\MerkleHashLength{Orchard}}\big(\leftInput\big)$ when $\leftInput \neq \bot$ \\ - &$\rightRepr$ &$= \ItoLEBSP{\MerkleHashLength{Orchard}}\big(\rightInput\big)$ when $\rightInput \neq \bot$. + \item \begin{tabular}{@{}l@{\;}r@{\;}l} + where &$\hash$ &$= \SinsemillaHash(\ascii{z.cash:Orchard-MerkleCRH},\, \layerRepr \bconcat \leftRepr \bconcat \rightRepr)$ \\ + &$\layerRepr$ &$= \ItoLEBSP{10}\big(\MerkleDepth{Orchard} - 1 - \layerInput\big)$ \\ + &$\leftRepr$ &$= \ItoLEBSP{\MerkleHashLength{Orchard}}\big(\leftInput\big)$ \\ + &$\rightRepr$ &$= \ItoLEBSP{\MerkleHashLength{Orchard}}\big(\rightInput\big)$. \end{tabular} \end{formulae} \begin{securityrequirements} - \item $\SinsemillaHash$ must be \collisionResistant, when restricted to non-$\bot$ inputs. - \item It must be infeasible to find a input of length $6 + 2 \mult \MerkleHashLength{Orchard}$ - to $\SinsemillaHash$ that yields output $\bot$. + \item $\SinsemillaHash$ must be \collisionResistant. + \item It must be infeasible to find a input of length $10 + 2 \mult \MerkleHashLength{Orchard}$ + bits to $\SinsemillaHash$ that yields output $\bot$. \end{securityrequirements} -\pnote{The prefix $l$ provides domain separation between inputs at different layers of the +\pnote{The prefix $\layerRepr$ provides domain separation between inputs at different layers of the \noteCommitmentTree.} } %nufive @@ -10183,10 +10184,12 @@ \end{proof} \vspace{-2ex} -\nnote{There are also no points in $\GroupP$ with \affineSW $x$-coordinate $0 \pmod{\ParamP{q}}$. -We do not choose $\Uncommitted{Orchard} = 0$ because we define $\ExtractPbot\Of{\ZeroP} = 0$. -Although $\SinsemillaCommitAlg{}$ cannot return $\ZeroP$ (the incomplete addition would return -$\bot$ instead), it would arguably be confusing to rely on that.} +\nnote{There are also no points in $\GroupP$ with \affineSW $x$-coordinate +$0 \pmod{\ParamP{q}}$, as shown in a note at \crossref{concreteextractorpallas}. +We do not choose $\Uncommitted{Orchard} = 0$ because $\MerkleCRH{Orchard}$ returns $0$ +in exceptional cases. Although the \merkleHashes of \merkleLeafNodes are separated from +the \merkleHashes at other \merkleLayers by the $\layerInput$ input to $\MerkleCRH{Orchard}$, +it would arguably be confusing to rely on that.} } %nufive @@ -10868,9 +10871,13 @@ \item $\ExtractPbot\big(P \typecolon \GroupP\big) = \ExtractP(P)$. \end{formulae} -\vspace{-3ex} -\nnote{$\ExtractP$ returns the type $\GroupPx$ which is precise for its range, unlike $\ExtractJ$ -which returns a bit sequence.} +\vspace{-2ex} +\begin{pnotes} + \item There is no solution to $y^2 = 0^3 + 5$ in $\GF{\ParamP{q}}$, and so $\ExtractP(P)$ + can only be $0$ when $P = \ZeroP$. + \item $\ExtractP$ returns the type $\GroupPx$ which is precise for its range, unlike $\ExtractJ$ + which returns a bit sequence. +\end{pnotes} } %nufive \nufive{ @@ -14426,6 +14433,31 @@ \lsection{Change History}{changehistory} +\historyentry{2021.2.9}{} +\begin{itemize} +\nufive{ + \item Delete the consensus rule in \crossref{transactions} that required checking + that each intermediate \merkleRoot of the \noteCommitmentTree is not $\bot$. + Checking this rule would have imposed a significant performance penalty, + since intermediate roots do not otherwise need to be computed. + \item Change the type of $\MerkleCRH{Orchard}$ to have $\MerkleHashOrchard$ in place + of $\maybe{\MerkleHashOrchard}$ for the inputs and output, and map a $\bot$ + output from $\SinsemillaHash$ to $0$. (We retain the original definitions + of $\SinsemillaHash$ and $\SinsemillaHashToPoint$ both because it would be + disruptive to change them at this point in the Network Upgrade Process, and + because it is necessary to track $\bot$ outputs in order to correctly model + non-determinism in the \actionCircuit.) + \item Allow the Merkle path validity check in the \actionCircuit to pass if any + output of $\MerkleCRH{Orchard}$ is $0$, and add a note in \crossref{merklepath} + arguing that this is safe. + \item Fix a typo in the Security Requirements for \crossref{orchardmerklecrh}: the + length of the input to $\SinsemillaHash$ is $10 + 2 \mult \MerkleHashLength{Orchard}$ + bits, not $6 + 2 \mult \MerkleHashLength{Orchard}$ bits. +} % nufive + \item No changes before \NUFive. +\end{itemize} + + \historyentry{2021.2.8}{2021-06-29} \begin{itemize} \nufive{