Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the check that Merkle roots are not ⊥ for Orchard #530

Closed
wants to merge 5 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Binary file modified protocol/protocol.pdf
Binary file not shown.
128 changes: 80 additions & 48 deletions protocol/protocol.tex
Original file line number Diff line number Diff line change
Expand Up @@ -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}}
Expand Down Expand Up @@ -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.}
Copy link
Collaborator Author

@daira daira Jun 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that after this change, the Orchard Merkle root in a final treestate (not just an intermediate treestate) is allowed to be 0. There's no advantage in making a distinction between intermediate and final roots, even if the latter is cheaper to check.

} %nufive


\lsubsection{JoinSplit Transfers and Descriptions}{joinsplit}

Expand Down Expand Up @@ -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}.

Expand Down Expand Up @@ -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}.
Comment on lines +5931 to +5935
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just moving the existing note for formatting reasons.

\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.
Comment on lines +5937 to +5940
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, this is just moving the existing note into a list.

\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}
Expand Down Expand Up @@ -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) =
Expand Down Expand Up @@ -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}$
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was an independent typo.

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
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, an independent fix.

\noteCommitmentTree.}
} %nufive

Expand Down Expand Up @@ -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


Expand Down Expand Up @@ -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$.
Comment on lines +10876 to +10877
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to say this in order to argue that MerkleCRHOrchard only returns 0 for the exceptional case that we proved would yield a discrete log.

\item $\ExtractP$ returns the type $\GroupPx$ which is precise for its range, unlike $\ExtractJ$
which returns a bit sequence.
\end{pnotes}
} %nufive

\nufive{
Expand Down Expand Up @@ -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{
Expand Down