From 78e3d6853916a14940a9e75b78cf5b050b029ecf Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 19 Mar 2021 14:00:19 +0000 Subject: [PATCH 01/41] Remove support for generating the Sprout-only specification (sprout.pdf). Signed-off-by: Daira Hopwood --- protocol/Makefile | 33 +-- protocol/protocol.tex | 523 +++++++++++------------------------------- 2 files changed, 135 insertions(+), 421 deletions(-) diff --git a/protocol/Makefile b/protocol/Makefile index 64e6e3bc..599d3c08 100644 --- a/protocol/Makefile +++ b/protocol/Makefile @@ -18,10 +18,10 @@ NOCRUFT?=|perl -pe 's|[{\<\(]\/[^ ]* ?||g;s|^.* has been referenced but does not .PHONY: all all-specs release all: .Makefile.uptodate - $(MAKE) nu5 canopy heartwood blossom sapling sprout + $(MAKE) nu5 canopy heartwood blossom sapling all-specs: .Makefile.uptodate - $(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf sprout.pdf + $(MAKE) nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf release: ifeq ($(shell git tag --points-at HEAD |wc -l),0) @@ -41,9 +41,6 @@ endif $(MAKE) clean touch .Makefile.uptodate -sprout.pdf: protocol.tex zcash.bib incremental_merkle.png key_components.png - $(MAKE) sprout - sapling.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) sapling @@ -59,18 +56,6 @@ canopy.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling nu5.pdf: protocol.tex zcash.bib incremental_merkle.png key_components_sapling.png $(MAKE) nu5 -.PHONY: auxsprout -auxsprout: - printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - mkdir -p aux - rm -f aux/sprout.* aux/protocol.* - $(LATEXMK) -jobname=sprout -auxdir=aux -outdir=aux $(EXTRAOPT) protocol $(NOCRUFT) - -.PHONY: sprout -sprout: - $(MAKE) auxsprout - mv -f aux/sprout.pdf . - .PHONY: auxsapling auxsapling: printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver @@ -132,18 +117,6 @@ nu5: $(MAKE) auxnu5 mv -f aux/nu5.pdf . -.PHONY: nolatexmk-sprout -nolatexmk-sprout: - printf '\\renewcommand{\\docversion}{Version %s [\\SproutSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver - # If $(LATEX) fails, touch an input so that 'make' won't think it is up-to-date next time. - rm -f sprout.aux sprout.bbl sprout.blg sprout.brf sprout.bcf - $(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; } - biber sprout - $(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; } - $(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; } - sh mymakeindex.sh -o sprout.ind sprout.idx - $(LATEX) -jobname=sprout protocol.tex || { touch incremental_merkle.png; exit 1; } - .PHONY: nolatexmk-sapling nolatexmk-sapling: printf '\\toggletrue{issapling}\n\\renewcommand{\\docversion}{Version %s [\\SaplingSpec]}' "$$(git describe --tags --abbrev=6)" |tee protocol.ver @@ -207,4 +180,4 @@ nolatexmk-nu5: .PHONY: clean clean: - rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf sprout.pdf + rm -f aux/* html/* protocol.ver protocol.pdf nu5.pdf canopy.pdf heartwood.pdf blossom.pdf sapling.pdf diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 841c1725..9ed46b71 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -512,7 +512,6 @@ \newcommand{\docversion}{Version unavailable (check protocol.ver)} -\newcommand{\SproutSpec}{Sprout} \newcommand{\SaplingSpec}{Overwinter+Sapling} \newcommand{\BlossomSpec}{Overwinter+Sapling+Blossom} \newcommand{\HeartwoodSpec}{Overwinter+Sapling+Blossom+Heartwood} @@ -624,16 +623,12 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \iftoggle{issapling}{ \providecommand{\baseurl}{https://zips.z.cash/protocol/sapling.pdf} - \newcommand{\sprout}[1]{} - \newcommand{\notsprout}[1]{#1} \newcommand{\setsapling}{\color{\saplingcolor}} \newcommand{\sapling}[1]{\texorpdfstring{{\setsapling{#1}}}{#1}} \newcommand{\setoverwinter}{\color{\overwintercolor}} \newcommand{\overwinter}[1]{\texorpdfstring{{\setoverwinter{#1}}}{#1}} } { \providecommand{\baseurl}{https://zips.z.cash/protocol/sprout.pdf} - \newcommand{\sprout}[1]{#1} - \newcommand{\notsprout}[1]{} \newcommand{\setsapling}{} \newcommand{\sapling}[1]{} \newcommand{\setoverwinter}{} @@ -698,8 +693,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ZerocashText}{\textbf{Zerocash}} \newcommand{\Sprout}{\termbf{Sprout}} \newcommand{\SproutText}{\textbf{Sprout}} -\newcommand{\pSproutOrNothing}{\notsprout{ (\Sprout)}\xspace} -\newcommand{\pSproutOrNothingText}{\notsprout{ (\SproutText)}} \newcommand{\Overwinter}{\termbf{Overwinter}} \newcommand{\OverwinterText}{\textbf{Overwinter}} \newcommand{\Sapling}{\termbf{Sapling}} @@ -2342,13 +2335,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\heartwoodonward}[1]{\heartwood{[\Heartwood onward]\, {#1}}} \newcommand{\preblossom}[1]{\notbeforeblossom{\blossom{[Pre-\Blossom\!]\,}} {#1}} \newcommand{\blossomonward}[1]{\blossom{[\Blossom onward]\, {#1}}} -\newcommand{\presapling}[1]{\notsprout{\sapling{[Pre-\Sapling\!]\,}} {#1}} +\newcommand{\presapling}[1]{\sapling{[Pre-\Sapling\!]\,} {#1}} \newcommand{\saplingonward}[1]{\sapling{[\Sapling onward]\, {#1}}} \newcommand{\saplingandblossom}[1]{\sapling{[\Sapling and \Blossom only, \heartwood{pre-\Heartwood}]\,} {#1}} -\newcommand{\preoverwinter}[1]{\notsprout{\overwinter{[Pre-\Overwinter\!]\,}} {#1}} +\newcommand{\preoverwinter}[1]{\overwinter{[Pre-\Overwinter\!]\,} {#1}} \newcommand{\overwinteronly}[1]{\overwinter{[\Overwinter only, \sapling{pre-\Sapling}]\, {#1}}} \newcommand{\overwinteronward}[1]{\overwinter{[\Overwinter onward]\, {#1}}} -\newcommand{\sproutspecific}[1]{\notsprout{[\Sprout\!]\,} {#1}} +\newcommand{\sproutspecific}[1]{[\Sprout\!]\, {#1}} \newcommand{\securityrequirement}[1]{\needspace{4ex}\vspace{2ex}\callout{}{Security requirement:}{#1}} \newenvironment{securityrequirements}{\introlist\callout{}{Security requirements:}\begin{itemize}}{\end{itemize}} @@ -2364,11 +2357,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\canopyonwardpnote}[1]{\canopy{\callout{[\Canopy onward]\,\,}{Note:}{#1}}} \newcommand{\precanopypnote}[1]{\callout{\notbeforecanopy{\canopy{[Pre-\Canopy\!]\,\,}}}{Note:}{#1}} \newcommand{\preheartwoodpnote}[1]{\callout{\notbeforeheartwood{\heartwood{[Pre-\Heartwood\!]\,\,}}}{Note:}{#1}} -\newcommand{\presaplingpnote}[1]{\callout{\notsprout{\sapling{[Pre-\ Sapling\!]\,\,}}}{Note:}{#1}} -\newcommand{\preoverwinterpnote}[1]{\callout{\notsprout{\overwinter{[Pre-\Overwinter\!]\,\,}}}{Note:}{#1}} +\newcommand{\presaplingpnote}[1]{\callout{\sapling{[Pre-\ Sapling\!]\,\,}}{Note:}{#1}} +\newcommand{\preoverwinterpnote}[1]{\callout{\overwinter{[Pre-\Overwinter\!]\,\,}}{Note:}{#1}} \newcommand{\overwinteronlypnote}[1]{\callout{\overwinter{[\Overwinter only, \sapling{pre-\Sapling}]\,\,}}{Note:}{#1}} \newcommand{\overwinteronwardpnote}[1]{\callout{\overwinter{[\Overwinter onward]\,\,}}{Note:}{#1}} -\newcommand{\sproutspecificpnote}[1]{\callout{\notsprout{[\Sprout\!]\,\,}}{Note:}{#1}} +\newcommand{\sproutspecificpnote}[1]{\callout{[\Sprout\!]\,\,}{Note:}{#1}} \newcommand{\fact}[1]{\callout{}{Fact:}{#1}} \newcommand{\facts}[1]{\callout{}{Facts:}{#1}} @@ -2385,15 +2378,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \Large \coauthora\affiliation — \coauthorb\affiliation — \coauthorc\affiliation} \date{\today} \maketitle -\vspace{-6ex}\sprout{\vspace{-3ex}} +\vspace{-6ex} -\notsprout{ \begin{center} \hspace{0.6em}\includegraphics[scale=.1]{jubjub} \footnote{Jubjub bird image credit: Peter Newell 1902; Daira Hopwood 2018.} \end{center} \vspace{-6ex} -} %notsprout \renewcommand{\abstractname}{} \begin{abstract} @@ -2406,11 +2397,7 @@ succinct non-interactive arguments of knowledge (\zkSNARKs). It attempted to address the problem of mining centralization by use of the \Equihash memory-hard proof-of-work algorithm. -\notsprout{\vspace{1.5ex}} -\sprout{\noindent This specification defines the \Zcash consensus protocol -as it was at launch, and explains its differences from \Zerocash and \Bitcoin. -It is a historical document and no longer specifies the current \Zcash -consensus protocol.} +\vspace{1.5ex} \notblossom{\sapling{\noindent This specification defines the \Zcash consensus protocol at launch; after the upgrade codenamed \Overwinter; and after the subsequent upgrade codenamed \Sapling. It is a work in progress. @@ -2432,8 +2419,7 @@ at launch; after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom, \Heartwood, and \Canopy; and proposed changes for \NUFive. It is a work in progress. Protocol differences from \Zerocash and \Bitcoin are also explained.} - -\sprout{\vspace{1ex}}\notsprout{\vspace{2.5ex}} +\vspace{2.5ex} \noindent \textbf{Keywords:}~ \StrSubstitute[0]{\keywords}{,}{, }. \ifxetex @@ -2450,7 +2436,6 @@ This document was built with Lua\TeX, which is \href{https://github.com/zcash/zi \end{abstract} -\sprout{\vspace{-2ex}} \phantompart{Contents}{contents} \renewcommand{\contentsname}{} @@ -2473,7 +2458,7 @@ non-interactive arguments of knowledge (\zkSNARKs). Changes from the original \Zerocash are explained in \crossref{differences}, and highlighted in \changed{\changedcolorname} throughout the document. -\notsprout{Changes specific to the \Overwinter upgrade +Changes specific to the \Overwinter upgrade are highlighted in \overwinter{\overwintercolorname}. Changes specific to the \Sapling upgrade following \Overwinter @@ -2494,15 +2479,13 @@ are highlighted in \nufive{\nufivecolorname}.} All of these are also changes from \Zerocash. The name \Sprout is used for the \Zcash protocol prior to \Sapling (both before and after \Overwinter), and in particular its shielded protocol. -} %notsprout Technical terms for concepts that play an important rôle in \Zcash are written in \defining{\term{slanted text}}. \emph{Italics} are used for emphasis and for references between sections of the document. -The key words \defining{\MUST, \MUSTNOT, \SHOULD, -\sprout{and \SHOULDNOT}\notsprout{\SHOULDNOT, \RECOMMENDED, \MAY, and \OPTIONAL}} in -this document are to be interpreted as described in \cite{RFC-2119} when +The key words \defining{\MUST, \MUSTNOT, \SHOULD, \SHOULDNOT, \RECOMMENDED, \MAY, and \OPTIONAL} +in this document are to be interpreted as described in \cite{RFC-2119} when they appear in \defining{\ALLCAPS}. These words may also appear in this document in lower case as plain English words, absent their normative meanings. @@ -2517,19 +2500,15 @@ This specification is structured as follows: of ideal cryptographic components; \item Concrete Protocol — how the functions and encodings of the abstract protocol are instantiated; -\notsprout{ \item Network Upgrades — the strategy for upgrading the \Zcash protocol. -} \item Consensus Changes from \Bitcoin — how \Zcash differs from \Bitcoin at the consensus layer, including the Proof of Work; \item Differences from the \Zerocash protocol — a summary of changes from the protocol in \cite{BCGGMTV2014}. -\notsprout{ \item Appendix: Circuit Design — details of how the \Sapling circuits are defined as \quadraticConstraintPrograms. \item Appendix: Batching Optimizations — improvements to the efficiency of validating multiple signatures and verifying multiple proofs. -} \end{itemize} @@ -2554,9 +2533,9 @@ please file an issue at \url{https://github.com/zcash/zips/issues} or contact The following overview is intended to give a concise summary of the ideas behind the protocol, for an audience already familiar with \blockChain-based cryptocurrencies such as \Bitcoin. It is imprecise in some aspects and is not -part of the normative protocol specification. \notsprout{This overview applies to +part of the normative protocol specification. This overview applies to \notnufive{both \Sprout and \Sapling}\notbeforenufive{\Sprout, \Sapling, and \Orchard}, -differences in the cryptographic constructions used notwithstanding.} +differences in the cryptographic constructions used notwithstanding. \introsection Value in \Zcash is either \defining{\transparent or \shielded}. Transfers of \transparent @@ -2566,8 +2545,8 @@ value work essentially as in \Bitcoin and have the same privacy properties. \defining{\quotedtermandindex{coins}{coins (in Zerocash)}}, and \nullifiers were called \defining{\quotedtermandindex{serial numbers}{serial numbers (in Zerocash)}}.}, -which specify an amount and \sprout{a \payingKey. The \payingKey is part of}\notsprout{ (indirectly)} -a \shieldedPaymentAddress, which is a destination to which \notes can be sent. +which specify an amount and (indirectly) a \shieldedPaymentAddress, which is a +destination to which \notes can be sent. As in \Bitcoin, this is associated with a \privateKey that can be used to spend \notes sent to the address; in \Zcash this is called a \spendingKey. @@ -2577,23 +2556,14 @@ To each \note there is cryptographically associated a \noteCommitment. Once the unique to that \note. Computing the \nullifier requires the associated private \spendingKey\sapling{ (or the \nullifierDerivingKey for \SaplingOrOrchard \notes)}. It is infeasible to correlate the \noteCommitment or \notePosition with the -corresponding \nullifier without knowledge of at least this -\sprout{\spendingKey}\notsprout{key}. An unspent valid \note, at a given point -on the \blockChain, is one for which the \noteCommitment has been publically -revealed on the \blockChain prior to that point, but the \nullifier has not. +corresponding \nullifier without knowledge of at least this key. An unspent valid +\note, at a given point on the \blockChain, is one for which the \noteCommitment +has been publically revealed on the \blockChain prior to that point, but the +\nullifier has not. \introlist A \transaction can contain \transparent inputs, outputs, and scripts, which all work as in \Bitcoin \cite{Bitcoin-Protocol}. -\sprout{ -It also can include a sequence of zero or more \joinSplitDescriptions. -Each of these describes a \joinSplitTransfer\footnote{ -\joinSplitTransfers in \Zcash generalize \quotedterm{Mint} and \quotedterm{Pour} -\transactions in \Zerocash; see \crossref{trstructure} for differences.} -which takes in a \transparent value and up to two input \notes, and produces a -\transparent value and up to two output \notes. -} -\notsprout{ It also can include \joinSplitDescriptions,\sapling{ \spendDescriptions,\notnufive{ and} \outputDescriptions}\nufive{ and \actionDescriptions}. Together these describe \defining{\shieldedTransfers} which take in \defining{\shieldedInput} \notes, @@ -2604,30 +2574,12 @@ has its own description.}\nufive{ For \Orchard, each \actionDescription handles up to one \shieldedInput and up to one \shieldedOutput.}) It is also possible for value to be transferred between the \transparent and \shielded domains. -} The \nullifiers of the input \notes are revealed (preventing them from being spent again) and the commitments of the output \notes are revealed (allowing -them to be spent in future).\sprout{ Each -\joinSplitDescription also includes a computationally sound \zkSNARK proof, -which proves that all of the following hold except with insignificant probability: - -\begin{itemize} - \item The input and output values balance (individually for each \joinSplitTransfer). - \item For each input \note of nonzero value, some revealed \noteCommitment - exists for that \note. - \item The prover knew the private \spendingKeys of the input \notes. - \item The \nullifiers and \noteCommitments are computed correctly. - \item The private \spendingKeys of the input \notes are cryptographically - linked to a signature over the whole \transaction, in such a way that - the \transaction cannot be modified by a party who did not know these - \privateKeys. - \item Each output \note is generated in such a way that it is infeasible to - cause its \nullifier to collide with the \nullifier of any other \note. -\end{itemize} -}\notsprout{ A -\transaction also includes computationally sound \zkSNARK proofs and signatures, -which prove that all of the following hold except with insignificant probability: +them to be spent in future). A \transaction also includes computationally sound +\zkSNARK proofs and signatures, which prove that all of the following hold except +with insignificant probability: For each \shieldedInput, @@ -2662,18 +2614,15 @@ outside the \zkSNARK.} In addition, various measures\sapling{ (differing between \Sprout and \SaplingOrOrchard)} are used to ensure that the \transaction cannot be modified by a party not authorized to do so. -} %notsprout -Outside the \zkSNARK, it is\sprout{ also} checked that the \nullifiers for the input +Outside the \zkSNARK, it is checked that the \nullifiers for the input \notes had not already been revealed (i.e.\ they had not already been spent). -A \shieldedPaymentAddress includes -\sprout{two \publicKeys: a \payingKey matching that of \notes sent to the address, and }a -\transmissionKey for a ``\keyPrivate'' asymmetric encryption -scheme. \defining{\mbox{\xKeyPrivate}} means that ciphertexts do not reveal information -about which key they were encrypted to, except to a holder of the corresponding -\privateKey, which in this context is called the \receivingKey. This facility is -used to communicate encrypted output \notes on the \blockChain to their +A \shieldedPaymentAddress includes a \transmissionKey for a ``\keyPrivate'' asymmetric +encryption scheme. \defining{\mbox{\xKeyPrivate}} means that ciphertexts do not +reveal information about which key they were encrypted to, except to a holder of the +corresponding \privateKey, which in this context is called the \receivingKey. This +facility is used to communicate encrypted output \notes on the \blockChain to their intended recipient, who can use the \receivingKey to scan the \blockChain for \notes addressed to them and then decrypt those \notes. @@ -2744,7 +2693,6 @@ $S \union T$ means the set union of $S$ and $T$. $S \intersection T$ means the set intersection of $S$ and $T$, i.e.\ $\setof{x \typecolon S \suchthat x \in T}$. -\notsprout{ $S \setminus T$ means the set difference obtained by removing elements in $T$ from $S$, i.e. $\setof{x \typecolon S \suchthat x \notin T}$. @@ -2757,7 +2705,6 @@ $\fun{x \typecolon T}{e_x \typecolon U \union V}$ restricted to the domain $\setof{x \typecolon T \suchthat e_x \not\in V}$ and range $U$. $\powerset{T}$ means the powerset of $T$. -} $\typeexp{T}{\ell}$, where $T$ is a type and $\ell$ is an integer, means the type of sequences of length $\ell$ with elements in $T$. For example, @@ -2768,20 +2715,18 @@ $\byteseqs$ means the type of byte sequences of arbitrary length. $\length(S)$ means the length of (number of elements in) $S$. -\notsprout{ $\truncate{k}(S)$ means the sequence formed from the first $k$ elements of $S$. -} $\hexint{}$ followed by a string of $\mathtt{monospace}$ hexadecimal digits means the corresponding integer converted from hexadecimal. -\notsprout{$\zerobytes{\ell}$ means the sequence of $\ell$ zero bytes.} +$\zerobytes{\ell}$ means the sequence of $\ell$ zero bytes. $\ascii{...}$ means the given string represented as a sequence of bytes in US-ASCII. For example, $\ascii{abc}$ represents the byte sequence $\hexarray{61,62,63}$. $\zeros{\ell}$ means the sequence of $\ell$ zero bits. -\notsprout{$\ones{\ell}$ means the sequence of $\ell$ one bits.} +$\ones{\ell}$ means the sequence of $\ell$ one bits. $a..b$, used as a subscript, means the sequence of values with indices $a$ through $b$ inclusive. For example, @@ -2867,7 +2812,6 @@ $\ssum{i=1}{0} a_i = 0$, $\sproduct{i=1}{0} a_i = 1$, and $\sxor{i=1}{0} a_i = 0$ or the all-zero bit sequence of length given by the type of $a$. -\notsprout{ $\possqrt{a}$, where $a \typecolon \GF{q}$, means the positive square root of $a$ in $\GF{q}$, i.e.\ in the range $\bigrange{0}{\hfrac{q-1}{2}}$. It is only used in cases where the square root must exist. @@ -2876,7 +2820,6 @@ $\optsqrt{a}$, where $a \typecolon \GF{q}$, means an arbitrary square root of $a$ in $\GF{q}$, or $\bot$ if no such square root exists. $b \bchoose x : y$ means $x$ when $b = 1$, or $y$ when $b = 0$. -} $a^b$, for $a$ an integer or finite field element and $b \typecolon \Int$, means the result of raising $a$ to the exponent $b$, @@ -2924,12 +2867,6 @@ The following integer constants will be instantiated in \crossref{constants}: \end{flushleft} \end{formulae} -\sprout{ -The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$, and -the bit sequence constant $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}}$, -will also be defined in that section. -} %sprout -\notsprout{ The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$, and the bit sequence constants $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}}$, \sapling{$\Uncommitted{Sapling} \typecolon \bitseq{\MerkleHashLength{Sapling}}$,} @@ -2938,7 +2875,6 @@ will also be defined in that section. We use the abbreviation ``\defining{\xCtEdwards}'' to refer to \completeTwistedEdwardsEllipticCurves and coordinates (see \crossref{jubjub}). -} \intropart @@ -2951,14 +2887,13 @@ Users who wish to receive shielded payments in the \Zcash protocol must have a \introlist The following diagram depicts the relations between key -components\notsprout{ in \Sprout}\sapling{ and \Sapling}\nufive{ and \Orchard}. +components in \Sprout\sapling{ and \Sapling}\nufive{ and \Orchard}. Arrows point from a component to any other component(s) that can be derived from it. Double lines indicate that the same component is used in multiple abstractions. \begin{center} -\sprout{\includegraphics[scale=.7]{key_components}} -\sapling{\notnufive{\includegraphics[scale=.5]{key_components_sapling}}} +\notnufive{\includegraphics[scale=.5]{key_components_sapling}} \nufive{\includegraphics[scale=.385]{key_components_orchard}} \end{center} @@ -3045,23 +2980,14 @@ in order to exploit a hypothetical weakness in that cryptosystem. \introsection \lsubsection{Notes}{notes} -\sprout{ -A \defining{\note} (denoted $\NoteTuple{}$) is a tuple $\changed{(\AuthPublic, \Value, -\NoteUniqueRand, \NoteCommitRand)}$. It represents that a value $\Value$ is -spendable by the recipient who holds the \spendingKey $\AuthPrivate$ corresponding -to $\AuthPublic$, as described in the previous section. -} %sprout -\notsprout{ A \defining{\note} (denoted $\NoteTuple{}$) can be a \Sprout \note\sapling{ or a \Sapling \note}\nufive{ or an \Orchard \note}. In each case it represents that a value $\Value$ is spendable by the recipient who holds the \spendingKey corresponding to a given \shieldedPaymentAddress. -} %notsprout \vspace{1ex} -Let \sprout{$\MAXMONEY$ and $\PRFOutputLengthSprout$} -\notsprout{$\MAXMONEY$, $\PRFOutputLengthSprout$\sapling{, $\PRFOutputLengthNfSapling$,\notnufive{ and} -$\DiversifierLength$}}\nufive{, and $\ValueLength$} be as defined in \crossref{constants}. +Let $\MAXMONEY$, $\PRFOutputLengthSprout$\sapling{, $\PRFOutputLengthNfSapling$,\notnufive{ and} +$\DiversifierLength$}\nufive{, and $\ValueLength$} be as defined in \crossref{constants}. Let $\NoteCommitAlg{Sprout}$ be as defined in \crossref{concretesproutnotecommit}. @@ -3086,8 +3012,8 @@ Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. \vspace{2ex} \introlist -A \Sprout \note is a tuple $\changed{(\AuthPublic, -\Value, \NoteUniqueRand, \NoteCommitRand)}$, where: +A \Sprout \note is a tuple $\changed{(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)}$, +where: \begin{itemize} \item $\AuthPublic \typecolon \PRFOutputSprout$ is the \defining{\payingKey} of the recipient's \shieldedPaymentAddress; @@ -3359,11 +3285,9 @@ The remaining value in the \transparentTxValuePool \MUST be nonnegative. \vspace{2ex} \introlist -\sprout{To each \transaction there is associated an initial \defining{\treestate}. -A \treestate consists of:} -\notsprout{To each \transaction there are associated initial \defining{\treestates} +To each \transaction there are associated initial \defining{\treestates} for \Sprout\sapling{ and for \Sapling}\nufive{ and for \Orchard}. \sapling{Each} -\treestate consists of:} +\treestate consists of: \begin{itemize} \item a \noteCommitmentTree (\crossref{merkletree}); @@ -3396,18 +3320,17 @@ In a given \blockChain, \sapling{for each of \Sprout and \SaplingAndOrchard,} \end{itemize} \changed{\joinSplitDescriptions also have interstitial input and output -\treestates\notsprout{ for \Sprout}, explained in the following section.} +\treestates for \Sprout, explained in the following section.} \sapling{There is no equivalent of interstitial \treestates for \Sapling\nufive{ or for \Orchard}.} \lsubsection{JoinSplit Transfers and Descriptions}{joinsplit} -A \defining{\joinSplitDescription} is data included in a \transaction that describes a -\defining{\joinSplitTransfer}, i.e.\ a \shielded value transfer. -\sprout{This kind of value transfer is} -\notsprout{In \Sprout, this kind of value transfer was} -the primary \Zcash-specific operation performed by \transactions. +A \defining{\joinSplitDescription} is data included in a \transaction that describes +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 @@ -3698,12 +3621,6 @@ Let $\GroupJ$, $\SubgroupJ$, $\SubgroupJstar$, $\ParamJ{r}$, and $\ellJ$ be as d Let $\GroupPstar$ be as defined in \crossref{pallasandvesta}. } %nufive -\sprout{ -$\MerkleCRH \typecolon \MerkleHash{Sprout} \times \MerkleHash{Sprout} \rightarrow \MerkleHash{Sprout}$ -is a \collisionResistant \hashFunction used in \crossref{merklepath}. -It is instantiated in \crossref{merklecrh}. -} %sprout -\notsprout{ \introlist The following \hashFunctions are used in \crossref{merklepath}: @@ -3718,7 +3635,6 @@ $\MerkleCRH{Sprout}$ is \collisionResistant except on its first argument. \collisionResistant on all\notnufive{ its}\nufive{ their} arguments.} These functions are instantiated in \crossref{merklecrh}. -} %notsprout \changed{ $\hSigCRH{} \typecolon \bitseq{\RandomSeedLength} \times \typeexp{\PRFOutputSprout}{\NOld} \times \JoinSplitSigPublic \rightarrow \hSigType$ @@ -3777,11 +3693,9 @@ Let $\ellP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. \vspace{1ex} \introlist -\sprout{\changed{Four} \emph{independent} $\PRF{x}{}$ are needed in our protocol:} +For \Sprout, \changed{four} \emph{independent} $\PRF{x}{}$ are needed: -\notsprout{For \Sprout, \changed{four} \emph{independent} $\PRF{x}{}$ are needed:} - -\begin{tabular}{@{\hskip 2em}l@{\;\notnufive{\hskip 0.86em}}l@{\;\notnufive{\hskip 0.54em}}l@{\;}l@{\,\notnufive{\notsprout{\hskip 4em}}}l} +\begin{tabular}{@{\hskip 2em}l@{\;\notnufive{\hskip 0.86em}}l@{\;\notnufive{\hskip 0.54em}}l@{\;}l@{\,\notnufive{\hskip 4em}}l} $\PRFaddr{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \byte $& &$\rightarrow \PRFOutputSprout$ \\ $\PRFpk{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \setofOld $&$\times\; \hSigType $&$\rightarrow \PRFOutputSprout$ \\ $\setchanged\PRFrho{} $&$\setchanged\typecolon\; \bitseq{\NoteUniquePreRandLength} $&$\setchanged\times\; \setofNew $&$\setchanged\times\; \hSigType $&$\setchanged\rightarrow \PRFOutputSprout$ \\ @@ -3841,12 +3755,12 @@ $\PRFnf{Sapling}{}$ is used in \crossref{spendstatement}. $\PRFnf{Orchard}{}$ is used in \crossref{actionstatement}. } %nufive -\sprout{They}\notsprout{All of these \pseudoRandomFunctions} are instantiated in \crossref{concreteprfs}. +All of these \pseudoRandomFunctions are instantiated in \crossref{concreteprfs}. \begin{securityrequirements} \item Security definitions for \defining{\pseudoRandomFunctions} are given in \cite[section 4]{BDJR2000}. \item In addition to being \pseudoRandomFunctions, it is required that - $\PRFaddr{x}$,\changed{ $\PRFrho{x}$,\sprout{ and} $\PRFnf{Sprout}{x}$}\sapling{,\notnufive{ and} + $\PRFaddr{x}$,\changed{ $\PRFrho{x}$, $\PRFnf{Sprout}{x}$}\sapling{,\notnufive{ and} $\PRFnf{Sapling}{x}$}\nufive{ and $\PRFnf{Orchard}{x}$} be \collisionResistant across all $x$ --- i.e.\ finding $(x, y) \neq (x', y')$ such that $\PRFaddr{x}(y) = \PRFaddr{x'}(y')$ should not be feasible\changed{, and similarly for $\PRFrho{}$ and $\PRFnf{Sprout}{}$\sapling{ and @@ -3947,47 +3861,6 @@ A \defining{\keyDerivationFunction} is defined for a particular \keyAgreementSch agreement and additional arguments, and derives a key suitable for the encryption scheme. -\sprout{ -Let $\KDF{Sprout} \typecolon \setofNew \times \hSigType \times \KASharedSecret{Sprout} -\times \KAPublic{Sprout} \times \KAPublic{Sprout} \rightarrow \Keyspace$ be a -\keyDerivationFunction suitable for use with $\KA{Sprout}$, deriving keys -for $\SymEncrypt{}$. - -\securityrequirement{ -In addition to adaptive security of the key agreement and KDF, -the following security property is required: - -Let $\TransmitBase{Sprout} := \KABase{Sprout}$. - -Let $\TransmitPrivateSup{1}$ and $\TransmitPrivateSup{2}$ each be chosen uniformly and -independently at random from $\KAPrivate{Sprout}$. - -Let $\TransmitPublicSup{j} := \KADerivePublic{Sprout}(\TransmitPrivateSup{j}, \TransmitBase{Sprout})$. - -\introlist -An adversary can adaptively query a function -$Q \typecolon \range{1}{2} \times \hSigType \rightarrow -\KAPublic{Sprout} \times \Keyspace_{\allNew}$ where $Q_j(\hSig)$ is defined as follows: -\begin{enumerate} - \item Choose $\EphemeralPrivate$ uniformly at random from $\KAPrivate{Sprout}$. - \item Let $\EphemeralPublic = \KADerivePublic{Sprout}(\EphemeralPrivate, \TransmitBase{Sprout})$. - \item For $i \in \setofNew$, let $\Key_i = - \KDF{}(i, \hSig, \KAAgree{Sprout}(\EphemeralPrivate, \TransmitPublicSup{j}), \EphemeralPublic, \TransmitPublicSup{j}))$. - \item Return $(\EphemeralPublic, \Key_{\allNew})$. -\end{enumerate} - -Then the adversary must make another query to $Q_j$ with random unknown -$j \in \range{1}{2}$, and guess $j$ with probability greater than chance. -} %securityrequirement - -\pnote{The given definition only requires ciphertexts to be indistinguishable -between \transmissionKeys that are outputs of $\KADerivePublic{Sprout}$ (which -includes all keys generated as in \crossref{sproutkeycomponents}). If a -\transmissionKey not in that range is used, it may be distinguishable. -This is not considered to be a significant security weakness.} -} %sprout - -\notsprout{ \introlist \sapling{The inputs to the \keyDerivationFunction differ between the \Sprout and \SaplingAndOrchard KDFs:} @@ -4039,7 +3912,6 @@ with $\KA{Orchard}$ and derives keys for $\SymEncrypt{}$. \end{securityrequirements} \defining{\xKeyPrivacy is defined in \cite{BBDP2001}.} -} %notsprout \vspace{-1ex} @@ -4066,16 +3938,16 @@ such that for any \signingKey $\sk \leftarrowR \SigGenPrivate()$ and correspondi any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrowR \SigSign{\sk}(m)$, $\SigValidate{\vk}(m, s) = 1$. -\vspace{1ex}\sprout{\vspace{2ex}} +\vspace{1ex} \introlist -\Zcash uses \sprout{two}\sapling{four} \signatureSchemes: +\Zcash uses \sapling{four} \signatureSchemes: \begin{itemize} \item one used for signatures that can be validated by script operations such as \ScriptOP{CHECKSIG} and \ScriptOP{CHECKMULTISIG} as in \Bitcoin; \vspace{-0.5ex} \item one called $\JoinSplitSig$ which is used to sign \transactions that contain at least one \joinSplitDescription (instantiated in - \crossref{concretejssig})\sprout{.}\notsprout{;} + \crossref{concretejssig}); \vspace{-0.5ex} \saplingonwarditem{one called $\SpendAuthSig{}$ which is used to sign authorizations of \spendTransfers (instantiated in \crossref{concretespendauthsig});} @@ -4094,12 +3966,10 @@ The signature scheme used in script operations is instantiated by \ECDSA on the \sapling{$\SpendAuthSig{}$ and $\BindingSig{}$ are instantiated by $\RedDSA$; on the \jubjubCurve in \Sapling\nufive{, and on the \pallasCurve in \Orchard}.} -\notsprout{ The following security property is needed for $\JoinSplitSig$\sapling{ and $\BindingSig{}$}. \sapling{Security requirements for $\SpendAuthSig{}$ are defined in the next section, \crossref{abstractsigrerand}. An additional requirement for $\BindingSig{}$ is defined in \crossref{abstractsigmono}.} -} %notsprout \vspace{-1ex} \securityrequirement{ @@ -4114,8 +3984,6 @@ pair without access to the \signingKey. \vspace{1ex} \begin{nnotes} -\notsprout{ -% Sprout *doesn't* need this, so it wouldn't make sense to include this explanation in the Sprout-only spec. \item We need separate \signingKey generation and \validatingKey derivation algorithms, rather than the more conventional combined key pair generation algorithm $\SigGen \typecolon () \rightarrowR \SigPrivate \times \SigPublic$, to support @@ -4124,7 +3992,6 @@ pair without access to the \signingKey. The definitions of schemes with additional features in \crossref{abstractsigrerand} and in \crossref{abstractsigmono} also become simpler. -} %notsprout \item A fresh signature key pair is generated for each \transaction containing a \joinSplitDescription{}. Since each key pair is only used for one signature (see \crossref{sproutnonmalleability}), @@ -4334,13 +4201,6 @@ be a function satisfying the following security requirements. such that $x \neq x'$ and $\Commit{r}(x) = \Commit{r'}(x')$. \end{securityrequirements} -\sprout{ -\pnote{If it were only feasible to find $x \typecolon \CommitInput$ and -$r, r' \typecolon \CommitTrapdoor$ such that $r \neq r'$ and -$\Commit{r}(x) = \Commit{r'}(x)$, this would not contradict -the computational binding security requirement.} -} %sprout -\notsprout{ \vspace{-1ex} \begin{pnotes}[leftmargin=2em] \item $\CommitGenTrapdoor$ need not produce the uniform distribution on $\CommitTrapdoor$. @@ -4354,7 +4214,6 @@ the computational binding security requirement.} for those algorithms is $\binaryrange{\ScalarLength{Sapling}}$ where $2^{\ScalarLength{Sapling}} > \ParamJ{r}$.)} \end{pnotes} -} %notsprout \vspace{1ex} Let $\NoteCommitRandLength$, $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$, @@ -4367,8 +4226,8 @@ $\NoteCommitOutput{Sprout} := \bitseq{\MerkleHashLength{Sprout}}$. \begin{tabular}{@{\hskip 1.5em}r@{\;}l} $\NoteCommit{Sprout}{} $&$\typecolon\; \NoteCommitTrapdoor{Sprout} \times \PRFOutputSprout - \times \ValueType \times \PRFOutputSprout$ - \notsprout{\\[-1ex]\hphantom{$\NoteCommitAlg{Sapling}$} &\hspace{26.9em}}$\rightarrow \NoteCommitOutput{Sprout}$, + \times \ValueType \times \PRFOutputSprout$ \\[-1ex] + \hphantom{$\NoteCommitAlg{Sapling}$} &\hspace{26.9em}$\rightarrow \NoteCommitOutput{Sprout}$, \end{tabular} instantiated in \crossref{concretesproutnotecommit}. @@ -4686,14 +4545,6 @@ infeasible to find a new proof $\Proof{}$ where $\ZKVerify{\vk}(x, \Proof{}) = 1 ``verify'' \zkSNARKProofs. \end{nnotes} -\sprout{ -The \provingSystem is instantiated in \crossref{bctv}. -$\JoinSplit$ refers to this \provingSystem with the \BNPairing pairing, -specialized to the \joinSplitStatement given in \crossref{joinsplitstatement}. -In this case we omit the key subscripts on $\JoinSplitProve$ and $\JoinSplitVerify$, -taking them to be the particular \provingKey and \verifyingKey defined by the -\joinSplitParameters in \crossref{bctvparameters}. -} %sprout \sapling{ \introlist \Zcash uses \notnufive{two}\nufive{three} \provingSystems: @@ -4744,9 +4595,9 @@ parameter files. } %sapling -\lsubsection{Key Components}{\sprout{sproutkeycomponents}\notsprout{keycomponents}} +\lsubsection{Key Components}{keycomponents} -\notsprout{\lsubsubsection{\SproutText{} Key Components}{sproutkeycomponents}} +\lsubsubsection{\SproutText{} Key Components}{sproutkeycomponents} Let $\AuthPrivateLength$ be as defined in \crossref{constants}. @@ -5343,7 +5194,7 @@ $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrc \lsubsection{Sending Notes}{send} \vspace{-1ex} -\notsprout{\lsubsubsection{Sending Notes (\SproutText)}{sproutsend}} +\lsubsubsection{Sending Notes (\SproutText)}{sproutsend} \vspace{-1ex} In order to send \Sprout \shielded value, the sender constructs a @@ -5590,10 +5441,10 @@ this should have no negative effect on security. \vspace{-1ex} \introlist -\lsubsection{Dummy Notes}{\sprout{sproutdummynotes}\notsprout{dummynotes}} +\lsubsection{Dummy Notes}{dummynotes} \vspace{-1ex} -\notsprout{\lsubsubsection{Dummy Notes\pSproutOrNothingText}{sproutdummynotes}} +\lsubsubsection{Dummy Notes (\SproutText)}{sproutdummynotes} \vspace{-1ex} The fields in a \joinSplitDescription allow for $\NOld$ input \notes, and @@ -5742,10 +5593,6 @@ zero value, and sent to a random \shieldedPaymentAddress. \introsection \lsubsection{Merkle Path Validity}{merklepath} -\sprout{ -The depth of the \noteCommitmentTree is $\MerkleDepth{}$ (defined in \crossref{constants}). -} %sprout -\notsprout{ Let $\MerkleDepth{}$ be $\MerkleDepth{Sprout}$ for the \Sprout \noteCommitmentTree\sapling{, or $\MerkleDepth{Sapling}$ for the \Sapling \noteCommitmentTree}\nufive{, or $\MerkleDepth{Orchard}$ for the \Orchard \noteCommitmentTree}. @@ -5756,7 +5603,6 @@ or $\MerkleCRH{Sapling}$ for \Sapling}\nufive{, or $\MerkleCRH{Orchard}$ for \Or The following discussion applies independently to the \Sprout and \Sapling\nufive{ and \Orchard} \noteCommitmentTrees. -} %notsprout Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash, which is a bit sequence. @@ -5814,17 +5660,13 @@ with \transaction inputs to authorize spending. Because these signatures or proo could otherwise be replayed in a different \transaction, it is necessary to ``bind'' them to the \transaction for which they are intended. This is done by hashing information about the \transaction and (where applicable) the specific input, to give a -\defining{\sighashTxHash} which is then used for the Spend authorization. The means of -authorization differs between -\sprout{\transparentInputs and inputs to \Sprout \joinSplitTransfers,} -\notsprout{\transparentInputs, inputs to \Sprout \joinSplitTransfers,\sapling{ and -\Sapling \spendTransfers\nufive{ or \Orchard \actionTransfers,}}} +\defining{\sighashTxHash} which is then used for the Spend authorization. +The means of authorization differs between \transparentInputs, inputs to \Sprout +\joinSplitTransfers,\sapling{ and \Sapling \spendTransfers\nufive{ or \Orchard \actionTransfers,}} but for a given \transactionVersion the same \sighashTxHash algorithm is used. -In the case of \Zcash, the -\sprout{\BCTV proving system used is}% -\notsprout{\BCTV\sapling{ and \Groth}\nufive{ and \HaloTwo} proving systems used are}% -\emph{malleable}, meaning that there is the potential for an adversary who does +In the case of \Zcash, the \BCTV\sapling{ and \Groth}\nufive{ and \HaloTwo} proving systems +used are \emph{malleable}, meaning that there is the potential for an adversary who does not know all of the \auxiliaryInputs to a proof, to malleate it in order to create a new proof involving related \auxiliaryInputs \cite{DSDCOPS2001}. This can be understood as similar to a malleability attack on an encryption scheme, in which an adversary can malleate a @@ -5838,9 +5680,9 @@ sources, \Bitcoin defines several \defining{\sighashTypes} that cover various pa \cite{Bitcoin-SigHash}. One of these types is $\SIGHASHALL$\changed{, which is used for \Zcash-specific signatures, i.e.\ \joinSplitSignatures\sapling{, \spendAuthSignatures, \notnufive{and} \saplingBindingSignatures}\nufive{, and \orchardBindingSignatures}}. -\changed{In \sprout{this case}\notsprout{these cases} the \sighashTxHash is not associated -with a \transparentInput, and so the input to hashing excludes \emph{all} of the $\scriptSig$ -fields in the non-\Zcash-specific parts of the \transaction.} +\changed{In these cases the \sighashTxHash is not associated with a \transparentInput, +and so the input to hashing excludes \emph{all} of the $\scriptSig$ fields in the +non-\Zcash-specific parts of the \transaction.} \changed{In \Zcash, all \sighashTypes are extended to cover the \Zcash-specific fields $\nJoinSplit$, $\vJoinSplit$, and if present $\joinSplitPubKey$. These fields @@ -5887,7 +5729,7 @@ by \cite{ZIP-225}. It will use a new \consensusBranchID \hexint{F919A198} as def \cite{ZIP-252}.} -\lsubsection{Non-malleability\pSproutOrNothingText}{sproutnonmalleability} +\lsubsection{Non-malleability (\SproutText)}{sproutnonmalleability} Let $\dataToBeSigned$ be the hash of the \transaction{}, not associated with an input, \changed{using the $\SIGHASHALL$ \sighashType}. @@ -5923,7 +5765,7 @@ to $\joinSplitPubKey$ to sign this \transaction. \introsection -\lsubsection{Balance\pSproutOrNothingText}{joinsplitbalance} +\lsubsection{Balance (\SproutText)}{joinsplitbalance} In \Bitcoin, all inputs to and outputs from a \transaction are transparent. The total value of \transparentOutputs{} must not exceed the total value of @@ -6441,7 +6283,7 @@ would have added a \nullifier to the \nullifierSet that already exists in the se (see \crossref{nullifierset}). \vspace{2ex} -\sprout{Each}\notsprout{In \Sprout, each} \note has a $\NoteUniqueRand$ component. +In \Sprout, each \note has a $\NoteUniqueRand$ component. \sapling{ \vspace{2ex} @@ -6500,8 +6342,7 @@ which has scalar field $\GF{\ParamP{r}}$.} } %nufive \securityrequirement{ -\sprout{The}\notsprout{For each shielded protocol, the} requirements on \nullifier -derivation are as follows: +For each shielded protocol, the requirements on \nullifier derivation are as follows: \begin{itemize} \item The derived \nullifier must be determined completely by the fields of @@ -6520,11 +6361,11 @@ derivation are as follows: \end{itemize} } %securityrequirement -\notsprout{\pagebreak}\sprout{\intropart} +\pagebreak \lsubsection{Zk-SNARK Statements}{snarkstatements} \vspace{-1ex} -\lsubsubsection{JoinSplit Statement\pSproutOrNothingText}{joinsplitstatement} +\lsubsubsection{JoinSplit Statement (\SproutText)}{joinsplitstatement} \vspace{-2ex} Let $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$, $\MerkleDepth{Sprout}$, $\ValueLength$, @@ -6945,10 +6786,10 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h } %nufive -\lsubsection{In-band secret distribution\pSproutOrNothingText}{sproutinband} +\lsubsection{In-band secret distribution (\SproutText)}{sproutinband} \vspace{-1ex} -\sprout{The}\notsprout{In \Sprout, the} secrets that need to be transmitted +In \Sprout, the secrets that need to be transmitted to a recipient of funds in order for them to later spend, are $\Value$, $\NoteUniqueRand$, and $\NoteCommitRand$. \canopy{(After \Canopy activation, $\NoteCommitRand$ is replaced by $\NoteSeedBytes$.)} @@ -6980,7 +6821,7 @@ For both encryption and decryption, \vspace{-2ex} -\lsubsubsection{Encryption\pSproutOrNothingText}{sproutencrypt} +\lsubsubsection{Encryption (\SproutText)}{sproutencrypt} \vspace{-1ex} Let $\KA{Sprout}$ be the \keyAgreementScheme instantiated in \crossref{concretesproutkeyagreement}. @@ -7032,7 +6873,7 @@ further security considerations, for example of how to validate a \Sprout{} } \vspace{-2ex} -\lsubsubsection{Decryption\pSproutOrNothingText}{sproutdecrypt} +\lsubsubsection{Decryption (\SproutText)}{sproutdecrypt} \vspace{-1ex} Let $\InViewingKey = (\AuthPublic, \TransmitPrivate)$ be the recipient's \incomingViewingKey, @@ -7441,7 +7282,7 @@ and that in \crossref{decryptivk}. \canopy{In particular: } %sapling -\lsubsection{Block Chain Scanning\pSproutOrNothingText}{sproutscan} +\lsubsection{Block Chain Scanning (\SproutText)}{sproutscan} Let $\PRFOutputLengthSprout$ be as defined in \crossref{constants}. @@ -7572,12 +7413,6 @@ All integers in \Zcash-specific encodings are unsigned, have a fixed bit length, and are encoded in little-endian byte order \emph{unless otherwise specified}. -\sprout{ -Define $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$ -such that $\ItoBEBSP{\ell}(x)$ is the sequence of $\ell$ bits representing $x$ in -\emph{big-endian} order. -} %sprout -\notsprout{ \introlist The following functions convert between sequences of bits, sequences of bytes, and integers: @@ -7612,14 +7447,13 @@ and integers: defined as follows: convert each byte to a group of 8 bits with the \emph{least} significant bit first, and concatenate the resulting groups in the same order as the bytes. \end{itemize} -} %notsprout In bit layout diagrams, each box of the diagram represents a sequence of bits. Diagrams are read from left-to-right, with lines read from top-to-bottom; the breaking of boxes across lines has no significance. The bit length $\ell$ is given explicitly in each box, except when it is obvious (e.g. for a single bit, or for the notation $\zeros{\ell}$ representing the sequence -of $\ell$ zero bits\notsprout{, or for the output of $\LEBStoOSP{\ell}$}). +of $\ell$ zero bits, or for the output of $\LEBStoOSP{\ell}$). The entire diagram represents the sequence of \emph{bytes} formed by first concatenating these bit sequences, and then treating each subsequence of 8 bits @@ -7635,7 +7469,7 @@ are used, the text will clarify their position in each case. Define: -\begin{formulae}[itemsep=\sprout{1ex}\notsprout{0.2ex}] +\begin{formulae}[itemsep=0.2ex] \item $\MerkleDepth{Sprout} \typecolon \Nat := \changed{29}$ \sapling{ \item $\MerkleDepth{Sapling} \typecolon \Nat := 32$ @@ -7783,7 +7617,7 @@ The comment above concerning bit vs byte-sequence interfaces also applies to \bi } %changed -\lsubsubsubsection{\sprout{BLAKE2b Hash Function}\notsprout{BLAKE2 Hash Functions}}{concreteblake2} +\lsubsubsubsection{BLAKE2 Hash Functions}{concreteblake2} \vspace{-1ex} BLAKE2 is defined by \cite{ANWW2013}. @@ -7843,18 +7677,6 @@ and $\GroupJHash{}$. \end{lrbox} \vspace{-2ex} -\sprout{ -$\MerkleCRH{Sprout}$ is used to hash \incrementalMerkleTree \merkleHashes. - -$\MerkleCRH{Sprout} \typecolon \MerkleHash{Sprout} \times \MerkleHash{Sprout} \rightarrow \MerkleHash{Sprout}$ -is defined as follows: - -\begin{formulae} - \item $\MerkleCRH{Sprout}(\mathsf{left}, \mathsf{right}) := \SHACompressBox{\merklebox}$. -\end{formulae} -} %sprout - -\notsprout{ $\MerkleCRH{Sprout}$ and $\MerkleCRH{Sapling}$ are used to hash \incrementalMerkleTree \merkleHashes for \Sprout and \Sapling respectively. @@ -7867,7 +7689,6 @@ $\MerkleCRH{Sprout} \typecolon \MerkleLayer{Sprout} \times \MerkleHash{Sprout} \ \begin{formulae} \item $\MerkleCRH{Sprout}(\mathsf{layer}, \mathsf{left}, \mathsf{right}) := \SHACompressBox{\merklebox}$. \end{formulae} -} %notsprout \vspace{-1ex} $\SHACompress$ is defined in \crossref{concretesha256}. @@ -7878,19 +7699,11 @@ $\SHACompress$ is defined in \crossref{concretesha256}. such that $\SHACompress(x) = \zeros{256}$. } -\sprout{ -\pnote{ -\shaCompress is not the same as the \shaHash function, which hashes arbitrary-length -byte sequences. -} -} %sprout -\notsprout{ \begin{pnotes} \item The $\mathsf{layer}$ argument does not affect the output. \item \shaCompress is not the same as the \shaHash function, which hashes arbitrary-length byte sequences. \end{pnotes} -} %notsprout \sapling{ \vspace{-2ex} @@ -9104,9 +8917,9 @@ Define $\ItoLEOSP{}$, $\LEOStoBSP{}$, and $\LEBStoIP{}$ as in \crossref{endian}. Define $\reprBytesEdSpecific \typecolon \GroupEdSpecific \rightarrow \ReprEdSpecificBytes$ such that $\reprBytesEdSpecific\Of{x, y} = \ItoLEOSP{256}\big(y + 2^{255} \smult \tilde{x}\big)$, where -$\tilde{x} = x \bmod 2$.\notsprout{\footnotewithlabel{coordinatenames}{\changed{Here we use the $(x, y)$ naming of coordinates in +$\tilde{x} = x \bmod 2$.\footnotewithlabel{coordinatenames}{\changed{Here we use the $(x, y)$ naming of coordinates in \cite{BDLSY2012}, which is different from the $(u, \varv)$ naming used for coordinates of \ctEdwardsCurves -in \crossref{jubjub} and in \crossref{ecbackground}.}}} +in \crossref{jubjub} and in \crossref{ecbackground}.}} \introlist Define $\abstBytesEdSpecific \typecolon \ReprEdSpecificBytes \rightarrow \maybe{\GroupEdSpecific}$ such that @@ -9183,7 +8996,7 @@ The encoding of an \EdSpecific signature is: where $\EdDSAReprR{}$ and $\EdDSAReprS{}$ are as defined in \cite{BDLSY2012}. \begin{pnotes} - \item It is \emph{not} required that the integer encoding of the $y$-coordinate\notsprout{\footnoteref{coordinatenames}} + \item It is \emph{not} required that the integer encoding of the $y$-coordinate\footnoteref{coordinatenames} of the points represented by $\EdDSAReprR{}$ or $\EdDSAReprA{}$ are less than $2^{255}-19$. \item It is \emph{not} required that $\EdDSAReprA{} \not\in \ExcludedPointEncodings$. \canopyonwarditem{Appendix \crossref{ed25519batchvalidate} describes an optimization that \MAY be used to speed up @@ -10768,7 +10581,7 @@ other details of the \provingSystem are beyond the scope of this protocol document. For example, certain details of the translations of the \spendStatement and \outputStatement to \quadraticArithmeticPrograms are not specified in this document. In practice it will be necessary to use the specific proving and verifying keys -generated for the \Zcash production \blockChain\notsprout{ (see \crossref{grothparameters})}, +generated for the \Zcash production \blockChain (see \crossref{grothparameters}), and a \provingSystem implementation that is interoperable with the \bellman library used by \Zcash, to ensure compatibility. } @@ -10825,7 +10638,7 @@ the \blockChain in encrypted form. \introlist The \notePlaintexts in a \joinSplitDescription are encrypted to the respective \transmissionKeys $\TransmitPublicNew{\allNew}$. -Each \notsprout{\Sprout} \notePlaintext (denoted $\NotePlaintext{}$) consists of: +Each \Sprout \notePlaintext (denoted $\NotePlaintext{}$) consists of: \begin{formulae} \item $(\changed{\NotePlaintextLeadByte \typecolon \byte,\ } \Value \typecolon \ValueType, \NoteUniqueRand \typecolon \PRFOutputSprout, @@ -11077,8 +10890,8 @@ cause the first two characters of the \BaseFiftyEightCheck encoding to be fixed \changed{ Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}. -\sprout{An}\notsprout{A \Sprout} \defining{\incomingViewingKey} consists of $\AuthPublic \typecolon \PRFOutputSprout$ and -$\TransmitPrivate \typecolon \KAPrivate{Sprout}$. +A \Sprout \defining{\incomingViewingKey} consists of $\AuthPublic \typecolon \PRFOutputSprout$ +and $\TransmitPrivate \typecolon \KAPrivate{Sprout}$. $\AuthPublic$ is a \shaCompress output. $\TransmitPrivate$ is a $\KAPrivate{Sprout}$ key, for use with the encryption scheme defined in @@ -11086,7 +10899,7 @@ $\TransmitPrivate$ is a $\KAPrivate{Sprout}$ key, for use with the encryption sc \crossref{sproutkeycomponents}. \introlist -The \rawEncoding of \sprout{an}\notsprout{a \Sprout} \incomingViewingKey consists of, in order: +The \rawEncoding of a \Sprout \incomingViewingKey consists of, in order: } \vspace{1ex} \begin{equation*} @@ -11722,10 +11535,10 @@ The \Zcash{} \defining{\transaction} format up to and including \transactionVers (this should be read in the context of consensus rules later in the section): \begin{center} -\scalebox{\sprout{0.87}\notsprout{0.8}}{ -\notsprout{\renewcommand{\arraystretch}{1.3}} +\scalebox{0.8}{ +\renewcommand{\arraystretch}{1.3} \hbadness=10000 -\begin{tabularx}{\sprout{1.08}\notsprout{1.21}\textwidth}{|c|c|l|p{10em}|L|} +\begin{tabularx}{1.21\textwidth}{|c|c|l|p{10em}|L|} \hline \!\!Version$\footnotestar$\!\!\! & \heading{Bytes} & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=====|} @@ -11736,10 +11549,8 @@ $\barerange{1}{4}$ & $4$ & $\headerField$ & \type{uint32} & Contains: \begin{com \transactionVersion. \end{compactitemize} \\ \hline -\notsprout{ \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 @@ -11751,7 +11562,6 @@ $\barerange{1}{4}$ & \Varies & $\txOut$ & $\txOut$ & \xTransparent outputs, enco $\barerange{1}{4}$ & $4$ & $\lockTime$ & \type{uint32} & Unix-epoch UTC time or \blockHeight, encoded as in \Bitcoin.\! \\ \hline -\notsprout{ \setoverwinter $\barerange{3}{4}$ &\setoverwinter $4$ &\setoverwinter $\nExpiryHeight$ &\overwintertype{uint32} &\setoverwinter A \blockHeight in the range $\range{1}{499999999}$ after which the \transaction will expire, or $0$ to disable expiry. \smash{\cite{ZIP-203}} \\ \hline @@ -11770,7 +11580,6 @@ The number of \outputDescriptions in $\vOutputsSapling$.\! \\ \hline \setsapling $4$ &\setsapling \Longunderstack{$948 \mult$ \\$\!\nOutputsSapling\!$} &\setsapling $\vOutputsSapling\!$ &\saplingtype{OutputDescriptionV4} \saplingtype{[$\nOutputsSapling$]} &\setsapling A sequence of \outputDescriptions{}, encoded per \crossref{outputencodingandconsensus}.\! \\ \hline -} %notsprout $\barerange{2}{4}$ & \Varies & $\nJoinSplit$ & \type{compactSize} & The number of \joinSplitDescriptions in $\vJoinSplit$.\! \\ \hline @@ -11778,10 +11587,8 @@ The number of \joinSplitDescriptions in $\vJoinSplit$.\! \\ \hline $\barerange{2}{3}$ & \Longunderstack{$1802 \mult$ \\ $\nJoinSplit$} & $\vJoinSplit$ & \type{JSDescriptionBCTV14}\!\! \type{[$\nJoinSplit$]} & A \sequenceOfJoinSplitDescriptions{} using \BCTV proofs, encoded per \crossref{joinsplitencodingandconsensus}.\! \\ \hline -\notsprout{ \setsapling $4$ &\setsapling \Longunderstack{$1698 \mult$ \\ $\nJoinSplit$} &\setsapling $\vJoinSplit$ &\saplingtype{JSDescriptionGroth16}\!\! \saplingtype{[$\nJoinSplit$]} &\setsapling A sequence of \joinSplitDescriptions using \Groth proofs, encoded per \crossref{joinsplitencodingandconsensus}.\! \\ \hline -} %notsprout $\barerange{2}{4}\;\dagger$ & $32$ & $\joinSplitPubKey\!$ & \type{byte[32]} & An encoding of a $\JoinSplitSig$ public \validatingKey.\! \\ \hline @@ -11790,10 +11597,8 @@ $\barerange{2}{4}\;\dagger$ & $64$ & $\joinSplitSig$ & \type{byte[64]} & A signature on a prefix of the \transaction encoding, validated using $\joinSplitPubKey$ as specified in \crossref{sproutnonmalleability}.\! \\ \hline -\notsprout{ \setsapling $4\;\ddagger$ &\setsapling $64$ &\setsapling $\bindingSig{Sapling}$ &\saplingtype{byte[64]} &\setsapling A \saplingBindingSignature on the \sighashTxHash, validated as specified in \crossref{concretebindingsig}.\! \\ \hline -} %notsprout \end{tabularx} \renewcommand{\arraystretch}{\defaultarraystretch} @@ -11808,10 +11613,8 @@ $\minimum(2, \versionField)$ when $\fOverwintered = 0$ and to $\versionField$ ot $\dagger$ & The \joinSplitPubKey{} and \joinSplitSig{} fields are present if and only if $\effectiveVersion \geq 2$ and $\nJoinSplit > 0$. \\ -\notsprout{ \setsapling $\ddagger$ & \textcolor{\saplingcolor}{\bindingSig{Sapling} is present if and only if $\effectiveVersion = 4$ and $\nSpendsSapling + \nOutputsSapling > 0$.} -} %notsprout \end{tabularx} \sapling{ @@ -11826,7 +11629,6 @@ $\nShieldedOutput \rightarrow \nOutputsSapling$; $\vShieldedOutput \rightarrow \ $\bindingSig{} \rightarrow \bindingSig{Sapling}$. \end{flushleft} } %sapling -\sprout{\vspace{3ex}} \nufive{ \introlist @@ -11835,7 +11637,7 @@ The \Zcash{} \defining{\transaction} format for \transactionVersion 5 is as foll \vspace{-1.8ex} \begin{center} \scalebox{0.77}{ -\notsprout{\renewcommand{\arraystretch}{1.28}} +\renewcommand{\arraystretch}{1.28} \hbadness=10000 \begin{tabularx}{1.26\textwidth}{|c|c|l|p{11.1em}|L|} \hline @@ -11956,7 +11758,7 @@ Several fields are reordered and/or renamed relative to prior versions. \begin{consensusrules} \item The \defining{\transactionVersionNumber} \MUST be greater than or equal to $1$. - \preoverwinteritem{The \fOverwintered{} flag \MUSTNOT be set\sprout{ in the protocol version described by this document}.} + \preoverwinteritem{The \fOverwintered{} flag \MUSTNOT be set.} \overwinteronwarditem{The \fOverwintered{} flag \MUST be set.} \overwinteronwarditem{The \versionGroupID \MUST be recognized.} \overwinteronlyitem{The \transactionVersionNumber \MUST be $3$, and the \versionGroupID \MUST @@ -12059,13 +11861,11 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notnufive{ and} e as a signed $\type{int32}$ field which was required to be positive. The consensus rule that the \fOverwintered{} flag \MUSTNOT be set before \Overwinter has activated, has the same effect. - \sprout{(\Overwinter is an upgrade of the \Zcash protocol, not specified in - this document.)} \item The semantics of \transactions with \transactionVersionNumber not equal to $1$, $2$, \overwinter{$3$,}\sapling{\notnufive{ or} $4$}\nufive{, or $5$} is not currently defined. \item The exclusion of \transactions with \transactionVersionNumber - \emph{greater than} $2$ is not a consensus rule\notsprout{ before \Overwinter activation}. + \emph{greater than} $2$ is not a consensus rule before \Overwinter activation. Such \transactions may exist in the \blockChain and \MUST be treated identically to version 2 \transactions. \overwinteronwarditem{Once \Overwinter has activated, limits on the maximum @@ -12142,15 +11942,9 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B and $\vOutputsSapling$ respectively.} \nufiveonwarditem{The $\nActionsOrchard$, $\vActionsOrchard$, and $\bindingSig{Orchard}$ fields have been added.} -\sprout{ - \item In \Zcash it is permitted for a \transaction to have no \transparent inputs provided - that $\nJoinSplit > 0$. -} %sprout -\notsprout{ \item In \Zcash it is permitted for a \transaction to have no \transparent inputs, provided at least one of $\nJoinSplit$\sapling{, $\nSpendsSapling$,\notnufive{ and} $\nOutputsSapling$}\nufive{, and $\nActionsOrchard$} are nonzero. -} %notsprout \item A consensus rule limiting \transaction size has been added. In \Bitcoin there is a corresponding standard rule but no consensus rule. \end{itemize} @@ -12199,13 +11993,11 @@ $64$ & $\vmacs$ & \type{byte[32][$\NOld$]} & A sequence of message authenticatio $\h{\allOld}$ binding $\hSig$ to each $\AuthPrivate$ of the $\joinSplitDescription$, computed as described in \crossref{sproutnonmalleability}. \\ \hline -$296\notsprout{\;\dagger}$ & $\zkproof$ & \type{byte[296]} & An encoding of the \zkSNARKProof +$296\;\dagger$ & $\zkproof$ & \type{byte[296]} & An encoding of the \zkSNARKProof $\ProofJoinSplit$ (see \crossref{bctv}). \\ \hline -\notsprout{ $192\;\ddagger$ & $\zkproof$ & \type{byte[192]} & An encoding of the \zkSNARKProof $\ProofJoinSplit$ (see \crossref{groth}). \\ \hline -} $1202$ & $\encCiphertexts$ & \type{byte[601][$\NNew$]} & A sequence of ciphertext components for the encrypted output \notes, $\TransmitCiphertext{\allNew}$. \\ \hline @@ -12213,13 +12005,11 @@ components for the encrypted output \notes, $\TransmitCiphertext{\allNew}$. \\ \ \end{tabularx} \end{center} -\notsprout{ $\dagger$ \BCTV proofs are used when the \transactionVersion is $2$ or $3$, i.e.\ before \Sapling activation. \sapling{$\ddagger$ \Groth proofs are used when the \transactionVersion is $\geq 4$, i.e.\ after \Sapling activation.} -} The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphertextSprout, which is computed as described in \crossref{sproutinband}. @@ -12417,8 +12207,7 @@ $32$ & $\hashMerkleRoot$ & \type{byte[32]} & A \shadHash hash in internal byte o merkle root is derived from the hashes of all \transactions included in this \block, ensuring that none of those \transactions can be modified without modifying the \header. \\ \hline -$32$ & \sprout{$\hashReserved$} -\notsprout{\Longunderstack[l]{$\hashReserved$ /\\ \sapling{$\hashFinalSaplingRoot$} \notbeforeheartwood{/}\\ \heartwood{$\hashLightClientRoot$} }} & +$32$ & \Longunderstack[l]{$\hashReserved$ /\\ \sapling{$\hashFinalSaplingRoot$} \notbeforeheartwood{/}\\ \heartwood{$\hashLightClientRoot$} } & \type{byte[32]} & \presapling{A reserved field which should be ignored.} \saplingandblossom{The \merkleRoot $\LEBStoOSPOf{256}{\rt{Sapling}}$ of the \Sapling{} @@ -13481,33 +13270,28 @@ with colliding outputs of the truncated hash, and therefore the same Balance property by double-spending \notes, potentially creating arbitrary amounts of currency for themself \cite{HW2016}. -\Zcash uses a simpler construction with a single -\notsprout{hash evaluation for the commitment: -\shaHash for \Sprout\sapling{, and $\PedersenHash$ for \Sapling}.} -\sprout{\shaHash evaluation for the commitment.} +\Zcash uses a simpler construction with a single hash evaluation for the +commitment: \shaHash for \Sprout\sapling{, and $\PedersenHash$ for \Sapling}. The motivation for the nested construction in \Zerocash was to allow Mint transactions to be publically verified without requiring a \zkSNARKProof (\cite[section 1.3, under step 3]{BCGGMTV2014}). Since \Zcash combines ``Mint'' and ``Pour'' -transactions into generalized \notsprout{\joinSplitTransfers (for \Sprout), +transactions into generalized \joinSplitTransfers (for \Sprout), \sapling{or \spendTransfers and \outputTransfers (for \Sapling)}, and each -transfer always uses a \zkSNARKProof\!\!, -\Zcash does not require the nesting.}\sprout{\joinSplitTransfers, -and each transfer always uses a \zkSNARKProof\!\!, it does not require the nesting.} +transfer always uses a \zkSNARKProof\!\!, \Zcash does not require the nesting. A side benefit is that this reduces the cost of computing the -\noteCommitments: \notsprout{for \Sprout} it reduces the number of \shaCompress +\noteCommitments: for \Sprout it reduces the number of \shaCompress evaluations needed to compute each \noteCommitment from three to two, saving a total of four \shaCompress evaluations in the \joinSplitStatement. \sproutspecificpnote{ -\notsprout{\Sprout \noteCommitments are not statistically hiding, so for \Sprout notes,} -\sprout{\Zcash \noteCommitments are not statistically hiding, so} -\Zcash does not support the ``everlasting anonymity'' property -described in \cite[section 8.1]{BCGGMTV2014}, -even when used as described in that section. While it is possible to -define a statistically hiding, computationally binding commitment scheme -for this use at a 128-bit security level, the overhead of doing so -within the \joinSplitStatement was not considered to justify the benefits. +\Sprout \noteCommitments are not statistically hiding, so for \Sprout notes, +\Zcash does not support the ``everlasting anonymity'' property described in +\cite[section 8.1]{BCGGMTV2014}, even when used as described in that section. +While it is possible to define a statistically hiding, computationally binding +commitment scheme for this use at a 128-bit security level, the overhead of +doing so within the \joinSplitStatement was not considered to justify the +benefits. } \saplingonward{ @@ -13603,12 +13387,10 @@ $\BlakeTwosGeneric$ truncated to $251$ bits (see \crossref{concretecrhivk}). \Zerocash specified ECIES (referencing Certicom's SEC 1 standard) as the encryption scheme used for the in-band secret distribution. This has been -changed to a key agreement scheme based on -\sprout{$\KASproutCurve$,} -\notsprout{$\KASproutCurve$ (for \Sprout) \sapling{or \Jubjub (for \Sapling)}} -and the authenticated encryption algorithm $\SymSpecific$. This scheme is -still loosely based on ECIES, and on the $\CryptoBoxSeal$ scheme defined in -libsodium \cite{libsodium-Seal}. +changed to a key agreement scheme based on $\KASproutCurve$ (for \Sprout)\sapling{ or +\Jubjub (for \Sapling)} and the authenticated encryption algorithm $\SymSpecific$. +This scheme is still loosely based on ECIES, and on the $\CryptoBoxSeal$ scheme +defined in libsodium \cite{libsodium-Seal}. \introlist The motivations for this change were as follows: @@ -13644,7 +13426,7 @@ The motivations for this change were as follows: properties of the scheme. (The Std 1363a-2004 version of ECIES \cite{IEEE2004} has a ``DHAES mode'' that allows this, but the representation of the key input is underspecified, leading to incompatible implementations.) - The scheme we use\notsprout{ for \Sprout} has both the ephemeral and + The scheme we use for \Sprout has both the ephemeral and recipient \publicKey encodings --which are unambiguous for $\KASproutCurve$-- and also $\hSig$ and a nonce as described below, as input to the KDF. \sapling{For \Sapling, it is only possible to include the ephemeral public @@ -13690,7 +13472,7 @@ setting \cite{Zaverucha2012}. This is especially necessary because the privacy o the encryption algorithm would not prevent a future adversary from attempting to decrypt ciphertexts encrypted before the upgrade. Other cryptovalues that could be attacked to break the privacy of transactions are also sufficiently long -to resist parallel brute force in the multi-user setting: \notsprout{for \Sprout,} +to resist parallel brute force in the multi-user setting: for \Sprout, $\AuthPrivate$ is $252$ bits, and $\TransmitPrivate$ is no shorter than $\AuthPrivate$. @@ -13748,7 +13530,7 @@ distinct openings of the \noteCommitment when Condition I or II is violated. \begin{itemize} \item The paper defines a \note as $((\AuthPublic, \TransmitPublic), \Value, \NoteUniqueRand, \NoteCommitRand, \NoteCommitS, \cm)$, whereas this - specification defines \sprout{it}\notsprout{a \Sprout \note} as + specification defines a \Sprout \note as $(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$. The instantiation of $\Commit{\NoteCommitS}$ in section 5.1 of the paper did not actually use $\NoteCommitS$, and neither does the new @@ -13827,14 +13609,12 @@ found by Brian Warner. The design of \Orchard is primarily due to Daira Hopwood, Sean Bowe, Jack Grigg, Kris Nuttycombe, Ying Tong Lai, and Steven Smith. -\notsprout{ The observation in \crossref{concretediversifyhash} that \diversifiedPaymentAddress unlinkability can be proven in the same way as \keyPrivacy for ElGamal, is due to Mary Maller. -} We thank Ariel Gabizon for teaching us the techniques of \cite{BFIJSV2010} -\notsprout{used in \crossref{grothbatchverify}}, by applying them to \BCTV. +used in \crossref{grothbatchverify}, by applying them to \BCTV. The arithmetization used by \HaloTwo is based on that used by \PLONK \cite{GWC2019}, which was designed by Ariel Gabizon, Zachary Williamson, and Oana Ciobotaru. @@ -13852,7 +13632,7 @@ community immeasurably. Many of the ideas used in \Zcash{} ---including the use of zero-knowledge proofs to resolve the tension between privacy and auditability, Merkle trees over -note commitments\notsprout{ (using Pedersen hashes as in \Sapling)}, +note commitments (using Pedersen hashes as in \Sapling), and the use of ``serial numbers'' or \nullifiers to detect or prevent double-spends--- were first applied to privacy-preserving digital currencies by Tomas Sander and Amnon Ta–Shma. To a large extent \Zcash is a refinement @@ -13861,15 +13641,19 @@ of their ``Auditable, Anonymous Electronic Cash'' proposal in \cite{ST1999}. We thank Alexandra Elbakyan for her tireless work in dismantling barriers to scientific research. -\notsprout{ Finally, we would like to thank the Internet Archive for their scan of Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. -} \intropart \lsection{Change History}{changehistory} +\historyentry{2021.1.20}{2021-03-18} +\begin{itemize} + \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). +\end{itemize} + + \historyentry{2021.1.19}{2021-03-17} \begin{itemize} \nufive{ @@ -13910,9 +13694,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. $\DiversifiedTransmitPublic$), despite being described correctly in the Change History entry below. } %sapling -\sprout{ - \item No changes before \Sapling. -} %sprout \end{itemize} @@ -13928,9 +13709,9 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. } %canopy \item The definition of an abstraction function in \crossref{abstractgroup} incorrectly required canonicity, i.e.\ that $\abstG{}$ does not accept inputs outside the range - of $\reprG{}$. \notsprout{While this was originally intended, it is not true of $\abstJ$. + of $\reprG{}$. While this was originally intended, it is not true of $\abstJ$. (It is also not true of $\abstBytesEdSpecific$, but \EdSpecific is not strictly - defined as a \representedGroup in this specification.)} + defined as a \representedGroup in this specification.) \sapling{ \item Correct \theoremref{thmuncommittedsapling}, which was proving the wrong thing. It needs to prove that $\NoteCommitAlg{Sapling}$ does not return $\Uncommitted{Sapling}$, @@ -14003,9 +13784,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. raw encodings are not; for example, the \rawEncoding of a \Sapling \spendingKey can be a prefix of several of the other encodings.) \item Use ``let mutable'' to introduce mutable variables in algorithms. -\notsprout{ \item Include a reference to \cite{BFIJSV2010} for batch pairing verification techniques. -} \item Acknowledge Jack Gavigan as a co-designer of \Sapling and of the \Zcash protocol. \item Acknowledge Izaak Meckler, Zac Williamson, Vitalik Buterin, and Jakub Zalewski. \item Acknowledge Alexandra Elbakyan. @@ -14236,7 +14015,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2019.0.9}{2019-12-27} \begin{itemize} - \item No changes to \Sprout\notsprout{ or \Sapling}. + \item No changes to \Sprout or \Sapling. \blossom{ \item Specify the height at which \Blossom activated. \item Add \Blossom to \crossref{networkupgrades}. @@ -14249,7 +14028,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2019.0.8}{2019-09-24} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Fix a typo in the generator $\GenS{1}$ in \crossref{blspairing} found by magrady. \item Clarify the type of $\ValueNew{}$ in \crossref{saplingsend}. @@ -14272,7 +14050,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2019.0.6}{2019-08-23} \begin{itemize} - \item No changes to \Sprout\notsprout{ or \Sapling}. + \item No changes to \Sprout or \Sapling. \blossom{ \item Replace dummy \Blossom \activationHeight with the \Testnet height, and a reference to \cite{ZIP-206}. } @@ -14302,9 +14080,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Clicking on a section heading now shows section labels. -\notsprout{ \item Add a \snarkref{List of Theorems and Lemmata}{theorems}. -} %notsprout \item Changes needed to support TeXLive 2019. \end{itemize} @@ -14338,7 +14114,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2019.0.1}{2019-05-20} \begin{itemize} - \item No changes to \Sprout\notsprout{ or \Sapling}. + \item No changes to \Sprout or \Sapling. \blossom{ \item Minor fix to the list of integer constants in \crossref{notation}. \item Use $\IsBlossomActivated$ in the definition of $\FounderAddressAdjustedHeight$ @@ -14464,7 +14240,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-33}{2018-11-14} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Complete \crossref{cctsaplingspend}. \item Add \crossref{cctsaplingoutput}. @@ -14480,7 +14255,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-32}{2018-10-24} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Correct the input to $\RedDSAHashToScalar$ used to derive the nonce $r$ in $\RedDSASign{}$, from $T \bconcat M$ to $T \bconcat \vkBytes{} \bconcat M$. @@ -14493,7 +14267,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-31}{2018-09-30} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Correct some uses of $\ParamJ{r}$ that should have been $\ParamS{r}$ or $q$. \item Correct uses of $\LEOStoIP{\ell}$ in $\RedDSAValidate{}$ and $\RedDSABatchValidate{}$ @@ -14520,7 +14293,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-30}{2018-09-02} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Give an informal security argument for Unlinkability of \diversifiedPaymentAddresses based on reduction to \keyPrivacy of ElGamal encryption, for which a security proof @@ -14550,7 +14322,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-29}{2018-08-15} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Finish \crossref{cctrange}. \item Change \crossref{cctblake2s} to correct the constraint count and @@ -14562,7 +14333,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-28}{2018-08-14} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Finish \crossref{cctblake2s}. \item Minor corrections to \crossref{cctvarscalarmult}. @@ -14596,7 +14366,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-26}{2018-08-05} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Add \crossref{grothbatchverify}. } %sapling @@ -14605,7 +14374,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-25}{2018-08-05} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Add the hashes of parameter files for \Sapling. \item Add cross references for parameters and functions used in $\RedDSA$ batch validation. @@ -14617,7 +14385,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-24}{2018-07-31} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Add a missing consensus rule for version 4 \transactions: if there are no \Sapling Spends or Outputs, then $\valueBalance{Sapling}$ \MUST be $0$. @@ -14627,7 +14394,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-23}{2018-07-27} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Update $\RedDSA$ validation to use cofactor multiplication. This is necessary in order for the output of batch validation to match @@ -14639,13 +14405,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-22}{2018-07-18} \begin{itemize} -\sprout{ - \item Update the abstract to clarify that this version of the specification - is a historical document. -} %sprout -\notsprout{ - \item No changes to \Sprout. -} %notsprout \overwinter{ \item Update \crossref{networkupgrades} to take account that \Overwinter has activated. @@ -14670,7 +14429,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. ``If $\nJoinSplit > 0$, the \transaction \MUSTNOT use \sighashTypes other than $\SIGHASHALL$.'', which was never implemented. \item Add section on signature hashing. - \item Briefly describe the changes to computation of \sighashTxHashes\notsprout{ in \Sprout}. + \item Briefly describe the changes to computation of \sighashTxHashes in \Sprout. \item Clarify that interstitial \treestates form a tree for each \transaction containing \joinSplitDescriptions. \item Correct the description of P2PKH addresses in \crossref{transparentaddrencoding} --- they use a hash of a compressed, not an uncompressed \ECDSA key representation. @@ -14774,7 +14533,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-19}{2018-04-23} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Minor clarifications. } %sapling @@ -14783,7 +14541,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-18}{2018-04-23} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Clarify the security argument for balance in \Sapling. \item Correct a subtle problem with the type of the value input to @@ -14800,7 +14557,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-17}{2018-04-21} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Correct an error in the definition of $\DefaultDiversifier$. } %sapling @@ -14817,7 +14573,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Specify support for \cite{BIP-111} (the \texttt{NODE\_BLOOM} service bit) in peer-to-peer network protocol version $170004$. \item Give references \cite{Vercauter2009} and \cite{AKLGL2010} for the optimal ate pairing. - \item Give references for\notsprout{ BLS \cite{BLS2002} and} BN \cite{BN2005} curves. + \item Give references for BLS \cite{BLS2002} and BN \cite{BN2005} curves. \item Define $\KADerivePublic{Sprout}$ for $\KASproutCurve$. \item Caveat the claim about \noteTraceabilitySet in \crossref{overview} and link to \cite{Peterson2017} and \cite{Quesnelle2017}. @@ -14906,7 +14662,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-12}{2018-03-06} \begin{itemize} - \item No changes to \Sprout. \overwinter{ \item Add references to \Overwinter ZIPs and update the section on \Overwinter/\Sapling transitions. @@ -14925,7 +14680,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-11}{2018-02-26} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Add sections on \spendDescriptions and \outputDescriptions. \item Swap order of $\cv$ and $\rt{}$ in a \spendDescription for consistency. @@ -14976,7 +14730,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-8}{2018-02-08} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Add instantiation of $\CRHivk$. \item Add instantiation of a hash extractor (later renamed to \coordinateExtractor) @@ -15012,7 +14765,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-6}{2018-01-31} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item \Sapling work in progress, mainly on Appendix \crossref{circuitdesign}. } @@ -15031,7 +14783,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2018.0-beta-4}{2018-01-25} \begin{itemize} - \item No changes to \Sprout. \sapling{ \item Update key components diagram for \Sapling. } @@ -15363,8 +15114,6 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \printbibliography \endgroup -\notsprout{ - \pagebreak \appendix \lpart{Appendices}{appendices} @@ -16663,9 +16412,8 @@ final $\xor$ operations), but not the message bits. such as MiMC \cite{AGRRT2017}, it was felt that they had not yet received sufficient cryptanalytic attention to confidently use them for \Sapling. \end{nnotes} -} %notsprout -\notsprout{ + \pagebreak \lsubsection{The \SaplingText{} Spend circuit}{cctsaplingspend} @@ -16950,9 +16698,8 @@ Check & Implements & \heading{Cost} & Reference \\ \pnote{The implementation represents $\EphemeralPrivateRepr$, $\DiversifiedTransmitPublicRepr$, $\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as bit sequences rather than integers.} -} %notsprout -\notsprout{ + \lsection{Batching Optimizations}{batching} \extralabel{reddsabatchverify}{\lsubsection{\RedDSAText{} batch validation}{reddsabatchvalidate}} @@ -17023,9 +16770,7 @@ $- \Bigscalarmult{\ssum{j}{}{(z_j \mult \RedDSASigS{j}) \pmod{\ParamG{r}}}}{\Gen The benefit of this relative to using separate batches is that the multiscalar multiplication can be extended across a larger batch.} %pnote -} %notsprout -\notsprout{ \lsubsection{\GrothText{} batch verification}{grothbatchverify} The reference verification algorithm for \Groth proofs is defined in \crossref{groth}. @@ -17139,8 +16884,6 @@ the cost of batched verification is therefore \end{itemize} } %pnote -} %notsprout - \canopy{ \lsubsection{\EdSpecificText{} batch validation}{ed25519batchvalidate} @@ -17200,12 +16943,10 @@ The performance benefits of this approach are the same as for \crossref{reddsaba } %canopy -\notsprout{ \lpart{List of Theorems and Lemmata}{theorems} \hfuzz=10pt \hbadness=10000 \listtheorems{theorem,lemma} -} \needspace{30ex} \phantompart{Index}{index} From 9af5978852f1fc27593be5ce530951f549d6def6 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 19 Mar 2021 15:12:35 +0000 Subject: [PATCH 02/41] Remove magenta highlighting of differences from Zerocash. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 390 +++++++++++++++++------------------------- 1 file changed, 154 insertions(+), 236 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 9ed46b71..45e9c427 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -547,10 +547,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\vulncolor}{BrickRed} \newcommand{\setwarning}{\color{\warningcolor}} \newcommand{\warningcolor}{BrickRed} -\newcommand{\changedcolor}{magenta} -\newcommand{\changedcolorname}{\changedcolor} -\newcommand{\setchanged}{\color{\changedcolor}} -\newcommand{\changed}[1]{\texorpdfstring{{\setchanged{#1}}}{#1}} \newcommand{\saplingcolor}{green} \newcommand{\saplingcolorname}{\saplingcolor} \newcommand{\overwintercolor}{blue} @@ -787,7 +783,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\valueCommitmentScheme}{\term{value commitment scheme}} \newcommand{\joinSplitDescription}{\term{JoinSplit description}} \newcommand{\joinSplitDescriptions}{\terms{JoinSplit description}} -\newcommand{\sequenceOfJoinSplitDescriptions}{\changed{sequence of} \joinSplitDescription{}\kern -0.05em\changed{\textsl{s}}} \newcommand{\joinSplitTransfer}{\term{JoinSplit transfer}} \newcommand{\joinSplitTransfers}{\terms{JoinSplit transfer}} \newcommand{\joinSplitSignature}{\term{JoinSplit signature}} @@ -2455,8 +2450,7 @@ transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with \emph{shielded} payment scheme secured by zero-knowledge succinct non-interactive arguments of knowledge (\zkSNARKs). -Changes from the original \Zerocash are explained in \crossref{differences}, -and highlighted in \changed{\changedcolorname} throughout the document. +The most significant changes from the original \Zerocash are explained in \crossref{differences}. Changes specific to the \Overwinter upgrade are highlighted in \overwinter{\overwintercolorname}. @@ -2857,8 +2851,8 @@ The following integer constants will be instantiated in \crossref{constants}: $\MerkleDepth{Sprout}$,\sapling{ $\MerkleDepth{Sapling}$,}\nufive{ $\MerkleDepth{Orchard}$,} $\MerkleHashLength{Sprout}$,\sapling{ $\MerkleHashLength{Sapling}$,}\nufive{ $\MerkleHashLength{Orchard}$,} $\NOld$, $\NNew$, $\ValueLength$, $\hSigLength$, $\PRFOutputLengthSprout$,\sapling{ $\PRFOutputLengthExpand$, - $\PRFOutputLengthNfSapling$,} $\NoteCommitRandLength$, \changed{$\RandomSeedLength$,} $\AuthPrivateLength$, - \changed{$\NoteUniquePreRandLength$,}\sapling{ $\SpendingKeyLength$, $\DiversifierLength$,\nufive{ $\DiversifierKeyLength$,} + $\PRFOutputLengthNfSapling$,} $\NoteCommitRandLength$, $\RandomSeedLength$, $\AuthPrivateLength$, + $\NoteUniquePreRandLength$,\sapling{ $\SpendingKeyLength$, $\DiversifierLength$,\nufive{ $\DiversifierKeyLength$,} $\InViewingKeyLength{Sapling}$, $\OutViewingKeyLength$, $\ScalarLength{Sapling}$,\nufive{ $\ScalarLength{Orchard}$, $\BaseLength{Orchard}$,}} $\MAXMONEY$,\blossom{ $\BlossomActivationHeight$,}\strut\canopy{ $\CanopyActivationHeight$, $\ZIPTwoOneTwoGracePeriod$,} $\SlowStartInterval$, $\PreBlossomHalvingInterval$, $\MaxBlockSubsidy$, $\NumFounderAddresses$, @@ -2938,11 +2932,11 @@ $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$, as de \sapling{\nnote{In \zcashd, all \SaplingAndOrchard keys and addresses are derived according to \cite{ZIP-32}.}} \vspace{2ex} -The composition of \shieldedPaymentAddresses, \changed{\incomingViewingKeys,} +The composition of \shieldedPaymentAddresses, \incomingViewingKeys, \sapling{\fullViewingKeys,} and \spendingKeys is a cryptographic protocol detail that should not normally be exposed to users. However, user-visible operations should be provided to obtain a -\shieldedPaymentAddress\changed{ or \incomingViewingKey}\sapling{ or \fullViewingKey} +\shieldedPaymentAddress, \incomingViewingKey\sapling{, or \fullViewingKey} from a \spendingKey\sapling{ or \extendedSpendingKey}. Users can accept payment from multiple parties with a single @@ -3012,7 +3006,7 @@ Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. \vspace{2ex} \introlist -A \Sprout \note is a tuple $\changed{(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)}$, +A \Sprout \note is a tuple $(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$, where: \begin{itemize} \item $\AuthPublic \typecolon \PRFOutputSprout$ is the \defining{\payingKey} of the @@ -3030,8 +3024,8 @@ where: \introlist Let $\NoteType{Sprout}$ be the type of a \Sprout \note, i.e. \begin{formulae} - \item $\NoteType{Sprout} := \changed{\PRFOutputSprout \times \range{0}{\MAXMONEY} \times \PRFOutputSprout - \times \NoteCommitTrapdoor{Sprout}}$. + \item $\NoteType{Sprout} := \PRFOutputSprout \times \range{0}{\MAXMONEY} \times \PRFOutputSprout + \times \NoteCommitTrapdoor{Sprout}$. \end{formulae} \sapling{ @@ -3100,7 +3094,7 @@ on the \blockChain. \vspace{2ex} \introlist A \Sprout{} \defining{\noteCommitment} on a \note -$\NoteTuple{} = \changed{(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)}$ is computed as +$\NoteTuple{} = (\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$ is computed as \vspace{-1ex} \begin{formulae} @@ -3208,9 +3202,9 @@ Each \Sprout{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists o \vspace{-1ex} \begin{formulae} - \item $(\changed{\NotePlaintextLeadByte \typecolon \byte,\ } + \item $(\NotePlaintextLeadByte \typecolon \byte, \Value \typecolon \ValueType, \NoteUniqueRand \typecolon \PRFOutputSprout, - \NoteCommitRand \typecolon \NoteCommitTrapdoor{Sprout}\changed{, \Memo \typecolon \MemoType})$. + \NoteCommitRand \typecolon \NoteCommitTrapdoor{Sprout}, \Memo \typecolon \MemoType)$. \end{formulae} \saplingonward{ @@ -3234,10 +3228,8 @@ The field $\NoteSeedBytes$ is described in \crossref{saplingsend}. } %canopy } %saplingonward -\changed{ $\Memo$ represents a $\MemoByteLength$-byte \defining{\memo} associated with this \note. The usage of the \memo is by agreement between the sender and recipient of the \note. -} Encodings are given in \crossref{notept}. The result of encryption forms part of a \noteOrNotesCiphertext. @@ -3319,8 +3311,8 @@ In a given \blockChain, \sapling{for each of \Sprout and \SaplingAndOrchard,} \transaction. \end{itemize} -\changed{\joinSplitDescriptions also have interstitial input and output -\treestates for \Sprout, explained in the following section.} +\joinSplitDescriptions also have interstitial input and output +\treestates for \Sprout, explained in the following section. \sapling{There is no equivalent of interstitial \treestates for \Sapling\nufive{ or for \Orchard}.} @@ -3338,9 +3330,9 @@ $\vpubNew$. It is associated with a \joinSplitStatement instance (\crossref{joinsplitstatement}), for which it provides a \zkSNARKProof. -Each \transaction has a \sequenceOfJoinSplitDescriptions{}. +Each \transaction has a sequence of \joinSplitDescriptions. -The \changed{total $\vpubNew$ value adds to, and the total} $\vpubOld$ +The total $\vpubNew$ value adds to, and the total $\vpubOld$ value subtracts from the \transparentTxValuePool of the containing \transaction. The \anchor of each \joinSplitDescription in a \transaction{} refers to a @@ -3349,7 +3341,6 @@ The \anchor of each \joinSplitDescription in a \transaction{} refers to a For each of the $\NOld$ \shieldedInputs, a \nullifier is revealed. This allows detection of double-spends as described in \crossref{nullifierset}. -\changed{ For each \joinSplitDescription in a \transaction, an interstitial output \treestate is constructed which adds the \noteCommitments and \nullifiers specified in that \joinSplitDescription to the input \treestate referred to by its \anchor. @@ -3361,7 +3352,6 @@ the parent of each node is determined by its \anchor. Interstitial \treestates are necessary because when a \transaction is constructed, it is not known where it will eventually appear in a mined \block. Therefore the \anchors that it uses must be independent of its eventual position. -} \vspace{-3ex} \begin{consensusrules} @@ -3370,13 +3360,11 @@ it is not known where it will eventually appear in a mined \block. Therefore the \vspace{-0.5ex} \item For the first \joinSplitDescription of a \transaction, the \anchor \MUST be the output \Sprout \treestate of a previous \block. -\changed{ \vspace{-0.5ex} \item The \anchor of each \joinSplitDescription in a \transaction \MUST refer to either some earlier \block's final \Sprout \treestate, or to the interstitial output \treestate of any prior \joinSplitDescription in the same \transaction. -} \end{consensusrules} @@ -3636,7 +3624,6 @@ $\MerkleCRH{Sprout}$ is \collisionResistant except on its first argument. These functions are instantiated in \crossref{merklecrh}. -\changed{ $\hSigCRH{} \typecolon \bitseq{\RandomSeedLength} \times \typeexp{\PRFOutputSprout}{\NOld} \times \JoinSplitSigPublic \rightarrow \hSigType$ is a \collisionResistant \hashFunction used in \crossref{joinsplitdesc}. It is instantiated in \crossref{hsigcrh}. @@ -3646,7 +3633,6 @@ is another \hashFunction, used in \crossref{equihash} to generate input to the \Equihash solver. The first two arguments, representing the \Equihash parameters $n$ and $k$, are written subscripted. It is instantiated in \crossref{equihashgen}. -} \sapling{ $\CRHivk \typecolon \ReprJ \times \ReprJ \rightarrow \InViewingKeyTypeSapling$ @@ -3674,7 +3660,7 @@ used to derive a \diversifiedBase from a \diversifier, which is specified in $\PRF{x}{}$ denotes a \defining{\pseudoRandomFunction} keyed by $x$. -Let $\AuthPrivateLength$, $\hSigLength$, $\PRFOutputLengthSprout$, \changed{$\NoteUniquePreRandLength$,} +Let $\AuthPrivateLength$, $\hSigLength$, $\PRFOutputLengthSprout$, $\NoteUniquePreRandLength$, \sapling{$\SpendingKeyLength$, $\OutViewingKeyLength$, $\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,} $\NOld$, and $\NNew$ be as defined in \crossref{constants}. @@ -3693,12 +3679,12 @@ Let $\ellP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. \vspace{1ex} \introlist -For \Sprout, \changed{four} \emph{independent} $\PRF{x}{}$ are needed: +For \Sprout, four \emph{independent} $\PRF{x}{}$ are needed: \begin{tabular}{@{\hskip 2em}l@{\;\notnufive{\hskip 0.86em}}l@{\;\notnufive{\hskip 0.54em}}l@{\;}l@{\,\notnufive{\hskip 4em}}l} $\PRFaddr{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \byte $& &$\rightarrow \PRFOutputSprout$ \\ $\PRFpk{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \setofOld $&$\times\; \hSigType $&$\rightarrow \PRFOutputSprout$ \\ -$\setchanged\PRFrho{} $&$\setchanged\typecolon\; \bitseq{\NoteUniquePreRandLength} $&$\setchanged\times\; \setofNew $&$\setchanged\times\; \hSigType $&$\setchanged\rightarrow \PRFOutputSprout$ \\ +$\PRFrho{} $&$\typecolon\; \bitseq{\NoteUniquePreRandLength} $&$\times\; \setofNew $&$times\; \hSigType $&$\rightarrow \PRFOutputSprout$ \\ $\PRFnf{Sprout}{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \PRFOutputSprout $& &$\rightarrow \PRFOutputSprout$ \end{tabular} @@ -3760,11 +3746,11 @@ All of these \pseudoRandomFunctions are instantiated in \crossref{concreteprfs}. \begin{securityrequirements} \item Security definitions for \defining{\pseudoRandomFunctions} are given in \cite[section 4]{BDJR2000}. \item In addition to being \pseudoRandomFunctions, it is required that - $\PRFaddr{x}$,\changed{ $\PRFrho{x}$, $\PRFnf{Sprout}{x}$}\sapling{,\notnufive{ and} + $\PRFaddr{x}$, $\PRFrho{x}$, $\PRFnf{Sprout}{x}$\sapling{,\notnufive{ and} $\PRFnf{Sapling}{x}$}\nufive{ and $\PRFnf{Orchard}{x}$} be \collisionResistant across all $x$ --- i.e.\ finding $(x, y) \neq (x', y')$ such that $\PRFaddr{x}(y) = \PRFaddr{x'}(y')$ should - not be feasible\changed{, and similarly for $\PRFrho{}$ and $\PRFnf{Sprout}{}$\sapling{ and - $\PRFnf{Sapling}{}$}\nufive{ and $\PRFnf{Orchard}{}$}}. + not be feasible, and similarly for $\PRFrho{}$, $\PRFnf{Sprout}{}$\sapling{,\notnufive{ and} + $\PRFnf{Sapling}{}$}\nufive{, and $\PRFnf{Orchard}{}$}. \end{securityrequirements} \vspace{-2ex} @@ -3962,7 +3948,7 @@ $\SigValidate{\vk}(m, s) = 1$. \vspace{-1ex} The signature scheme used in script operations is instantiated by \ECDSA on the \secpCurve. -\changed{$\JoinSplitSig$ is instantiated by \EdSpecific.} +$\JoinSplitSig$ is instantiated by \EdSpecific. \sapling{$\SpendAuthSig{}$ and $\BindingSig{}$ are instantiated by $\RedDSA$; on the \jubjubCurve in \Sapling\nufive{, and on the \pallasCurve in \Orchard}.} @@ -4610,16 +4596,14 @@ A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a bit sequenc uniformly at random from $\bitseq{\AuthPrivateLength}$. \introlist -\changed{ $\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived from -$\AuthPrivate$ -as follows:} +$\AuthPrivate$ as follows: \vspace{-0.5ex} \begin{tabular}{@{\hskip 2em}r@{\;}l} - $\AuthPublic$ &$:= \changed{\PRFaddr{\AuthPrivate}(0)}$ \\ - $\TransmitPrivate$ &$:= \changed{\KAFormatPrivate{Sprout}(\PRFaddr{\AuthPrivate}(1))}$ \\ - $\TransmitPublic$ &$:= \changed{\KADerivePublic{Sprout}(\TransmitPrivate, \KABase{Sprout})}$. + $\AuthPublic$ &$:= \PRFaddr{\AuthPrivate}(0)$ \\ + $\TransmitPrivate$ &$:= \KAFormatPrivate{Sprout}(\PRFaddr{\AuthPrivate}(1))$ \\ + $\TransmitPublic$ &$:= \KADerivePublic{Sprout}(\TransmitPrivate, \KABase{Sprout})$. \end{tabular} @@ -4915,8 +4899,8 @@ A \joinSplitDescription comprises $(\vpubOld, \vpubNew, \rt{Sprout}, \nfOld{\all \TransmitCiphertext{\allNew})$ \\ where \begin{itemize} - \item \changed{$\vpubOld \typecolon \range{0}{\MAXMONEY}$ is - the value that the \joinSplitTransfer removes from the \transparentTxValuePool}; + \item $\vpubOld \typecolon \range{0}{\MAXMONEY}$ is + the value that the \joinSplitTransfer removes from the \transparentTxValuePool; \item $\vpubNew \typecolon \range{0}{\MAXMONEY}$ is the value that the \joinSplitTransfer inserts into the \transparentTxValuePool; \item $\rt{Sprout} \typecolon \MerkleHash{Sprout}$ is an \anchor, as defined in @@ -4927,18 +4911,18 @@ where the sequence of \nullifiers for the input \notes; \item $\cmNew{\allNew} \typecolon \typeexp{\NoteCommitOutput{Sprout}}{\NNew}$ is the sequence of \noteCommitments for the output \notes; - \item \changed{$\EphemeralPublic \typecolon \KAPublic{Sprout}$ is + \item $\EphemeralPublic \typecolon \KAPublic{Sprout}$ is a key agreement \publicKey, used to derive the key for encryption - of the \notesCiphertextSprout (\crossref{sproutinband})}; - \item \changed{$\RandomSeed \typecolon \RandomSeedType$ is + of the \notesCiphertextSprout (\crossref{sproutinband}); + \item $\RandomSeed \typecolon \RandomSeedType$ is a seed that must be chosen independently at random for each - \joinSplitDescription}; + \joinSplitDescription; \vspace{-0.5ex} \item $\h{\allOld} \typecolon \typeexp{\PRFOutputSprout}{\NOld}$ is a sequence of tags that bind $\hSig$ to each $\AuthPrivate$ of the input \notes; \item $\ProofJoinSplit \typecolon \JoinSplitProof$ is a \zkProof with - \primaryInput $(\rt{Sprout}, \nfOld{\allOld}, \cmNew{\allNew},\changed{ \vpubOld,\,} + \primaryInput $(\rt{Sprout}, \nfOld{\allOld}, \cmNew{\allNew}, \vpubOld, \vpubNew, \hSig, \h{\allOld})$ for the \joinSplitStatement defined in \crossref{joinsplitstatement}\sapling{ (this is a \BCTV proof before \Sapling activation, and a \Groth proof after \Sapling @@ -4950,10 +4934,10 @@ where \introlist The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphertextSprout. -The value $\hSig$ is also computed from \changed{$\RandomSeed$, $\nfOld{\allOld}$, and} the +The value $\hSig$ is also computed from $\RandomSeed$, $\nfOld{\allOld}$, and the $\joinSplitPubKey$ of the containing \transaction: \begin{formulae} - \item $\hSig := \hSigCRH(\changed{\RandomSeed, \nfOld{\allOld},\,} \joinSplitPubKey)$. + \item $\hSig := \hSigCRH(\RandomSeed, \nfOld{\allOld}, \joinSplitPubKey)$. \end{formulae} \vspace{-1ex} @@ -4962,7 +4946,7 @@ $\joinSplitPubKey$ of the containing \transaction: above (for example: $0 \leq \vpubOld \leq \MAXMONEY$ and $0 \leq \vpubNew \leq \MAXMONEY$). \item The proof $\Proof{\JoinSplit}$ \MUST be valid given a \primaryInput formed from the relevant other fields and $\hSig$ --- i.e.\ $\JoinSplitVerify{}\big(\kern-0.1em(\rt{Sprout}, \nfOld{\allOld}, - \cmNew{\allNew},\changed{\vpubOld,} \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}\big) = 1$. + \cmNew{\allNew}, \vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}\big) = 1$. \item Either $\vpubOld$ or $\vpubNew$ \MUST be zero. \canopyonwarditem{$\vpubOld$ \MUST be zero.} \end{consensusrules} @@ -5219,18 +5203,16 @@ generating a new $\JoinSplitSig$ key pair: For each \joinSplitDescription, the sender chooses $\RandomSeed$ uniformly at random on $\bitseq{\RandomSeedLength}$, and selects the input \notes. At this point there is sufficient information to compute $\hSig$, -as described in the previous section. \changed{The sender also chooses $\NoteUniquePreRand$ -uniformly at random on $\strut\smash{\bitseq{\NoteUniquePreRandLength}}$.} +as described in the previous section. The sender also chooses $\NoteUniquePreRand$ +uniformly at random on $\strut\smash{\bitseq{\NoteUniquePreRandLength}}$. Then it creates each output \note with index $i \typecolon \setofNew$: \begin{itemize} \item Choose uniformly random $\NoteCommitRand_i \leftarrowR \NoteCommitGenTrapdoor{Sprout}()$. -\changed{ \item Compute $\NoteUniqueRand_i = \PRFrho{\NoteUniquePreRand}(i, \hSig)$. -} \item Compute $\cm_i = \NoteCommit{Sprout}{\NoteCommitRand_i}(\AuthPublicSub{i}, \Value_i, \NoteUniqueRand_i)$. - \item Let $\NotePlaintext{i} = (\changed{\hexint{00},\ } \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i\changed{, \Memo_i})$. + \item Let $\NotePlaintext{i} = (\hexint{00}, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i, \Memo_i)$. \end{itemize} \vspace{-1ex} @@ -5460,7 +5442,6 @@ Let $\NoteCommitAlg{Sprout}$ be as defined in \crossref{abstractcommit}. \introlist \vspace{0.5ex} -\changed{ A \dummy \Sprout input \note, with index $i$ in the \joinSplitDescription, is constructed as follows: \vspace{-0.5ex} @@ -5477,7 +5458,6 @@ is constructed as follows: \auxiliaryInput to the \joinSplitStatement (this will not be checked). \item When generating the \joinSplitProof\!\!, set $\EnforceMerklePath{i}$ to $0$. \end{itemize} -} A \dummy \Sprout output \note is constructed as normal but with zero value, and sent to a random \shieldedPaymentAddress. @@ -5677,16 +5657,16 @@ in \crossref{sproutnonmalleability}\sapling{, \crossref{bindingsig}, and \crossr \introlist To provide additional flexibility when combining spend authorizations from different sources, \Bitcoin defines several \defining{\sighashTypes} that cover various parts of a transaction -\cite{Bitcoin-SigHash}. One of these types is $\SIGHASHALL$\changed{, which is used for -\Zcash-specific signatures, i.e.\ \joinSplitSignatures\sapling{, \spendAuthSignatures, -\notnufive{and} \saplingBindingSignatures}\nufive{, and \orchardBindingSignatures}}. -\changed{In these cases the \sighashTxHash is not associated with a \transparentInput, +\cite{Bitcoin-SigHash}. One of these types is $\SIGHASHALL$, which is used for +\Zcash-specific signatures, i.e.\ \joinSplitSignatures\sapling{, \spendAuthSignatures,\notnufive{ and} +\saplingBindingSignatures}\nufive{, and \orchardBindingSignatures}. +In these cases the \sighashTxHash is not associated with a \transparentInput, and so the input to hashing excludes \emph{all} of the $\scriptSig$ fields in the -non-\Zcash-specific parts of the \transaction.} +non-\Zcash-specific parts of the \transaction. -\changed{In \Zcash, all \sighashTypes are extended to cover the \Zcash-specific +In \Zcash, all \sighashTypes are extended to cover the \Zcash-specific fields $\nJoinSplit$, $\vJoinSplit$, and if present $\joinSplitPubKey$. These fields -are described in \crossref{txnencodingandconsensus}. The hash \emph{does not} cover the field $\joinSplitSig$.} +are described in \crossref{txnencodingandconsensus}. The hash \emph{does not} cover the field $\joinSplitSig$. \overwinter{After \Overwinter activation, all \sighashTypes are also extended to cover \transaction fields introduced in that upgrade\sapling{, and similarly after \Sapling activation}\nufive{ and after \NUFive activation}. @@ -5732,7 +5712,7 @@ by \cite{ZIP-225}. It will use a new \consensusBranchID \hexint{F919A198} as def \lsubsection{Non-malleability (\SproutText)}{sproutnonmalleability} Let $\dataToBeSigned$ be the hash of the \transaction{}, not associated with an input, -\changed{using the $\SIGHASHALL$ \sighashType}. +using the $\SIGHASHALL$ \sighashType. In order to ensure that a \joinSplitDescription is cryptographically bound to the \transparent inputs and outputs corresponding to $\vpubNew$ and $\vpubOld$, and @@ -5743,12 +5723,10 @@ signed with the private \signingKey of this key pair. The corresponding public $\JoinSplitSig$ is instantiated in \crossref{concretejssig}. -\changed{ If $\nJoinSplit$ is zero, the $\joinSplitPubKey$ and $\joinSplitSig$ fields are omitted. Otherwise, a \transaction has a correct \defining{\joinSplitSignature} if and only if $\JoinSplitSigValidate{\text{\small\joinSplitPubKey}}(\dataToBeSigned, \joinSplitSig) = 1$. % FIXME: distinguish pubkey and signature from their encodings. -} Let $\hSig$ be computed as specified in \crossref{joinsplitdesc}. @@ -5775,14 +5753,12 @@ to the \minerSubsidy in the \coinbaseTransaction of the \block. \Zcash \Sprout extends this by adding \joinSplitTransfers. Each \joinSplitTransfer can be seen, from the perspective of the \transparentTxValuePool, -as an input \changed{and an output simultaneously}. +as an input and an output simultaneously. -\changed{$\vpubOld$ takes value from the \transparentTxValuePool and} -$\vpubNew$ adds value to the \transparentTxValuePool. As a result, \changed{$\vpubOld$ is -treated like an \emph{output} value, whereas} $\vpubNew$ is treated like an -\emph{input} value. +$\vpubOld$ takes value from the \transparentTxValuePool and $\vpubNew$ adds value to +the \transparentTxValuePool. As a result, $\vpubOld$ is treated like an \emph{output} +value, whereas $\vpubNew$ is treated like an \emph{input} value. -\changed{ \defining{As defined in \cite{ZIP-209}, the \SproutChainValuePoolBalance for a given \blockChain is the sum of all $\vpubOld$ field values for \transactions in the \blockChain, minus the sum of all $\vpubNew$ fields values for transactions in the \blockChain.} @@ -5805,7 +5781,6 @@ $\vpubNew$ were nonzero were allowed, it could be replaced by an equivalent one in which $\minimum(\vpubOld, \vpubNew)$ is subtracted from both of these values. This restriction helps to avoid unnecessary distinctions between \transactions according to client implementation. -} %changed \sapling{ @@ -6348,8 +6323,7 @@ For each shielded protocol, the requirements on \nullifier derivation are as fol \item The derived \nullifier must be determined completely by the fields of the \note\sapling{, and possibly its position}, in a way that can be checked in the corresponding statement that controls spends (i.e.\ the - \changed{\joinSplitStatement}\sapling{, \spendStatement}\nufive{, or - \actionStatement}). + \joinSplitStatement\sapling{, \spendStatement}\nufive{, or \actionStatement}). \item Under the assumption that $\NoteUniqueRand$ values are unique, it must not be possible to generate two \notes with distinct \noteCommitments but the same \nullifier. (See \crossref{faeriegold} for further discussion.) @@ -6372,7 +6346,7 @@ Let $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$, $\MerkleDepth{Sprout} $\AuthPrivateLength$, $\NoteUniquePreRandLength$, $\hSigLength$, $\NOld$, $\NNew$ be as defined in \crossref{constants}. \vspace{-1ex} -Let $\PRFaddr{}$, $\PRFnf{Sprout}{}$, $\PRFpk{}$, \changed{and $\PRFrho{}$} be as defined in \crossref{abstractprfs}. +Let $\PRFaddr{}$, $\PRFnf{Sprout}{}$, $\PRFpk{}$, and $\PRFrho{}$ be as defined in \crossref{abstractprfs}. \vspace{-1ex} Let $\NoteCommit{Sprout}{}$ be as defined in \crossref{abstractcommit}, and @@ -6385,7 +6359,7 @@ A valid instance of a \defining{\joinSplitStatement}, $\ProofJoinSplit$, assures \item $\oparen\rt{Sprout} \typecolon \MerkleHash{Sprout},\\ \hparen\nfOld{\allOld} \typecolon \typeexp{\PRFOutputSprout}{\NOld},\\ \hparen\cmNew{\allNew} \typecolon \typeexp{\NoteCommitOutput{Sprout}}{\NNew},\vspace{0.6ex}\\ - \hparen\changed{\vpubOld \typecolon \ValueType,}\vspace{0.6ex}\\ + \hparen\vpubOld \typecolon \ValueType,\vspace{0.6ex}\\ \hparen\vpubNew \typecolon \ValueType,\\ \hparen\hSig \typecolon \hSigType,\vspace{0.5ex}\\ \hparen\h{\allOld} \typecolon \smash{\typeexp{\PRFOutputSprout}{\NOld}\cparen}$, @@ -6398,9 +6372,9 @@ the prover knows an \auxiliaryInput: \hparen\NotePosition_{\allOld} \typecolon \typeexp{\NotePositionType{Sprout}}{\NOld},\\ \hparen\nOld{\allOld} \typecolon \typeexp{\NoteType{Sprout}}{\NOld},\\ \hparen\AuthPrivateOld{\allOld} \typecolon \typeexp{\bitseq{\AuthPrivateLength}}{\NOld},\\ - \hparen\nNew{\allNew} \typecolon \typeexp{\NoteType{Sprout}}{\NNew}\changed{,}\vspace{0.5ex}\\ - \hparen\changed{\NoteUniquePreRand \typecolon \bitseq{\NoteUniquePreRandLength},}\vspace{-0.5ex}\\ - \hparen\changed{\EnforceMerklePath{\allOld} \typecolon \bitseq{\NOld}}\cparen$, + \hparen\nNew{\allNew} \typecolon \typeexp{\NoteType{Sprout}}{\NNew},\vspace{0.5ex}\\ + \hparen\NoteUniquePreRand \typecolon \bitseq{\NoteUniquePreRandLength},\vspace{-0.5ex}\\ + \hparen\EnforceMerklePath{\allOld} \typecolon \bitseq{\NOld}\cparen$, \end{formulae} \vspace{-2ex} where: @@ -6415,18 +6389,18 @@ where: such that the following conditions hold: \snarkcondition{Merkle path validity}{sproutmerklepathvalidity} -for each $i \in \setofOld$ \changed{$\mid$ $\EnforceMerklePath{i} = 1$}: +for each $i \in \setofOld$ $\mid$ $\EnforceMerklePath{i} = 1$: $(\TreePath{i}, \NotePosition_i)$ is a valid \merklePath (see \crossref{merklepath}) of depth $\MerkleDepth{Sprout}$ from $\NoteCommitment{Sprout}(\nOld{i})$ to the \anchor $\rt{Sprout}$. \pnote{Merkle path validity covers conditions 1.\,(a) and 1.\,(d) of the NP \statement in \cite[section 4.2]{BCGGMTV2014}.} -\changed{\snarkcondition{Merkle path enforcement}{sproutmerklepathenforcement}} +\snarkcondition{Merkle path enforcement}{sproutmerklepathenforcement} for each $i \in \setofOld$, if $\vOld{i} \neq 0$ then $\EnforceMerklePath{i} = 1$. \snarkcondition{Balance}{sproutbalance} -$\changed{\vpubOld\; +} \ssum{i=1}{\NOld} \vOld{i} = \vpubNew + \ssum{i=1}{\NNew} \vNew{i} \in \ValueType$. +$\vpubOld + \ssum{i=1}{\NOld} \vOld{i} = \vpubNew + \ssum{i=1}{\NNew} \vNew{i} \in \ValueType$. \snarkcondition{Nullifier integrity}{sproutnullifierintegrity} for each $i \in \setofOld$: @@ -6434,15 +6408,15 @@ $\nfOld{i} = \PRFnf{Sprout}{\AuthPrivateOld{i}}(\NoteUniqueRandOld{i})$. \snarkcondition{Spend authority}{sproutspendauthority} for each $i \in \setofOld$: -$\AuthPublicOld{i} = \changed{\PRFaddr{\AuthPrivateOld{i}}(0)}$. +$\AuthPublicOld{i} = \PRFaddr{\AuthPrivateOld{i}}(0)$. \snarkcondition{Non-malleability}{sproutnonmalleablejs} for each $i \in \setofOld$: $\h{i} = \PRFpk{\AuthPrivateOld{i}}(i, \hSig)$. -\changed{\snarkcondition{Uniqueness of $\NoteUniqueRandNew{i}$}{sproutuniquerho} +\snarkcondition{Uniqueness of $\NoteUniqueRandNew{i}$}{sproutuniquerho} for each $i \in \setofNew$: -$\NoteUniqueRandNew{i} = \PRFrho{\NoteUniquePreRand}(i, \hSig)$.} +$\NoteUniqueRandNew{i} = \PRFrho{\NoteUniquePreRand}(i, \hSig)$. \snarkcondition{Note commitment integrity}{sproutcommitmentintegrity} for each $i \in \setofNew$: $\cmNew{i} = \NoteCommitment{Sprout}(\nNew{i})$. @@ -6793,13 +6767,13 @@ In \Sprout, the secrets that need to be transmitted to a recipient of funds in order for them to later spend, are $\Value$, $\NoteUniqueRand$, and $\NoteCommitRand$. \canopy{(After \Canopy activation, $\NoteCommitRand$ is replaced by $\NoteSeedBytes$.)} -\changed{A \memo (\crossref{noteptconcept}) is also transmitted.} +A \memo (\crossref{noteptconcept}) is also transmitted. To transmit these secrets securely to a recipient \emph{without} requiring an out-of-band communication channel, the \transmissionKey $\TransmitPublic$ is used to encrypt them. The recipient's possession of the associated \incomingViewingKey $\InViewingKey$ is used to -reconstruct the original \note\changed{ and \memo}. +reconstruct the original \note and \memo. \introlist A single \ephemeralPublicKey is shared between encryptions of the $\NNew$ @@ -6840,27 +6814,21 @@ Then to encrypt: \vspace{-0.5ex} \begin{itemize} -\changed{ \item Generate a new $\KA{Sprout}$ (public, private) key pair $(\EphemeralPublic, \EphemeralPrivate)$. \vspace{-0.5ex} \item For $i \in \setofNew$, \begin{itemize} \item Let $\TransmitPlaintext{i}$ be the \rawEncoding of $\NotePlaintext{i}$. - \vspace{-0.5ex} - \item Let $\DHSecret{i} = \KAAgree{Sprout}(\EphemeralPrivate, -\TransmitPublicSub{i})$. - \vspace{-0.5ex} - \item Let $\TransmitKey{i} = \KDF{Sprout}(i, \hSig, \DHSecret{i}, \EphemeralPublic, -\TransmitPublicSub{i})$. - \item Let $\TransmitCiphertext{i} = -\SymEncrypt{\TransmitKey{i}}(\TransmitPlaintext{i})$. + \vspace{-0.5ex} + \item Let $\DHSecret{i} = \KAAgree{Sprout}(\EphemeralPrivate, \TransmitPublicSub{i})$. + \vspace{-0.5ex} + \item Let $\TransmitKey{i} = \KDF{Sprout}(i, \hSig, \DHSecret{i}, \EphemeralPublic, \TransmitPublicSub{i})$. + \item Let $\TransmitCiphertext{i} = \SymEncrypt{\TransmitKey{i}}(\TransmitPlaintext{i})$. \end{itemize} -} \end{itemize} \vspace{-2ex} -The resulting \defining{\notesCiphertextSprout} is $\changed{(\EphemeralPublic, -\TransmitCiphertext{\allNew})}$. +The resulting \defining{\notesCiphertextSprout} is $(\EphemeralPublic, \TransmitCiphertext{\allNew})$. \pnote{ It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note @@ -6887,16 +6855,13 @@ Let $\cm_{\allNew}$ be the \noteCommitments of each output coin. Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext component $(\EphemeralPublic, \TransmitCiphertext{i})$ as follows: -\changed{ \begin{formulae} \vspace{-0.5ex} \item let $\DHSecret{i} = \KAAgree{Sprout}(\TransmitPrivate, \EphemeralPublic)$ \vspace{-0.5ex} - \item let $\TransmitKey{i} = \KDF{Sprout}(i, \hSig, \DHSecret{i}, \EphemeralPublic, -\TransmitPublic)$ + \item let $\TransmitKey{i} = \KDF{Sprout}(i, \hSig, \DHSecret{i}, \EphemeralPublic, \TransmitPublic)$ \vspace{-0.5ex} - \item return $\DecryptNoteSprout(\TransmitKey{i}, \TransmitCiphertext{i}, \cm_i, -\AuthPublic).$ + \item return $\DecryptNoteSprout(\TransmitKey{i}, \TransmitCiphertext{i}, \cm_i, \AuthPublic).$ \end{formulae} \introlist @@ -6910,15 +6875,14 @@ is defined as follows: \item if $\TransmitPlaintext{i} = \bot$, return $\bot$ \vspace{-1.5ex} \item extract $\NotePlaintext{i} = (\NotePlaintextLeadByte_i \typecolon \byte, -\Value_i \typecolon \ValueType, -\NoteUniqueRand_i \typecolon \PRFOutputSprout, -\NoteCommitRand_i \typecolon \NoteCommitTrapdoor{Sprout}, -\Memo_i \typecolon \MemoType)$ from $\TransmitPlaintext{i}$ + \Value_i \typecolon \ValueType, + \NoteUniqueRand_i \typecolon \PRFOutputSprout, + \NoteCommitRand_i \typecolon \NoteCommitTrapdoor{Sprout}, + \Memo_i \typecolon \MemoType)$ from $\TransmitPlaintext{i}$ \vspace{-0.5ex} \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}((\AuthPublic, \Value_i, \NoteUniqueRand_i, -\NoteCommitRand_i)) \neq \cm_i$, return $\bot$, else return $\NotePlaintext{i}$. + \NoteCommitRand_i)) \neq \cm_i$, return $\bot$, else return $\NotePlaintext{i}$. \end{formulae} -} \vspace{-0.5ex} \introlist @@ -7470,7 +7434,7 @@ are used, the text will clarify their position in each case. Define: \begin{formulae}[itemsep=0.2ex] - \item $\MerkleDepth{Sprout} \typecolon \Nat := \changed{29}$ + \item $\MerkleDepth{Sprout} \typecolon \Nat := 29$ \sapling{ \item $\MerkleDepth{Sapling} \typecolon \Nat := 32$ } %sapling @@ -7493,10 +7457,10 @@ Define: \item $\PRFOutputLengthExpand \typecolon \Nat := 512$ \item $\PRFOutputLengthNfSapling \typecolon \Nat := 256$ } %sapling - \item $\NoteCommitRandLength \typecolon \Nat := \changed{256}$ - \item $\changed{\RandomSeedLength \typecolon \Nat := 256}$ - \item $\AuthPrivateLength \typecolon \Nat := \changed{252}$ - \item $\changed{\NoteUniquePreRandLength \typecolon \Nat := 252}$ + \item $\NoteCommitRandLength \typecolon \Nat := 256$ + \item $\RandomSeedLength \typecolon \Nat := 256$ + \item $\AuthPrivateLength \typecolon \Nat := 252$ + \item $\NoteUniquePreRandLength \typecolon \Nat := 252$ \sapling{ \item $\SpendingKeyLength \typecolon \Nat := 256$ \item $\DiversifierLength \typecolon \Nat := 88$ @@ -7519,7 +7483,7 @@ Define: \vspace{-1ex} \item $\Uncommitted{Orchard} \typecolon \bitseq{\MerkleHashLength{Orchard}} := \ItoLEBSPOf{\MerkleHashLength{Orchard}}{2}$ } %nufive - \item $\MAXMONEY \typecolon \Nat := \changed{2.1 \smult 10^{15}}$ (\zatoshi) + \item $\MAXMONEY \typecolon \Nat := 2.1 \smult 10^{15}$ (\zatoshi) \blossom{ \item $\BlossomActivationHeight \typecolon \Nat := \begin{cases} 653600,&\squash\text{for \Mainnet} \\ @@ -7604,7 +7568,6 @@ $\MerkleCRH{Sprout}$. The ordering of bits within words in the interface to $\SHACompress$ is consistent with \cite[section 3.1]{NIST2015}, i.e.\ big-endian. -\changed{ \vspace{2ex} \EdSpecific uses \defining{\bigShaHash}: @@ -7614,7 +7577,6 @@ consistent with \cite[section 3.1]{NIST2015}, i.e.\ big-endian. \vspace{-2ex} The comment above concerning bit vs byte-sequence interfaces also applies to \bigShaHash. -} %changed \lsubsubsubsection{BLAKE2 Hash Functions}{concreteblake2} @@ -7760,7 +7722,6 @@ $\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHash{Orchard \newsavebox{\hsigbox} \begin{lrbox}{\hsigbox} -\setchanged \begin{bytefield}[bitwidth=0.04em]{1024} \sbitbox{256}{$256$-bit $\RandomSeed$} & \sbitbox{256}{\hfill $256$-bit $\nfOld{\mathrm{1}}$\hfill...\;} & @@ -7772,7 +7733,6 @@ $\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHash{Orchard \vspace{-2ex} $\hSigCRH$ is used to compute the value $\hSig$ in \crossref{joinsplitdesc}. -\changed{ \begin{formulae} \item $\hSigCRH(\RandomSeed, \nfOld{\allOld}, \joinSplitPubKey) := \BlakeTwobOf{256}{\ascii{ZcashComputehSig},\; \hSigInput}$ \end{formulae} @@ -7782,7 +7742,6 @@ where \begin{formulae} \item $\hSigInput := \Justthebox{\hsigbox}$. \end{formulae} -} \vspace{-1ex} $\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}. @@ -8405,14 +8364,13 @@ $n = 200$). Let \shaCompress be as given in \crossref{concretesha256}. -The \pseudoRandomFunctions $\PRFaddr{}$, $\PRFnf{Sprout}{}$, $\PRFpk{}$\changed{, and $\PRFrho{}$} +The \pseudoRandomFunctions $\PRFaddr{}$, $\PRFnf{Sprout}{}$, $\PRFpk{}$, and $\PRFrho{}$ from \crossref{abstractprfs}, are all instantiated using \shaCompress: \newcommand{\iminusone}{\hspace{0.3pt}\scriptsize{$i$\hspace{0.6pt}-1}} \newsavebox{\addrbox} \begin{lrbox}{\addrbox} -\setchanged \begin{bytefield}[bitwidth=0.06em]{512} \sbitbox{18}{$1$} & \sbitbox{18}{$1$} & @@ -8426,7 +8384,6 @@ from \crossref{abstractprfs}, are all instantiated using \shaCompress: \newsavebox{\nfbox} \begin{lrbox}{\nfbox} -\setchanged \begin{bytefield}[bitwidth=0.06em]{512} \sbitbox{18}{$1$} & \sbitbox{18}{$1$} & @@ -8439,7 +8396,6 @@ from \crossref{abstractprfs}, are all instantiated using \shaCompress: \newsavebox{\pkbox} \begin{lrbox}{\pkbox} -\setchanged \begin{bytefield}[bitwidth=0.06em]{512} \sbitbox{18}{$0$} & \sbitbox{18}{\iminusone} & @@ -8452,7 +8408,6 @@ from \crossref{abstractprfs}, are all instantiated using \shaCompress: \newsavebox{\rhobox} \begin{lrbox}{\rhobox} -\setchanged \begin{bytefield}[bitwidth=0.06em]{512} \sbitbox{18}{$0$} & \sbitbox{18}{\iminusone} & @@ -8466,10 +8421,10 @@ from \crossref{abstractprfs}, are all instantiated using \shaCompress: \vspace{-3ex} \begin{equation*} \begin{aligned} -\setchanged \PRFaddr{x}(t) &\setchanged := \SHACompressBox{\addrbox} \\ +\PRFaddr{x}(t) &:= \SHACompressBox{\addrbox} \\ \PRFnf{Sprout}{\AuthPrivate}(\NoteUniqueRand) &:= \SHACompressBox{\nfbox} \\ -\PRFpk{\AuthPrivate}(i, \hSig) &:= \SHACompressBox{\pkbox} \\ -\setchanged \PRFrho{\NoteUniquePreRand}(i, \hSig) &\setchanged := \SHACompressBox{\rhobox} +\PRFpk{\AuthPrivate}(i, \hSig) &:= \SHACompressBox{\pkbox} \\ +\PRFrho{\NoteUniquePreRand}(i, \hSig) &:= \SHACompressBox{\rhobox} \end{aligned} \end{equation*} @@ -8481,7 +8436,6 @@ from \crossref{abstractprfs}, are all instantiated using \shaCompress: in the above diagrams, with input in the remaining bits. \end{securityrequirements} -\changed{ \pnote{ The first four bits --i.e.\ the most significant four bits of the first byte-- are used to separate distinct uses of \shaCompress, ensuring that the functions @@ -8495,8 +8449,7 @@ additional bit to $\AuthPrivate$ to encode a new key type, or that would have required an additional \xPRF.\sapling{ In fact since \Sapling switches to non-\shaCompress-based cryptographic primitives, these extensions are unlikely to be necessary.}) -} -} +} %pnote \newsavebox{\saplingockbox} @@ -8647,7 +8600,6 @@ PRF when keyed by its first argument, with its second argument as input. \introsection \lsubsubsection{Symmetric Encryption}{concretesym} -\changed{ Let $\Keyspace := \bitseq{256}$, $\Plaintext := \byteseqs$, and $\Ciphertext := \byteseqs$. Let the \symmetricEncryptionScheme $\SymEncrypt{\Key}(\Ptext)$ be authenticated encryption using @@ -8665,8 +8617,7 @@ or $\bot$ indicating failure to decrypt. The ``IETF" definition of $\SymSpecific$ from \cite{RFC-7539} is used; this has a $32$-bit block count and a $96$-bit nonce, rather than a $64$-bit block count and $64$-bit nonce as in the original definition of $\SymCipher$. -} -} %changed +} %pnote \nufive{ \lsubsubsection{Pseudo Random Permutations}{concreteprps} @@ -8692,7 +8643,6 @@ Define $\PRPd{K}(\Diversifier) := \FFOneAES{K}(\ascii{}, \Diversifier)$. \lsubsubsubsection{\SproutText{} Key Agreement}{concretesproutkeyagreement} -\changed{ $\KA{Sprout}$ is a \keyAgreementScheme as specified in \crossref{abstractkeyagreement}. It is instantiated as $\KASproutCurve$ key agreement, described in \cite{Bernstein2006}, @@ -8722,14 +8672,12 @@ Define $\KAFormatPrivate{Sprout}(x) := \KASproutCurveClamp(x)$. Define $\KADerivePublic{Sprout}(n, q) := \KASproutCurveMultiply(n, q)$. Define $\KAAgree{Sprout}(n, q) := \KASproutCurveMultiply(n, q)$. -} \introsection \lsubsubsubsection{\SproutText{} Key Derivation}{concretesproutkdf} \newsavebox{\kdftagbox} \begin{lrbox}{\kdftagbox} -\setchanged \begin{bytefield}[bitwidth=0.16em]{128} \sbitbox{64}{$64$-bit $\ascii{ZcashKDF}$} & \sbitbox{32}{$8$-bit $i\!-\!1$} & @@ -8739,7 +8687,6 @@ Define $\KAAgree{Sprout}(n, q) := \KASproutCurveMultiply(n, q)$. \newsavebox{\kdfinputbox} \begin{lrbox}{\kdfinputbox} -\setchanged \begin{bytefield}[bitwidth=0.04em]{1024} \sbitbox{256}{$256$-bit $\hSig$} & \sbitbox{256}{$256$-bit $\DHSecret{i}$} & @@ -8748,7 +8695,6 @@ Define $\KAAgree{Sprout}(n, q) := \KASproutCurveMultiply(n, q)$. \end{bytefield} \end{lrbox} -\changed{ $\KDF{Sprout}$ is a \keyDerivationFunction as specified in \crossref{abstractkdf}. It is instantiated using $\BlakeTwob{256}$ as follows: @@ -8763,7 +8709,6 @@ where: \item $\kdftag := \Justthebox{\kdftagbox}$ \item $\kdfinput := \Justthebox{\kdfinputbox}$. \end{formulae} -} $\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}. @@ -8884,7 +8829,7 @@ $\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}. \EdSpecific is a \signatureScheme as specified in \crossref{abstractsig}. It is used to instantiate $\JoinSplitSig$ as described in \crossref{sproutnonmalleability}. -\changed{Let $\ExcludedPointEncodings \typecolon \powerset{\byteseq{32}} = \{$ \\ +Let $\ExcludedPointEncodings \typecolon \powerset{\byteseq{32}} = \{$ \\ \scalebox{0.615}[0.7]{ \begin{tabular}{@{\hspace{1.5em}}l@{}} $\hexarray{00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00},$ \\ @@ -8917,9 +8862,9 @@ Define $\ItoLEOSP{}$, $\LEOStoBSP{}$, and $\LEBStoIP{}$ as in \crossref{endian}. Define $\reprBytesEdSpecific \typecolon \GroupEdSpecific \rightarrow \ReprEdSpecificBytes$ such that $\reprBytesEdSpecific\Of{x, y} = \ItoLEOSP{256}\big(y + 2^{255} \smult \tilde{x}\big)$, where -$\tilde{x} = x \bmod 2$.\footnotewithlabel{coordinatenames}{\changed{Here we use the $(x, y)$ naming of coordinates in +$\tilde{x} = x \bmod 2$.\footnotewithlabel{coordinatenames}{Here we use the $(x, y)$ naming of coordinates in \cite{BDLSY2012}, which is different from the $(u, \varv)$ naming used for coordinates of \ctEdwardsCurves -in \crossref{jubjub} and in \crossref{ecbackground}.}} +in \crossref{jubjub} and in \crossref{ecbackground}.} \introlist Define $\abstBytesEdSpecific \typecolon \ReprEdSpecificBytes \rightarrow \maybe{\GroupEdSpecific}$ such that @@ -8977,10 +8922,9 @@ considered invalid. \vspace{1ex} \introlist The encoding of an \EdSpecific signature is: -} + \newsavebox{\sigbox} \begin{lrbox}{\sigbox} -\setchanged \begin{bytefield}[bitwidth=0.075em]{512} \sbitbox{256}{$256$-bit $\EdDSAReprR{}$} & \sbitbox{256}{$256$-bit $\EdDSAReprS{}$} @@ -8991,7 +8935,6 @@ The encoding of an \EdSpecific signature is: \item $\Justthebox{\sigbox}$ \end{formulae} -\changed{ \vspace{-1ex} where $\EdDSAReprR{}$ and $\EdDSAReprS{}$ are as defined in \cite{BDLSY2012}. @@ -9012,7 +8955,6 @@ signature validation in \zcashd. exclude points of order less than $\ell$; however, not all such points were covered. It is possible, with due attention to detail, to reproduce this quirk without using libsodium~v1.0.15.} -} %changed \sapling{ @@ -9291,7 +9233,6 @@ $\ValueCommitRandBase{Orchard}$}. \newsavebox{\cmbox} \begin{lrbox}{\cmbox} -\setchanged \begin{bytefield}[bitwidth=0.027em]{840} \sbitbox{28}{$1$} & \sbitbox{28}{$0$} & @@ -9318,9 +9259,7 @@ instantiated using \shaHash as follows: \end{formulae} \vspace{-1ex} -\changed{\pnote{ -The leading byte of the \shaHash input is $\hexint{B0}$. -}} +\pnote{The leading byte of the \shaHash input is $\hexint{B0}$.} \begin{securityrequirements} \item \shaCompress must be \collisionResistant\!. @@ -9633,7 +9572,6 @@ $\GenG{1}$ and $\GenG{2}$ are generators of $\SubgroupG{1}$ and $\SubgroupG{2}$ \newsavebox{\gonebox} \begin{lrbox}{\gonebox} -\setchanged \begin{bytefield}[bitwidth=0.045em]{264} \sbitbox{20}{$0$} & \sbitbox{20}{$0$} & @@ -9649,7 +9587,6 @@ $\GenG{1}$ and $\GenG{2}$ are generators of $\SubgroupG{1}$ and $\SubgroupG{2}$ \newsavebox{\gtwobox} \begin{lrbox}{\gtwobox} -\setchanged \begin{bytefield}[bitwidth=0.045em]{520} \sbitbox{20}{$0$} & \sbitbox{20}{$0$} & @@ -10507,7 +10444,6 @@ the appropriate \network.} \newsavebox{\bctvbox} \begin{lrbox}{\bctvbox} -\setchanged \begin{bytefield}[bitwidth=0.021em]{2368} \sbitbox{264}{264-bit $\Proof{A}$} & \sbitbox{264}{264-bit $\Proof{A}'$} & @@ -10640,9 +10576,9 @@ The \notePlaintexts in a \joinSplitDescription are encrypted to the respective \transmissionKeys $\TransmitPublicNew{\allNew}$. Each \Sprout \notePlaintext (denoted $\NotePlaintext{}$) consists of: \begin{formulae} - \item $(\changed{\NotePlaintextLeadByte \typecolon \byte,\ } + \item $(\NotePlaintextLeadByte \typecolon \byte, \Value \typecolon \ValueType, \NoteUniqueRand \typecolon \PRFOutputSprout, -\NoteCommitRand \typecolon \NoteCommitOutput{Sprout}\changed{, \Memo \typecolon \MemoType})$ + \NoteCommitRand \typecolon \NoteCommitOutput{Sprout}, \Memo \typecolon \MemoType)$ \end{formulae} \saplingonward{ @@ -10656,7 +10592,7 @@ Each \Sapling \notePlaintext (denoted $\NotePlaintext{}$) consists of: \end{formulae} } -\changed{$\Memo$ is a $\MemoByteLength$-byte \memo associated with this \note. +$\Memo$ is a $\MemoByteLength$-byte \memo associated with this \note. \introlist The usage of the \memo is by agreement between the sender and recipient of the @@ -10676,7 +10612,6 @@ characters (\ReplacementCharacter). In other cases, the contents of the \memo \SHOULDNOT be displayed unless otherwise specified by \cite{ZIP-302}. -} Other fields are as defined in \crossref{notes}. @@ -10686,26 +10621,21 @@ The encoding of a \Sprout \notePlaintext consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.029em]{1672} -\changed{ - \sbitbox{220}{$8$-bit $\NotePlaintextLeadByte$} - &}\sbitbox{180}{$64$-bit $\Value$} & + \sbitbox{220}{$8$-bit $\NotePlaintextLeadByte$} & + \sbitbox{180}{$64$-bit $\Value$} & \sbitbox{256}{$256$-bit $\NoteUniqueRand$} & - \sbitbox{256}{\changed{$256$}-bit $\NoteCommitRand$} & - \changed{\sbitbox{800}{$\Memo$ ($\MemoByteLength$ bytes)}} + \sbitbox{256}{$256$-bit $\NoteCommitRand$} & + \sbitbox{800}{$\Memo$ ($\MemoByteLength$ bytes)} \end{bytefield} \end{equation*} \begin{itemize} -\changed{ \item A byte, $\hexint{00}$, indicating this version of the encoding of a \Sprout \notePlaintext. -} \item $8$ bytes specifying $\Value$. \item $32$ bytes specifying $\NoteUniqueRand$. - \item \changed{32} bytes specifying $\NoteCommitRand$. -\changed{ + \item $32$ bytes specifying $\NoteCommitRand$. \item $\MemoByteLength$ bytes specifying $\Memo$. -} \end{itemize} \sapling{ @@ -10736,7 +10666,7 @@ The encoding of a \Sapling \notePlaintext consists of: \lsubsection{Encodings of Addresses and Keys}{addressandkeyencoding} -This section describes how \Zcash encodes \shieldedPaymentAddresses\changed{, \incomingViewingKeys,} +This section describes how \Zcash encodes \shieldedPaymentAddresses, \incomingViewingKeys, and \spendingKeys. Addresses and keys can be encoded as a byte sequence; this is called @@ -10856,25 +10786,22 @@ The \rawEncoding of a \Sprout \shieldedPaymentAddress consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{520} -\changed{ - \sbitbox{80}{$8$-bit $\PaymentAddressLeadByte$} - \sbitbox{80}{$8$-bit $\PaymentAddressSecondByte$} - &}\sbitbox{256}{$256$-bit $\AuthPublic$} & - \sbitbox{256}{\changed{$256$}-bit $\TransmitPublic$} + \sbitbox{80}{$8$-bit $\PaymentAddressLeadByte$} & + \sbitbox{80}{$8$-bit $\PaymentAddressSecondByte$} & + \sbitbox{256}{$256$-bit $\AuthPublic$} & + \sbitbox{256}{$256$-bit $\TransmitPublic$} \end{bytefield} \end{equation*} \begin{itemize} -\changed{ \item Two bytes $[\PaymentAddressLeadByte, \PaymentAddressSecondByte]$, indicating this version of the \rawEncoding of a \Sprout \shieldedPaymentAddress on \Mainnet. (Addresses on \Testnet use $[\PaymentAddressTestnetLeadByte, \PaymentAddressTestnetSecondByte]$ instead.) -} \item $32$ bytes specifying $\AuthPublic$. - \item \changed{$32$ bytes} specifying $\TransmitPublic$, \changed{using the - normal encoding of a $\KASproutCurve$ \publicKey \cite{Bernstein2006}}. + \item $32$ bytes specifying $\TransmitPublic$, using the + normal encoding of a $\KASproutCurve$ \publicKey \cite{Bernstein2006}. \end{itemize} \pnote{ @@ -10887,7 +10814,6 @@ cause the first two characters of the \BaseFiftyEightCheck encoding to be fixed \lsubsubsubsection{\SproutText{} Incoming Viewing Keys}{sproutinviewingkeyencoding} -\changed{ Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}. A \Sprout \defining{\incomingViewingKey} consists of $\AuthPublic \typecolon \PRFOutputSprout$ @@ -10900,21 +10826,18 @@ $\TransmitPrivate$ is a $\KAPrivate{Sprout}$ key, for use with the encryption sc \introlist The \rawEncoding of a \Sprout \incomingViewingKey consists of, in order: -} + \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.062em]{536} -\changed{ \sbitbox{88}{$8$-bit $\InViewingKeyLeadByte$} \sbitbox{88}{$8$-bit $\InViewingKeySecondByte$} \sbitbox{88}{$8$-bit $\InViewingKeyThirdByte$} \sbitbox{256}{$256$-bit $\AuthPublic$} \sbitbox{256}{$256$-bit $\TransmitPrivate$} -} \end{bytefield} \end{equation*} -\changed{ \vspace{-1ex} \begin{itemize} \item Three bytes $[\InViewingKeyLeadByte, \InViewingKeySecondByte, \InViewingKeyThirdByte]$, @@ -10933,54 +10856,46 @@ considered invalid if $\TransmitPrivate \neq \KAFormatPrivate{Sprout}(\TransmitP $\KAFormatPrivate{Sprout}$ is defined in \crossref{concretesproutkeyagreement}. -\pnote{ -For addresses on \Mainnet, the lead bytes and encoded length +\pnote{For addresses on \Mainnet, the lead bytes and encoded length cause the first four characters of the \BaseFiftyEightCheck encoding to be fixed as \ascii{ZiVK}. For \Testnet, the first four characters are fixed as -\ascii{ZiVt}.}} %changed +\ascii{ZiVt}.} \lsubsubsubsection{\SproutText{} Spending Keys}{sproutspendingkeyencoding} A \Sprout{} \defining{\spendingKey} consists of $\AuthPrivate$, which is a sequence of -\changed{$252$} bits (see \crossref{sproutkeycomponents}). +$252$ bits (see \crossref{sproutkeycomponents}). \introlist The \rawEncoding of a \Sprout \spendingKey consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{264} -\changed{ - \sbitbox{80}{$8$-bit $\SpendingKeyLeadByte$} - \sbitbox{80}{$8$-bit $\SpendingKeySecondByte$} + \sbitbox{80}{$8$-bit $\SpendingKeyLeadByte$} & + \sbitbox{80}{$8$-bit $\SpendingKeySecondByte$} & \sbitbox{32}{$\zeros{4}$} & - &}\sbitbox{252}{\changed{$252$}-bit $\AuthPrivate$} + \sbitbox{252}{$252$-bit $\AuthPrivate$} \end{bytefield} \end{equation*} \begin{itemize} -\changed{ \item Two bytes $[\SpendingKeyLeadByte, \SpendingKeySecondByte]$, indicating this version of the \rawEncoding of a \Zcash \spendingKey on \Mainnet. (Addresses on \Testnet use $[\SpendingKeyTestnetLeadByte, \SpendingKeyTestnetSecondByte]$ instead.) -} - \item $32$ bytes: \changed{$4$ zero padding bits and $252$ bits} specifying $\AuthPrivate$. + \item $32$ bytes: $4$ zero padding bits and $252$ bits specifying $\AuthPrivate$. \end{itemize} -\changed{ -The zero padding occupies the most significant 4 bits of the third byte. -} +The zero padding occupies the most significant $4$ bits of the third byte. \begin{pnotes} -\changed{ \item If an implementation represents $\AuthPrivate$ internally as a sequence of $32$ bytes with the $4$ bits of zero padding intact, it will be in the correct form for use as an input to $\PRFaddr{}$, $\PRFnf{Sprout}{}$, and $\PRFpk{}$ without need for bit-shifting. Future key representations may make use of these padding bits. -} \item For addresses on \Mainnet, the lead bytes and encoded length cause the first two characters of the \BaseFiftyEightCheck encoding to be fixed as \ascii{SK}. For \Testnet, the first two characters @@ -11585,7 +11500,7 @@ $\barerange{2}{4}$ & \Varies & $\nJoinSplit$ & \type{compactSize} & The number of \joinSplitDescriptions in $\vJoinSplit$.\! \\ \hline $\barerange{2}{3}$ & \Longunderstack{$1802 \mult$ \\ $\nJoinSplit$} & $\vJoinSplit$ & \type{JSDescriptionBCTV14}\!\! \type{[$\nJoinSplit$]} & -A \sequenceOfJoinSplitDescriptions{} using \BCTV proofs, encoded per \crossref{joinsplitencodingandconsensus}.\! \\ \hline +A sequence of \joinSplitDescriptions using \BCTV proofs, encoded per \crossref{joinsplitencodingandconsensus}.\! \\ \hline \setsapling $4$ &\setsapling \Longunderstack{$1698 \mult$ \\ $\nJoinSplit$} &\setsapling $\vJoinSplit$ &\saplingtype{JSDescriptionGroth16}\!\! \saplingtype{[$\nJoinSplit$]} &\setsapling A sequence of \joinSplitDescriptions using \Groth proofs, encoded per \crossref{joinsplitencodingandconsensus}.\! \\ \hline @@ -11967,40 +11882,40 @@ a \transaction as an instance of a \type{JoinSplitDescription} type as follows: Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=|=|=|=|} -\setchanged 8 &\setchanged $\vpubOldField$ &\setchanged \type{uint64} &\mbox{}\setchanged +$8$ & $\vpubOldField$ & \type{uint64} & A value $\vpubOld$ that the \joinSplitTransfer removes from the \transparentTxValuePool. \\ \hline -$8$ & $\vpubNewField$ & \type{uint64} & A value $\vpubNew$ that the \joinSplitTransfer inserts -into the \transparentTxValuePool. \\ \hline +$8$ & $\vpubNewField$ & \type{uint64} & +A value $\vpubNew$ that the \joinSplitTransfer inserts into the \transparentTxValuePool. \\ \hline -$32$ & $\anchorField{}$ & \type{byte[32]} & A \merkleRoot $\rt{Sprout}$ of the \Sprout{} -\noteCommitmentTree at some \blockHeight in the past, or the \merkleRoot produced by a previous -\joinSplitTransfer in this \transaction. \\ \hline +$32$ & $\anchorField{}$ & \type{byte[32]} & +A \merkleRoot $\rt{Sprout}$ of the \Sprout{} \noteCommitmentTree at some \blockHeight in the past, +or the \merkleRoot produced by a previous \joinSplitTransfer in this \transaction. \\ \hline -$64$ & $\nullifiersField$ & \type{byte[32][$\NOld$]} & A sequence of \nullifiers of the input -\notes $\nfOld{\allOld}$. \\[0.4ex] \hline +$64$ & $\nullifiersField$ & \type{byte[32][$\NOld$]} & +A sequence of \nullifiers of the input \notes $\nfOld{\allOld}$. \\[0.4ex] \hline -$64$ & $\commitmentsField$ & \type{byte[32][$\NNew$]} & A sequence of \noteCommitments for the -output \notes $\cmNew{\allNew}$. \\ \hline +$64$ & $\commitmentsField$ & \type{byte[32][$\NNew$]} & +A sequence of \noteCommitments for the output \notes $\cmNew{\allNew}$. \\ \hline -\setchanged $32$ &\setchanged $\ephemeralKey$ &\setchanged \type{byte[32]} &\mbox{}\setchanged +$32$ & $\ephemeralKey$ & \type{byte[32]} & A $\KASproutCurve$ \publicKey $\EphemeralPublic$. \\ \hline -\setchanged $32$ &\setchanged $\randomSeed$ &\setchanged \type{byte[32]} &\mbox{}\setchanged +$32$ & $\randomSeed$ & \type{byte[32]} & A $256$-bit seed that must be chosen independently at random for each \joinSplitDescription. \\ \hline -$64$ & $\vmacs$ & \type{byte[32][$\NOld$]} & A sequence of message authentication tags -$\h{\allOld}$ binding $\hSig$ to each $\AuthPrivate$ of the $\joinSplitDescription$, -computed as described in \crossref{sproutnonmalleability}. \\ \hline +$64$ & $\vmacs$ & \type{byte[32][$\NOld$]} & +A sequence of message authentication tags $\h{\allOld}$ binding $\hSig$ to each $\AuthPrivate$ of the +$\joinSplitDescription$, computed as described in \crossref{sproutnonmalleability}. \\ \hline -$296\;\dagger$ & $\zkproof$ & \type{byte[296]} & An encoding of the \zkSNARKProof -$\ProofJoinSplit$ (see \crossref{bctv}). \\ \hline +$296\;\dagger$ & $\zkproof$ & \type{byte[296]} & +An encoding of the \zkSNARKProof $\ProofJoinSplit$ (see \crossref{bctv}). \\ \hline -$192\;\ddagger$ & $\zkproof$ & \type{byte[192]} & An encoding of the \zkSNARKProof -$\ProofJoinSplit$ (see \crossref{groth}). \\ \hline +$192\;\ddagger$ & $\zkproof$ & \type{byte[192]} & +An encoding of the \zkSNARKProof $\ProofJoinSplit$ (see \crossref{groth}). \\ \hline -$1202$ & $\encCiphertexts$ & \type{byte[601][$\NNew$]} & A sequence of ciphertext -components for the encrypted output \notes, $\TransmitCiphertext{\allNew}$. \\ \hline +$1202$ & $\encCiphertexts$ & \type{byte[601][$\NNew$]} & +A sequence of ciphertext components for the encrypted output \notes, $\TransmitCiphertext{\allNew}$. \\ \hline \end{tabularx} \end{center} @@ -12038,21 +11953,23 @@ a \transaction as an instance of a \type{SpendDescription} type as follows: Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=|=|=|=|} -$32$ & $\cvField$ & \type{byte[32]} & A \valueCommitment to the value of the input \note, -$\LEBStoOSPOf{256}{\reprJ\Of{\cv}}$. \\ \hline +$32$ & $\cvField$ & \type{byte[32]} & +A \valueCommitment to the value of the input \note, $\LEBStoOSPOf{256}{\reprJ\Of{\cv}}$. \\ \hline -$32\nufive{\;\dagger}$ & $\anchorField{}$ & \type{byte[32]} & A \merkleRoot of the \Sapling \noteCommitmentTree -at some \blockHeight in the past, $\LEBStoOSPOf{256}{\rt{Sapling}}$. \\ \hline +$32\nufive{\;\dagger}$ & $\anchorField{}$ & \type{byte[32]} & +A \merkleRoot of the \Sapling \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSPOf{256}{\rt{Sapling}}$. \\ \hline -$32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline +$32$ & $\nullifierField$ & \type{byte[32]} & +The \nullifier of the input \note, $\nf$. \\ \hline -$32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSigField$, -$\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline +$32$ & $\rkField$ & \type{byte[32]} & +The randomized \validatingKey for $\spendAuthSigField$, $\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline -$192\nufive{\;\dagger}$ & $\zkproof$ & \type{byte[192]} & An encoding of the \zkSNARKProof -$\ProofSpend$ (see \crossref{groth}). \\ \hline +$192\nufive{\;\dagger}$ & $\zkproof$ & \type{byte[192]} & +An encoding of the \zkSNARKProof $\ProofSpend$ (see \crossref{groth}). \\ \hline -$64\nufive{\;\dagger}$ & $\spendAuthSigField$ & \type{byte[64]} & A signature authorizing this Spend. \\ \hline +$64\nufive{\;\dagger}$ & $\spendAuthSigField$ & \type{byte[64]} & +A signature authorizing this Spend. \\ \hline \end{tabularx} \end{center} @@ -13651,6 +13568,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.1.20}{2021-03-18} \begin{itemize} \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). + \item Remove magenta highlighting of differences from \Zerocash. \end{itemize} From 3e160d6ecb2f2c835d78fdfa65985ab50a848ff0 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 19 Mar 2021 14:00:55 +0000 Subject: [PATCH 03/41] 2^16 -> 2^{16}. fixes #461 Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 45e9c427..1af4f9a8 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11835,7 +11835,7 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notnufive{ and} e the effect of disabling non-zero-valued \Orchard spends), the $\valueBalance{Orchard}$ field of a \coinbaseTransaction must have a negative or zero value.} \nufiveonwarditem{The rule that \nSpendsSapling, \nOutputsSapling, and \nActionsOrchard{} \MUST all - be less than $2^16$, is technically redundant because a \transaction that could violate this + be less than $2^{16}$, is technically redundant because a \transaction that could violate this rule would not fit within the $2$ MB \block size limit. It is included in order to simplify the security argument for balance preservation.} \end{pnotes} From 781ec6896da7747950c97f08f31e59a7dd3309a3 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 19 Mar 2021 14:06:47 +0000 Subject: [PATCH 04/41] Correct the type signature of DiversifyHash^Orchard in \crossref{abstracthashes}. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 1af4f9a8..a5bc9f50 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -7826,7 +7826,7 @@ Define \end{formulae} \nufive{ -$\DiversifyHash{Orchard} \typecolon \DiversifierType \rightarrow \maybe{\GroupPstar}$ +$\DiversifyHash{Orchard} \typecolon \DiversifierType \rightarrow \GroupPstar$ is used to derive a \diversifiedBase in \crossref{orchardkeycomponents}. Let $\GroupPHash{}$ be as defined in \crossref{concretegrouphashpallasandvesta}. @@ -13567,6 +13567,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.1.20}{2021-03-18} \begin{itemize} + \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). \item Remove magenta highlighting of differences from \Zerocash. \end{itemize} From a859014b98d2188772c1b550016ff242effac6bb Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 19 Mar 2021 14:08:59 +0000 Subject: [PATCH 05/41] Correct the description of `length` in \crossref{unifiedpaymentaddrencoding}. (It is the length of `addr`, not the length of the raw encoding; they differ for t-addrs.) Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index a5bc9f50..76fceaa8 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11089,7 +11089,7 @@ $(\typecodeField, \lengthField, \addrField)$ encodings of the consituent address \begin{itemize} \item $\typecodeField \typecolon \byte$ -- the typecode from the above list; - \item $\lengthField \typecolon \byte$ -- the length in bytes of the raw encoding; + \item $\lengthField \typecolon \byte$ -- the length in bytes of $\addrField$; \vspace{-0.5ex} \item $\addrField \typecolon \byteseq{\scriptsize\lengthField}$ -- the raw encoding of a \shieldedPaymentAddress, or the $160$-bit script hash of a P2SH address @@ -13567,6 +13567,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.1.20}{2021-03-18} \begin{itemize} + \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). \item Remove magenta highlighting of differences from \Zerocash. From 75a8a944d43132b019011e4c02f426685aa86b80 Mon Sep 17 00:00:00 2001 From: Deirdre Connolly Date: Fri, 19 Mar 2021 02:08:46 -0400 Subject: [PATCH 06/41] s/enableSpendsOrchard/enableOutputsOrchard/ re: no new notes --- protocol/protocol.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 76fceaa8..c76fc39b 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11821,7 +11821,7 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notnufive{ and} e \nufive{ \item The flags in \flagsOrchard allow a version 5 \transaction to declare that no funds are spent from \Orchard \notes (by setting \enableSpendsOrchard to $0$), or that no new \Orchard \notes - with non-zero values are created (by setting \enableSpendsOrchard to $0$). This has two primary + with non-zero values are created (by setting \enableOutputsOrchard to $0$). This has two primary purposes. First, the \enableSpendsOrchard flag is set to $0$ in version 5 \coinbaseTransactions to ensure that they cannot spend from existing \Orchard outputs, maintaining a restriction present in \coinbaseTransactions for \transparent, \Sprout, or \Sapling funds (which would not otherwise From e1bdfce3bc4871391baad5d651c966828a8e5269 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 22 Mar 2021 15:59:10 +0000 Subject: [PATCH 07/41] Remove specification of memo contents, which will be in ZIP 302. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 20 +++----------------- 1 file changed, 3 insertions(+), 17 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index c76fc39b..82b26368 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10595,23 +10595,8 @@ Each \Sapling \notePlaintext (denoted $\NotePlaintext{}$) consists of: $\Memo$ is a $\MemoByteLength$-byte \memo associated with this \note. \introlist -The usage of the \memo is by agreement between the sender and recipient of the -\note. The \memo \SHOULD be encoded as one of: - -\begin{itemize} - \item a UTF-8 human-readable string \cite{Unicode}, padded by appending zero bytes; or - \item the byte $\hexint{F6}$ followed by $511$ $\hexint{00}$ bytes, indicating ``no memo''; or - \item any other sequence of $\MemoByteLength$ bytes starting with a byte value $\hexint{F5}$ - or greater (which is therefore not a valid UTF-8 string), as specified in \cite{ZIP-302}. -\end{itemize} - -When the first byte value is less than $\hexint{F5}$, wallet software is expected to strip any -trailing zero bytes and then display the resulting \mbox{UTF-8} string to the recipient user, -where applicable. Incorrect UTF-8-encoded byte sequences \SHOULD be displayed as replacement -characters (\ReplacementCharacter). - -In other cases, the contents of the \memo \SHOULDNOT be displayed unless otherwise specified -by \cite{ZIP-302}. +The usage of the \memo is by agreement between the sender and recipient of the \note. +Non-consensus constraints on the \memo contents are specified in \cite{ZIP-302}. Other fields are as defined in \crossref{notes}. @@ -13569,6 +13554,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. + \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). \item Remove magenta highlighting of differences from \Zerocash. \end{itemize} From 218196f8dd905934386572528aacbde8f9dde93e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 23 Mar 2021 19:27:47 +0000 Subject: [PATCH 08/41] Output ciphertext -> outgoing ciphertext. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 82b26368..97bd633a 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -1084,8 +1084,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\noteCiphertextOrchard}{\termandindex{transmitted note ciphertext}{transmitted note ciphertext (Orchard)}} \newcommand{\noteCiphertextsOrchard}{\termandindex{transmitted note ciphertexts}{transmitted note ciphertext (Orchard)}} \newcommand{\noteOrNotesCiphertext}{\termnoindex{transmitted note(s) ciphertext}} -\newcommand{\outputCiphertext}{\term{Output ciphertext}} -\newcommand{\outputCiphertexts}{\terms{Output ciphertext}} +\newcommand{\outgoingCiphertext}{\term{outgoing ciphertext}} +\newcommand{\outgoingCiphertexts}{\terms{outgoing ciphertext}} \newcommand{\incrementalMerkleTree}{\term{incremental Merkle tree}} \newcommand{\merkleRoot}{\termandindex{root}{root (of a Merkle tree)}} \newcommand{\merkleNode}{\termandindex{node}{node (of a Merkle tree)}} @@ -6976,7 +6976,7 @@ $\NotePlaintext{}$ is encoded as defined in \crossref{notept}. Let $\cv$ be the \valueCommitment for the new \note, and let $\cm$ be the \noteCommitment. (These are needed to derive the \defining{\outgoingCipherKey} $\OutCipherKey$ in order to produce the -\defining{\outputCiphertext} $\OutCiphertext$.) +\defining{\outgoingCiphertext} $\OutCiphertext$.) \introlist \vspace{1ex} @@ -8496,7 +8496,7 @@ corresponding to $t$. \introlist \vspace{2ex} $\PRFock{Sapling}{}$ is used in \crossref{saplingencrypt} to derive the -\outgoingCipherKey $\OutCipherKey$ used to encrypt an \outputCiphertext. +\outgoingCipherKey $\OutCipherKey$ used to encrypt an \outgoingCiphertext. It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in \crossref{concreteblake2}: @@ -8551,7 +8551,7 @@ $\SubgroupReprJ$ is defined in \crossref{jubjub}. \introlist \vspace{2ex} $\PRFock{Orchard}{}$ is used in \crossref{orchardencrypt} to derive the -\outgoingCipherKey $\OutCipherKey$ used to encrypt an \outputCiphertext. +\outgoingCipherKey $\OutCipherKey$ used to encrypt an \outgoingCiphertext. It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in \crossref{concreteblake2}: @@ -14495,7 +14495,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Specify $\RedDSA$ and $\RedJubjub$. \item Specify \saplingBindingSignatures and \spendAuthSignatures. \item Specify the randomness beacon. - \item Add \outputCiphertexts and $\OutCipherKey$. + \item Add \outgoingCiphertexts and $\OutCipherKey$. \item Define $\DefaultDiversifier$. \item Change the \spendCircuit and \outputCircuit specifications to remove unintended differences from sapling-crypto. From 44c45004dfc96fa0905259436a45721a65c1a903 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 23 Mar 2021 20:01:13 +0000 Subject: [PATCH 09/41] Cosmetics and trivial changes. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 367 ++++++++++++++++++++++++++---------------- 1 file changed, 231 insertions(+), 136 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 97bd633a..25916ada 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -171,7 +171,7 @@ \renewcommand{\cftsubsubsecpagefont}{\pagenumfont} \renewcommand{\cftparapagefont}{\pagenumfont} -\hfuzz=4pt +\hfuzz=3.5pt \vfuzz=2pt \overfullrule=2cm @@ -2332,7 +2332,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\blossomonward}[1]{\blossom{[\Blossom onward]\, {#1}}} \newcommand{\presapling}[1]{\sapling{[Pre-\Sapling\!]\,} {#1}} \newcommand{\saplingonward}[1]{\sapling{[\Sapling onward]\, {#1}}} -\newcommand{\saplingandblossom}[1]{\sapling{[\Sapling and \Blossom only, \heartwood{pre-\Heartwood}]\,} {#1}} +\newcommand{\saplingandblossom}[1]{\sapling{[\Sapling and \Blossom only, \heartwood{pre-\Heartwood}]\, {#1}}} \newcommand{\preoverwinter}[1]{\overwinter{[Pre-\Overwinter\!]\,} {#1}} \newcommand{\overwinteronly}[1]{\overwinter{[\Overwinter only, \sapling{pre-\Sapling}]\, {#1}}} \newcommand{\overwinteronward}[1]{\overwinter{[\Overwinter onward]\, {#1}}} @@ -3353,7 +3353,7 @@ Interstitial \treestates are necessary because when a \transaction is constructe it is not known where it will eventually appear in a mined \block. Therefore the \anchors that it uses must be independent of its eventual position. -\vspace{-3ex} +\vspace{-1ex} \begin{consensusrules} \item The input and output values of each \joinSplitTransfer \MUST balance exactly. @@ -3830,7 +3830,7 @@ be the agreement function. \begin{securityrequirements} \item $\KAFormatPrivate{}$ must preserve sufficient entropy from its input to be used - as a secure $\KA{}$ \privateKey. + as a secure $\KA{}$ \privateKey\!\!. \item The key agreement and the KDF defined in the next section must together satisfy a suitable adaptive security assumption along the lines of \cite[section 3]{Bernstein2006} or \cite[Definition 3]{ABR1999}. @@ -4715,6 +4715,7 @@ For a random \spendingKey, $\DefaultDiversifier$ returns $\bot$ with probability if this happens, discard the key and repeat with a different $\SpendingKey$. \begin{pnotes} + \vspace{-0.5ex} \item The protocol does not prevent using the \diversifier $\Diversifier$ to produce \quotedtermnoindex{vanity} addresses that start with a meaningful string when encoded in \Bech (see \crossref{saplingpaymentaddrencoding}). @@ -4722,6 +4723,7 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. this provides weaker privacy properties than a randomly chosen \diversifier, since a vanity address can obviously be distinguished, and might leak more information than intended as to who created it. + \vspace{-0.5ex} \item Similarly, address generators \MAY encode information in the \diversifier that can be recovered by the recipient of a payment to determine which \diversifiedPaymentAddress was used. It is \RECOMMENDED that such \diversifiers @@ -4735,7 +4737,7 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. $2^{\PRFOutputLengthExpand}$ is large compared to $\ParamJ{r}$. Define $f \typecolon \SpendingKeyType \times \PRFInputExpand \rightarrow \GF{\ParamJ{r}}$ by - $f_{\sk}(t) := \ToScalar{Sapling}(\PRFexpand{\SpendingKey}(t))$. + $f_{\sk}(t) := \ToScalar{Sapling}\big(\PRFexpand{\SpendingKey}(t)\kern-0.1em\big)$. $f$ is also a \xPRF since $\LEOStoIP{\PRFOutputLengthExpand} \typecolon \PRFOutputExpand \rightarrow \binaryrange{\PRFOutputLengthExpand}$ @@ -4745,8 +4747,9 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. i.e.\ $\PRFexpand{\SpendingKey}([0]) : \SpendingKey \leftarrowR \SpendingKeyType$, is computationally indistinguishable from $\SpendAuthSigGenPrivate{Sapling}()$ defined in \crossref{concretespendauthsig}. + \vspace{-0.5ex} \item The distribution of $\AuthProvePrivate$, i.e.\ - $\ToScalar{Sapling}(\PRFexpand{\SpendingKey}([1])) : \SpendingKey \leftarrowR \SpendingKeyType$, + $\ToScalar{Sapling}\big(\PRFexpand{\SpendingKey}([1])\kern-0.1em\big) : \SpendingKey \leftarrowR \SpendingKeyType$, is computationally indistinguishable from the uniform distribution on $\GF{\ParamJ{r}}$. Since $\fun{\AuthProvePrivate \typecolon \GF{\ParamJ{r}}^{\vphantom{X}}} {\reprJ\big(\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}} \typecolon \SubgroupReprJ\big)$ @@ -4771,30 +4774,38 @@ Let $\GroupP$, $\GroupPx$, $\reprP$, $\ellP$, $\ParamP{q}$, and $\ParamP{r}$ be Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}. +\vspace{-0.25ex} Let $\GroupPHash$ be as defined in \crossref{concretegrouphashpallasandvesta}. -Let $\PRFexpand{}$ and $\PRFock{Orchard}{}$, instantiated in \crossref{concreteprfs}, -be \pseudoRandomFunctions. +\vspace{-0.25ex} +Let $\PRFexpand{}$ and $\PRFock{Orchard}{}$ be as defined in \crossref{concreteprfs}. +\vspace{-0.25ex} Let $\PRPd{} \typecolon \DiversifierKeyType \times \DiversifierType \rightarrow \DiversifierType$ be as defined in \crossref{concreteprps}. +\vspace{-0.25ex} Let $\KA{Orchard}$, instantiated in \crossref{concreteorchardkeyagreement}, be a \keyAgreementScheme. +\vspace{-0.25ex} Let $\CommitIvk{}$, instantiated in \crossref{concretesinsemillacommit}, be a \commitmentScheme. -Let $\DiversifyHash{Orchard}$, instantiated in \crossref{concretediversifyhash}, -be a \hashFunction. +\vspace{-0.25ex} +Let $\DiversifyHash{Orchard}$ be as defined in \crossref{concretediversifyhash}. +\vspace{-0.25ex} Let $\SpendAuthSig{Orchard}$ instantiated in \crossref{concretespendauthsig} be a \rerandomizableSignatureScheme. Let $\ItoLEBSP{}$, $\ItoLEOSP{}$, and $\LEOStoIP{}$ be as defined in \crossref{endian}. +\vspace{0.5ex} +\introlist Define $\ToBase{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{q}}$. +\vspace{-0.25ex} Define $\ToScalar{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{r}}$. \introlist @@ -4821,6 +4832,7 @@ as follows: \item let $\AuthSignPublic = \ExtractP(\AuthSignPublicPoint)$ \item let $\InViewingKey = \CommitIvk{\CommitIvkRand}\big(\AuthSignPublic, \NullifierKey\big)$ \item let $K = \ItoLEBSPOf{\SpendingKeyLength}{\CommitIvkRand}$ + \vspace{-0.2ex} \item let $R = \PRFexpand{K}\big([\hexint{82}] \bconcat \ItoLEOSPOf{256}{\AuthSignPublic} \bconcat \ItoLEOSPOf{256}{\NullifierKey}\kern-0.25em\big)$ \item let $\DiversifierKey$ be the first $\DiversifierKeyLength/8$ bytes of $R$ and let $\OutViewingKey$ be the remaining $\OutViewingKeyLength/8$ bytes of $R$. @@ -4851,6 +4863,7 @@ $(\Diversifier \typecolon \DiversifierType, \DiversifiedTransmitPublic \typecolo For each \spendingKey, there is also a \defining{\defaultDiversifiedPaymentAddress} with a ``random-looking'' \diversifier, which is derived as specified in \cite{ZIP-32}. +\vspace{1ex} \begin{pnotes} \item The protocol does not prevent using the \diversifier $\Diversifier$ to produce \quotedtermnoindex{vanity} addresses that start with a meaningful string when @@ -5036,14 +5049,19 @@ There are no signatures associated with \outputDescriptions. Let $\MerkleHashLength{Sapling}$ be as defined in \crossref{constants}. +\vspace{-0.25ex} Let $\ZeroJ$, $\abstJ$, $\reprJ$, and $\ParamJ{h}$ be as defined in \crossref{jubjub}. +\vspace{-0.5ex} Let $\ValueCommitOutput{Sapling}$ be as defined in \crossref{abstractcommit}. +\vspace{-0.5ex} Let $\KA{Sapling}$ be as defined in \crossref{abstractkeyagreement}. +\vspace{-0.25ex} Let $\Sym$ be as defined in \crossref{abstractsym}. +\vspace{-0.25ex} Let $\Output$ be as defined in \crossref{abstractzk}. \vspace{1ex} @@ -5051,18 +5069,23 @@ Let $\Output$ be as defined in \crossref{abstractzk}. An \outputDescription comprises $(\cv, \cmU, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \ProofOutput)$ where \begin{itemize} + \vspace{-0.25ex} \item $\cv \typecolon \ValueCommitOutput{Sapling}$ is the \valueCommitment to the value of the output \note; - \vspace{-0.5ex} + \vspace{-0.75ex} \item $\cmU \typecolon \MerkleHash{Sapling}$ is the result of applying $\ExtractJ$ (defined in \crossref{concreteextractorjubjub}) to the \noteCommitment for the output \note; + \vspace{-0.5ex} \item $\EphemeralPublic \typecolon \KAPublic{Sapling}$ is a key agreement \publicKey, used to derive the key for encryption of the \noteCiphertextSapling (\crossref{saplinginband}); + \vspace{-0.25ex} \item $\TransmitCiphertext{} \typecolon \Ciphertext$ is a ciphertext component for the encrypted output \note; + \vspace{-0.25ex} \item $\OutCiphertext{} \typecolon \Ciphertext$ is a ciphertext component that allows the holder of a \fullViewingKey to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey $\EphemeralPrivate$ (and therefore the entire \notePlaintext); + \vspace{-0.25ex} \item $\ProofOutput \typecolon \OutputProof$ is a \zkSNARKProof with \primaryInput $(\cv, \cmU, \EphemeralPublic)$ for the \outputStatement defined in \crossref{outputstatement}. \end{itemize} @@ -5070,14 +5093,16 @@ where \vspace{-1ex} \begin{consensusrules} \item Elements of an \outputDescription \MUST be valid encodings of the types given above. + \vspace{-0.25ex} \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\EphemeralPublic}$ \MUSTNOT be $\ZeroJ$. + \vspace{-0.25ex} \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed from the other fields except $\TransmitCiphertext{}$ and $\OutCiphertext{}$ --- i.e.\ $\SpendVerify{}\big(\kern-0.1em(\cv, \cmU, \EphemeralPublic), \Proof{\Output}\big) = 1$. \end{consensusrules} -\vspace{-2ex} +\vspace{-2.5ex} \nnote{The rule that $\cv$ and $\EphemeralPublic$ \MUST not be small-order, has the effect of also preventing non-canonical encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and @@ -5086,6 +5111,7 @@ $\reprJ\Of{\abstJ\Of{\EphemeralPublic}\kern0.05em} = \EphemeralPublic$.} \nufive{ +\vspace{-1ex} \lsubsection{Action Descriptions}{actiondesc} An \actionTransfer, as specified in \crossref{actions}, is encoded in \transactions as an @@ -5098,18 +5124,25 @@ Each \actionDescription is authorized by a signature, called the \defining{\spen Let $\MerkleHashLength{Orchard}$ be as defined in \crossref{constants}. +\vspace{-0.25ex} Let $\GroupPx$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. +\vspace{-0.25ex} Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}. +\vspace{-0.25ex} Let $\ValueCommitOutput{Orchard}$ be as defined in \crossref{abstractcommit}. +\vspace{-0.5ex} Let $\SpendAuthSig{Orchard}$ be as defined in \crossref{spendauthsig}. +\vspace{-0.5ex} Let $\KA{Orchard}$ be as defined in \crossref{abstractkeyagreement}. +\vspace{-0.25ex} Let $\Sym$ be as defined in \crossref{abstractsym}. +\vspace{-0.25ex} Let $\Action$ be as defined in \crossref{abstractzk}. \vspace{1ex} @@ -5117,24 +5150,30 @@ Let $\Action$ be as defined in \crossref{abstractzk}. An \actionDescription comprises $(\cvNet, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \spendAuthSig, \cmX, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \enableSpend, \enableOutput, \Proof{})$ where -\vspace{1ex} \begin{itemize} \item $\cvNet \typecolon \ValueCommitOutput{Orchard}$ is the \valueCommitment to the value of the input \note minus the value of the output \note; + \vspace{-0.5ex} \item $\rt{Orchard} \typecolon \MerkleHash{Orchard}$ is an \anchor, as defined in \crossref{blockchain}, for the output \treestate of a previous \block; \item $\nf \typecolon \PRFOutputNfOrchard$ is the \nullifier for the input \note; + \vspace{-0.25ex} \item $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard}$ is a randomized \validatingKey that should be used to validate $\spendAuthSig$; + \vspace{-0.25ex} \item $\spendAuthSig \typecolon \SpendAuthSigSignature{Orchard}$ is a \spendAuthSignature, validated as specified in \crossref{spendauthsig}; + \vspace{-0.25ex} \item $\cmX \typecolon \GroupPx$ is the result of applying $\ExtractP$ to the \noteCommitment for the output \note; + \vspace{-0.25ex} \item $\EphemeralPublic \typecolon \KAPublic{Orchard}$ is a key agreement \publicKey, used to derive the key for encryption of the \noteCiphertextOrchard (\crossref{saplinginband}); + \vspace{-0.25ex} \item $\TransmitCiphertext{} \typecolon \Ciphertext$ is a ciphertext component for the encrypted output \note; + \vspace{-0.25ex} \item $\OutCiphertext{} \typecolon \Ciphertext$ is a ciphertext component that allows the holder of a \fullViewingKey to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey $\EphemeralPrivate$ (and therefore the entire \notePlaintext); @@ -5142,19 +5181,24 @@ where spends in this Action; \item $\enableOutput \typecolon \bit$ is a flag that is set in order to enable non-zero-valued outputs in this Action; + \vspace{-0.25ex} \item $\Proof{} \typecolon \ActionProof$ is a \zkSNARKProof with \primaryInput $(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend,$ $\enableOutput)$ for the \actionStatement defined in \crossref{actionstatement}. \end{itemize} +\vspace{-1ex} \pnote{The $\rt{Orchard}$, $\enableSpend$, and $\enableOutput$ components are the same for all \actionTransfers in a \transaction. They are encoded once in the \transaction body (specified in \crossref{txnencodingandconsensus}), not in the $\type{ActionDescription}$ structure. $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrchard$ field of a \transaction.} +\vspace{-0.5ex} \begin{consensusrules} + \vspace{-0.25ex} \item Elements of an \actionDescription \MUST be canonical encodings of the types given above. + \vspace{-0.25ex} \item Let $\SigHash$ be the \sighashTxHash of this \transaction, not associated with an input, as defined in \crossref{sighash} using $\SIGHASHALL$. @@ -5163,6 +5207,7 @@ $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrc i.e.\ $\SpendAuthSigValidate{Orchard}{\AuthSignRandomizedPublic}(\SigHash, \spendAuthSig) = 1$. As specified in \crossref{concretereddsa}, validation of the $\RedDSAReprR{}$ component of the signature prohibits \nonCanonicalPoint encodings. + \vspace{-0.25ex} \item The proof $\Proof{\Action}$ \MUST be valid given a \primaryInput $(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend, \enableOutput)$ --- i.e.\ $\ActionVerify\big(\kern-0.1em(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend, \enableOutput), \Proof{\Action}\big) = 1$. @@ -5315,7 +5360,7 @@ performs the following steps: \item \tab Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$. \item \tab Derive $\EphemeralPrivate = \ToScalar{Sapling}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$. \item \tab Derive $\NoteCommitRand = \ToScalar{Sapling}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$. - \item \vspace{-2ex} + \item \blank } \item Let $\cv = \ValueCommit{Sapling}{\ValueCommitRand}(\Value)$. \item Let $\cm = \NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase}, @@ -5355,7 +5400,7 @@ output-related fields of an \actionDescription. \vspace{1ex} Let $\ValueCommitAlg{Orchard}$ and $\NoteCommitAlg{Orchard}$ be as specified in \crossref{abstractcommit}. -Let $\PRFexpand{Orchard}{}$ be as specified in \crossref{abstractprf}. +Let $\PRFexpand{}$ be as specified in \crossref{abstractprfs}. Let $\KA{Orchard}$ be as specified in \crossref{abstractkeyagreement}. @@ -5384,6 +5429,7 @@ and then performs the following steps: \MUST be a valid \swCurve point on the \pallasCurve (as defined in \crossref{pallasandvesta}). \item Calculate $\DiversifiedTransmitBase = \DiversifyHash{Orchard}(\Diversifier)$. \item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Orchard}()$. + \vspace{-0.25ex} \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$. \item Derive $\EphemeralPrivate = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$. \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$. @@ -5393,9 +5439,9 @@ and then performs the following steps: \item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, \Value, \NoteUniqueRand, \NoteNullifierRand)$. - \vspace{0.5ex} + \vspace{0.25ex} \item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteSeedBytes, \Memo)$. - \vspace{0.5ex} + \vspace{0.25ex} \item Encrypt $\NotePlaintext{}$ to the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ with \diversifiedBase $\DiversifiedTransmitBase$, and to the @@ -5404,15 +5450,17 @@ and then performs the following steps: This procedure is described in \crossref{saplingandorchardencrypt}; it also uses $\cvField$ and $\cmxField$ to derive $\OutCipherKey$, and takes $\EphemeralPrivate$ as input. - \item For an \Orchard \note, generate a proof $\Proof{}$ for the \actionStatement in \crossref{actionstatement}. + \item Generate a proof $\Proof{}$ for the \actionStatement in \crossref{actionstatement}. \item Return $(\cv, \cm, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \Proof{})$. \end{algorithm} +\vspace{-1ex} In order to minimize information leakage, the sender \SHOULD randomize the order of \actionDescriptions in a \transaction. Other considerations relating to information leakage from the structure of \transactions are beyond the scope of this specification. The encoded \transaction is submitted to the peer-to-peer network. +\vspace{-2ex} \nnote{ The inputs $[4]$ and $[5]$ are used as inputs to $\PRFexpand{}$ in both \Sapling and \Orchard shielded protocols. Since a fresh $\NoteSeedBytes$ is generated for each \note, @@ -5422,7 +5470,6 @@ this should have no negative effect on security. \vspace{-1ex} -\introlist \lsubsection{Dummy Notes}{dummynotes} \vspace{-1ex} @@ -5570,7 +5617,7 @@ zero value, and sent to a random \shieldedPaymentAddress. } %nufive -\introsection +\introlist \lsubsection{Merkle Path Validity}{merklepath} Let $\MerkleDepth{}$ be $\MerkleDepth{Sprout}$ for the \Sprout \noteCommitmentTree\sapling{, @@ -5581,7 +5628,7 @@ These constants are defined in \crossref{constants}. Similarly, let $\MerkleCRH{}$ be $\MerkleCRH{Sprout}$ for \Sprout\sapling{, or $\MerkleCRH{Sapling}$ for \Sapling}\nufive{, or $\MerkleCRH{Orchard}$ for \Orchard}. -The following discussion applies independently to the \Sprout and \Sapling\nufive{ and \Orchard} +The following discussion applies independently to the \Sprout\sapling{ and \Sapling}\nufive{ and \Orchard} \noteCommitmentTrees. Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash, @@ -5742,7 +5789,7 @@ all of the $\AuthPrivateOld{\allOld}$ for every \joinSplitDescription in the to $\joinSplitPubKey$ to sign this \transaction. -\introsection +\introlist \lsubsection{Balance (\SproutText)}{joinsplitbalance} In \Bitcoin, all inputs to and outputs from a \transaction are transparent. @@ -5996,7 +6043,7 @@ also used in \Bulletproofs \cite{Dalek-notes}. \nufive{ -\introsection +\introlist \lsubsection{Balance and Binding Signature (\OrchardText)}{orchardbalance} \Orchard introduces \actionTransfers, each of which can optionally perform a spend, @@ -6124,11 +6171,11 @@ $\cvNet{\alln}$. We may also assume, from Knowledge Soundness of \HaloTwo, that proofs could not have been generated without knowing $\ValueCommitRandNet{\alln} \pmod{\ParamP{r}}$. \introlist -Using the fact that $\ValueCommit{Orchard}{\ValueCommitRand}(\Value) = \scalarmult{\Value}{\ValueCommitValueBase{Orchard}}\, +Using the fact $\ValueCommit{Orchard}{\ValueCommitRand}(\Value) = \scalarmult{\Value}{\ValueCommitValueBase{Orchard}}\, \combplus \scalarmult{\ValueCommitRand}{\ValueCommitRandBase{Orchard}}$, the expression for $\BindingPublic{Orchard}$ above is equivalent to: -\vspace{1ex} +\vspace{0.5ex} \begin{tabular}{@{\hskip 2em}r@{\;}l} $\BindingPublic{Orchard}$ &$= \Biggscalarmult{\Bigg(\!\vgrpsum{i=1}{n} \vNet{i}\Bigg) \grpminus \vBalance{Orchard}}{\ValueCommitValueBase{Orchard}}\, \combplus \Biggscalarmult{\Bigg(\!\vgrpsum{i=1}{n} \ValueCommitRandNet{i}\Bigg)}{\ValueCommitRandBase{Orchard}}$ \\[3.5ex] @@ -6167,7 +6214,6 @@ In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em- \Orchard \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash by signing $\SigHash$. -\vspace{1ex} \pnote{ The spender \MAY reveal any strict subset of the \Orchard \valueCommitment randomnesses to other parties that are cooperating to create the \transaction. @@ -6625,10 +6671,10 @@ Let $\ValueCommitAlg{Orchard}$, $\NoteCommitAlg{Orchard}$, and $\CommitIvkAlg$ b \vspace{-0.5ex} Let $\SpendAuthSig{Orchard}$ be as defined in \crossref{concretespendauthsig}. -\vspace{-0.5ex} +\vspace{-0.25ex} Let $\GroupP$, $\GroupPstar$, $\GroupPx$, $\reprP$, $\ParamP{q}$, and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. -\vspace{-0.5ex} +\vspace{-0.25ex} Let $\DeriveNullifierAlg$ be as defined in \crossref{commitmentsandnullifiers}. \intropart @@ -6879,7 +6925,7 @@ is defined as follows: \NoteUniqueRand_i \typecolon \PRFOutputSprout, \NoteCommitRand_i \typecolon \NoteCommitTrapdoor{Sprout}, \Memo_i \typecolon \MemoType)$ from $\TransmitPlaintext{i}$ - \vspace{-0.5ex} + \vspace{-0.2ex} \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}((\AuthPublic, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i)) \neq \cm_i$, return $\bot$, else return $\NotePlaintext{i}$. \end{formulae} @@ -6984,22 +7030,25 @@ Then to encrypt: \begin{algorithm} \vspace{-0.5ex} \item let $\TransmitPlaintext{}$ be the \rawEncoding of $\NotePlaintext{}$ + \vspace{-0.2ex} \item let $\EphemeralPublic = \KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)$ - \vspace{0.3ex} \item let $\ephemeralKey = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\EphemeralPublic}\kern 0.03em}$ \vspace{-0.5ex} \item let $\DHSecret{} = \KAAgree{}(\EphemeralPrivate, \DiversifiedTransmitPublic)$ \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$ \item let $\TransmitCiphertext{} = \SymEncrypt{\TransmitKey{}}(\TransmitPlaintext{})$ \item if $\OutViewingKey = \bot$: + \vspace{-0.25ex} \item \tab choose random $\OutCipherKey \leftarrowR \Keyspace$ and $\OutPlaintext \leftarrowR \byteseq{(\ellG{} + 256)/8}$ + \vspace{-0.25ex} \item else: + \vspace{-0.25ex} \item \tab let $\cvField = \LEBStoOSP{\ellG{}}\big(\reprG{}(\cv)\kern-0.12em\big)$ - \vspace{-0.5ex} + \vspace{-0.75ex} \item \tab let $\cmstarField = \LEBStoOSP{256}\big(\ExtractG(\cm)\kern-0.12em\big)$ - \vspace{-0.5ex} + \vspace{-1ex} \item \tab let $\OutCipherKey = \PRFock{}{\OutViewingKey}(\cvField, \cmstarField, \ephemeralKey)$ - \vspace{0.5ex} + \vspace{0.25ex} \item \tab let $\OutPlaintext = \LEBStoOSPOf{\ellG{} + 256}{\reprG{}(\DiversifiedTransmitPublic) \,\bconcat\, \ItoLEBSPOf{256}{\EphemeralPrivate}\kern-0.12em}$ \item \blank \item let $\OutCiphertext = \SymEncrypt{\OutCipherKey}(\OutPlaintext)$ @@ -7007,6 +7056,7 @@ Then to encrypt: The resulting \defining{\noteCiphertextSapling} is $(\ephemeralKey, \TransmitCiphertext{}, \OutCiphertext)$. +\introlist \pnote{ It is technically possible to replace $\TransmitCiphertext{}$ for a given \note with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band @@ -7020,19 +7070,22 @@ received out-of-band, which are not addressed in this document. \sapling{ +\vspace{-2ex} \extralabel{saplingdecryptivk}{\lsubsubsection{Decryption using an Incoming Viewing Key (\SaplingAndOrchardText)}{decryptivk}} \vspace{-1ex} Let $\InViewingKey \typecolon \InViewingKeyTypeSapling$\notbeforenufive{ (in \Sapling)\nufive{ or -$\InViewingKeyTypeOrchard$ (in \Orchard)}} be the recipient's \incomingViewingKey, as specified in +$\InViewingKeyTypeOrchard$ (in \Orchard)}} be the recipient's \incomingViewingKey, specified in \crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}. +\vspace{-0.25ex} Let $(\ephemeralKey, \TransmitCiphertext{}, \OutCiphertext)$ be the \noteCiphertext from the \outputDescription{}. Let $\cmstarField$ be the $\cmuField$\nufive{ or $\cmxField$} field of the \outputDescription\nufive{ or \actionDescription respectively}. (This encodes the $u$-coordinate\nufive{ or $x$-coordinate} of the \noteCommitment, i.e.\ $\ExtractG(\cm)$.) \canopy{ +\vspace{-0.25ex} Let the constant $\CanopyActivationHeight$ be as defined in \crossref{constants}. Let $\BlockHeight$ be the \blockHeight of the \block containing this \transaction. @@ -7040,17 +7093,19 @@ Let $\BlockHeight$ be the \blockHeight of the \block containing this \transactio \introlist The recipient will attempt to decrypt the $\ephemeralKey$ and $\TransmitCiphertext{}$ -components of the \noteCiphertext as follows: +components of the \noteCiphertext: \begin{algorithm} -\vspace{-0.5ex} + \vspace{-0.5ex} \item let $\EphemeralPublic = \abstG{}\Of{\ephemeralKey}$ + \vspace{-0.2ex} \item if $\EphemeralPublic = \bot$, return $\bot$ + \vspace{-0.2ex} \item let $\DHSecret{} = \KAAgree{}(\InViewingKey, \EphemeralPublic)$ \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$ \item let $\TransmitPlaintext{} = \SymDecrypt{\TransmitKey{}}(\TransmitCiphertext{})$ -\vspace{-0.25ex} + \vspace{-0.4ex} \item if $\TransmitPlaintext{} = \bot$, return $\bot$ -\vspace{-0.25ex} + \vspace{-0.5ex} \item extract $\NotePlaintext{} = (\NotePlaintextLeadByte \typecolon \byte, \Diversifier \typecolon \DiversifierType, \Value \typecolon \ValueType, \NoteCommitRandBytesOrSeedBytes \typecolon \NoteSeedBytesType, \Memo \typecolon \MemoType)$ from $\TransmitPlaintext{}$ @@ -7058,7 +7113,7 @@ from $\TransmitPlaintext{}$ \precanopyitem{let $\NoteCommitRandBytes = \NoteSeedBytes$} \canopyonwarditem{if $\BlockHeight < \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \not\in \setof{\hexint{01}, \hexint{02}}$, return $\bot$} \canopyonwarditem{if $\BlockHeight \geq \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \neq \hexint{02}$, return $\bot$} -\vspace{-0.5ex} + \vspace{-0.5ex} \canopyonwarditem{let $\NoteCommitRandBytes = \begin{cases} \NoteSeedBytes,&\caseif \NotePlaintextLeadByte = \hexint{01} \\ \ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big),&\caseotherwise @@ -7074,14 +7129,15 @@ from $\TransmitPlaintext{}$ \item \blank } %canopy \item let $\DiversifiedTransmitPublic = \KADerivePublic{}(\InViewingKey, \DiversifiedTransmitBase)$ -\vspace{-0.25ex} + \vspace{-0.25ex} \item \notbeforenufive{for \Sapling,} let $\cmstar' = \ExtractJ{}\big(\NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase}, \reprJ\Of{\DiversifiedTransmitPublic}, \Value)\kern-0.1em\big)$. \nufive{ \item for \Orchard: - \item \tab let $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$ -\vspace{-0.25ex} + \vspace{-0.25ex} + \item \tab let $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.1em\big)$ + \vspace{-0.5ex} \item \tab let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. \item \tab let $\cmstar' = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, @@ -7097,16 +7153,18 @@ from $\TransmitPlaintext{}$ \vspace{-1ex} \begin{pnotes} + \vspace{-0.5ex} \item For \Sapling, 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 $\KDF{Sapling}$\canopy{, and (if \Canopy is active and $\NotePlaintextLeadByte \neq \hexint{01}$) in the comparison against $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.1em\big)$}. \nufive{For consistency this is also what is specified for \Orchard.} + \introlist \vspace{-0.25ex} \item Normally only \noteCiphertextsSapling of \transactions in \blocks need to be decrypted. In that case, - any received \Sapling \note is necessarily a \positionedNote, and so its $\NoteUniqueRand$ - value can immediately be calculated as described in \crossref{commitmentsandnullifiers}. + any received \Sapling \note is necessarily a \positionedNote, so its $\NoteUniqueRand$ + value can immediately be calculated as in \crossref{commitmentsandnullifiers}. To test whether a \SaplingOrOrchard \note is unspent in a particular \blockChain also requires the \nullifierDerivingKey $\NullifierKey$; the coin is unspent if and only if the \nullifier computed as described in \crossref{commitmentsandnullifiers} is not in the \nullifierSet for @@ -7124,37 +7182,42 @@ from $\TransmitPlaintext{}$ } %sapling \sapling{ +\vspace{-3ex} \extralabel{saplingdecryptovk}{\lsubsubsection{Decryption using a Full Viewing Key (\SaplingAndOrchardText)}{decryptovk}} +\vspace{-2ex} Let $\OutViewingKey \typecolon \OutViewingKeyType$ be the \outgoingViewingKey, as specified in \crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}, that is to be used for decryption. (If $\OutViewingKey = \bot$ was used for encryption, the payment is not decryptable by this method.) +\vspace{-0.75ex} Let $(\ephemeralKey, \TransmitCiphertext{}, \OutCiphertext)$ be the \noteCiphertext. +\vspace{-0.5ex} For a \Sapling \noteCiphertextSapling, let $\cvField$ and $\cmstarField$ be the $\cvField$ and $\cmuField$ -fields of the \outputDescription (encoding the \valueCommitment and the $u$-coordinate of the -\noteCommitment). +fields of the \outputDescription. \nufive{ +\vspace{-0.25ex} For an \Orchard \noteCiphertextOrchard, let $\cvField$ and $\cmstarField$ be the $\cvField$ and $\cmxField$ -fields of the \actionDescription (encoding the \valueCommitment and the $x$-coordinate of the -\noteCommitment). +fields of the \actionDescription. } %nufive \introsection -\vspace{0.5ex} +\vspace{0.25ex} The \outgoingViewingKey holder will attempt to decrypt the \noteCiphertext as follows: \introlist -\vspace{-0.5ex} +\vspace{-1.25ex} \begin{algorithm} \item let $\OutCipherKey = \PRFock{}{\OutViewingKey}(\cvField, \cmstarField, \ephemeralKey)$ + \vspace{-0.2ex} \item let $\OutPlaintext = \SymDecrypt{\OutCipherKey}(\OutCiphertext)$ + \vspace{-0.5ex} \item if $\OutPlaintext = \bot$, return $\bot$ -\vspace{-0.25ex} + \vspace{-0.5ex} \item extract $(\DiversifiedTransmitPublicRepr \typecolon \ReprG{}, \EphemeralPrivateBytes \typecolon \EphemeralPrivateBytesType)$ from $\OutPlaintext$ \item let $\EphemeralPrivate = \LEOStoIPOf{256}{\EphemeralPrivateBytes}$ @@ -7164,8 +7227,9 @@ The \outgoingViewingKey holder will attempt to decrypt the \noteCiphertext as fo \item let $\DHSecret{} = \KAAgree{}(\EphemeralPrivate, \DiversifiedTransmitPublic)$ \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$ \item let $\TransmitPlaintext{} = \SymDecrypt{\TransmitKey{}}(\TransmitCiphertext{})$ -\vspace{-0.25ex} + \vspace{-0.5ex} \item if $\TransmitPlaintext{} = \bot$, return $\bot$ + \vspace{-0.5ex} \item extract $\NotePlaintext{} = (\NotePlaintextLeadByte \typecolon \byte, \Diversifier \typecolon \DiversifierType, \Value \typecolon \ValueType, \NoteCommitRandBytesOrSeedBytes \typecolon \NoteSeedBytesType, \Memo \typecolon \MemoType)$ from $\TransmitPlaintext{}$ @@ -7173,14 +7237,16 @@ from $\TransmitPlaintext{}$ \precanopyitem{let $\NoteCommitRandBytes = \NoteSeedBytes$} \canopyonwarditem{if $\BlockHeight < \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \not\in \setof{\hexint{01}, \hexint{02}}$, return $\bot$} \canopyonwarditem{if $\BlockHeight \geq \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \neq \hexint{02}$, return $\bot$} -\vspace{-0.25ex} + \vspace{-0.25ex} \canopyonwarditem{if $\NotePlaintextLeadByte \neq \hexint{01}$ and $\ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.11em\big) \neq \EphemeralPrivate$, return $\bot$} + \vspace{-0.25ex} \canopyonwarditem{let $\NoteCommitRandBytes = \begin{cases} \NoteSeedBytes,&\caseif \NotePlaintextLeadByte = \hexint{01} \\ \ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big),&\caseotherwise \end{cases}$} \item let $\NoteCommitRand = \LEOStoIPOf{256}{\NoteCommitRandBytes}$ and $\DiversifiedTransmitBase = \DiversifyHash{}(\Diversifier)$ + \vspace{-0.5ex} \item if $\NoteCommitRand \geq \ParamG{r}$, return $\bot$ \notbeforenufive{ \item for \Sapling: @@ -7191,32 +7257,41 @@ from $\TransmitPlaintext{}$ \Value)\kern-0.1em\big)$. \nufive{ \item for \Orchard: - \item \tab let $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$ + \vspace{-0.25ex} + \item \tab let $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.1em\big)$ + \vspace{-0.6ex} \item \tab let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. \item \tab let $\cmstar' = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, \Value, \NoteUniqueRand, \NoteNullifierRand)\kern-0.1em\big)$ - \item \blank + \item \vspace{-3.5ex} } %nufive \item if $\LEBStoOSPOf{256}{\cmstar'} \neq \cmstarField$, return $\bot$ + \vspace{-0.75ex} \item if $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big) \neq \ephemeralKey$, return $\bot$ + \vspace{-0.2ex} \item return $\NotePlaintext{}$. \end{algorithm} +\vspace{-2ex} \begin{pnotes} + \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 $\reprJ\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$. - \nufive{For consistency this is also what is specified for \Orchard.} + and in the comparison against + $\reprJ\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$.\!\!\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 $\DiversifiedTransmitPublicRepr$ of a \Sapling \note is $\ItoLEBSP{256}\big(2^{255} + 1\big)$.} + \vspace{-0.25ex} \nufiveonwarditem{This procedure returns $\bot$ if $\DiversifiedTransmitPublicRepr$ is \nonCanonicalPoint (which can only occur for \Sapling \notes), as specified in \cite{ZIP-216}.} + \vspace{-0.25ex} \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 $\SubgroupJ$ (i.e.\ the condition ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJ$, return $\bot$``). That did not match the @@ -7227,56 +7302,62 @@ from $\TransmitPlaintext{}$ \notes decrypted by this procedure. \end{pnotes} -\vspace{-2ex} -\nnote{Implementors should pay close attention to the similarities and differences between this procedure -and that in \crossref{decryptivk}. \canopy{In particular: -\vspace{1ex} +\vspace{-2.5ex} +\nnote{Implementors should pay close attention to similarities and differences between this procedure +and \crossref{decryptivk}. \canopy{In particular:\!\! \begin{itemize} \item in this procedure, the ephemeral \privateKey $\EphemeralPrivate'$ derived from $\NoteSeedBytes$ is checked to be identical to that obtained from $\OutPlaintext$ (when $\NotePlaintextLeadByte \neq \hexint{01}$); + \vspace{-0.25ex} \item in this procedure, $\DiversifiedTransmitPublic$ is obtained from $\OutPlaintext$ rather than being derived as $\KADerivePublic{Sapling}(\InViewingKey, \DiversifiedTransmitBase)$; + \vspace{-0.25ex} \item in this procedure, the check that $\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase) = \EphemeralPublic$ is unconditional rather than being dependent on $\NotePlaintextLeadByte \neq \hexint{01}$, and it uses the $\EphemeralPrivate$ obtained from $\OutPlaintext$. \end{itemize} } %canopy } %nnote - } %sapling +\vspace{-2ex} \lsubsection{Block Chain Scanning (\SproutText)}{sproutscan} +\vspace{-1ex} Let $\PRFOutputLengthSprout$ be as defined in \crossref{constants}. +\vspace{-0.25ex} Let $\NoteType{Sprout}$ be as defined in \crossref{notes}. +\vspace{-0.25ex} Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}. -\vspace{1ex} -\introsection -The following algorithm can be used, given the \blockChain and a -\Sprout \spendingKey $\AuthPrivate$, to obtain each \note sent -to the corresponding \shieldedPaymentAddress, its \memo field, and its final status -(spent or unspent). - -\vspace{1ex} +\vspace{0.25ex} Let $\InViewingKey = (\AuthPublic \typecolon \PRFOutputSprout, \TransmitPrivate \typecolon \KAPrivate{Sprout})$ be the \incomingViewingKey corresponding to $\AuthPrivate$, and let $\TransmitPublic$ be the associated \transmissionKey, as specified in \crossref{sproutkeycomponents}. -\vspace{1ex} +\introsection +The following algorithm can be used, given the \blockChain and a \Sprout \spendingKey $\AuthPrivate$, +to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \memo, and its final status +(spent or unspent). + \begin{algorithm} + \vspace{-0.5ex} \item let mutable $\ReceivedSet \typecolon \powerset{\NoteType{Sprout} \times \MemoType} \leftarrow \setof{}$ + \vspace{-0.5ex} \item let mutable $\SpentSet \typecolon \powerset{\NoteType{Sprout}} \leftarrow \setof{}$ + \vspace{-1ex} \item let mutable $\NullifierMap \typecolon \PRFOutputSprout \rightarrow \NoteType{Sprout} \leftarrow$ the empty mapping - \vspace{1ex} + \vspace{0.5ex} \item for each \transaction $\tx$: + \vspace{-0.25ex} \item \tab for each \joinSplitDescription in $\tx$: \item \tab \tab let $(\EphemeralPublic, \TransmitCiphertext{\allNew})$ be the \notesCiphertextSprout of the \joinSplitDescription \item \tab \tab for $i$ in $\allNew$: + \vspace{-0.5ex} \item \tab \tab \tab Attempt to decrypt the \notesCiphertextSprout component $(\EphemeralPublic, \TransmitCiphertext{i})$ using $\InViewingKey$ with the \vspace{-1.2ex} @@ -7288,7 +7369,7 @@ be the \incomingViewingKey corresponding to $\AuthPrivate$, and let $\TransmitPu \item \tab \tab \tab \tab Calculate the nullifier $\nf$ of $\NoteTuple{}$ using $\AuthPrivate$ as described in \crossref{notes}. \item \tab \tab \tab \tab Add the mapping $\nf \rightarrow \NoteTuple{}$ to $\NullifierMap$. - \item \blank + \item \vspace{-3.5ex} \item \tab \tab let $\nf_{\allOld}$ be the \nullifiers of the \joinSplitDescription \item \tab \tab for $i$ in $\allOld$: \item \tab \tab \tab if $\nf_i$ is present in $\NullifierMap$, add $\NullifierMap(\nf_i)$ @@ -7323,11 +7404,11 @@ $(\NullifierKey \typecolon \SubgroupJ, \InViewingKey \typecolon \InViewingKeyTyp to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \memo field, and its final status (spent or unspent). -\vspace{1ex} \begin{algorithm} \item let mutable $\ReceivedSet \typecolon \powerset{\NoteType{Sapling} \times \MemoType} \leftarrow \setof{}$ \item let mutable $\SpentSet \typecolon \powerset{\NoteType{Sapling}} \leftarrow \setof{}$ \item let mutable $\NullifierMap \typecolon \PRFOutputNfSapling \rightarrow \NoteType{Sapling} \leftarrow$ the empty mapping + \vspace{0.2ex} \vspace{1ex} \item for each \transaction $\tx$: \item \tab for each \outputDescription in $\tx$ with \notePosition $\NotePosition$: @@ -7424,7 +7505,7 @@ concatenating these bit sequences, and then treating each subsequence of 8 bits as a byte with the bits ordered from \emph{most significant} to \emph{least significant}. Thus the \emph{most significant} bit in each byte is toward the left of a diagram. \sapling{(This convention is used only in -descriptions of the $\Sprout$ design; in the $\SaplingAndOrchard$ additions, +descriptions of the $\Sprout$ design; in the \SaplingAndOrchard additions, bit/byte sequence conversions are always specified explicitly.)} Where bit fields are used, the text will clarify their position in each case. @@ -8119,7 +8200,7 @@ The motivation for introducing a new discrete-log-based hash function (rather th using $\PedersenHash$) is to make efficient use of the lookups available in recent proof systems including \HaloTwo. -$\SinsemillaHash$ is used in the definition of $\SinsemillaCommit{}$ +$\SinsemillaHash$ is used in the definition of $\SinsemillaCommitAlg$ (\crossref{concretesinsemillacommit}), and for the \Orchard \incrementalMerkleTree (\crossref{orchardmerklecrh}). @@ -8156,10 +8237,11 @@ $\SinsemillaGenBase \typecolon \binaryrange{k} \rightarrow \GroupPstar$ by: \introlist Define $\incompleteadd \typecolon \GroupP \times \GroupP \rightarrow \maybe{\GroupP}$ as incomplete addition on the \Pallas curve: +\vspace{-1ex} \begin{tabular}{@{\hskip 1.5em}r@{\;}l@{\;}l@{\;}l} - $\ZeroP$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\ - $\ZeroP$ &$\incompleteadd$ &$(x', y')$ &$= \bot$ \\ - $(x, y)$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\ + $\ZeroP$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.25ex] + $\ZeroP$ &$\incompleteadd$ &$(x', y')$ &$= \bot$ \\[-0.5ex] + $(x, y)$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.25ex] $(x, y)$ &$\incompleteadd$ &$(x', y')$ &$= \begin{cases} \bot, &\caseif x = x' \\ (x, y) + (x', y'), &\caseotherwise\text{.} @@ -8167,6 +8249,7 @@ Define $\incompleteadd \typecolon \GroupP \times \GroupP \rightarrow \maybe{\Gro \end{tabular} \introlist +\vspace{1ex} Define $\SinsemillaHashToPoint(D \typecolon \byteseqs, M \typecolon \bitseq{\range{0}{k \mult c}}) \rightarrow \GroupP$ as follows: \begin{algorithm} @@ -8196,7 +8279,7 @@ See \cite[section TODO ``Sinsemilla'']{Zcash-Orchard} for rationale and efficien $\SinsemillaHash$ and $\SinsemillaHashToPoint$ are required to be \collisionResistant between inputs of fixed length, for a given personalization input $D$. No other security properties commonly associated with \hashFunctions are needed. -} +} %securityrequirement \begin{nnotes} \item These \hashFunctions are \emph{not} \collisionResistant across variable-length inputs for the @@ -8495,7 +8578,7 @@ corresponding to $t$. \introlist \vspace{2ex} -$\PRFock{Sapling}{}$ is used in \crossref{saplingencrypt} to derive the +$\PRFock{Sapling}{}$ is used in \crossref{saplingandorchardencrypt} to derive the \outgoingCipherKey $\OutCipherKey$ used to encrypt an \outgoingCiphertext. It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in @@ -8538,7 +8621,7 @@ $\SubgroupReprJ$ is defined in \crossref{jubjub}. \newsavebox{\orchardockbox} \begin{lrbox}{\orchardockbox} -\setsapling +\setnufive \begin{bytefield}[bitwidth=0.038em]{512} \sbitbox{256}{$\LEBStoOSPOf{256}{\OutViewingKey}$} & \sbitbox{256}{$32$-byte $\cvField$} @@ -8550,7 +8633,7 @@ $\SubgroupReprJ$ is defined in \crossref{jubjub}. \nufive{ \introlist \vspace{2ex} -$\PRFock{Orchard}{}$ is used in \crossref{orchardencrypt} to derive the +$\PRFock{Orchard}{}$ is used in \crossref{saplingandorchardencrypt} to derive the \outgoingCipherKey $\OutCipherKey$ used to encrypt an \outgoingCiphertext. It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in @@ -9430,10 +9513,13 @@ which is equivalent to: \introsection \extralabel{concreteorchardnotecommit}{\lsubsubsubsection{Sinsemilla commitments}{concretesinsemillacommit}} +\vspace{-1ex} Let $\BaseLength{Orchard}$ be as defined in \crossref{constants}. +\vspace{-0.25ex} Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}. +\vspace{1ex} \crossref{concretesinsemillahash} defines a \xSinsemillaHash construction. We construct \defining{\xSinsemillaCommitments} by reusing that construction, and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta}): @@ -9445,9 +9531,10 @@ and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta} \ExtractP\big(\SinsemillaCommit{r}(D, M)\kern-0.1em\big)$. \end{formulae} -See \cite[Section TODO]{Zcash-Orchard} for rationale and efficient circuit implementation of this function. +See \cite[section TODO]{Zcash-Orchard} for rationale and efficient circuit implementation of this function. -The commitment scheme $\NoteCommitAlg{Orchard}$ specified in \crossref{abstractcommit} is +\vspace{0.5ex} +The \commitmentScheme $\NoteCommitAlg{Orchard}$ specified in \crossref{abstractcommit} is instantiated as follows using $\SinsemillaCommitAlg$: \begin{formulae} @@ -9463,7 +9550,7 @@ instantiated as follows using $\SinsemillaCommitAlg$: \item $\NoteCommitGenTrapdoor{Orchard}()$ generates the uniform distribution on $\GF{\ParamP{r}}$. \end{formulae} -The commitment scheme $\CommitIvkAlg$ specified in \crossref{abstractcommit} is +The \commitmentScheme $\CommitIvkAlg$ specified in \crossref{abstractcommit} is instantiated as follows using $\SinsemillaCommitAlg$: \begin{formulae} @@ -9511,6 +9598,7 @@ But $0 \neq 2 \pmod{\ParamP{q}}$, and there are no points in $\GroupP$ with is not square in $\GF{\ParamP{q}}$. \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} = \ItoLEBSPOf{\MerkleHashLength{Orchard}}{0}$ because we define $\ExtractP\Of{\ZeroP} = 0$, and it is technically possible (with negligible probability) @@ -9881,6 +9969,7 @@ $\abstJ\Of{P\Repr}$ is computed as follows: \item if $u \bmod 2 = \tilde{u}$ then return $(u, \varv)$ else return $(\ParamJ{q} - u, \varv)$. \end{formulae} +\introlist \pnote{ In earlier versions of this specification, $\abstJ$ was defined as the left inverse of $\reprJ$ such that if $S$ is not in the range of $\reprJ$, then $\abstJ\Of{S} = \bot$. @@ -9921,11 +10010,11 @@ other conditions on points, for example that they have order at least $\ParamJ{r \lsubsubsubsection{Coordinate Extractor for \JubjubText}{concreteextractorjubjub} \vspace{-2ex} -Let $\Selectu\Of{(u, \varv)} = u$ and let $\Selectv\Of{(u, \varv)} = \varv$. +Let $\Selectu\big((u, \varv)\big) = u$ and let $\Selectv\big((u, \varv)\big) = \varv$. Define $\ExtractJ \typecolon \SubgroupJ \rightarrow \MerkleHash{Sapling}$ by \begin{formulae} - \item $\ExtractJ(P) := \ItoLEBSPOf{\MerkleHashLength{Sapling}}{\Selectu\Of{P}}$. + \item $\ExtractJ(P) := \ItoLEBSP{\MerkleHashLength{Sapling}}\big(\Selectu\Of{P}\kern-0.1em\big)$. \end{formulae} \vspace{-2ex} @@ -10004,7 +10093,7 @@ The hash $\GroupJHash{\URS}(D, M) \typecolon \SubgroupJstar$ is calculated as fo \begin{algorithm} \item let $\HashOutput = \BlakeTwos{256}(D,\, \URS \bconcat\, M)$ - \item let $P = \abstJ\Of{\LEOStoBSP{256}(\HashOutput)\kern-0.12em}$ + \item let $P = \abstJ\big(\LEOStoBSP{256}(\HashOutput)\kern-0.12em\big)$ \item if $P = \bot$ then return $\bot$ \item let $Q = \scalarmult{\ParamJ{h}}{P}$ \item if $Q = \ZeroJ$ then return $\bot$, else return $Q$. @@ -10139,7 +10228,7 @@ i.e.\ $\setof{x \typecolon \GF{\ParamP{q}} \suchthat x^3 + \ParamP{b}\text{ is s Define $\GroupPx := \GroupPstarx \union \setof{0}$. -\vspace{2ex} +\vspace{1ex} Define $\ExtractP \typecolon \GroupP \rightarrow \GroupPx$ such that \vspace{-1ex} @@ -10239,6 +10328,7 @@ $]$. \introlist Let $\IsoMapG \typecolon \GroupIsoG \rightarrow \GroupG{}$ be the isogeny map given by: +\vspace{-1ex} \begin{tabular}{@{\hskip 1.5em}r@{\;}l} $\IsoMapG\big(\ZeroIsoG\big)$ &$= \ZeroG{}$ \\ $\IsoMapG\big((x, y)\big)$ &$= \left(\hfrac{\IsoConstG{1} \mult x^3 + \IsoConstG{2} \mult x^2 + \IsoConstG{3} \mult x + \IsoConstG{4}} @@ -10247,9 +10337,10 @@ Let $\IsoMapG \typecolon \GroupIsoG \rightarrow \GroupG{}$ be the isogeny map gi {x^3 + \IsoConstG{11} \mult x^2 + \IsoConstG{12} \mult x + \IsoConstG{13}}\right)$. \end{tabular} -\vspace{3ex} +\vspace{2ex} Let $\BlakeTwob{512} \typecolon \byteseq{16} \times \byteseqs \rightarrow \byteseq{\ell/8}$ be as defined in \crossref{concreteblake2}. +\vspace{-0.25ex} Let $\BEOStoIP{}$ be as defined in \crossref{endian}. \vspace{0.5ex} @@ -10257,6 +10348,7 @@ Let $\BEOStoIP{}$ be as defined in \crossref{endian}. Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \typecolon \byteseqs, \DST \typecolon \byteseq{\range{0}{255}}) \rightarrow \typeexp{\GF{\ParamG{q}}\!}{2}$ as follows: +\vspace{-1ex} \begin{algorithm} \item let $\DST' = \DST \bconcat\, [\,\length(\DST)\,]$ \item let $\msg' = \zerobytes{64} \bconcat \msg \bconcat\, [\,0, 128\,] \bconcat\, [\,0\,] \bconcat \DST'$ @@ -10266,7 +10358,9 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type \item return $[\,\BEOStoIPOf{512}{b_1}\! \pmod{\ParamG{q}},\, \BEOStoIPOf{512}{b_2}\! \pmod{\ParamG{q}}\,]$. \end{algorithm} +\vspace{-1ex} \begin{nnotes} + \vspace{-0.25ex} \item This algorithm is intended to correspond to $\hashtofield(\msg, 2)$ defined in \cite[section 5.3]{ID-hashtocurve}, using as its $\expandmessage$ parameter the function $\XMDBlakeTwob$ corresponding to $\expandmessagexmd$ defined in @@ -10275,16 +10369,20 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type $\binbytes = 64$, and we specialize to $\leninbytes = 128$ since that is the only case we need. In the event of any discrepancy or change to the Internet Draft, the definition here takes precedence. + \vspace{-0.25ex} \item Unlike other uses of $\BlakeTwobGeneric$ in \Zcash, zero bytes are used for the $\BlakeTwobGeneric$ personalization, in order to follow the Internet Draft which 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.\!\! + \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{64}$, since this state does not depend on the message. \end{nnotes} +\introlist Let $\ParamG{\lambda}$ be any fixed nonsquare in $\GF{\ParamG{q}}$. Define $\sqrtratioG(\num, \xdiv) \typecolon \GF{\ParamG{q}} \times \GFstar{\ParamG{q}} \rightarrow \GF{\ParamG{q}}$ as follows: @@ -11076,7 +11174,7 @@ $(\typecodeField, \lengthField, \addrField)$ encodings of the consituent address \item $\typecodeField \typecolon \byte$ -- the typecode from the above list; \item $\lengthField \typecolon \byte$ -- the length in bytes of $\addrField$; \vspace{-0.5ex} - \item $\addrField \typecolon \byteseq{\scriptsize\lengthField}$ -- the raw encoding + \item $\addrField \typecolon \byteseq{\text{\scriptsize\lengthField}}$ -- the raw encoding of a \shieldedPaymentAddress, or the $160$-bit script hash of a P2SH address \cite{Bitcoin-P2SH}, or the $160$-bit \validatingKey hash of a P2PKH address \cite{Bitcoin-P2PKH}. @@ -11724,7 +11822,7 @@ Several fields are reordered and/or renamed relative to prior versions. \joinSplitDescriptions\sapling{ or \spendDescriptions}. \preheartwooditem{\sapling{A \coinbaseTransaction also \MUSTNOT have any \outputDescriptions.}} } - \nufiveonwarditem{In a version 5 \coinbaseTransaction, the \enableSpendsOrchard flag \MUST be $0$.} + \nufiveonwarditem{In a version 5 \coinbaseTransaction, the \enableSpendsOrchard{} flag \MUST be $0$.} \item A \coinbaseTransaction for a \block at \blockHeight greater than $0$ \MUST have a script that, as its first item, encodes the \blockHeight as follows. Let $\heightBytes$ be the signed little-endian representation of the number, using the minimum number of bytes such that @@ -11751,9 +11849,9 @@ Several fields are reordered and/or renamed relative to prior versions. \item \todo{Other rules inherited from \Bitcoin.} \end{consensusrules} -Consensus rules associated with each \joinSplitDescription (\crossref{joinsplitencodingandconsensus})\sapling{, -each \spendDescription (\crossref{spendencodingandconsensus}),\notnufive{ and} each \outputDescription -(\crossref{outputencodingandconsensus})}\nufive{, and each \actionDescription (\crossref{actionencodingandconsensus})} +Consensus rules associated with each \joinSplitDescription\, (\crossref{joinsplitencodingandconsensus})\sapling{,\, +each \spendDescription\, (\crossref{spendencodingandconsensus}),\,\notnufive{ and} each \outputDescription\, +(\crossref{outputencodingandconsensus})}\nufive{,\, and each \actionDescription\, (\crossref{actionencodingandconsensus})} \MUST also be followed. \begin{pnotes} @@ -11787,7 +11885,7 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notnufive{ and} e \Bitcoin, where it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY} as specified in \cite{BIP-68}. \Zcash was forked from \Bitcoin v0.11.2 and does not currently support BIP 68. - \saplingonwarditem{As a consequence of \coinbaseTransactions having no + \saplingonwarditem{Because \coinbaseTransactions have no \spendDescriptions\notheartwood{ or \outputDescriptions}, the $\valueBalance{Sapling}$ field of a \coinbaseTransaction must have a\heartwood{ negative or} zero value. \heartwood{The negative case can only occur after \Heartwood activation, for \transactions @@ -11804,21 +11902,21 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notnufive{ and} e \shieldedPaymentAddresses, if there are any. } %canopy \nufive{ - \item The flags in \flagsOrchard allow a version 5 \transaction to declare that no funds are spent - from \Orchard \notes (by setting \enableSpendsOrchard to $0$), or that no new \Orchard \notes - with non-zero values are created (by setting \enableOutputsOrchard to $0$). This has two primary - purposes. First, the \enableSpendsOrchard flag is set to $0$ in version 5 \coinbaseTransactions to - ensure that they cannot spend from existing \Orchard outputs, maintaining a restriction present - in \coinbaseTransactions for \transparent, \Sprout, or \Sapling funds (which would not otherwise - be enforceable in the combined \actionTransfer design). + \item The flags in \flagsOrchard{} allow a version 5 \transaction to declare that no funds are spent + from \Orchard \notes (by setting \enableSpendsOrchard{} to $0$), or that no new \Orchard \notes + with non-zero values are created (by setting \enableOutputsOrchard{} to $0$). This has two primary + purposes. First, the \enableSpendsOrchard{} flag is set to $0$ in version 5 \coinbaseTransactions to + ensure that they cannot spend from existing \Orchard outputs. This maintains a restriction present + in \coinbaseTransactions for \transparent, \Sprout, or \Sapling funds, which would not otherwise + be enforceable in the combined \actionTransfer design. Second, if a security vulnerability were found that affected only the input side, or only the output side of the \actionCircuit, it would be possible to use these flags in a soft fork (i.e.\ a strictly contracting consensus change) to effectively ``switch off'' non-zero-value transfers only on the relevant side. } %nufive - \nufiveonwarditem{As a consequence of the \enableSpendsOrchard flag being set to $0$ (which has - the effect of disabling non-zero-valued \Orchard spends), the $\valueBalance{Orchard}$ - field of a \coinbaseTransaction must have a negative or zero value.} + \nufiveonwarditem{Because \enableSpendsOrchard{} is set to $0$ in version 5 \coinbaseTransactions\ --which + disables non-zero-valued \Orchard spends-- the $\valueBalance{Orchard}$ field of a \coinbaseTransaction + must have a negative or zero value.} \nufiveonwarditem{The rule that \nSpendsSapling, \nOutputsSapling, and \nActionsOrchard{} \MUST all be less than $2^{16}$, is technically redundant because a \transaction that could violate this rule would not fit within the $2$ MB \block size limit. It is included in order to simplify @@ -11832,11 +11930,10 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B \item \Transactionversion 0 is not supported. \item A version 1 \transaction is equivalent to a version 2 \transaction with $\nJoinSplit = 0$. - \item The $\nJoinSplit$, $\vJoinSplit$, $\joinSplitPubKey$, and $\joinSplitSig$ fields - have been added. - \overwinteronwarditem{The $\nVersionGroupId$ field has been added.} - \saplingonwarditem{The $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, $\vOutputsSapling$, - and $\bindingSig{Sapling}$ fields have been added.} + \item The fields $\nJoinSplit$, $\vJoinSplit$, $\joinSplitPubKey$, and $\joinSplitSig$ have been added. + \overwinteronwarditem{The field $\nVersionGroupId$ has been added.} + \saplingonwarditem{The following fields have been added: $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, + $\vOutputsSapling$, and $\bindingSig{Sapling}$.} \nufiveonwarditem{In version 5 \transactions, the $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, and $\vOutputsSapling$ fields are renamed to $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, and $\vOutputsSapling$ respectively.} @@ -11858,7 +11955,7 @@ Software that creates \transactions \SHOULD use version 1 for \transactions with \extralabel{joinsplitencoding}{\lsubsection{JoinSplit Description Encoding and Consensus}{joinsplitencodingandconsensus}} An abstract \joinSplitDescription, as described in \crossref{joinsplit}, is encoded in -a \transaction as an instance of a \type{JoinSplitDescription} type as follows: +a \transaction as an instance of a \type{JoinSplitDescription} type: \begin{center} \hbadness=2200 @@ -11918,7 +12015,6 @@ Consensus rules applying to a \joinSplitDescription are given in \crossref{joins \sapling{ -\introsection \extralabel{spendencoding}{\lsubsection{Spend Description Encoding and Consensus}{spendencodingandconsensus}} Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}. @@ -11930,7 +12026,7 @@ Let $\reprJ$ and $\ParamJ{q}$ be as defined in \crossref{jubjub}. An abstract \spendDescription, as described in \crossref{spendsandoutputs}, is encoded in a \transaction as an instance of a \type{SpendDescription} type as follows: -\vspace{-2.5ex} +\vspace{-1.5ex} \begin{center} \hbadness=2000 \begin{tabularx}{0.92\textwidth}{|c|l|l|L|} @@ -11939,10 +12035,10 @@ Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=|=|=|=|} $32$ & $\cvField$ & \type{byte[32]} & -A \valueCommitment to the value of the input \note, $\LEBStoOSPOf{256}{\reprJ\Of{\cv}}$. \\ \hline +A \valueCommitment to the value of the input \note, $\LEBStoOSPOf{256}{\reprJ\Of{\cv}\kern 0.05em}$. \\ \hline $32\nufive{\;\dagger}$ & $\anchorField{}$ & \type{byte[32]} & -A \merkleRoot of the \Sapling \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSPOf{256}{\rt{Sapling}}$. \\ \hline +A \merkleRoot of the \Sapling \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Sapling}\big)$. \\ \hline $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline @@ -11959,9 +12055,10 @@ A signature authorizing this Spend. \\ \hline \end{tabularx} \end{center} -\nufive{$\dagger$ The $\anchorField, \zkproof, and \spendAuthSigField$ fields are only present in a \spendDescription -if the \transactionVersion is $4$. For version 5 \transactions, all \spendDescriptions share the same \anchor, -which is encoded once as the $\anchorField{Sapling}$ field of the \transaction as described in +\vspace{-1ex} +\nufive{$\dagger$ The $\anchorField{}$, $\zkproof$, and $\spendAuthSigField$ fields are only present in a +\spendDescription if the \transactionVersion is $4$. For version 5 \transactions, all \spendDescriptions share +the same \anchor, which is encoded once as the $\anchorField{Sapling}$ field of the \transaction as described in \crossref{txnencodingandconsensus}. The $\zkproof$ and $\spendAuthSigField$ fields of a \spendDescription have been moved into the $\vSpendProofsSapling$ and $\vSpendAuthSigs{Sapling}$ fields respectively of version 5 \transactions.} @@ -11998,7 +12095,7 @@ $32$ & $\cmuField$ & \type{byte[32]} & The $u$-coordinate of the \noteCommitment $\LEBStoOSPOf{256}{\cmU}$ where $\cmU = \ExtractJ(\cm)$. \\ \hline $32$ & $\ephemeralKey$ & \type{byte[32]} & An encoding of an ephemeral \Jubjub \publicKey, -$\LEBStoOSPOf{256}{\reprJ\Of{\EphemeralPublic}}$. \\ \hline +$\LEBStoOSPOf{256}{\reprJ\Of{\EphemeralPublic}\kern 0.05em}$. \\ \hline $580$ & $\encCiphertext$ & \type{byte[580]} & A ciphertext component for the encrypted output \note, $\TransmitCiphertext{}$. \\ \hline @@ -12012,18 +12109,17 @@ $\ProofOutput$ (see \crossref{groth}). \\ \hline \end{tabularx} \end{center} +\vspace{-1ex} \nufive{$\dagger$ The $\zkproof$ field is only present in a \spendDescription if the \transactionVersion is $4$. This field has been moved into the $\vOutputProofsSapling$ field of version 5 \transactions.} -\vspace{-2ex} The $\ephemeralKey$, $\encCiphertext$, and $\outCiphertext$ fields together form the \noteCiphertextSapling, which is computed as described in \crossref{saplinginband}. -\vspace{-2ex} +\vspace{-1ex} \consensusrule{$\LEOStoIPOf{256}{\cmuField}$ \MUST be less than $\ParamJ{q}$.} -\vspace{-0.5ex} Other consensus rules applying to an \outputDescription are given in \crossref{outputdesc}. } %sapling @@ -12039,9 +12135,9 @@ Let $\reprP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. \vspace{-0.5ex} An abstract \actionDescription, as described in \crossref{actions}, is encoded in -a \transaction as an instance of an \type{ActionDescription} type as follows: +a \transaction as an instance of an \type{ActionDescription} type: -\vspace{-2.5ex} +\vspace{-1.5ex} \begin{center} \hbadness=2000 \begin{tabularx}{0.92\textwidth}{|c|l|l|L|} @@ -12050,18 +12146,18 @@ Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=|=|=|=|} $32$ & $\cvField$ & \type{byte[32]} & A \valueCommitment to the net value of the input \note -minus the output \note, $\LEBStoOSPOf{256}{\reprP\Of{\cv}}$. \\ \hline +minus the output \note, $\LEBStoOSP{256}\big(\reprP\Of{\cv}\kern-0.1em\big)$. \\ \hline $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline $32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSigField$, -$\LEBStoOSPOf{256}{\reprP\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline +$\LEBStoOSP{256}\big(\reprP\Of{\AuthSignRandomizedPublic}\kern-0.1em\big)$. \\ \hline $32$ & $\cmxField$ & \type{byte[32]} & The $x$-coordinate of the \noteCommitment for the output \note, $\LEBStoOSPOf{256}{\cmX}$ where $\cmU = \ExtractJ(\cm)$. \\ \hline $32$ & $\ephemeralKey$ & \type{byte[32]} & An encoding of an ephemeral \Jubjub \publicKey, -$\LEBStoOSPOf{256}{\reprP\Of{\EphemeralPublic}}$. \\ \hline +$\LEBStoOSP{256}\big(\reprP\Of{\EphemeralPublic}\kern-0.1em\big)$. \\ \hline $580$ & $\encCiphertext$ & \type{byte[580]} & A ciphertext component for the encrypted output \note, $\TransmitCiphertext{}$. \\ \hline @@ -12072,14 +12168,12 @@ encrypted output \note, $\OutCiphertext{}$. \\ \hline \end{tabularx} \end{center} -\vspace{-2ex} The $\ephemeralKey$, $\encCiphertext$, and $\outCiphertext$ fields together form the \noteCiphertextOrchard, which is computed as described in \crossref{saplinginband}. -\vspace{-2ex} +\vspace{-1ex} \consensusrule{$\LEOStoIPOf{256}{\cmxField}$ \MUST be less than $\ParamP{q}$.} -\vspace{-0.5ex} Other consensus rules applying to an \actionDescription are given in \crossref{actiondesc}. } %nufive @@ -12092,7 +12186,7 @@ of consensus rules later in the section): \begin{center} \hbadness=5000 -\begin{tabularx}{0.92\textwidth}{|c|l|p{8.6em}|L|} +\begin{tabularx}{0.965\textwidth}{|c|l|p{8em}|L|} \hline Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=|=|=|=|} @@ -12226,7 +12320,6 @@ rejected by this rule at a given point in time may later be accepted. } \end{pnotes} -\vspace{-1ex} \introlist The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are: @@ -12246,6 +12339,7 @@ The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin- \Zcash uses \Equihash \cite{BK2016} as its Proof of Work. The original motivations for changing the Proof of Work from \shadHash used by \Bitcoin were described in \cite{WG2016}. +\vspace{1ex} \introlist A \block satisfies the Proof of Work if and only if: @@ -12255,6 +12349,7 @@ A \block satisfies the Proof of Work if and only if: \end{itemize} +\vspace{-1ex} \introsection \lsubsubsection{Equihash}{equihash} @@ -12303,7 +12398,7 @@ $\vxor{j=1}{2^k} X_{i_j} = 0$. \introlist \begin{itemize} \item For all $r \in \range{1}{k\!-\!1}$, for all $w \in \binaryrange{k-r}: - \smash{\vxor{j=1}{2^r}} X_{i_{w \mult 2^r + j}}$ has $\frac{n \mult r}{k+1}$ leading zeros; and + \smash{\vxor{j=1}{2^r}} X_{i_{w \mult \scalebox{0.65}[0.6]{$2^r$} + j}}$ has $\frac{n \mult r}{k+1}$ leading zeros; and \item For all $r \in \range{1}{k}$, for all $w \in \binaryrange{k-r}: i_{w \mult 2^r + 1 .. w \mult 2^r + 2^{r-1}} < i_{w \mult 2^r + 2^{r-1} + 1 .. w \mult 2^r + 2^r}$ lexicographically. From 02db9650361472c233f43c86e70a3027ebcd5153 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:22:36 +0000 Subject: [PATCH 10/41] Cosmetics and trivial changes. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 314 ++++++++++++++++++++++++++---------------- 1 file changed, 194 insertions(+), 120 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 25916ada..863732ed 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -490,7 +490,7 @@ % \newcommand{\clasp}[3][0pt]{\stackengine{0pt}{#3}{\kern#1#2}{O}{c}{F}{F}{L}} -\newcommand{\plus}{\hairspace +\hairspace} +\newcommand{\plus}{\hspace{0.01em}+\hspace{0.01em}} \newcommand{\spv}{\hspace{0.071em}\varv\hspace{0.064em}} \newcommand{\varvv}{\varv\kern 0.02em\varv} \newcommand{\yy}{\hspace{0.022em}y\hspace{0.021em}} @@ -1187,6 +1187,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\concatbits}{\mathsf{concat}_\bit} \newcommand{\bconcat}{\mathop{\kern 0.05em||}} \newcommand{\listcomp}[1]{\overlap{0.06em}{\ensuremath{[}}~{#1}~\overlap{0.06em}{\ensuremath{]}}} +\newcommand{\biglistcomp}[1]{\overlap{0.06em}{\ensuremath{\bigg[}}{#1}\overlap{0.06em}{\ensuremath{\bigg]}}} \newcommand{\fun}[2]{{#1} \mapsto {#2}} \newcommand{\exclusivefun}[3]{{#1} \mapsto_{\not\in\kern 0.05em{#3}\!} {#2}} \newcommand{\first}{\mathsf{first}} @@ -1219,7 +1220,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ascii}[1]{\textbf{``\texttt{#1}''}} \newcommand{\Justthebox}[2][-1.8ex]{\raisebox{#1}{\;\usebox{#2}\;}} \newcommand{\setof}[1]{\{{#1}\}} -\newcommand{\bigsetof}[1]{\left\{{#1}\right\}} +\newcommand{\bigsetof}[1]{\big\{{#1}\big\}} \newcommand{\powerset}[1]{\raisebox{-0.28ex}{\scalebox{1.25}{$\mathscr{P}$}}\kern -0.2em\big(\strut{#1}\big)} \newcommand{\barerange}[2]{{{#1}\,..\,{#2}}} \newcommand{\range}[2]{\setof{\barerange{#1}{#2}}} @@ -1343,6 +1344,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ReceivedSet}{\mathsf{ReceivedSet}} \newcommand{\SpentSet}{\mathsf{SpentSet}} \newcommand{\NullifierMap}{\mathsf{NullifierMap}} +\newcommand{\NullifierType}{\mathsf{NullifierType}} % Key pairs @@ -1621,7 +1623,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\cv}{\mathsf{cv}} \newcommand{\cvOld}[1]{\cv^\mathsf{old}_{#1}} \newcommand{\cvNew}[1]{\cv^\mathsf{new}_{#1}} -\newcommand{\cvNet}{\cv^\mathsf{net}} +\newcommand{\cvNet}[1]{\cv^\mathsf{net}_{#1}} \newcommand{\cm}{\mathsf{cm}} \newcommand{\cmU}{\cm_{\kern -0.06em u}} \newcommand{\cmX}{\cm_{\kern -0.06em x}} @@ -2278,11 +2280,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\AffineSWVesta}{\mathsf{AffineSWVesta}} \newcommand{\CompressedSWVesta}{\mathsf{CompressedSWVesta}} \newcommand{\PedersenHash}{\mathsf{PedersenHash}} -\newcommand{\PedersenGenAlg}[1]{\mathcal{I}^{\kern -0.05em\mathsf{#1}}} -\newcommand{\PedersenGen}[2]{\PedersenGenAlg{#1}_{\kern 0.1em {#2}}} +\newcommand{\PedersenGenAlg}[1]{\mathcal{I}^{\kern-0.05em{#1}}} +\newcommand{\PedersenGen}[2]{\PedersenGenAlg{#1}_{\kern0.1em{#2}}} \newcommand{\PedersenEncode}[1]{\langle{#1}\rangle} -\newcommand{\PedersenEncodeSub}[2]{\langle{#2}\rangle_{\kern -0.1em {#1}\vphantom{S'}}} -\newcommand{\PedersenEncodeNonneg}[1]{\langle{#1}\rangle^{\kern -0.1em\PedersenRangeOffset}} +\newcommand{\PedersenEncodeSub}[2]{\langle{#2}\rangle_{\kern-0.1em{#1}\vphantom{S'}}} +\newcommand{\PedersenEncodeNonneg}[1]{\langle{#1}\rangle^{\kern-0.1em\PedersenRangeOffset}} \newcommand{\PedersenHashToPoint}{\mathsf{PedersenHashToPoint}} \newcommand{\MixingPedersenHash}{\mathsf{MixingPedersenHash}} \newcommand{\WindowedPedersenCommitAlg}{\mathsf{WindowedPedersenCommit}} @@ -2450,6 +2452,7 @@ transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with \emph{shielded} payment scheme secured by zero-knowledge succinct non-interactive arguments of knowledge (\zkSNARKs). +\vspace{1ex} The most significant changes from the original \Zerocash are explained in \crossref{differences}. Changes specific to the \Overwinter upgrade @@ -2807,7 +2810,7 @@ $\sxor{i=1}{0} a_i = 0$ or the all-zero bit sequence of length given by the type of $a$. $\possqrt{a}$, where $a \typecolon \GF{q}$, means the positive square root -of $a$ in $\GF{q}$, i.e.\ in the range $\bigrange{0}{\hfrac{q-1}{2}}$. +of $a$ in $\GF{q}$, i.e.\ in the range $\bigrange{0}{\frac{q-1}{2}}$. It is only used in cases where the square root must exist. $\optsqrt{a}$, where $a \typecolon \GF{q}$, means an arbitrary @@ -2871,7 +2874,7 @@ We use the abbreviation ``\defining{\xCtEdwards}'' to refer to \completeTwistedE coordinates (see \crossref{jubjub}). -\intropart +\pagebreak \lsection{Concepts}{concepts} \lsubsection{Payment Addresses and Keys}{addressesandkeys} @@ -3262,6 +3265,7 @@ the vast majority of nodes should eventually agree on their \bestValidBlockChain up to that height. +\vspace{-1ex} \lsubsection{Transactions and Treestates}{transactions} Each \block contains one or more \defining{\transactions}. @@ -3274,7 +3278,7 @@ As in \Bitcoin, the remaining value in the pool is available to miners as a fee. \consensusrule{ The remaining value in the \transparentTxValuePool \MUST be nonnegative. } -\vspace{2ex} +\vspace{1ex} \introlist To each \transaction there are associated initial \defining{\treestates} @@ -3286,6 +3290,7 @@ for \Sprout\sapling{ and for \Sapling}\nufive{ and for \Orchard}. \sapling{Each} \item a \nullifierSet (\crossref{nullifierset}). \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. @@ -3311,6 +3316,7 @@ In a given \blockChain, \sapling{for each of \Sprout and \SaplingAndOrchard,} \transaction. \end{itemize} +\vspace{-1ex} \joinSplitDescriptions also have interstitial input and output \treestates for \Sprout, explained in the following section. \sapling{There is no equivalent of interstitial \treestates for \Sapling\nufive{ or @@ -5029,7 +5035,7 @@ where \item The check that $\AuthSignRandomizedPublic$ is not of small order is technically redundant with a check in the \spendCircuit, but it is simple and cheap to also check this outside the circuit. \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be small-order has the effect - of also preventing non-canonical encodings of these fields\nufive{, as required by \cite{ZIP-216}}. + of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\AuthSignRandomizedPublic}\kern0.05em} = \AuthSignRandomizedPublic$. \end{nnotes} @@ -5104,7 +5110,7 @@ where \vspace{-2.5ex} \nnote{The rule that $\cv$ and $\EphemeralPublic$ \MUST not be small-order, has the effect -of also preventing non-canonical encodings of these fields\nufive{, as required by \cite{ZIP-216}}. +of also preventing \nonCanonicalFieldElement encodings of these fields\nufive{, as required by \cite{ZIP-216}}. That is, it is necessarily the case that $\reprJ\Of{\abstJ\Of{\cv}\kern0.05em} = \cv$ and $\reprJ\Of{\abstJ\Of{\EphemeralPublic}\kern0.05em} = \EphemeralPublic$.} } %sapling @@ -5147,15 +5153,16 @@ Let $\Action$ be as defined in \crossref{abstractzk}. \vspace{1ex} \introlist -An \actionDescription comprises $(\cvNet, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \spendAuthSig, -\cmX, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \enableSpend, \enableOutput, \Proof{})$ +An \actionDescription comprises $(\cvNet{}, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \spendAuthSig, +\cmX, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \enableSpends, \enableOutputs,$ $\Proof{})$ where \begin{itemize} - \item $\cvNet \typecolon \ValueCommitOutput{Orchard}$ is the \valueCommitment to the value of the + \item $\cvNet{} \typecolon \ValueCommitOutput{Orchard}$ is the \valueCommitment to the value of the input \note minus the value of the output \note; \vspace{-0.5ex} - \item $\rt{Orchard} \typecolon \MerkleHash{Orchard}$ is an \anchor, as defined in - \crossref{blockchain}, for the output \treestate of a previous \block; + \item $\rt{Orchard} \typecolon \MerkleHash{Orchard}$ is an \anchor (\crossref{blockchain}) for the + output \treestate of a previous \block; + \vspace{-0.25ex} \item $\nf \typecolon \PRFOutputNfOrchard$ is the \nullifier for the input \note; \vspace{-0.25ex} \item $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard}$ is a randomized \validatingKey @@ -5189,7 +5196,7 @@ where \vspace{-1ex} \pnote{The $\rt{Orchard}$, $\enableSpend$, and $\enableOutput$ components are the same for all -\actionTransfers in a \transaction. They are encoded once in the \transaction body (specified in +\actionTransfers in a \transaction. They are encoded once in the \transaction body (see \crossref{txnencodingandconsensus}), not in the $\type{ActionDescription}$ structure. $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrchard$ field of a \transaction.} @@ -5213,7 +5220,7 @@ $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrc i.e.\ $\ActionVerify\big(\kern-0.1em(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend, \enableOutput), \Proof{\Action}\big) = 1$. \end{consensusrules} -\vspace{-3ex} +\vspace{-1.5ex} \nnote{$\cv$, $\AuthSignRandomizedPublic$, and $\EphemeralPublic$ can be the zero point $\ZeroP$.} } %nufive @@ -6077,6 +6084,7 @@ is enforced by the \defining{\orchardBindingSignature}. The rôle of this signat the total value produced) by \actionTransfers is consistent with the $\vBalance{Orchard}$ field of the \transaction{}. +\vspace{-1ex} \nnote{The other rôle of \saplingBindingSignatures, to prove that the signer knew the randomness used for commitments in order to prevent them from being replayed, is less important in \Orchard because all \actionDescriptions have a \spendAuthSignature. Still, @@ -6084,10 +6092,11 @@ an \orchardBindingSignature does prove that the signer knew this commitment rand this provides defence in depth and reduces the differences of \Orchard from \Sapling, which may simplify security analysis.} +\vspace{2ex} Instead of generating a key pair at random, we generate it as a function of the \valueCommitments in the \actionDescriptions of the \transaction, and the \orchardBalancingValue. -\vspace{2ex} +\vspace{1ex} Let $\GroupP$, $\GroupPstar$, and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. \introlist @@ -6199,7 +6208,7 @@ $\vSum = 0$, we will also demonstrate that it does not overflow $\ValueCommitTyp The $\actionStatements$ (\crossref{actionstatement}) prove that all $\vNet{\alln}$ are in $\SignedValueDifferenceType$. $\vBalance{Orchard}$ is encoded in the \transaction as a -signed two's complement $64$-bit integer in the range $\SignedValueFieldType$. Therefore, $\vSum$ is +\strut signed two's complement $64$-bit integer in the range $\SignedValueFieldType$. Therefore, $\vSum$ is in the range $\range{-n \mult (2^{64}-1) - 2^{63} + 1}{n \mult (2^{64}-1) + 2^{63}}$. $n$ is limited by consensus rule to at most $2^{16}-1$ (this rule is technically redundant due to the $2$ MB \transaction size limit, but it suffices here). @@ -6896,7 +6905,7 @@ $\TransmitPrivate$ as specified in \crossref{sproutkeycomponents}. Let $\cm_{\allNew}$ be the \noteCommitments of each output coin. -\introsection +\introlist \vspace{0.5ex} Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext component $(\EphemeralPublic, \TransmitCiphertext{i})$ as follows: @@ -6915,9 +6924,10 @@ $\DecryptNoteSprout(\TransmitKey{i}, \TransmitCiphertext{i}, \cm_i, \AuthPublic) is defined as follows: \begin{formulae} + \vspace{-0.4ex} \item let $\TransmitPlaintext{i} = \SymDecrypt{\TransmitKey{i}}(\TransmitCiphertext{i})$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item if $\TransmitPlaintext{i} = \bot$, return $\bot$ \vspace{-1.5ex} \item extract $\NotePlaintext{i} = (\NotePlaintextLeadByte_i \typecolon \byte, @@ -6925,34 +6935,35 @@ is defined as follows: \NoteUniqueRand_i \typecolon \PRFOutputSprout, \NoteCommitRand_i \typecolon \NoteCommitTrapdoor{Sprout}, \Memo_i \typecolon \MemoType)$ from $\TransmitPlaintext{i}$ - \vspace{-0.2ex} + \vspace{-0.4ex} \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}((\AuthPublic, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i)) \neq \cm_i$, return $\bot$, else return $\NotePlaintext{i}$. \end{formulae} -\vspace{-0.5ex} \introlist -To test whether a \note is unspent in a particular \blockChain also requires -the \spendingKey $\AuthPrivate$; the coin is unspent if and only if -$\nf = \PRFnf{Sprout}{\AuthPrivate}(\NoteUniqueRand)$ is not in the \nullifierSet -for that \blockChain. - -\vspace{0.5ex} +\vspace{-0.5ex} \begin{pnotes} \item The decryption algorithm corresponds to step 3 (b) i. and ii. (first bullet point) of the $\Receive$ algorithm shown in \cite[Figure 2]{BCGGMTV2014}. \vspace{-0.5ex} + \item To test whether a \note is unspent in a particular \blockChain also requires + the \spendingKey $\AuthPrivate$; the coin is unspent if and only if + $\nf = \PRFnf{Sprout}{\AuthPrivate}(\NoteUniqueRand)$ is not in the \nullifierSet + for that \blockChain. + \vspace{-0.5ex} \item A \note can change from being unspent to spent as a node's view of the \bestValidBlockChain is extended by new \transactions. Also, \blockChainReorganizations can cause a node to switch to a different \bestValidBlockChain that does not contain the \transaction in which a \note was output. \end{pnotes} +\vspace{-0.25ex} See \crossref{inbandrationale} for further discussion of the security and engineering rationale behind this encryption scheme. \sapling{ +\vspace{-1ex} \extralabel{saplinginband}{\lsubsection{In-band secret distribution (\SaplingAndOrchardText)}{saplingandorchardinband}} \vspace{-1ex} @@ -6972,23 +6983,33 @@ is encrypted by a fresh \ephemeralPublicKey. \vspace{0.5ex} \introlist For both encryption and decryption, -\vspace{0.5ex} +\vspace{0.25ex} \begin{itemize} \item let $\OutViewingKeyLength$ be as defined in \crossref{constants}; + \vspace{-0.25ex} \item let $\Sym$ be the encryption scheme instantiated in \crossref{concretesym}; + \vspace{-0.25ex} \item let $\KA{}$ be the \keyAgreementScheme $\KA{Sapling}$\nufive{ or $\KA{Orchard}$} instantiated in \crossref{concretesaplingkeyagreement}\nufive{ or \crossref{concreteorchardkeyagreement}}; + \vspace{-0.25ex} \item let $\KDF{}$ be the \keyDerivationFunction $\KDF{Sapling}$\nufive{ or $\KDF{Orchard}$} instantiated in \crossref{concretesaplingkdf}\nufive{ or \crossref{concreteorchardkdf}}; + \vspace{-0.25ex} \item let $\GroupG{}, \ellG{}$, and $\reprG{}$ be instantiated as $\GroupJ$, $\ellJ$, and $\reprJ$ defined in \crossref{jubjub}\nufive{, or $\GroupP$, $\ellP$, and $\reprP$ defined in \crossref{pallasandvesta}}; + \vspace{-0.25ex} \item let $\ExtractG$ be $\ExtractJ$ as defined in \crossref{concreteextractorjubjub}\nufive{ or $\ExtractP$ as defined in \crossref{concreteextractorpallas}}; \vspace{-0.5ex} \item let $\PRFock{}{}$ be $\PRFock{Sapling}{}$\nufive{ or $\PRFock{Orchard}{}$} instantiated in \crossref{concreteprfs}; + \vspace{-0.25ex} \item let $\DiversifyHash{}$ be $\DiversifyHash{Sapling}$ in \crossref{concretediversifyhash}\nufive{, or $\DiversifyHash{Orchard}$ in the same section}; + \vspace{-0.25ex} + \item let $\NoteCommitment{}$ be $\NoteCommitment{Sapling}$\nufive{ or $\NoteCommitment{Orchard}$} + instantiated in \crossref{notes}; + \vspace{-0.25ex} \item let $\ToScalar{}$ be $\ToScalar{Sapling}$ defined in \crossref{saplingkeycomponents}\nufive{ or $\ToScalar{Orchard}$ defined in \crossref{orchardkeycomponents}}. \end{itemize} @@ -7070,10 +7091,10 @@ received out-of-band, which are not addressed in this document. \sapling{ -\vspace{-2ex} +\vspace{-1.5ex} \extralabel{saplingdecryptivk}{\lsubsubsection{Decryption using an Incoming Viewing Key (\SaplingAndOrchardText)}{decryptivk}} -\vspace{-1ex} +\vspace{-1.5ex} Let $\InViewingKey \typecolon \InViewingKeyTypeSapling$\notbeforenufive{ (in \Sapling)\nufive{ or $\InViewingKeyTypeOrchard$ (in \Orchard)}} be the recipient's \incomingViewingKey, specified in \crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}. @@ -7097,19 +7118,21 @@ components of the \noteCiphertext: \begin{algorithm} \vspace{-0.5ex} \item let $\EphemeralPublic = \abstG{}\Of{\ephemeralKey}$ - \vspace{-0.2ex} + \vspace{-0.3ex} \item if $\EphemeralPublic = \bot$, return $\bot$ - \vspace{-0.2ex} + \vspace{-0.3ex} \item let $\DHSecret{} = \KAAgree{}(\InViewingKey, \EphemeralPublic)$ \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$ + \vspace{-0.2ex} \item let $\TransmitPlaintext{} = \SymDecrypt{\TransmitKey{}}(\TransmitCiphertext{})$ \vspace{-0.4ex} \item if $\TransmitPlaintext{} = \bot$, return $\bot$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item extract $\NotePlaintext{} = (\NotePlaintextLeadByte \typecolon \byte, \Diversifier \typecolon \DiversifierType, \Value \typecolon \ValueType, \NoteCommitRandBytesOrSeedBytes \typecolon \NoteSeedBytesType, \Memo \typecolon \MemoType)$ from $\TransmitPlaintext{}$ \precanopyitem{if $\NotePlaintextLeadByte \neq \hexint{01}$, return $\bot$} + \vspace{-0.2ex} \precanopyitem{let $\NoteCommitRandBytes = \NoteSeedBytes$} \canopyonwarditem{if $\BlockHeight < \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \not\in \setof{\hexint{01}, \hexint{02}}$, return $\bot$} \canopyonwarditem{if $\BlockHeight \geq \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \neq \hexint{02}$, return $\bot$} @@ -7123,7 +7146,9 @@ from $\TransmitPlaintext{}$ \item if $\NoteCommitRand \geq \ParamG{r}$ or\notbeforenufive{ (for \Sapling)} $\DiversifiedTransmitBase = \bot$, return $\bot$ \canopyonwarditem{if $\NotePlaintextLeadByte \neq \hexint{01}$:} \canopy{ + \vspace{-0.2ex} \item \tab $\EphemeralPrivate = \ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.11em\big)$ + \vspace{-0.2ex} \item \tab if $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big) \neq \ephemeralKey$, return $\bot$ \item \blank @@ -7135,10 +7160,11 @@ from $\TransmitPlaintext{}$ \Value)\kern-0.1em\big)$. \nufive{ \item for \Orchard: - \vspace{-0.25ex} + \vspace{-0.3ex} \item \tab let $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.1em\big)$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item \tab let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. + \vspace{-0.2ex} \item \tab let $\cmstar' = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, \Value, @@ -7151,7 +7177,7 @@ from $\TransmitPlaintext{}$ \item return $\NotePlaintext{}$. \end{algorithm} -\vspace{-1ex} +\vspace{-1.5ex} \begin{pnotes} \vspace{-0.5ex} \item For \Sapling, as explained in the note in \crossref{jubjub}, $\abstJ$ accepts \nonCanonicalPoint @@ -7161,19 +7187,19 @@ from $\TransmitPlaintext{}$ $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.1em\big)$}. \nufive{For consistency this is also what is specified for \Orchard.} \introlist - \vspace{-0.25ex} + \vspace{-0.5ex} \item Normally only \noteCiphertextsSapling of \transactions in \blocks need to be decrypted. In that case, any received \Sapling \note is necessarily a \positionedNote, so its $\NoteUniqueRand$ - value can immediately be calculated as in \crossref{commitmentsandnullifiers}. + value can immediately be calculated per \crossref{commitmentsandnullifiers}. To test whether a \SaplingOrOrchard \note is unspent in a particular \blockChain also requires the \nullifierDerivingKey $\NullifierKey$; the coin is unspent if and only if the \nullifier - computed as described in \crossref{commitmentsandnullifiers} is not in the \nullifierSet for + computed as in \shortcrossref{commitmentsandnullifiers} is not in the \nullifierSet for that \blockChain. - \vspace{-0.25ex} + \vspace{-0.5ex} \item A \note can change from being unspent to spent as a node's view of the \bestValidBlockChain is extended by new \transactions. Also, \blockChainReorganizations can cause a node to switch to a different \bestValidBlockChain that does not contain the \transaction in which a \note was output. - \vspace{-0.25ex} + \vspace{-0.5ex} \item A client \MAY attempt to decrypt a \noteCiphertextSapling of a \transaction in the \mempool\canopy{, using the next \blockHeight for $\BlockHeight$}. However, in that case it \MUSTNOT assume that the \transaction will be mined and \MUST treat the decrypted information as provisional. It @@ -7200,7 +7226,7 @@ For a \Sapling \noteCiphertextSapling, let $\cvField$ and $\cmstarField$ be the fields of the \outputDescription. \nufive{ -\vspace{-0.25ex} +\vspace{-0.5ex} For an \Orchard \noteCiphertextOrchard, let $\cvField$ and $\cmstarField$ be the $\cvField$ and $\cmxField$ fields of the \actionDescription. } %nufive @@ -7213,23 +7239,27 @@ The \outgoingViewingKey holder will attempt to decrypt the \noteCiphertext as fo \vspace{-1.25ex} \begin{algorithm} \item let $\OutCipherKey = \PRFock{}{\OutViewingKey}(\cvField, \cmstarField, \ephemeralKey)$ - \vspace{-0.2ex} + \vspace{-0.4ex} \item let $\OutPlaintext = \SymDecrypt{\OutCipherKey}(\OutCiphertext)$ \vspace{-0.5ex} \item if $\OutPlaintext = \bot$, return $\bot$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item extract $(\DiversifiedTransmitPublicRepr \typecolon \ReprG{}, \EphemeralPrivateBytes \typecolon \EphemeralPrivateBytesType)$ from $\OutPlaintext$ \item let $\EphemeralPrivate = \LEOStoIPOf{256}{\EphemeralPrivateBytes}$ and $\DiversifiedTransmitPublic = \abstG{}\Of{\DiversifiedTransmitPublicRepr}$ + \vspace{-0.3ex} \item if $\EphemeralPrivate \geq \ParamG{r}$ or $\DiversifiedTransmitPublic = \bot$, return $\bot$ \nufiveonwarditem{if $\reprP\big(\DiversifiedTransmitPublic\big) \neq \DiversifiedTransmitPublicRepr$, return $\bot$} + \vspace{-0.3ex} \item let $\DHSecret{} = \KAAgree{}(\EphemeralPrivate, \DiversifiedTransmitPublic)$ + \vspace{-0.3ex} \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$ + \vspace{-0.3ex} \item let $\TransmitPlaintext{} = \SymDecrypt{\TransmitKey{}}(\TransmitCiphertext{})$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item if $\TransmitPlaintext{} = \bot$, return $\bot$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item extract $\NotePlaintext{} = (\NotePlaintextLeadByte \typecolon \byte, \Diversifier \typecolon \DiversifierType, \Value \typecolon \ValueType, \NoteCommitRandBytesOrSeedBytes \typecolon \NoteSeedBytesType, \Memo \typecolon \MemoType)$ from $\TransmitPlaintext{}$ @@ -7237,16 +7267,16 @@ from $\TransmitPlaintext{}$ \precanopyitem{let $\NoteCommitRandBytes = \NoteSeedBytes$} \canopyonwarditem{if $\BlockHeight < \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \not\in \setof{\hexint{01}, \hexint{02}}$, return $\bot$} \canopyonwarditem{if $\BlockHeight \geq \CanopyActivationHeight + \ZIPTwoOneTwoGracePeriod \text{ and } \NotePlaintextLeadByte \neq \hexint{02}$, return $\bot$} - \vspace{-0.25ex} + \vspace{-0.4ex} \canopyonwarditem{if $\NotePlaintextLeadByte \neq \hexint{01}$ and $\ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.11em\big) \neq \EphemeralPrivate$, return $\bot$} - \vspace{-0.25ex} + \vspace{-0.4ex} \canopyonwarditem{let $\NoteCommitRandBytes = \begin{cases} \NoteSeedBytes,&\caseif \NotePlaintextLeadByte = \hexint{01} \\ \ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big),&\caseotherwise \end{cases}$} \item let $\NoteCommitRand = \LEOStoIPOf{256}{\NoteCommitRandBytes}$ and $\DiversifiedTransmitBase = \DiversifyHash{}(\Diversifier)$ - \vspace{-0.5ex} + \vspace{-0.6ex} \item if $\NoteCommitRand \geq \ParamG{r}$, return $\bot$ \notbeforenufive{ \item for \Sapling: @@ -7257,10 +7287,11 @@ from $\TransmitPlaintext{}$ \Value)\kern-0.1em\big)$. \nufive{ \item for \Orchard: - \vspace{-0.25ex} + \vspace{-0.4ex} \item \tab let $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.1em\big)$ - \vspace{-0.6ex} + \vspace{-0.75ex} \item \tab let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. + \vspace{-0.4ex} \item \tab let $\cmstar' = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, \Value, @@ -7269,10 +7300,10 @@ from $\TransmitPlaintext{}$ \item \vspace{-3.5ex} } %nufive \item if $\LEBStoOSPOf{256}{\cmstar'} \neq \cmstarField$, return $\bot$ - \vspace{-0.75ex} + \vspace{-1ex} \item if $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big) \neq \ephemeralKey$, return $\bot$ - \vspace{-0.2ex} + \vspace{-0.4ex} \item return $\NotePlaintext{}$. \end{algorithm} @@ -7288,10 +7319,10 @@ from $\TransmitPlaintext{}$ \prenufiveitem{$\DiversifiedTransmitPublicRepr$ can also be \nonCanonicalPoint. Since $\bot$ is returned if $\DiversifiedTransmitBase \not\in \SubgroupJ$, the only accepted \nonCanonicalPoint encoding for $\DiversifiedTransmitPublicRepr$ of a \Sapling \note is $\ItoLEBSP{256}\big(2^{255} + 1\big)$.} - \vspace{-0.25ex} + \vspace{-0.5ex} \nufiveonwarditem{This procedure returns $\bot$ if $\DiversifiedTransmitPublicRepr$ is \nonCanonicalPoint (which can only occur for \Sapling \notes), as specified in \cite{ZIP-216}.} - \vspace{-0.25ex} + \vspace{-0.5ex} \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 $\SubgroupJ$ (i.e.\ the condition ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJ$, return $\bot$``). That did not match the @@ -7790,10 +7821,8 @@ $\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHash{Orchard \item where $l = \ItoLEBSP{10}\big(\MerkleDepth{Orchard} - 1 - \mathsf{layer}\big)$. \end{formulae} -\vspace{-2ex} \securityrequirement{$\SinsemillaHash$ must be \collisionResistant\!.} -\vspace{1ex} \pnote{The prefix $l$ provides domain separation between inputs at different layers of the \noteCommitmentTree.} } %nufive @@ -8159,21 +8188,21 @@ Because $\ExtractJ$ is injective, it follows that $\PedersenHash$ is equally \sapling{ \lsubsubsubsection{Mixing Pedersen Hash Function}{concretemixinghash} +\vspace{-1ex} A mixing \xPedersenHash is used to compute $\NoteUniqueRand$ from $\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as input a \xPedersenCommitment $P$, and hashes it with another input $x$. Define $\NotePositionBaseSapling := \FindGroupJHash\Of{\ascii{Zcash\_J\_}, \ascii{}}$. -\vspace{1ex} +\vspace{0.5ex} We define $\MixingPedersenHash \typecolon \GroupJ \times \range{0}{\ParamJ{r}-1} \rightarrow \GroupJ$ by: - \begin{formulae} \item $\MixingPedersenHash(P, x) := P + \scalarmult{x}{\NotePositionBaseSapling}$. \end{formulae} -\vspace{-1ex} +\vspace{-3ex} \securityrequirement{ The function \begin{formulae} @@ -8184,15 +8213,17 @@ The function must be \collisionResistant on $(r, M, x)$. } -\vspace{2ex} +\vspace{1.5ex} See \crossref{cctmixinghash} for efficient circuit implementation of this function. } %sapling \nufive{ \introlist +\vspace{-2ex} \lsubsubsubsection{Sinsemilla Hash Function}{concretesinsemillahash} +\vspace{-1ex} \defining{$\SinsemillaHash$} is an algebraic \hashFunction with \collisionResistance (for fixed input length) derived from assumed hardness of the Discrete Logarithm Problem. It is designed by Sean Bowe and Daira Hopwood. @@ -8207,20 +8238,25 @@ $\SinsemillaHash$ is used in the definition of $\SinsemillaCommitAlg$ Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, $\ParamP{r}$, and $\ParamP{b}$ be as defined in \crossref{pallasandvesta}. +\vspace{-0.25ex} Let $\ExtractP \typecolon \GroupP \rightarrow \MerkleHash{Orchard}$ be as defined in \crossref{concreteextractorpallas}. +\vspace{-0.25ex} Let $\GroupPHash$ be as defined in \crossref{concretegrouphashpallasandvesta}. +\vspace{-0.25ex} Let $\Uncommitted{Orchard}$ be as defined in \crossref{constants}. +\vspace{-0.25ex} Let $\ItoLEOSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ and $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ be as defined in \crossref{endian}. -\vspace{1ex} +\vspace{0.5ex} Let $k := 10$. +\vspace{-0.25ex} Let $c$ be the largest integer such that $2^n \leq \hfrac{\ParamP{r}-1}{2}$, i.e.\ $c := 253$. @@ -8229,8 +8265,8 @@ Define $\SinsemillaGenInit \typecolon \byteseqs \rightarrow \GroupPstar$ and $\SinsemillaGenBase \typecolon \binaryrange{k} \rightarrow \GroupPstar$ by: \begin{tabular}{@{\hskip 1.5em}r@{\;}l} - $\SinsemillaGenInit(D)$ &$:= \GroupPHash\!\big(\ascii{z.cash:SinsemillaQ}, D\big)$ \\ - $\SinsemillaGenBase(j)$ &$:= \GroupPHash\!\big(\ascii{z.cash:SinsemillaS}, \ItoLEOSPOf{32}{j}\big)$. + $\SinsemillaGenInit(D)$ &$:= \GroupPHash\!\big(\ascii{z.cash:SinsemillaQ}, D\big)$ \\[-0.25ex] + $\SinsemillaGenBase(j)$ &$:= \GroupPHash\!\big(\ascii{z.cash:SinsemillaS}, \ItoLEOSP{32}(j)\kern-0.1em\big)$. \end{tabular} \vspace{1ex} @@ -8239,9 +8275,9 @@ Define $\incompleteadd \typecolon \GroupP \times \GroupP \rightarrow \maybe{\Gro \vspace{-1ex} \begin{tabular}{@{\hskip 1.5em}r@{\;}l@{\;}l@{\;}l} - $\ZeroP$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.25ex] - $\ZeroP$ &$\incompleteadd$ &$(x', y')$ &$= \bot$ \\[-0.5ex] - $(x, y)$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.25ex] + $\ZeroP$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.3ex] + $\ZeroP$ &$\incompleteadd$ &$(x', y')$ &$= \bot$ \\[-0.6ex] + $(x, y)$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.3ex] $(x, y)$ &$\incompleteadd$ &$(x', y')$ &$= \begin{cases} \bot, &\caseif x = x' \\ (x, y) + (x', y'), &\caseotherwise\text{.} @@ -8259,7 +8295,7 @@ Define $\SinsemillaHashToPoint(D \typecolon \byteseqs, M \typecolon \bitseq{\ran each of length $k$ bits, so that $M' = \concatbits(M_\barerange{1}{n})$. \item let mutable $\Acc \leftarrow \SinsemillaGenInit(D)$ \item for $i$ from $1$ up to $n$: - \vspace{-1ex} + \vspace{-0.5ex} \item \tab set $\Acc \leftarrow \Big(\Acc \incompleteadd \SinsemillaGenBase\big(\LEBStoIP{k}(M_i)\kern-0.1em\big)\kern-0.15em\Big) \incompleteadd \Acc$ \item \blank \item return $\Acc$. @@ -8284,6 +8320,7 @@ No other security properties commonly associated with \hashFunctions are needed. \begin{nnotes} \item These \hashFunctions are \emph{not} \collisionResistant across variable-length inputs for the same $D$ (that is, it is assumed that a single input length will be used for any given $D$). + \vspace{-0.5ex} \item The intermediate value $\scalarmult{2}{\GroupPHash\!\big(\ascii{z.cash:SinsemillaQ}, D\big)}$ for the first iteration of the loop can be precomputed, if $D$ is known in advance. \end{nnotes} @@ -8956,7 +8993,7 @@ $\abstBytesEdSpecific\Of{\bytes{P}}$ is computed as follows: \item let ${y\Repr} \typecolon \bitseq{255}$ be the first $255$ bits of $\LEOStoBSPOf{256}{\bytes{P}}$ and let $\tilde{x} \typecolon \bit$ be the last bit. \item let $y \typecolon \GF{p} = \LEBStoIPOf{255}{y\Repr} \pmod{p}$. \item let $x = \optsqrt{\hfrac{1 - y^2}{a - d \smult y^2}}$.\; - (The denominator $a - d \smult y^2$ cannot be zero, since $\hfrac{a}{d}$ is not square in $\GF{p}$.) + (The denominator $a - d \smult y^2$ cannot be zero, since $\hfrac{a}{d}$ is not square in $\GF{p}$.) \item if $x = \bot$, return $\bot$. \item if $x \bmod 2 = \tilde{x}$ then return $(x, y)$ else return $(p - x, y)$. \end{formulae} @@ -9144,11 +9181,11 @@ Define $\RedDSASign{} \typecolon (\sk \typecolon \RedDSAPrivate) \times (M \type \begin{algorithm} \item Choose a byte sequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$. \item Let $\vkBytes{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\RedDSADerivePublic(\sk)}\kern 0.05em}$. - \vspace{-0.5ex} + \vspace{-0.75ex} \item Let $r = \RedDSAHashToScalar(T \bconcat \vkBytes{} \bconcat M)$. \item Let $\RedDSASigR{} = \scalarmult{r}{\GenG{}}$. \item Let $\RedDSAReprR{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\RedDSASigR{}}\kern 0.05em}$. - \vspace{-0.5ex} + \vspace{-0.75ex} \item Let $\RedDSASigS{} = (r + \RedDSAHashToScalar(\RedDSAReprR{} \bconcat \vkBytes{} \bconcat M) \mult \sk) \bmod \ParamG{r}$. \item Let $\RedDSAReprS{} = \ItoLEOSPOf{\bitlength(\ParamG{r})}{\RedDSASigS{}}$. \item Return $\RedDSAReprR{} \bconcat \RedDSAReprS{}$. @@ -9160,33 +9197,40 @@ Define $\RedDSAValidate{} \typecolon (\vk \typecolon \RedDSAPublic) \times (M \t \begin{algorithm} \item Let $\RedDSAReprR{}$ be the first $\ceiling{\ellG{}/8}$ bytes of $\sigma$, and let $\RedDSAReprS{}$ be the remaining $\ceiling{\bitlength(\ParamG{r})/8}$ bytes. + \vspace{-0.25ex} \item Let $\RedDSASigR{} = \abstG{}\big(\LEOStoBSP{\ellG{}}(\RedDSAReprR{})\kern-0.15em\big)$, and let $\RedDSASigS{} = \LEOStoIP{8 \mult \length(\RedDSAReprS{})}(\RedDSAReprS{})$. + \vspace{-1ex} \item Let $\vkBytes{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\vk}\kern 0.03em}$. - \vspace{-0.5ex} + \vspace{-1ex} \item Let $\RedDSASigc{} = \RedDSAHashToScalar(\RedDSAReprR{} \bconcat \vkBytes{} \bconcat M)$. - \vspace{0.5ex} \nufiveonwarditem{If $\reprG{}\Of{\RedDSASigR{}} \neq \RedDSAReprR{}$, return $0$.} + \vspace{-0.25ex} \item Return $1$ if $\RedDSASigR{} \neq \bot$ and $\RedDSASigS{} < \ParamG{r}$ and $\scalarmult{\ParamG{h}}{\big(\!\!-\!\scalarmult{\RedDSASigS{}}{\GenG{}} + \RedDSASigR{} + \scalarmult{\RedDSASigc{}}{\vk}\big)} = \ZeroG{}$, otherwise $0$. \end{algorithm} \vspace{-2ex} \begin{pnotes} + \vspace{-0.25ex} \item The validation algorithm \emph{does not} check that $\RedDSASigR{}$ is a point of order at least $\ParamG{r}$. \nufive{ + \vspace{-0.5ex} \item After activation of \cite{ZIP-216}, validation returns $0$ if $\RedDSAReprR{}$ is a \nonCanonicalPoint compressed point encoding. } + \vspace{-0.5ex} \item The value $\RedDSAReprR{}$ used as part of the input to $\RedDSAHashToScalar$ \MUST be exactly as encoded in the signature. + \vspace{-0.5ex} \item Appendix \crossref{reddsabatchvalidate} describes an optimization that \MAY be used to speed up validation of batches of $\RedDSA$ signatures. \end{pnotes} \vspace{-2ex} \begin{nnotes} + \vspace{-0.25ex} \item The randomization used in $\RedDSARandomizePrivate$ and $\RedDSARandomizePublic$ may interact with other uses of additive properties of keys for Schnorr-based signature schemes. In the \Zcash protocol, such properties are used for \bindingSignatures but not at the same time @@ -9194,6 +9238,7 @@ at least $\ParamG{r}$. but this does not result in any practical security weakness as long as the security recommendations of ZIP-32 are followed. If $\RedDSA$ is reused in other protocols making use of these additive properties, careful analysis of potential interactions is required. + \vspace{-0.25ex} \item It is \RECOMMENDED that, for deployments of $\RedDSA$ in other protocols than \Zcash, the requirement for $\RedDSAReprR{}$ to be canonically encoded is always enforced (which was the original intent of the design). @@ -9204,8 +9249,11 @@ The two abelian groups specified in \crossref{abstractsigmono} are instantiated as follows: \begin{itemize} \item $\grpzero := 0 \pmod{\ParamG{r}}$ + \vspace{-0.5ex} \item $\sk_1 \grpplus \sk_2 := \sk_1 + \sk_2 \pmod{\ParamG{r}}$ + \vspace{-0.5ex} \item $\combzero := \ZeroG{}$ + \vspace{-0.5ex} \item $\vk_1 \combplus \vk_2 := \vk_1 + \vk_2$. \end{itemize} @@ -9227,8 +9275,11 @@ length $\ellG{}$ bits (or as a corresponding byte sequence $\vkBytes{}$ by then \introlist The scheme $\RedJubjub$ specializes $\RedDSA$ with: \begin{itemize} + \vspace{-0.25ex} \item $\GroupG{} := \GroupJ$ as defined in \crossref{jubjub}; + \vspace{-0.75ex} \item $\RedDSAHashLength := 512$; + \vspace{-0.75ex} \item $\RedDSAHash(x) := \BlakeTwobOf{512}{\ascii{Zcash\_RedJubjubH}, x}$ as defined in \crossref{concreteblake2}. \end{itemize} @@ -9236,13 +9287,17 @@ The scheme $\RedJubjub$ specializes $\RedDSA$ with: \introlist The scheme $\RedPallas$ specializes $\RedDSA$ with: \begin{itemize} + \vspace{-0.25ex} \item $\GroupG{} := \GroupP$ as defined in \crossref{pallasandvesta}; + \vspace{-0.75ex} \item $\RedDSAHashLength := 512$; + \vspace{-0.75ex} \item $\RedDSAHash(x) := \BlakeTwobOf{512}{\ascii{Zcash\_RedPallasH}, x}$ as defined in \crossref{concreteblake2}. \end{itemize} } %nufive \vspace{-1ex} +\introlist The generator $\GenG{} \typecolon \SubgroupG{}$ is left as an unspecified parameter, different between $\BindingSig{Sapling}$\notbeforenufive{,}\notnufive{ and} $\SpendAuthSig{Sapling}$\nufive{, $\BindingSig{Orchard}$, and $\SpendAuthSig{Orchard}$}. @@ -9273,7 +9328,7 @@ with key re-randomization and with generator $\GenG{} = \AuthSignBase{Orchard}$. \vspace{0.5ex} See \crossref{spendauthsig} for details on the use of this \signatureScheme. -\vspace{-1ex} +\vspace{-2ex} \securityrequirement{ \nufive{Each instantiation of} $\SpendAuthSig{}$ must be a SURK-CMA secure \rerandomizableSignatureScheme as defined in \crossref{abstractsigrerand}. @@ -9298,6 +9353,7 @@ without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Or \crossref{concretevaluecommit}. See \crossref{orchardbalance} for details on the use of this \signatureScheme. } %nufive +\vspace{-2ex} \securityrequirement{ \nufive{Each instantiation of} $\BindingSig{}$ must be a SUF-CMA secure \keyMonomorphicSignatureScheme as defined in \crossref{abstractsigmono}. A signature must prove knowledge of the discrete logarithm of @@ -9308,7 +9364,7 @@ $\ValueCommitRandBase{Orchard}$}. \introlist -\vspace{-1ex} +\vspace{-2ex} \lsubsubsection{Commitment schemes}{concretecommit} \vspace{-1ex} @@ -9333,7 +9389,7 @@ $\ValueCommitRandBase{Orchard}$}. \end{lrbox} \vspace{-1ex} -The commitment scheme $\NoteCommit{Sprout}{}$ specified in \crossref{abstractcommit} is +The \commitmentScheme $\NoteCommit{Sprout}{}$ specified in \crossref{abstractcommit} is instantiated using \shaHash as follows: \begin{formulae}[leftmargin=1em] @@ -9469,7 +9525,7 @@ Define: \introlist The commitment scheme $\ValueCommitAlg{Sapling}$ specified in \crossref{abstractcommit} is -instantiated as follows using $\HomomorphicPedersenCommit{Sapling}{}$ on the \jubjubCurve: +instantiated as follows using $\HomomorphicPedersenCommitAlg{Sapling}$ on the \jubjubCurve: \begin{formulae} \item $\ValueCommitAlg{\ValueCommitRand}(\Value) := \HomomorphicPedersenCommit{Sapling}{\ValueCommitRand}(\ascii{Zcash\_cv}, \Value)$. @@ -9484,7 +9540,7 @@ which is equivalent to: \nufive{ \introlist The commitment scheme $\ValueCommitAlg{Orchard}$ specified in \crossref{abstractcommit} is -instantiated as follows using $\HomomorphicPedersenCommit{Orchard}{}$ on the \pallasCurve: +instantiated as follows using $\HomomorphicPedersenCommitAlg{Orchard}$ on the \pallasCurve: \begin{formulae} \item $\ValueCommit{Orchard}{\ValueCommitRand}(\Value) := \HomomorphicPedersenCommit{Orchard}{\ValueCommitRand}(\ascii{z.cash:Orchard-cv}, \Value)$. @@ -9531,6 +9587,7 @@ and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta} \ExtractP\big(\SinsemillaCommit{r}(D, M)\kern-0.1em\big)$. \end{formulae} +\vspace{-1ex} See \cite[section TODO]{Zcash-Orchard} for rationale and efficient circuit implementation of this function. \vspace{0.5ex} @@ -9964,7 +10021,7 @@ $\abstJ\Of{P\Repr}$ is computed as follows: \item if $\LEBStoIPOf{255}{\varv\Repr} \geq \ParamJ{q}$ then return $\bot$, otherwise let $\varv \typecolon \GF{\ParamJ{q}} = \LEBStoIPOf{255}{\varv\Repr} \pmod{\ParamJ{q}}$. \item let $u = \optsqrt{\hfrac{1 - \varv^2}{\ParamJ{a} - \ParamJ{d} \mult \varv^2}}$.\; - (The denominator $\ParamJ{a} - \ParamJ{d} \smult \varv^2$ cannot be zero, since $\hfrac{\ParamJ{a}}{\ParamJ{d}}$ is not square in $\GF{\ParamJ{q}}$.) + (The denominator $\ParamJ{a} - \ParamJ{d} \smult \varv^2$ cannot be zero, since $\hfrac{\ParamJ{a}}{\ParamJ{d}}$ is not square in $\GF{\ParamJ{q}}$.) \item if $u = \bot$, return $\bot$. \item if $u \bmod 2 = \tilde{u}$ then return $(u, \varv)$ else return $(\ParamJ{q} - u, \varv)$. \end{formulae} @@ -10027,6 +10084,7 @@ $\SubgroupJ$ is of odd-prime order.} \theoremlabel{lemmasubgroupnegation} \begin{lemma}[Let $P = (u, \varv) \in \SubgroupJ$. Then $(u, -\varv) \notin \SubgroupJ$]\end{lemma} +\vspace{-1ex} \begin{proof} If $P = \ZeroJ$ then $(u, -\varv) = (0, -1) \notin \SubgroupJ$. Else, $P$ is of odd-prime order. Note that $\varv \neq 0$. @@ -10047,6 +10105,7 @@ since $\SubgroupJ$ is of odd order \cite{KvE2013}). \theoremlabel{thmselectuinjective} \begin{theorem}[$\Selectu$ is injective on $\SubgroupJ$]\end{theorem} +\vspace{-1ex} \begin{proof} By writing the curve equation as $\varv^2 = (1 - a \smult u^2) / (1 - d \smult u^2)$, and noting that the @@ -10066,6 +10125,7 @@ $\ExtractJ$ is injective on $\SubgroupJ$. \sapling{ \introlist +\vspace{-1ex} \lsubsubsubsection{Group Hash into \JubjubText}{concretegrouphashjubjub} \vspace{-1ex} @@ -10078,13 +10138,15 @@ different purposes.) Let $\URS$ be the MPC randomness beacon defined in \crossref{beacon}. +\vspace{-0.25ex} Let $\BlakeTwos{256}$ be as defined in \crossref{concreteblake2}. +\vspace{-0.25ex} Let $\LEOStoIP{}$ be as defined in \crossref{endian}. +\vspace{-0.25ex} Let $\SubgroupJ$, $\SubgroupJstar$, and $\abstJ$ be as defined in \crossref{jubjub}. -\vspace{1ex} Let $D \typecolon \byteseq{8}$ be an $8$-byte domain separator, and let $M \typecolon \byteseqs$ be the hash input. @@ -10099,7 +10161,7 @@ The hash $\GroupJHash{\URS}(D, M) \typecolon \SubgroupJstar$ is calculated as fo \item if $Q = \ZeroJ$ then return $\bot$, else return $Q$. \end{algorithm} -\vspace{-2ex} +\vspace{-1ex} \begin{pnotes} \vspace{-0.5ex} \item The use of $\GroupJHash{\URS}$ for $\DiversifyHash{Sapling}$ and to generate independent bases @@ -10123,6 +10185,7 @@ The hash $\GroupJHash{\URS}(D, M) \typecolon \SubgroupJstar$ is calculated as fo \end{pnotes} \vspace{0.5ex} +\introlist Define $\first \typecolon (\byte \rightarrow \maybe{T}) \rightarrow \maybe{T}$ so that $\first(f) = f(i)$ where $i$ is the least integer in $\byte$ such that $f(i) \neq \bot$, or $\bot$ if no such $i$ exists. @@ -10226,6 +10289,7 @@ Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, and $\ParamP{b}$ be as defined in \crossr Define $\GroupPstarx$ be the set of $x$-coordinates of points on the \pallasCurve, i.e.\ $\setof{x \typecolon \GF{\ParamP{q}} \suchthat x^3 + \ParamP{b}\text{ is square in }\GF{\ParamP{q}}}$. +\vspace{-0.5ex} Define $\GroupPx := \GroupPstarx \union \setof{0}$. \vspace{1ex} @@ -10418,10 +10482,12 @@ Define $\maptocurvesimpleswuIsoG(u \typecolon \GF{\ParamG{q}}) \rightarrow \Grou \item let $\mathsf{ta} = \mathsf{Zuu}^2 + \mathsf{Zuu}$ \item let $\mathsf{x1}_\num = \ParamIsoG{b} \mult (\mathsf{ta} + 1)$ \item let $\mathsf{x}_\xdiv = \ParamIsoG{a} \mult \big(\kern-0.1em(\mathsf{ta} = 0) \bchoose \ParamIsoG{Z} : -\mathsf{ta}\big)$ + \vspace{-0.25ex} \item compute $\mathsf{x}_\xdiv^2$ and $\mathsf{x}_\xdiv^3$ \item let $\mathsf{U} = (\mathsf{x1}_\num^2 + \ParamIsoG{a} \mult \mathsf{x}_\xdiv^2) \mult \mathsf{x1}_\num + \ParamIsoG{b} \mult \mathsf{x}_\xdiv^3$ \item let $\mathsf{x2}_\num = \mathsf{Zuu} \mult \mathsf{x1}_\num$ \item let $(\mathsf{y1},\, \mathsf{is\_gx1\_square}) = \sqrtratioG(\mathsf{U},\, \mathsf{x}_\xdiv^3)$ + \vspace{-0.5ex} \item let $\mathsf{y2} = \ParamIsoG{\theta} \mult \mathsf{Zuu} \mult u \mult \mathsf{y1}$ \item let $\mathsf{x}_\num = \mathsf{is\_gx1\_square} \bchoose \mathsf{x1}_\num : \mathsf{x2}_\num$ \item let $\mathsf{y}' = \mathsf{is\_gx1\_square} \bchoose \mathsf{y1} : \mathsf{y2}$ @@ -11029,7 +11095,7 @@ considered invalid if $\abstJ$ returns $\bot$. \nufive{\cite{ZIP-216} specifies that the address \MUST also be considered invalid if the resulting $\DiversifiedTransmitPublic$ is not in the prime-order subgroup $\SubgroupJ$, or -if it is a non-canonical encoding as defined in \crossref{abstractgroup}. This \MAY be +if it is a \nonCanonicalPoint encoding as defined in \crossref{abstractgroup}. This \MAY be enforced in advance of activation of \NUFive.} \vspace{1ex} @@ -11733,12 +11799,12 @@ An \orchardBindingSignature on the \sighashTxHash, validated per \crossref{concr } %scalebox \vspace{-0.3ex} -\scalebox{0.86}{ -\begin{tabularx}{1.16\textwidth}{@{\!\!}l@{\hskip 1em}X@{}} $\ddagger$ & The fields \valueBalance{Sapling}, \anchorField{Sapling}, \vSpendProofsSapling, \vSpendAuthSigs{Sapling}, \vOutputProofsSapling, and \bindingSig{Sapling} are present if and only if $\nSpendsSapling + \nOutputsSapling > 0$. If \valueBalance{Sapling} is not present, then $\vBalance{Sapling}$ is defined to be $0$. \\[-0.5ex] +\scalebox{0.87}{ +\begin{tabularx}{1.14\textwidth}{@{\!\!}l@{\hskip 1em}X@{}} $\mathsection$ & The fields \flagsOrchard, \valueBalance{Orchard}, \anchorField{Orchard}, \sizeProofsOrchard, \proofsOrchard, \vSpendAuthSigs{Orchard}, and \bindingSig{Orchard} @@ -11748,8 +11814,8 @@ then $\vBalance{Orchard}$ is defined to be $0$. } %scalebox \end{center} \vspace{-2ex} -\scalebox{0.86}{ -\!\!\Transactionversion 5 does not support \joinSplitTransfers. +\scalebox{0.87}{ +\raggedright\!\!\Transactionversion 5 does not support \joinSplitTransfers. Several fields are reordered and/or renamed relative to prior versions. } %scalebox } %nufive @@ -11904,7 +11970,7 @@ each \spendDescription\, (\crossref{spendencodingandconsensus}),\,\notnufive{ an \nufive{ \item The flags in \flagsOrchard{} allow a version 5 \transaction to declare that no funds are spent from \Orchard \notes (by setting \enableSpendsOrchard{} to $0$), or that no new \Orchard \notes - with non-zero values are created (by setting \enableOutputsOrchard{} to $0$). This has two primary + with nonzero values are created (by setting \enableOutputsOrchard{} to $0$). This has two primary purposes. First, the \enableSpendsOrchard{} flag is set to $0$ in version 5 \coinbaseTransactions to ensure that they cannot spend from existing \Orchard outputs. This maintains a restriction present in \coinbaseTransactions for \transparent, \Sprout, or \Sapling funds, which would not otherwise @@ -13271,7 +13337,7 @@ amounts of currency for themself \cite{HW2016}. commitment: \shaHash for \Sprout\sapling{, and $\PedersenHash$ for \Sapling}. The motivation for the nested construction in \Zerocash was to allow Mint transactions to be publically verified without requiring -a \zkSNARKProof (\cite[section 1.3, under step 3]{BCGGMTV2014}). +\zkSNARKProofs (\cite[section 1.3, under step 3]{BCGGMTV2014}). Since \Zcash combines ``Mint'' and ``Pour'' transactions into generalized \joinSplitTransfers (for \Sprout), \sapling{or \spendTransfers and \outputTransfers (for \Sapling)}, and each @@ -13314,7 +13380,7 @@ These truncations are not taken into account in the security proofs. Both truncations affect the validity of the proof sketch for Lemma D.2 in the proof of Ledger Indistinguishability in \cite[Appendix D]{BCGGMTV2014}. -\introlist +\introsection In more detail: \begin{itemize} @@ -13522,6 +13588,7 @@ constraint 1(b) of the \joinSplitStatement (see \crossref{sproutspendauthority}) implies distinctness of $\AuthPublicOldX{1}$ and $\AuthPublicOldX{2}$, therefore distinct openings of the \noteCommitment when Condition I or II is violated. +\introlist \lsubsection{Miscellaneous}{miscdiffs} \begin{itemize} @@ -13555,12 +13622,11 @@ distinct openings of the \noteCommitment when Condition I or II is violated. \end{itemize} -\introsection +\introlist \lsection{Acknowledgements}{acknowledgements} The inventors of \Zerocash are Eli Ben-Sasson, Alessandro Chiesa, -Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars -Virza. +Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. The designers of the \Zcash protocol are the \Zerocash inventors and also Daira Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, @@ -13604,7 +13670,7 @@ linking \diversifiedPaymentAddresses, avoided in the adopted design, was found by Brian Warner. The design of \Orchard is primarily due to Daira Hopwood, Sean Bowe, Jack Grigg, -Kris Nuttycombe, Ying Tong Lai, and Steven Smith. +Kris Nuttycombe, Ying~Tong Lai, and Steven Smith. The observation in \crossref{concretediversifyhash} that \diversifiedPaymentAddress unlinkability can be proven in the same way @@ -13632,7 +13698,7 @@ to resolve the tension between privacy and auditability, Merkle trees over note commitments (using Pedersen hashes as in \Sapling), and the use of ``serial numbers'' or \nullifiers to detect or prevent double-spends--- were first applied to privacy-preserving digital currencies -by Tomas Sander and Amnon Ta–Shma. To a large extent \Zcash is a refinement +by Tomas Sander and Amnon Ta-Shma. To a large extent \Zcash is a refinement of their ``Auditable, Anonymous Electronic Cash'' proposal in \cite{ST1999}. We thank Alexandra Elbakyan for her tireless work in dismantling barriers @@ -13717,7 +13783,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Correct \theoremref{thmuncommittedsapling}, which was proving the wrong thing. It needs to prove that $\NoteCommitAlg{Sapling}$ does not return $\Uncommitted{Sapling}$, but was previously proving that $\PedersenHash$ does not return that value. - \item The note about non-canonical encodings in \crossref{jubjub} gave incorrect values + \item The note about \nonCanonicalPoint encodings in \crossref{jubjub} gave incorrect values for the encodings of the point of order $2$, by omitting a $\ParamJ{q}$ term. \item The specification of decryption in \crossref{decryptovk} differed from its implementation in \zcashd, in two respects: @@ -14307,11 +14373,11 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \crossref{cctednonsmallorder} accurately reflect the implementation in sapling-crypto. \item Minor correction to the non-normative note in \crossref{cctrange}. - \item Clarify the non-normative note in \crossref{abstractcommit} about + \item Clarify non-normative note in \crossref{abstractcommit} about the definitions of $\ValueCommitOutput{Sapling}$ and $\NoteCommitOutput{Sapling}$. \item Clarify that the signer of a \spendAuthSignature is supposed to choose - the \spendAuthRandomizer, $\AuthSignRandomizer$, itself. Only step 4 in the - procedure in \crossref{spendauthsig} may securely be delegated. + the \spendAuthRandomizer, $\AuthSignRandomizer$, itself. Only step 4 in + \crossref{spendauthsig} may securely be delegated. \item Add a non-normative note to \crossref{concretereddsa} explaining that $\RedDSA$ key randomization may interact with other uses of additive properties of Schnorr keys. @@ -15437,7 +15503,7 @@ $c_{\barerange{n-2}{0}}$. Assume $c_{\barerange{0}{n-1}} \typecolon \bitseq{n}$ and $c_{n-1} = 1$. Define $A_m := \ssum{i=m}{n-1} a_i \mult 2^i$ and $C_m := \ssum{i=m}{n-1} c_i \mult 2^i$. -For any\, $m \in \range{0}{n-1}$, $A_m \leq C_m$ iff the restriction of the above +For any\, $m \in \range{0}{n-1}$, $A_m \leq C_m$ if and only if the restriction of the above constraint system to $i \in \range{m}{n-1}$ is satisfied. Furthermore the system at least boolean-constrains $a_{\barerange{0}{n-1}}$. \end{theorem} @@ -15471,7 +15537,7 @@ Inductive case $m < n-1$: \begin{itemize} \item If $A_{m+1} = C_{m+1}$, then $a_i = c_i$ for all $i \in \range{m+1}{n-1}$ and so $\Pi_{m+1} = 1$. - Also $A_m \leq C_m$ iff $a_m \leq c_m$. \\ + Also $A_m \leq C_m$ if and only if $a_m \leq c_m$. \\ When $c_m = 1$, only a boolean constraint is added for $a_m$ which fulfils the theorem. \\ When $c_m = 0$, $a_m$ is constrained to be $0$ which fulfils the theorem. \item If $A_{m+1} < C_{m+1}$, then it cannot be the case that $a_i \geq c_i$ @@ -15876,10 +15942,11 @@ a total of $750$ constraints. Fixed-base scalar multiplication is also used in two places with shorter scalars: \begin{itemize} - \item \crossref{ccthomomorphiccommit} uses a $64$-bit scalar for the + \item \crossref{ccthomomorphiccommit} uses $64$ bits for the $\Value$ input to $\ValueCommitAlg{Sapling}$, requiring $22$ windows at a cost of $3 \smult 22 - 1 + 6 \smult 21 = 191$ constraints; - \item \crossref{cctmixinghash} uses a $32$-bit scalar for the + \vspace{-0.25ex} + \item \crossref{cctmixinghash} uses $32$ bits for the $\NotePosition$ input to $\MixingPedersenHash$, requiring $11$ windows at a cost of $3 \smult 11 - 1 + 6 \smult 10 = 92$ constraints. \end{itemize} @@ -15894,13 +15961,14 @@ None of these costs include the cost of boolean-constraining the scalar. fixed-base scalar multiplication in the \spendCircuit and two in the \outputCircuit\footnote{A \xPedersenCommitment uses fixed-base scalar multiplication as a subcomponent.}, the additional complexity was not considered justified for \Sapling. + \vspace{-0.25ex} \item For the multiplications with $64$-bit and $32$-bit scalars, the scalar is padded to a multiple of $3$ bits with zeros. This causes the computation of $s\suband$ in the lookup for the most significant window to be optimized out, which is where the ``$-\;1$'' comes from in the above cost calculations. No further optimization is done for this lookup. \end{nnotes} -\vspace{-2ex} +\vspace{-2.5ex} \introsection @@ -15920,12 +15988,15 @@ Given $k = \ssum{i=0}{250} k_i \smult 2^i$, we calculate $R = \scalarmult{k}{B}$ \item let $\Acc^{\spv}_0\hairspace = k_0 \bchoose \Base^{\spv}_0 : 1$ \vspace{1ex} \item for $i$ from $1$ up to $250$: + \vspace{-0.25ex} \item \tab let $\Base_i = \scalarmult{2}{\Base_{i-1}}$ - \vspace{1ex} + \vspace{0.5ex} \item \tab // select $\Base_i$ or $\ZeroJ$ depending on the bit $k_i$ \item \tab let $\Addend^u_i = k_i \bchoose \Base^u_i : 0$ \item \tab let $\Addend^{\spv}_i\hairspace = k_i \bchoose \Base^{\spv}_i : 1$ + \vspace{-0.25ex} \item \tab let $\Acc_i = \Acc_{i-1} + \Addend_i$ + \vspace{1ex} \item let $R = \Acc_{250}$. \end{algorithm} @@ -16003,7 +16074,7 @@ We have to prove that: The proof of \theoremref{thmpedersenencodeinjective} showed that all indices of addition inputs are in the range -$\bigrangenozero{-\hfrac{\ParamJ{r}-1}{2}}{\hfrac{\ParamJ{r}-1}{2}}$. +$\bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$. Because the $\PedersenGen{D}{j}$ (which are outputs of $\GroupJHash{}$) are all of prime order, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, @@ -16016,6 +16087,7 @@ the conversions will not encounter exceptional cases. We also need to show that the indices of addition inputs are all distinct disregarding sign. +\introlist \theoremlabel{thmpedersendistinctabsindices} \begin{theorem}[Concerning addition inputs in the Pedersen circuit] @@ -16242,7 +16314,7 @@ In order to support this property, we also define \homomorphicPedersenCommitment as follows: \begin{formulae} - \item $\HomomorphicPedersenCommit{\ValueCommitRand}(D, \Value) = + \item $\HomomorphicPedersenCommit{Sapling}{\ValueCommitRand}(D, \Value) = \scalarmult{\Value}{\FindGroupJHash\Of{D, \ascii{v}}}\, + \scalarmult{\ValueCommitRand}{\FindGroupJHash\Of{D, \ascii{r}}}$ \end{formulae} @@ -16424,18 +16496,18 @@ The primary input is \vspace{1ex} \begin{formulae} \item $\oparen\rt{Sapling} \typecolon \MerkleHash{Sapling},\\ - \hparen\cvOld{} \typecolon \ValueCommitOutput,\\ + \hparen\cvOld{} \typecolon \ValueCommitOutput{Sapling},\\ \hparen\nfOld{} \typecolon \PRFOutputNfSapling,\\ - \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic\cparen$, + \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Sapling}\cparen$, \end{formulae} which is encoded as $8$ $\GF{\ParamS{r}}$ elements (starting with the fixed element $1$ required by \Groth): \begin{formulae} - \item $[1, \Selectu(\AuthSignRandomizedPublic), \Selectv(\AuthSignRandomizedPublic), - \Selectu(\cvOld{}), \Selectv(\cvOld{}), \LEBStoIPOf{\MerkleHashLength{Sapling}}{\rt{Sapling}}, - \LEBStoIP{254}\big(\nfOldRepr{\!\barerange{0}{253}}\big), \LEBStoIP{2}\big(\nfOldRepr{\!\barerange{254}{255}}\big)]$ + \item $\big[1, \Selectu(\AuthSignRandomizedPublic), \Selectv(\AuthSignRandomizedPublic), + \Selectu(\cvOld{}), \Selectv(\cvOld{}), \LEBStoIP{\MerkleHashLength{Sapling}}\big(\rt{Sapling}\big), + \LEBStoIP{254}\big(\nfOldRepr{\!\barerange{0}{253}}\big), \LEBStoIP{2}\big(\nfOldRepr{\!\barerange{254}{255}}\big)\big]$ \end{formulae} \vspace{-2ex} -where $\nfOldRepr{} = \LEOStoBSP{\PRFOutputLengthNfSapling}(\nfOld{})$. +where $\nfOldRepr{} = \LEOStoBSP{\PRFOutputLengthNfSapling}\big(\nfOld{}\big)$. \introlist \vspace{1ex} @@ -16610,8 +16682,8 @@ The primary input is which is encoded as $6$ $\GF{\ParamS{r}}$ elements (starting with the fixed element $1$ required by \Groth): \begin{formulae} - \item $[1, \Selectu\Of{\cvNew{}}, \Selectv\Of{\cvNew{}}, - \Selectu\Of{\EphemeralPublic}, \Selectv\Of{\EphemeralPublic}, \LEBStoIPOf{\MerkleHashLength{Sapling}}{\cmU}]$ + \item $\big[1, \Selectu\Of{\cvNew{}}, \Selectv\Of{\cvNew{}}, + \Selectu\Of{\EphemeralPublic}, \Selectv\Of{\EphemeralPublic}, \LEBStoIPOf{\MerkleHashLength{Sapling}}{\cmU}\big]$ \end{formulae} The auxiliary input is @@ -16735,9 +16807,10 @@ Define $\RedDSABatchValidate \typecolon (\Entry{\barerange{0}{N-1}} \typecolon \ let $\RedDSAReprS{j}$ be the remaining $\ceiling{\bitlength(\ParamG{r})/8}$ bytes. \item \tab Let $\RedDSASigR{j} = \abstG{}\big(\LEOStoBSP{\ellG{}}(\RedDSAReprR{j})\kern-0.12em\big)$, and let $\RedDSASigS{j} = \LEOStoIP{8 \mult \length(\RedDSAReprS{j})}(\RedDSAReprS{j})$. + \vspace{-0.5ex} \item \tab Let $\vkBytes{j} = \LEBStoOSPOf{\ellG{}}{\reprG{}(\vk_j)\kern-0.1em}$. + \vspace{-1ex} \item \tab Let $\RedDSASigc{j} = \RedDSAHashToScalar(\RedDSAReprR{j} \bconcat \vkBytes{j} \bconcat M_j)$. - \vspace{1ex} \item \tab Choose random $z_j \typecolon \GFstar{\ParamG{r}} \leftarrowR \range{1}{2^{128}-1}$. \item \blank \item Return $1$ if @@ -16875,8 +16948,10 @@ the cost of batched verification is therefore \item for each proof: the cost of decoding the proof representation to the form $\GrothSProof$, which requires three point decompressions and three subgroup checks (two for $\SubgroupSstar{1}$ and one for $\SubgroupSstar{2}$); + \vspace{-0.25ex} \item for each successfully decoded proof: a Miller loop; and a $128$-bit scalar multiplication by $z_j$ in $\SubgroupS{1}$; + \vspace{-0.25ex} \item for each verification key: two Miller loops; an exponentiation in $\SubgroupS{T}$; a multiscalar multiplication in $\SubgroupS{1}$ with $N$ $128$-bit scalars to compute $\Accum{\Delta}$; and a multiscalar multiplication in $\SubgroupS{1}$ with $\ell+1$ $255$-bit scalars to compute @@ -16920,7 +16995,6 @@ Define $\EdSpecificBatchValidate \typecolon (\Entry{\barerange{0}{N-1}} \typecol let $\EdDSASigS{j} = \LEOStoIP{256}(\EdDSAReprS{j})$. \item \tab Let $\EdDSAReprA{j} = \reprBytesEdSpecific(\EdDSASigA{j})$. \item \tab Let $\EdDSASigc{j} = \LEOStoIP{512}\big(\BigSHAFull(\EdDSAReprR{j} \bconcat \EdDSAReprA{j} \bconcat M_j)\kern-0.12em\big)$. - \vspace{1ex} \item \tab Choose random $z_j \typecolon \GFstar{\ell} \leftarrowR \range{1}{2^{128}-1}$. \item \blank \item Return $1$ if From 54a0894acf66e54f816618a006e505525925373b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Tue, 23 Mar 2021 20:07:37 +0000 Subject: [PATCH 11/41] NCC audit: fix 'reasonable' typo. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 863732ed..dfacf265 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -4382,7 +4382,7 @@ the \jubjubCurve defined by \crossref{jubjub}. \vspace{-2ex} \securityrequirement{ For a randomly selected $\URS \typecolon \SubgroupGHashURSType$, -it must be reasonble to model $\SubgroupGHash{\URS}$ (restricted to inputs for which it does +it must be reasonable to model $\SubgroupGHash{\URS}$ (restricted to inputs for which it does not return $\bot$) as a \randomOracle. } %securityrequirement @@ -13711,10 +13711,16 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \lsection{Change History}{changehistory} -\historyentry{2021.1.20}{2021-03-18} +\historyentry{2021.1.20}{2021-03-23} \begin{itemize} +\nufive{ + \item Correct some interim findings of the NCC specification audit: + \begin{itemize} + \item Fix typos. + \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. +} %nufive \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). \item Remove magenta highlighting of differences from \Zerocash. From b14c33291093ba58ab37fba928f24eab4932dd20 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:23:51 +0000 Subject: [PATCH 12/41] NCC audit: Correct the definition of c in \crossref{concretesinsemillahash}. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index dfacf265..2109f43d 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -8257,7 +8257,7 @@ be as defined in \crossref{endian}. Let $k := 10$. \vspace{-0.25ex} -Let $c$ be the largest integer such that $2^n \leq \hfrac{\ParamP{r}-1}{2}$, +Let $c$ be the largest integer such that $2^c \leq \hfrac{\ParamP{r}-1}{2}$, i.e.\ $c := 253$. \introlist @@ -13717,6 +13717,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Correct some interim findings of the NCC specification audit: \begin{itemize} \item Fix typos. + \item Correct the definition of $c$ in \crossref{concretesinsemillahash}. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. From 20478ae40d00963c27d0332544ac2aa03aeea2cb Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 25 Mar 2021 21:20:33 +0000 Subject: [PATCH 13/41] Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, Kevin Gorham, Larry Ruane, Marshall Gaucher, and Ryan Taylor to the acknowledgements. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 2109f43d..55a1b253 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -13630,8 +13630,8 @@ Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. The designers of the \Zcash protocol are the \Zerocash inventors and also Daira Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby, -Nathan Wilcox, Zooko Wilcox, Jay Graber, Ariel Gabizon, George Tankersley, -Ying Tong Lai, Kris Nuttycombe, Jack Gavigan, and Steven Smith. +Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik Ogilvie-Wigley, Ariel Gabizon, +George Tankersley, Ying~Tong Lai, Kris Nuttycombe, Jack Gavigan, and Steven Smith. The \Equihash proof-of-work algorithm was designed by Alex Biryukov and Dmitry Khovratovich. @@ -13641,10 +13641,12 @@ includes Mike Perry, isis agora lovecruft, Leif Ryge, Andrew Miller, Ben Blaxill Samantha Hulsey, Alex Balducci, Jake Tarren, Solar Designer, Ling Ren, John Tromp, Paige Peterson, jl777, Alison Stevenson, Maureen Walsh, Filippo Valsorda, Zaki Manian, Tracy Hu, Brian Warner, Mary Maller, -Michael Dixon, Andrew Poelstra, Eirik Ogilvie-Wigley, Benjamin Winston, +Michael Dixon, Andrew Poelstra, Benjamin Winston, Kobi Gurkan, Weikeng Chen, Henry de Valence, Deirdre Connolly, Chelsea Komlo, Zancas Wilcox, Jane Lusby, Teor, Izaak Meckler, Zac Williamson, Vitalik Buterin, -Jakub Zalewski, Oana Ciobotaru, and no doubt others. +Jakub Zalewski, Oana Ciobotaru, Andre Serrano, Brad Miller, Charlie O'Keefe, +David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, +Kevin Gorham, Larry Ruane, Marshall Gaucher, Ryan Taylor, and no doubt others. We would also like to thank the designers and developers of \Bitcoin. \Zcash has benefited from security audits performed by NCC Group, Coinspect, @@ -13713,6 +13715,9 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \historyentry{2021.1.20}{2021-03-23} \begin{itemize} + \item Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, + Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, + Kevin Gorham, Larry Ruane, Marshall Gaucher, and Ryan Taylor to the acknowledgements. \nufive{ \item Correct some interim findings of the NCC specification audit: \begin{itemize} From c11c329bebcaadcd094f92b9956c2cec521d34a3 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 25 Mar 2021 23:31:36 +0000 Subject: [PATCH 14/41] NCC audit: Propagate \bot intermediate results to the output of Sinsemilla primitives. Change the output types of NoteCommitAlg^Orchard and CommitIvkAlg to reflect that these can return \bot, and change the action statement to be satisfied if they do. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 184 +++++++++++++++++++++++++++++++----------- 1 file changed, 139 insertions(+), 45 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 55a1b253..eb2ce165 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -2180,6 +2180,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\IsoConstP}[1]{\mathcal{C}^{\GroupP}_{#1}} \newcommand{\ExtractP}{\Extract_{\GroupP}} +\newcommand{\ExtractPbot}{\Extract^{\kern-0.03em\scalebox{0.65}{$\bot$}}_{\GroupP}} \newcommand{\GroupPHash}{\GroupHash^{\GroupP}} \newcommand{\GroupPHashInput}{\GroupPHash{}\mathsf{.Input}} \newcommand{\GroupPHashURSType}{\GroupPHash{}\mathsf{.URSType}} @@ -3157,6 +3158,9 @@ $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRa \vspace{-2.5ex} where $\NoteCommitAlg{Orchard}$ is instantiated in \crossref{concretesinsemillacommit}. +If $\NoteCommitAlg{Orchard}$ returns $\bot$ (which happens with insignificant probability), +the \note is invalid and should be recreated with a different $\NoteSeedBytes$. + Unlike in \Sapling, the definition of an \Orchard \note includes the $\NoteUniqueRand$ field; the \note's position in the \noteCommitmentTree does not need to be known in order to compute this value. @@ -4269,11 +4273,11 @@ Let $\GroupP$, $\GroupPx$, $\ellP$, $\ParamP{q}$, and $\ParamP{r}$ be as defined Define: \begin{formulae} \item $\NoteCommitTrapdoor{Orchard} := \binaryrange{\ScalarLength{Orchard}}$ and - $\NoteCommitOutput{Orchard} := \GroupP$; + $\NoteCommitOutput{Orchard} := \maybe{\GroupP}$; \item $\ValueCommitTrapdoor{Orchard} := \binaryrange{\ScalarLength{Orchard}}$ and $\ValueCommitOutput{Orchard} := \GroupP$. \item $\CommitIvkTrapdoor := \binaryrange{\ScalarLength{Orchard}}$ and - $\CommitIvkOutput := \InViewingKeyTypeOrchard$. + $\CommitIvkOutput := \maybe{\InViewingKeyTypeOrchard}$. \end{formulae} \introlist @@ -4286,6 +4290,9 @@ Define: $\CommitIvkAlg $&$\typecolon\; \CommitIvkTrapdoor \times \GroupPx \times \NullifierKeyTypeOrchard $&$\rightarrow \CommitIvkOutput$ \end{tabular} +\vspace{-1ex} +\nnote{$\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ can return $\bot$ with insignificant probability.} + $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ are instantiated in \crossref{concreteorchardnotecommit}. $\ValueCommitAlg{Orchard}$ is instantiated in \crossref{concretevaluecommit}. } %nufive @@ -4837,6 +4844,7 @@ as follows: \item \blank \item let $\AuthSignPublic = \ExtractP(\AuthSignPublicPoint)$ \item let $\InViewingKey = \CommitIvk{\CommitIvkRand}\big(\AuthSignPublic, \NullifierKey\big)$ + \item if $\InViewingKey = \bot$, discard this key and repeat with a new $\SpendingKey$. \item let $K = \ItoLEBSPOf{\SpendingKeyLength}{\CommitIvkRand}$ \vspace{-0.2ex} \item let $R = \PRFexpand{K}\big([\hexint{82}] \bconcat \ItoLEOSPOf{256}{\AuthSignPublic} \bconcat \ItoLEOSPOf{256}{\NullifierKey}\kern-0.25em\big)$ @@ -5447,6 +5455,7 @@ and then performs the following steps: \reprP\Of{\DiversifiedTransmitPublic}, \Value, \NoteUniqueRand, \NoteNullifierRand)$. \vspace{0.25ex} + \item If $\cm = \bot$, return $\bot$. \item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteSeedBytes, \Memo)$. \vspace{0.25ex} \item Encrypt $\NotePlaintext{}$ to the recipient @@ -5614,6 +5623,7 @@ constructed as follows: \item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}\big(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, \Value, \NoteUniqueRand, \NoteNullifierRand\big)$. + \item If $\cm = \bot$, return $\bot$. \item Let $\nf = \DeriveNullifier{\NullifierKey}(\NoteUniqueRand, \NoteNullifierRand, \cm)$. \item Construct a \dummy \merklePath $\TreePath{}$ for use in the \auxiliaryInput to the \spendStatement (this will not be checked, because $\Value = 0$). @@ -6683,6 +6693,9 @@ Let $\SpendAuthSig{Orchard}$ be as defined in \crossref{concretespendauthsig}. \vspace{-0.25ex} Let $\GroupP$, $\GroupPstar$, $\GroupPx$, $\reprP$, $\ParamP{q}$, and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. +\vspace{-0.25ex} +Let $\ExtractP$ and $\ExtractPbot$ be as defined in \crossref{concreteextractorpallas}. + \vspace{-0.25ex} Let $\DeriveNullifierAlg$ be as defined in \crossref{commitmentsandnullifiers}. @@ -6732,11 +6745,11 @@ such that the following conditions hold: \introlist \snarkcondition{Old note commitment integrity}{actionoldnotecommitmentintegrity} -$\cmOld{} = \NoteCommit{Orchard}{\NoteCommitRandOld{}}(\reprP\big(\DiversifiedTransmitBaseOld\big), - \reprP\big(\DiversifiedTransmitPublicOld), - \vOld{}, - \NoteUniqueRandOld{}, - \NoteNullifierRandOld)$. +$\NoteCommit{Orchard}{\NoteCommitRandOld{}}(\reprP\big(\DiversifiedTransmitBaseOld\big), + \reprP\big(\DiversifiedTransmitPublicOld), + \vOld{}, + \NoteUniqueRandOld{}, + \NoteNullifierRandOld) \in \setof{\cmOld{}, \bot}$. \vspace{-0.5ex} \snarkcondition{Merkle path validity}{actionmerklepathvalidity} @@ -6754,17 +6767,15 @@ $\nfOld{} = \DeriveNullifier{\NullifierKey}(\NoteUniqueRandOld{}, \NoteNullifier $\AuthSignRandomizedPublic = \SpendAuthSigRandomizePublic{Orchard}(\AuthSignRandomizer, \AuthSignPublicPoint)$. \snarkcondition{Diversified address integrity}{actionaddressintegrity} -$\DiversifiedTransmitPublicOld = \scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$ where +$\InViewingKey = \bot$ or $\DiversifiedTransmitPublicOld = \scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$ where $\InViewingKey = \CommitIvk{\CommitIvkRandom}\big(\ExtractP(\AuthSignPublicPoint), \NullifierKey\big)$. \snarkcondition{New note commitment integrity}{actionnewnotecommitmentintegrity} -$\cmX = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRandNew{}}(\DiversifiedTransmitBaseNewRepr, - \DiversifiedTransmitPublicNewRepr, - \vNew{}, - \NoteUniqueRandNew{}, - \NoteNullifierRandNew)\kern-0.12em\big)$, - -\vspace{-1.5ex} +$\ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRandNew{}}(\DiversifiedTransmitBaseNewRepr, + \DiversifiedTransmitPublicNewRepr, + \vNew{}, + \NoteUniqueRandNew{}, + \NoteNullifierRandNew)\kern-0.1em\big) \in \setof{\cmX, \bot}$, where $\NoteUniqueRandNew{} = \nfOld{}$. \vspace{-0.5ex} @@ -6811,6 +6822,16 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h to prove knowledge of $\EphemeralPrivate$, because the potential attack this originally addressed for \Sapling is prevented by checks added at \Canopy activation in \cite{ZIP-212} (which are required after the end of the ZIP 212 grace period). + \item If $\NoteCommitAlg{Orchard}$ returns $\bot$ for the old or new \note, then the corresponding + \textbf{note commitment integrity} check is satisfied. Similarly, if $\CommitIvkAlg$ returns $\bot$, then + the \textbf{diversified address integrity} check is satisfied. This models the fact that the implemented circuit + uses incomplete point addition to compute $\SinsemillaHashToPoint$. If an exceptional case were to occur, + the prover could arbitrarily choose the intermediate $\lambda$ value in an addition, which must be + assumed to allow them to control the output. (The formal output of $\SinsemillaHashToPoint$ + is $\bot$ in such a case, while the output computed by the circuit would be nondeterministic.) + But as proven in \theoremref{thmsinsemillaex}, these exceptional cases allow immediately + finding a nontrivial discrete logarithm. If the Discrete Logarithm Problem is hard on the + \pallasCurve, then finding such a case is infeasible. \end{nnotes} } %nufive @@ -7821,7 +7842,11 @@ $\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHash{Orchard \item where $l = \ItoLEBSP{10}\big(\MerkleDepth{Orchard} - 1 - \mathsf{layer}\big)$. \end{formulae} -\securityrequirement{$\SinsemillaHash$ must be \collisionResistant\!.} +\begin{securityrequirements} + \item $\SinsemillaHash$ must be \collisionResistant, when restricted to non-$\bot$ inputs. + \item It must be infeasible to find inputs $(\mathsf{layer}, \mathsf{left} \neq \bot, \mathsf{right} \neq \bot)$ + such that $\SinsemillaHash(\mathsf{layer}, \mathsf{left}, \mathsf{right}) = \bot$. +\end{securityrequirements} \pnote{The prefix $l$ provides domain separation between inputs at different layers of the \noteCommitmentTree.} @@ -8239,7 +8264,7 @@ Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, $\ParamP{r}$, and $\ParamP{b}$ be as defi \crossref{pallasandvesta}. \vspace{-0.25ex} -Let $\ExtractP \typecolon \GroupP \rightarrow \MerkleHash{Orchard}$ be as +Let $\ExtractPbot \typecolon \GroupP \rightarrow \MerkleHash{Orchard}$ be as defined in \crossref{concreteextractorpallas}. \vspace{-0.25ex} @@ -8271,10 +8296,13 @@ $\SinsemillaGenBase \typecolon \binaryrange{k} \rightarrow \GroupPstar$ by: \vspace{1ex} \introlist -Define $\incompleteadd \typecolon \GroupP \times \GroupP \rightarrow \maybe{\GroupP}$ as incomplete addition on the \Pallas curve: +Define $\incompleteadd \typecolon \maybe{\GroupP} \times \maybe{\GroupP} \rightarrow \maybe{\GroupP}$ as incomplete addition on the \Pallas curve: \vspace{-1ex} \begin{tabular}{@{\hskip 1.5em}r@{\;}l@{\;}l@{\;}l} + $\bot$ &$\incompleteadd$ &$\bot$ &$= \bot$ \\[-0.6ex] + $\bot$ &$\incompleteadd$ &$P$ &$= \bot$ \\[-0.6ex] + $P$ &$\incompleteadd$ &$\bot$ &$= \bot$ \\[-0.6ex] $\ZeroP$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.3ex] $\ZeroP$ &$\incompleteadd$ &$(x', y')$ &$= \bot$ \\[-0.6ex] $(x, y)$ &$\incompleteadd$ &$\ZeroP$ &$= \bot$ \\[-0.3ex] @@ -8303,17 +8331,19 @@ Define $\SinsemillaHashToPoint(D \typecolon \byteseqs, M \typecolon \bitseq{\ran \introlist \vspace{-1ex} -Finally, define $\SinsemillaHash \typecolon \byteseqs \times \bitseq{\range{0}{k \mult c}} \rightarrow \MerkleHash{Orchard}$ by: +Finally, define $\SinsemillaHash \typecolon \byteseqs \times \bitseq{\range{0}{k \mult c}} \rightarrow \maybe{\MerkleHash{Orchard}}$ by: \begin{formulae} - \item $\SinsemillaHash(D, M) := \ExtractP\big(\SinsemillaHashToPoint\Of{D, M}\kern-0.1em\big)$. + \item $\SinsemillaHash(D, M) := \ExtractPbot\big(\SinsemillaHashToPoint\Of{D, M}\kern-0.1em\big)$. \end{formulae} -See \cite[section TODO ``Sinsemilla'']{Zcash-Orchard} for rationale and efficient circuit implementation of these functions. +See \cite[section ``Sinsemilla'']{Zcash-Orchard} for rationale and efficient circuit implementation of these functions. +\vspace{-1.5ex} \securityrequirement{ $\SinsemillaHash$ and $\SinsemillaHashToPoint$ are required to be \collisionResistant -between inputs of fixed length, for a given personalization input $D$. +between inputs of fixed length, for a given personalization input $D$. It must also be +infeasible to find inputs $(D, M)$ such that $\SinsemillaHashToPoint(D, M) = \bot$. No other security properties commonly associated with \hashFunctions are needed. } %securityrequirement @@ -8346,6 +8376,44 @@ to show security of the $\SinsemillaShortCommitAlg$ \commitmentScheme defined in \nullifier derivation defined in \crossref{commitmentsandnullifiers} against Faerie Gold attacks, as described in \crossref{faeriegold}. } %nnote + +\theoremlabel{thmsinsemillaex} +\begin{theorem}[A $\bot$ output from $\SinsemillaHashToPoint$ yields a nontrivial discrete logarithm]\end{theorem} + +\begin{proof} +For convenience of reference, we repeat the algorithm for $\SinsemillaHashToPoint$ in terms +of the message pieces $m \typecolon \typeexp{\binaryrange{k}}{n}$, with indexing of the +intermediate values of $\Acc$: + +\begin{formulae} + \item let $\Acc_0 \leftarrow \SinsemillaGenInit(D)$ + \item for $i$ from $1$ up to $n$: + \vspace{-0.5ex} + \item \tab set $\Acc_i \leftarrow \big(\Acc_{i-1} \incompleteadd \SinsemillaGenBase(m_i)\kern-0.1em\big) \incompleteadd \Acc_{i-1}$ + \item \blank + \item return $\Acc_n$. +\end{formulae} + +We have an exceptional case if and only if $\Acc_i = \pm\, \SinsemillaGenBase(m_i)$ or $\Acc_i + \SinsemillaGenBase(m_i) = \pm\, \Acc_i$. +(Since none of $\SinsemillaGenInit(D)$ or $\big\{\SinsemillaGenBase(j) \suchthat j \in \range{0}{2^k - 1}\kern-0.1em\big\}$ are $\ZeroP$, +no intermediate results can be $\ZeroP$ unless one of the preceding conditions occurs.) + +If $\Acc_i + \SinsemillaGenBase(m_i) = \Acc_i$, then we have $\SinsemillaGenBase(m_i) = \ZeroP$ +contrary to assumption. So exceptional cases occur only if $\scalarmult{\alpha}{\Acc_i} + \SinsemillaGenBase(m_i) = \ZeroP$ +for some $i \in \range{0}{n}$ and some $\alpha \in \setof{-1, 1, 2}$. + +\vspace{0.5ex} +$\Acc_i$ has a representation $\scalarmult{2^i}{\SinsemillaGenInit(D)} + \ssum{j=0}{i-1} \left(\scalarmult{x_{j+1}}{\SinsemillaGenBase(j)}\kern-0.1em\right)$ +for some $x \typecolon \typeexp{\GF{\ParamP{r}}}{i}$. +So given $m$ that results in an exceptional case, the nontrivial discrete logarithm relation +$\scalarmult{\alpha \mult 2^i}{\SinsemillaGenInit(D)} + \ssum{j=0}{i-1} \left(\scalarmult{\alpha \mult x_{j+1}}{\SinsemillaGenBase(j)}\kern-0.1em\right) + \SinsemillaGenBase(i) = \ZeroP$ +is easily computable from $m$. The coefficients in this representation do not overflow since +$|\alpha \mult 2^i| \leq \ParamP{r}-1$, for all $i < n$ and $\alpha \in \setof{-1, 1, 2}$. +\end{proof} + +Since by assumption it is hard to find a nontrivial discrete logarithm relation, +we can argue that it is safe to use incomplete additions when computing Sinsemilla +inside a circuit. } %nufive @@ -9573,23 +9641,38 @@ which is equivalent to: Let $\BaseLength{Orchard}$ be as defined in \crossref{constants}. \vspace{-0.25ex} -Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}. +Let $\GroupP$ and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. + +\vspace{-0.25ex} +Let $\ExtractPbot$ be as defined in \crossref{concreteextractorpallas}. + +\vspace{-0.25ex} +Let $\SinsemillaHashToPoint$ and $\incompleteadd$ be as defined in \crossref{concretesinsemillahash}. \vspace{1ex} -\crossref{concretesinsemillahash} defines a \xSinsemillaHash construction. -We construct \defining{\xSinsemillaCommitments} by reusing that construction, -and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta}): +We construct \defining{\xSinsemillaCommitments} by reusing the \xSinsemillaHash construction, +and adding (using incomplete addition) a randomized point on the \pallasCurve (see +\crossref{pallasandvesta}): \begin{formulae} \item $\SinsemillaCommit{r}(D, M) := - \SinsemillaHashToPoint(D \bconcat \ascii{-M}, M) + \scalarmult{r}{\GroupPHash\Of{D \bconcat \ascii{-r}, \ascii{}}}$ + \SinsemillaHashToPoint(D \bconcat \ascii{-M}, M) \incompleteadd \scalarmult{r}{\GroupPHash\Of{D \bconcat \ascii{-r}, \ascii{}}}$ \item $\SinsemillaShortCommit{r}(D, M) := - \ExtractP\big(\SinsemillaCommit{r}(D, M)\kern-0.1em\big)$. + \ExtractPbot\big(\SinsemillaCommit{r}(D, M)\kern-0.1em\big)$. \end{formulae} \vspace{-1ex} See \cite[section TODO]{Zcash-Orchard} for rationale and efficient circuit implementation of this function. +\vspace{1ex} +The probability of the incomplete addition returning $\bot$ is insignificant (and +such a case would yield a nontrivial discrete logarithm relation unless $r = 0$). + +$\SinsemillaCommitAlg$ is statistically hiding because the output distribution is statistically +indistinguishable from a random point in $\GroupPstar$, given that $r$ is a uniformly random scalar +on $[0, q)$. It follows that $\SinsemillaShortCommitAlg$ is also statistically hiding, since hiding +cannot be affected by applying any fixed function to the \emph{output} of $\SinsemillaCommitAlg$. + \vspace{0.5ex} The \commitmentScheme $\NoteCommitAlg{Orchard}$ specified in \crossref{abstractcommit} is instantiated as follows using $\SinsemillaCommitAlg$: @@ -9608,7 +9691,7 @@ instantiated as follows using $\SinsemillaCommitAlg$: \end{formulae} The \commitmentScheme $\CommitIvkAlg$ specified in \crossref{abstractcommit} is -instantiated as follows using $\SinsemillaCommitAlg$: +instantiated as follows using $\SinsemillaShortCommitAlg$: \begin{formulae} \item $\CommitIvk{\CommitIvkRand}(\AuthSignPublic, \NullifierKey) := @@ -9623,18 +9706,15 @@ instantiated as follows using $\SinsemillaCommitAlg$: \begin{securityrequirements} \item $\SinsemillaCommitAlg$ and $\SinsemillaShortCommitAlg$, and hence $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$, must be computationally binding - and at least computationally hiding \commitmentSchemes. + and at least computationally hiding \commitmentSchemes. They are in fact unconditionally + hiding \commitmentSchemes provided that no $\bot$ output is observed. \end{securityrequirements} \vspace{-1ex} -(They are in fact unconditionally hiding \commitmentSchemes.) - -\begin{pnotes} - \item $\MerkleCRH{Orchard}$ is also defined in terms of $\SinsemillaHashToPoint$ - (see \crossref{merklecrh}). - \item The arguments to $\NoteCommitAlg{Orchard}$ are the same order as their encodings in - the input to $\SinsemillaCommit{}$; this is different to $\NoteCommitAlg{Sapling}$. -\end{pnotes} +\pnote{ +The arguments to $\NoteCommitAlg{Orchard}$ are the same order as their encodings in +the input to $\SinsemillaCommit{}$; this is different to $\NoteCommitAlg{Sapling}$. +} %pnote \introlist \theoremlabel{thmuncommittedorchard} @@ -9643,12 +9723,12 @@ instantiated as follows using $\SinsemillaCommitAlg$: \begin{proof} $\Uncommitted{Orchard}$ is defined as $\ItoLEBSPOf{\MerkleHashLength{Orchard}}{2}$. By injectivity of $\ItoLEBSP{\MerkleHashLength{Orchard}}$ and definitions of -$\ExtractP$, $\SinsemillaShortCommitAlg$, and $\NoteCommitAlg{Orchard}$, +$\ExtractPbot$, $\SinsemillaShortCommitAlg$, and $\NoteCommitAlg{Orchard}$, $\ItoLEBSPOf{\MerkleHashLength{Orchard}}{2}$ can be in the range of $\NoteCommitAlg{Orchard}$ only if there exist $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Orchard}$, $D \typecolon \byteseqs$, and $M \typecolon \bitseq{\smash{\PosInt}}$ such that -$\ExtractP\big(\SinsemillaCommit{\NoteCommitRand}(D, M)\kern-0.1em\big) = 2$. -$\ExtractP\big(\SinsemillaHashToPoint(D, M)\kern-0.1em\big)$ can only be $0$ or the +$\ExtractPbot\big(\SinsemillaCommit{\NoteCommitRand}(D, M)\kern-0.1em\big) = 2$. +$\ExtractPbot\big(\SinsemillaHashToPoint(D, M)\kern-0.1em\big)$ can only be $0$ or the \affineSW $x$-coordinate of a point in $\GroupP$. But $0 \neq 2 \pmod{\ParamP{q}}$, and there are no points in $\GroupP$ with \affineSW $x$-coordinate $2 \pmod{\ParamP{q}}$, since $2^3 + \ParamP{b} = 13$ @@ -9658,8 +9738,9 @@ is not square in $\GF{\ParamP{q}}$. \vspace{-2ex} \nnote{There are also no points in $\GroupP$ with \affineSW $x$-coordinate $0 \pmod{\ParamP{q}}$. We do not choose $\Uncommitted{Orchard} = \ItoLEBSPOf{\MerkleHashLength{Orchard}}{0}$ because we -define $\ExtractP\Of{\ZeroP} = 0$, and it is technically possible (with negligible probability) -that $\SinsemillaHashToPoint$ could return $\ZeroP$.} +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.} } %nufive @@ -10297,8 +10378,17 @@ Define $\ExtractP \typecolon \GroupP \rightarrow \GroupPx$ such that \vspace{-1ex} \begin{formulae} - \item $\ExtractP\big(\ZeroP\big) = 0$ - \item $\ExtractP\big((x, y)\big) = x$. + \item $\ExtractP\big(\ZeroP\big) = \bot$ + \item $\ExtractP\big((x, y)\big) = x \bmod \ParamP{q}$. +\end{formulae} + +\vspace{-1ex} +We also define $\ExtractPbot \typecolon \maybe{\GroupP} \rightarrow \maybe{\GroupPx}$ such that + +\vspace{-1ex} +\begin{formulae} + \item $\ExtractPbot\big(\bot\big) = 0$ + \item $\ExtractPbot\big(P \typecolon \GroupP\big) = \ExtractP(P)$. \end{formulae} \vspace{-2ex} @@ -13723,6 +13813,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Fix typos. \item Correct the definition of $c$ in \crossref{concretesinsemillahash}. + \item Propagate $\bot$ intermediate results to the output of Sinsemilla primitives. + \item Change the output types of $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ to + reflect that these can return $\bot$, and change the \actionStatement to be + satisfied if they do. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. From b7d61884e10f34486c55b48e154fc72919047b39 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 25 Mar 2021 23:38:43 +0000 Subject: [PATCH 15/41] NCC audit: Propagate \bot from the inputs of MerkleCRH^Orchard to its output, and add an explicit consensus rule that rt^Orchard computed from appending a note commitment is not \bot. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index eb2ce165..9b8f7b71 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -3326,6 +3326,17 @@ In a given \blockChain, \sapling{for each of \Sprout and \SaplingAndOrchard,} \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} @@ -3624,13 +3635,14 @@ The following \hashFunctions are used in \crossref{merklepath}: \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}$\notnufive{.} \\ -\setnufive $\MerkleCRH{Orchard}$ &\setnufive $\typecolon\, \MerkleLayer{Orchard}$ &\setnufive $\times\; \MerkleHash{Orchard}$ &\setnufive $\times\; \MerkleHash{Orchard}$ &\setnufive $\rightarrow \MerkleHash{Orchard}$. +\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{\MerkleHash{Orchard}}$ &\setnufive $\times\; \maybe{\MerkleHash{Orchard}}$ &\setnufive $\rightarrow \maybe{\MerkleHash{Orchard}}$}. \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.} +\collisionResistant on all\notnufive{ its}\nufive{ their} arguments\nufive{ (restricted +to non-$\bot$ inputs in the case of $\MerkleCRH{Orchard}$)}.} These functions are instantiated in \crossref{merklecrh}. @@ -7833,12 +7845,15 @@ but using a prefix that cannot collide with a layer prefix, as noted in \crossre \vspace{-2ex} Let $\SinsemillaHash$ be as specified in \crossref{concretesinsemillahash}. -$\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHash{Orchard} \times \MerkleHash{Orchard} -\rightarrow \MerkleHash{Orchard}$ is defined as follows: +$\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \maybe{\MerkleHash{Orchard}} \times \maybe{\MerkleHash{Orchard}} +\rightarrow \maybe{\MerkleHash{Orchard}}$ is defined as follows: \begin{formulae} - \item $\MerkleCRH{Orchard}(\mathsf{layer}, \mathsf{left}, \mathsf{right}) := \SinsemillaHash(\ascii{z.cash:Orchard-MerkleCRH}, - l \bconcat \mathsf{left} \bconcat \mathsf{right})$ + \item $\MerkleCRH{Orchard}(\mathsf{layer}, \mathsf{left}, \mathsf{right}) := \begin{cases} + \bot, &\caseif \mathsf{left} = \bot \text{ or } \mathsf{right} = \bot \\ + \Longunderstack[l]{$\SinsemillaHash(\ascii{z.cash:Orchard-MerkleCRH},$ \\ + $\hspace{6.7em} l \bconcat \mathsf{left} \bconcat \mathsf{right}),$} &\Longunderstack{\\ \squash otherwise} + \end{cases}$ \item where $l = \ItoLEBSP{10}\big(\MerkleDepth{Orchard} - 1 - \mathsf{layer}\big)$. \end{formulae} @@ -13817,6 +13832,9 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Change the output types of $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ to reflect that these can return $\bot$, and change the \actionStatement to be satisfied if they do. + \item Propagate $\bot$ from the inputs of $\MerkleCRH{Orchard}$ to its output, and + add an explicit consensus rule that $\rt{Orchard}$ computed from appending a + \noteCommitment is not $\bot$. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. From 2e50a09e9704ae8f11665e5a95203d6000c84c48 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 25 Mar 2021 23:40:48 +0000 Subject: [PATCH 16/41] NCC audit: Correct the definition of PRFnf^Orchard by changing Poseidon to PoseidonHash. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 9b8f7b71..22ab65d6 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -8781,12 +8781,12 @@ part of deriving the \nullifier for an \Orchard \note. It is instantiated using the $\PoseidonHash$ \hashFunction \cite{GKRRS2019} defined in \crossref{poseidonhash}: \begin{formulae} - \item $\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) := \Poseidon(\NullifierKey, \NoteUniqueRand)$. + \item $\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) := \PoseidonHash(\NullifierKey, \NoteUniqueRand)$. \end{formulae} \vspace{-2ex} \securityrequirement{ -$\Poseidon \typecolon \GF{\ParamP{q}} \times \GF{\ParamP{q}} \rightarrow \GF{\ParamP{q}}$ must be a +$\PoseidonHash \typecolon \GF{\ParamP{q}} \times \GF{\ParamP{q}} \rightarrow \GF{\ParamP{q}}$ must be a PRF when keyed by its first argument, with its second argument as input. } %securityrequirement @@ -13835,6 +13835,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Propagate $\bot$ from the inputs of $\MerkleCRH{Orchard}$ to its output, and add an explicit consensus rule that $\rt{Orchard}$ computed from appending a \noteCommitment is not $\bot$. + \item Correct the definition of $\PRFnf{Orchard}{}$ in \crossref{concreteprfs} + by changing $\Poseidon$ to $\PoseidonHash$. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. From 591c7e45ccaf804b4a33d9b51a82a98aae8c93e0 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 25 Mar 2021 23:43:06 +0000 Subject: [PATCH 17/41] NCC audit: Restrict the definition of a short Weierstrass elliptic curve to base fields of characteristic greater than 3. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 22ab65d6..7890dd7f 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10309,10 +10309,11 @@ system (playing a similar rôle to \BLSPairing in \Sapling), and \Pallas for the The \representedGroups $\GroupP$ and $\GroupV$ of points on \Pallas and \Vesta respectively are defined in this section. -A \defining{\swEllipticCurve}, as defined for example in \cite[Definition 2.3.1]{Hisil2010}, is an -elliptic curve $E$ over a field $\GF{q}$, parameterized by $a, b \typecolon \GF{q}$ such that -$4 \mult a^3 + 27 \mult b^2 \neq 0$, with equation $E : y^2 = x^3 + a \mult x + b$. The curve has -a distinguished zero point $\Zero$, also called the \definingquotedterm{point at infinity}. +A \defining{\swEllipticCurve} over a field $\GF{q}$ of characteristic greater than $3$, as +defined for example in \cite[Definition 2.3.1]{Hisil2010}, is an elliptic curve $E$ over $\GF{q}$, +parameterized by $a, b \typecolon \GF{q}$ such that $4 \mult a^3 + 27 \mult b^2 \neq 0$, with +equation $E : y^2 = x^3 + a \mult x + b$. The curve has a distinguished zero point $\Zero$, also +called the \definingquotedterm{point at infinity}. For \Pallas and \Vesta we have $a = 0$ and so we will omit that term below. \begin{tabular}{@{}l@{\;}r@{\;}l} @@ -13837,6 +13838,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \noteCommitment is not $\bot$. \item Correct the definition of $\PRFnf{Orchard}{}$ in \crossref{concreteprfs} by changing $\Poseidon$ to $\PoseidonHash$. + \item Restrict the definition of a \swEllipticCurve in \crossref{pallasandvesta} to + base fields of characteristic greater than $3$. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. From 8f1ff764170aadd46d870c1a79dc10fe28c3baee Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 25 Mar 2021 23:47:58 +0000 Subject: [PATCH 18/41] Add proof of collision resistance for Sinsemilla. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 127 +++++++++++++++++++++++++++++++++++------- 1 file changed, 108 insertions(+), 19 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 7890dd7f..bd014c5f 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -2303,6 +2303,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\SinsemillaCommit}[1]{\SinsemillaCommitAlg_{#1}} \newcommand{\SinsemillaShortCommitAlg}{\mathsf{SinsemillaShortCommit}} \newcommand{\SinsemillaShortCommit}[1]{\SinsemillaShortCommitAlg_{#1}} +\newcommand{\pad}{\mathsf{pad}} +\newcommand{\Mpadded}{M^{\mathsf{padded}}} % Consensus rules @@ -8329,17 +8331,26 @@ Define $\incompleteadd \typecolon \maybe{\GroupP} \times \maybe{\GroupP} \righta \introlist \vspace{1ex} -Define $\SinsemillaHashToPoint(D \typecolon \byteseqs, M \typecolon \bitseq{\range{0}{k \mult c}}) \rightarrow \GroupP$ as follows: - +Define $\pad(n \typecolon \range{0}{c}, M \typecolon \bitseq{\range{n \mult (k-1) + 1}{n \mult k}}) \rightarrow \typeexp{\binaryrange{k}}{n}$ as follows: +\vspace{-1ex} \begin{algorithm} - \item pad $M$ to a multiple of $k$ bits by appending zero bits, giving $M'$. - \item let $n \typecolon \range{0}{c} = \ceiling{\hfrac{\length(M')}{k}\kern-0.1em}$ - \item split $M'$ into $n$ \defining{\pieces} $M_\barerange{1}{n}$, - each of length $k$ bits, so that $M' = \concatbits(M_\barerange{1}{n})$. + \item pad $M$ to $n \mult k$ bits, giving $\Mpadded$. + \vspace{-0.25ex} + \item split $\Mpadded$ into $n$ \defining{\pieces} $\Mpadded_{\barerange{1}{n}}$, + each of length $k$ bits, so that $\Mpadded = \concatbits(\Mpadded_{\barerange{1}{n}})$. + \item return $\listcomp{\LEBStoIP{k}(\Mpadded_i) \for i \from 1 \upto n}$. +\end{algorithm} + +Define $\SinsemillaHashToPoint(D \typecolon \byteseqs, M \typecolon \bitseq{\range{0}{k \mult c}}) \rightarrow \maybe{\GroupP}$ as follows: +\vspace{-1ex} +\begin{algorithm} + \item let $n \typecolon \range{0}{c} = \ceiling{\hfrac{\length(M)}{k}\kern-0.1em}$ + \vspace{-0.5ex} + \item let $m = \pad_n(M)$ \item let mutable $\Acc \leftarrow \SinsemillaGenInit(D)$ \item for $i$ from $1$ up to $n$: \vspace{-0.5ex} - \item \tab set $\Acc \leftarrow \Big(\Acc \incompleteadd \SinsemillaGenBase\big(\LEBStoIP{k}(M_i)\kern-0.1em\big)\kern-0.15em\Big) \incompleteadd \Acc$ + \item \tab set $\Acc \leftarrow \big(\Acc \incompleteadd \SinsemillaGenBase(m_i)\kern-0.1em\big) \incompleteadd \Acc$ \item \blank \item return $\Acc$. \end{algorithm} @@ -8370,26 +8381,98 @@ No other security properties commonly associated with \hashFunctions are needed. iteration of the loop can be precomputed, if $D$ is known in advance. \end{nnotes} -\todo{Security proof} +\vspace{-3ex} +\lsubsubsubsubsection{Security argument}{sinsemillasecurity} -\introlist -\theoremlabel{thmshortsinsemillacr} -\begin{theorem}[Collision resistance of generalized $\SinsemillaHash$] +\vspace{-2.5ex} +We show a correspondence between Sinsemilla and a vector Pedersen hash, which allows using the +security argument from \cite{BGG1995} to show that collision-resistance can be tightly reduced +to the discrete logarithm problem in $\mathbb{P}$. -Consider ... We show that ... +\vspace{1ex} +Define $\delta(a, b) = \begin{cases} + 0, &\caseif a \neq b \\ + 1, &\caseif a = b\text{.} + \end{cases}$ + +\vspace{-2ex} +\theoremlabel{lemmasinsemillaonetoone} +\begin{lemma}[An injectivity property for Sinsemilla] + +Let $n \typecolon \range{0}{c}$, and consider a sequence of message pieces $m \typecolon \typeexp{\binaryrange{k}}{n}$. +Collect the scalars by which each generator $\SinsemillaGenBase(j)$ is multiplied in the +algorithm for $\SinsemillaHashToPoint$: + +Define $x(m) = \biglistcomp{\vsum{i=1}{n} \big(2^{n-i} \mult \delta(m_i, j)\kern-0.1em\big) \pmod{\ParamP{r}} \for j \from 0 \upto 2^k - 1}$. + +The mapping $m \typecolon \typeexp{\binaryrange{k}}{n} \mapsto x(m) \typecolon \typeexp{\GF{\ParamP{r}}}{2^k} $ is injective. +\end{lemma} + +\begin{proof} +There is an injective mapping from $m$ to the matrix of bits with $2^k$ columns and $n$ rows, such +that the bit at ($1$-based) column $j+1$ and row $i$ is set if and only if $m_i = j$. Then the binary representations +of the elements of $x(m)$ are given by the columns of this matrix, and they do not overflow +due to the requirement that $2^n \leq 2^c \leq \frac{\ParamP{r}-1}{2}$. The claim follows. $\qed$ +\end{proof} + +\theoremlabel{thmsinsemillacr} +\begin{theorem}[Collision resistance of\, $\SinsemillaHash$ and\, $\SinsemillaHashToPoint$] + +Let $D \typecolon \byteseqs$ be a personalization input, and let $\ell \typecolon \range{0}{k \mult c}$. +Finding a collision $M, M' \typecolon \bitseq{\ell}$ with $M \neq M'$ such that +$\SinsemillaHashToPoint(D, M) = \SinsemillaHashToPoint(D, M')$ efficiently yields a nontrivial +discrete logarithm relation, and similarly for $\SinsemillaHash(D, M) = \SinsemillaHash(D, M')$. \end{theorem} \begin{proof} -... +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} +\begin{formulae} + \item $\SinsemillaHashToPoint(M) = \scalarmult{2^n}{\SinsemillaGenInit(D)} + \vsum{j=0}{2^k - 1} \scalarmult{x(m)_{j+1}}{\SinsemillaGenBase(j)}$,\, where $m = \pad_n(M)$. +\end{formulae} +\vspace{-1ex} +(The $j+1$ is just because sequence indices are $1$-based.) + +This is a Pedersen vector hash of the $x(m)$ elements, with a fixed offset $\scalarmult{2^n}{Q}$. +The fixed offset does not affect \collisionResistance in this context. (See below for why +it cannot be eliminated for $\SinsemillaHash$ or $\SinsemillaCommitAlg$, or when using incomplete +addition.) It follows that the \collisionResistance of $\SinsemillaHash$ can be tightly reduced, +via the proof in \cite[Appendix A]{BGG1995}, to the discrete logarithm problem over $\GroupP$. + +Note that \cite{BGG1995} requires for their main scheme that the scalars are nonzero, which +is not necessarily the case in our context. However, their proof in Appendix A does not depend +on this, given that $n$ is fixed. The restriction that scalars are nonzero appears to have +been motivated by wanting to support variable-length messages and incremental hashing, which +we do not. + +Now we consider $\SinsemillaHash$. We want to prove that if we can find two messages $M$ +and $M'$ such that $\ExtractPbot\big(\SinsemillaHash(M)\kern-0.1em\big) = +\ExtractPbot\big(\SinsemillaHash(M')\kern-0.1em\big)$ then we can find a discrete logarithm. +So either $\SinsemillaHash(M) = \SinsemillaHash(M')$ (in which case use the original Pedersen +hash proof) or $\SinsemillaHash(M) = -\SinsemillaHash(M')$. In the latter case, let +$m = \pad_n(M)$ and $m' = \pad_n(M')$, then we have + +\begin{tabular}{@{\hskip 1.5em}r@{\;}l} +$ \scalarmult{2^n}{\SinsemillaGenInit(D)} + \vsum{j=0}{{2^k}-1} \scalarmult{x(m)_{j+1}}{\SinsemillaGenBase(j)} = $&$ -\kern-0.1em\left(\scalarmult{2^n}{\SinsemillaGenInit(D)} + \vsum{j'=0}{{2^k}-1} \scalarmult{x(m')_{j'+1}}{\SinsemillaGenBase(j')}\kern-0.1em\right)$ \\ +$\scalarmult{2^{n+1}}{\SinsemillaGenInit(D)} + \vsum{j=0}{{2^k}-1} \scalarmult{x(m)_{j+1} + x(m')_{j+1}}{\SinsemillaGenBase(j)} = $&$ 0$ +\end{tabular} + +Because the coefficients $\!\!\pmod{q}$ are not all zero, this is a nontrivial discrete logarithm +relation between independent bases. \end{proof} +\vspace{-4ex} \nnote{ -The above theorem covers the case where additional terms may be added to the -$\SinsemillaHashToPoint$ output before applying $\ExtractP$. This is needed -to show security of the $\SinsemillaShortCommitAlg$ \commitmentScheme defined in -\crossref{concretesinsemillacommit}. It is also needed to show security of the -\nullifier derivation defined in \crossref{commitmentsandnullifiers} against -Faerie Gold attacks, as described in \crossref{faeriegold}. +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$. +This is needed to show security of the $\SinsemillaShortCommitAlg$ \commitmentScheme defined in +\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}. } %nnote \theoremlabel{thmsinsemillaex} @@ -9682,6 +9765,11 @@ See \cite[section TODO]{Zcash-Orchard} for rationale and efficient circuit imple \vspace{1ex} The probability of the incomplete addition returning $\bot$ is insignificant (and such a case would yield a nontrivial discrete logarithm relation unless $r = 0$). +The binding property of $\SinsemillaCommitAlg$ follows from \collisionResistance of +$\SinsemillaHashToPoint$ proven in \theoremref{thmsinsemillacr}, given that +$\GroupPHash\Of{D \bconcat \ascii{-r}, \ascii{}}$ is independent of any of the bases +used in $\SinsemillaHashToPoint$. The binding property of $\SinsemillaShortCommitAlg$ can +be proven by a similar argument to that used for $\SinsemillaHash$. $\SinsemillaCommitAlg$ is statistically hiding because the output distribution is statistically indistinguishable from a random point in $\GroupPstar$, given that $r$ is a uniformly random scalar @@ -13825,6 +13913,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, Kevin Gorham, Larry Ruane, Marshall Gaucher, and Ryan Taylor to the acknowledgements. \nufive{ + \item Add proof of \collisionResistance for Sinsemilla. \item Correct some interim findings of the NCC specification audit: \begin{itemize} \item Fix typos. From e5336bb536848fa178880200e7440361c3b552a6 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 00:54:48 +0000 Subject: [PATCH 19/41] Various rationale updates for NU5. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 78 ++++++++++++++++++++++++------------------- protocol/zcash.bib | 10 ++++++ 2 files changed, 54 insertions(+), 34 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index bd014c5f..9f40fe8b 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -809,6 +809,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\spendProof}{\term{Spend proof}} \newcommand{\spendAuthSignature}{\term{spend authorization signature}} \newcommand{\spendAuthSignatures}{\terms{spend authorization signature}} +\newcommand{\xSpendAuthSignatures}{\termxs{spend authorization signature}} \newcommand{\spendAuthRandomizer}{\term{spend authorization randomizer}} \newcommand{\spendAuthRandomizers}{\terms{spend authorization randomizer}} \newcommand{\spendAuthAddressKey}{\term{spend authorization address key}} @@ -1019,6 +1020,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\nullifierSets}{\terms{nullifier set}} \newcommand{\paymentAddress}{\term{payment address}} \newcommand{\paymentAddresses}{\termes{payment address}} +\newcommand{\xPaymentAddresses}{\termxes{payment address}} \newcommand{\shieldedPaymentAddress}{\term{shielded payment address}} \newcommand{\shieldedPaymentAddresses}{\termes{shielded payment address}} \newcommand{\unifiedPaymentAddress}{\term{unified payment address}} @@ -1157,6 +1159,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\xSinsemillaHashes}{\termes{Sinsemilla hash}} \newcommand{\xSinsemillaCommitment}{\term{Sinsemilla commitment}} \newcommand{\xSinsemillaCommitments}{\terms{Sinsemilla commitment}} +\newcommand{\xPedersenOrSinsemillaCommitments}{\termandindex{Pedersen}{Pedersen commitment}\nufive{ or \termandindex{Sinsemilla}{Sinsemilla commitment}} commitments\xspace} \newcommand{\chunks}{\termandindex{chunks}{chunk (of a Pedersen hash input)}} \newcommand{\segments}{\termandindex{segments}{segment (of a Pedersen hash input)}} \newcommand{\pieces}{\termandindex{pieces}{piece (of a Sinsemilla hash input)}} @@ -3779,7 +3782,7 @@ All of these \pseudoRandomFunctions are instantiated in \crossref{concreteprfs}. \vspace{-2ex} \nnote{$\PRFnf{Sprout}{}$ was called $\PRFsn{}$ in \Zerocash \cite{BCGGMTV2014}, and just $\PRFnf{}{}$ in -previous versions of this specification.} +some previous versions of this specification.} \nufive{ @@ -13486,27 +13489,27 @@ potential knowledge of viewing keys. } %saplingonward \nufiveonward{ -In \Orchard, the \nullifier is computed as -$\DeriveNullifier{\NullifierKey}(\NoteUniqueRand, \NoteNullifierRand, \cm)$ -as described in \crossref{commitmentsandnullifiers}. This construction -combines elliptic curve cryptography and the $\Poseidon$-based $\PRFnf{Orchard}{}$ -in a way that, for privacy properties, aims to provide defence in depth -against potential weaknesses in either. Resistance to Faerie Gold attacks, on -the other hand, depends entirely on hardness of the Discrete Logarithm Problem. -The $\NoteUniqueRand$ value of a \note created in a given \actionTransfer is obtained -from the \nullifier of the \note spent in that \actionTransfer; this ensures -(without any cryptographic assumption) that all $\NoteUniqueRand$ values of -\notes added to the \noteCommitmentTree are unique. Then, the \nullifier -derivation can be considered as computing a modified Pedersen commitment on -input that includes $\NoteUniqueRand$, so that the binding property of that -\commitmentScheme ensures that \Orchard \nullifiers will be unique. (Specifically, +In \Orchard, the \nullifier is computed using a construction that combines +elliptic curve cryptography and the $\Poseidon$-based $\PRFnf{Orchard}{}$ +in a way that, for privacy, aims to provide defence in depth against potential +weaknesses in either (see \cite[Section 3.5 Nullifiers]{Zcash-Orchard} and +\crossref{commitmentsandnullifiers}). + +Resistance to Faerie Gold attacks, on the other hand, depends entirely on hardness +of the Discrete Logarithm Problem. The $\NoteUniqueRand$ value of a \note created +in a given \actionTransfer is obtained from the \nullifier of the \note spent in +that \actionTransfer; this ensures (without any cryptographic assumption) that all +$\NoteUniqueRand$ values of \notes added to the \noteCommitmentTree are unique. +Then, the \nullifier derivation can be considered as computing a vector Pedersen +commitment on input that includes $\NoteUniqueRand$, so that the binding property of +that \commitmentScheme ensures that \Orchard \nullifiers will be unique. (Specifically, this is a Sinsemilla commitment with an additional term having base $\NullifierBaseOrchard$, truncated to its $x$-coordinate. The $x$-coordinate truncation cannot harm \collisionResistance because, assuming hardness of the Discrete Logarithm -Problem on the \pallasCurve, the security proof in \theoremref{thmshortsinsemillacr} -covers the case where the additional term is added.) Roadblock attacks are -not possible because $\NoteUniqueRand$ does not repeat for \notes in the -\noteCommitmentTree, and by a corresponding argument to \Sapling for \dummyNotes. +Problem on the \pallasCurve, \crossref{sinsemillasecurity} covers the case where +the additional term is added.) Roadblock attacks are not possible because $\NoteUniqueRand$ +does not repeat for \notes in the \noteCommitmentTree, and by a corresponding argument +to \Sapling for \dummyNotes. } %nufiveonward \lsubsection{Internal hash collision attack and fix}{internalh} @@ -13528,14 +13531,16 @@ Balance property by double-spending \notes, potentially creating arbitrary amounts of currency for themself \cite{HW2016}. \Zcash uses a simpler construction with a single hash evaluation for the -commitment: \shaHash for \Sprout\sapling{, and $\PedersenHash$ for \Sapling}. +commitment: \shaHash for \Sprout \notes\sapling{,\notnufive{ and} $\PedersenHashToPoint$ +for \Sapling \notes}\nufive{, and $\SinsemillaHashToPoint$ for \Orchard \notes}. The motivation for the nested construction in \Zerocash was to allow Mint transactions to be publically verified without requiring \zkSNARKProofs (\cite[section 1.3, under step 3]{BCGGMTV2014}). Since \Zcash combines ``Mint'' and ``Pour'' -transactions into generalized \joinSplitTransfers (for \Sprout), -\sapling{or \spendTransfers and \outputTransfers (for \Sapling)}, and each -transfer always uses a \zkSNARKProof\!\!, \Zcash does not require the nesting. +transactions into generalized \joinSplitTransfers (for \Sprout)\sapling{, or +\spendTransfers and \outputTransfers (for \Sapling)}\nufive{, or +\actionTransfers (for \Orchard)}, and each transfer always uses a +\zkSNARKProof\!\!, \Zcash does not require the nesting. A side benefit is that this reduces the cost of computing the \noteCommitments: for \Sprout it reduces the number of \shaCompress evaluations needed to compute each \noteCommitment from three to two, @@ -13552,12 +13557,12 @@ benefits. } \saplingonward{ -In \Sapling, \xPedersenCommitments are used instead of \shaCompress. +In \Sapling, \xPedersenOrSinsemillaCommitments are used instead of \shaCompress. These commitments are statistically hiding, and so ``everlasting anonymity'' -is supported for \Sapling notes under the same conditions as in \Zerocash +is supported for \SaplingAndOrchard notes under the same conditions as in \Zerocash (by the protocol, not necessarily by \zcashd). Note that \diversifiedPaymentAddresses can be linked if the Discrete Logarithm Problem -on the \jubjubCurve can be broken. +on the \jubjubCurve\nufive{ or \pallasCurve} can be broken. } \lsubsection{Changes to PRF inputs and truncation}{truncation} @@ -13662,7 +13667,8 @@ The motivations for this change were as follows: \cite{BL-SafeCurves} \cite{Hopwood2018}. This retains $\KASproutCurve$'s advantages while keeping \shieldedPaymentAddress sizes short, because the same \publicKey material supports both encryption and - spend authentication.} + spend authentication.} \nufive{For \Orchard, we define a prime-order curve + \Pallas \cite{Hopwood2020}, with similar advantages to \Jubjub.} \item ECIES permits many options, which were not specified. There are at least --counting conservatively-- 576 possible combinations of options and algorithms over the four standards (ANSI X9.63, IEEE Std 1363a-2004, @@ -13676,7 +13682,9 @@ The motivations for this change were as follows: $\KASproutCurve$ \sapling{(and \Jubjub)} key agreement is defined in a way that avoids these concerns due to the curve structure and the ``clamping'' of \privateKeys\sapling{ (or explicit cofactor multiplication and point - validation for \Sapling)}. + validation for \Sapling)}. \nufive{The \pallasCurve is prime-order, but + we still validate points, and use a similar \keyAgreementScheme to \Sapling + for consistency and ease of analysis.} \item Unlike the DHAES/DHIES proposal on which it is based \cite{ABR1999}, ECIES does not require a representation of the sender's \ephemeralPublicKey to be included in the input to the KDF, which may impair the security @@ -13686,13 +13694,13 @@ The motivations for this change were as follows: The scheme we use for \Sprout has both the ephemeral and recipient \publicKey encodings --which are unambiguous for $\KASproutCurve$-- and also $\hSig$ and a nonce as described below, as input to the KDF. - \sapling{For \Sapling, it is only possible to include the ephemeral public + \sapling{For \SaplingAndOrchard, it is only possible to include the ephemeral public key encoding, but this is sufficient to retain the original security properties of DHAES.} Note that being able to break the Elliptic Curve Diffie--Hellman Problem - on $\KASproutCurve$\sapling{ or \Jubjub} (without breaking + on $\KASproutCurve$\sapling{ or \Jubjub}\nufive{ or \Pallas} (without breaking $\SymSpecific$ as an authenticated encryption scheme or $\BlakeTwob{256}$ as a KDF) would not help to decrypt the \noteOrNotesCiphertext unless - $\TransmitPublic$ is known or guessed. + $\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$} is known or guessed. \item \sproutspecific{The KDF also takes a public seed $\hSig$ as input. This can be modeled as using a different ``randomness extractor'' for each \joinSplitTransfer, which limits degradation of security with the number of @@ -13705,8 +13713,8 @@ The motivations for this change were as follows: with knowledge of $\AuthPrivateOld{\allOld}$, so an adversary cannot modify it in a ciphertext from someone else's transaction for use in a chosen-ciphertext attack without detection.} - \sapling{(In \Sapling, there is no equivalent to $\hSig$, but the \bindingSignature - and \spendAuthSignatures prevent such modifications.)} + \sapling{(In \SaplingAndOrchard, there is no equivalent to $\hSig$, but the + \bindingSignature and \spendAuthSignatures prevent such modifications.)} \item \sproutspecific{The scheme used by \Sprout includes an optimization that reuses the same ephemeral key (with different nonces) for the two ciphertexts encrypted in each \joinSplitDescription.} @@ -13806,7 +13814,8 @@ distinct openings of the \noteCommitment when Condition I or II is violated. defined in \cite{IEEE2004}. The fork of \libsnark used by \Zcash uses this standard encoding rather than the less efficient (uncompressed) one used by upstream \libsnark.} \sapling{In \Sapling, a customized encoding - is used for \BLSPairing points in \Groth proofs to minimize length.} + is used for \BLSPairing points in \Groth proofs to minimize length\nufive{, and + similarly for \Pallas and \Vesta points in \Orchard}.} \item The range of monetary values differs. In \Zcash this range is $\range{0}{\MAXMONEY}$, while in \Zerocash it is $\ValueType$. (The \joinSplitStatement still only directly enforces that the sum @@ -13932,6 +13941,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. + \item Various rationale updates for \NUFive. } %nufive \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 9ccdac10..3c13e13d 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -1422,6 +1422,16 @@ Last revised February~5, 2018.} addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.} } +@misc{Hopwood2020, + presort={Hopwood2020}, + author={Daira Hopwood}, + title={GitHub repository `\hairspace zcash/pasta'\hairspace: +{G}enerator and supporting evidence for security of the {P}allas/{V}esta pair of elliptic curves suitable for {H}alo}, + url={https://github.com/zcash/pasta}, + urldate={2021-03-23}, + addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.} +} + @misc{Bowe2018, presort={Bowe2018}, author={Sean Bowe}, From 4d983aa8551edf0664d1cea242f847890d73705f Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 14:31:04 +0000 Subject: [PATCH 20/41] NCC audit: Make the naming of enableSpends and enableOutputs consistent. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 27 ++++++++++++++------------- zip-0225.rst | 6 +++--- 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 9f40fe8b..747a5633 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -1637,8 +1637,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\nf}{\mathsf{nf}} \newcommand{\nfOld}[1]{\nf^\mathsf{old}_{#1}} \newcommand{\nfOldRepr}[1]{{\MakeRepr{\nf}{\mathsf{old}}}_{#1}} -\newcommand{\enableSpend}{\mathsf{enableSpend}} -\newcommand{\enableOutput}{\mathsf{enableOutput}} +\newcommand{\enableSpends}{\mathsf{enableSpends}} +\newcommand{\enableOutputs}{\mathsf{enableOutputs}} \newcommand{\Memo}{\mathsf{memo}} \newcommand{\MemoByteLength}{512} \newcommand{\MemoType}{\byteseq{\MemoByteLength}} @@ -5209,18 +5209,18 @@ where \item $\OutCiphertext{} \typecolon \Ciphertext$ is a ciphertext component that allows the holder of a \fullViewingKey to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey $\EphemeralPrivate$ (and therefore the entire \notePlaintext); - \item $\enableSpend \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable non-zero-valued spends in this Action; - \item $\enableOutput \typecolon \bit$ is a flag that is set in order to enable non-zero-valued + \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable non-zero-valued outputs in this Action; \vspace{-0.25ex} \item $\Proof{} \typecolon \ActionProof$ is a \zkSNARKProof with \primaryInput - $(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend,$ $\enableOutput)$ + $(\cv, \rt{Orchard}\kern-0.1em, \nf\kern-0.1em, \AuthSignRandomizedPublic, \cmX, \enableSpends, \enableOutputs)$ for the \actionStatement defined in \crossref{actionstatement}. \end{itemize} \vspace{-1ex} -\pnote{The $\rt{Orchard}$, $\enableSpend$, and $\enableOutput$ components are the same for all +\pnote{The $\rt{Orchard}$, $\enableSpends$, and $\enableOutputs$ components are the same for all \actionTransfers in a \transaction. They are encoded once in the \transaction body (see \crossref{txnencodingandconsensus}), not in the $\type{ActionDescription}$ structure. $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrchard$ field of a @@ -5240,9 +5240,9 @@ $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrc As specified in \crossref{concretereddsa}, validation of the $\RedDSAReprR{}$ component of the signature prohibits \nonCanonicalPoint encodings. \vspace{-0.25ex} - \item The proof $\Proof{\Action}$ \MUST be valid given a \primaryInput - $(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend, \enableOutput)$ --- - i.e.\ $\ActionVerify\big(\kern-0.1em(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpend, \enableOutput), \Proof{\Action}\big) = 1$. + \item The proof $\Proof{}$ \MUST be valid given a \primaryInput + $(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpends,$ $\enableOutputs)$ --- + i.e.\ $\ActionVerify\big(\kern-0.1em(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \enableSpends, \enableOutputs), \Proof{}\big) = 1$. \end{consensusrules} \vspace{-1.5ex} @@ -6727,8 +6727,8 @@ A valid instance of a \defining{\actionStatement}, $\Proof{}$, assures that give \hparen\nfOld{} \typecolon \PRFOutputNfOrchard,\\ \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard},\\ \hparen\cmX \typecolon \GroupPx,\vspace{0.2ex}\\ - \hparen\enableSpend \typecolon \bit,\vspace{0.4ex}\\ - \hparen\enableOutput \typecolon \bit\cparen$, + \hparen\enableSpends \typecolon \bit,\vspace{0.4ex}\\ + \hparen\enableOutputs \typecolon \bit\cparen$, \end{formulae} \vspace{-2ex} @@ -6797,10 +6797,10 @@ where $\NoteUniqueRandNew{} = \nfOld{}$. \vspace{-0.5ex} \snarkcondition{Enable spend flag}{actionenablespend} -$\vOld{} = 0$ or $\enableSpend = 1$. +$\vOld{} = 0$ or $\enableSpends = 1$. \snarkcondition{Enable output flag}{actionenableoutput} -$\vNew{} = 0$ or $\enableOutput = 1$. +$\vNew{} = 0$ or $\enableOutputs = 1$. \vspace{2ex} For details of the form and encoding of \actionStatement proofs, see \crossref{halo2}. @@ -13938,6 +13938,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. by changing $\Poseidon$ to $\PoseidonHash$. \item Restrict the definition of a \swEllipticCurve in \crossref{pallasandvesta} to base fields of characteristic greater than $3$. + \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. diff --git a/zip-0225.rst b/zip-0225.rst index 4f1f0ccb..cf1d08e9 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -136,8 +136,8 @@ Transaction Format | | | |§7.5 ‘Action Description Encoding and Consensus’. | +-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+ |``1`` |``flagsOrchard`` |``byte`` |An 8-bit value representing a set of flags. Ordered from LSB to MSB: | -| | | | * ``spendsEnabledOrchard`` | -| | | | * ``outputsEnabledOrchard`` | +| | | | * ``enableSpendsOrchard`` | +| | | | * ``enableOutputsOrchard`` | | | | | * The remaining bits are set to ``0``. | +-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+ |``8`` |``valueBalanceOrchard`` |``int64`` |The net value of Orchard spends minus outputs. | @@ -176,7 +176,7 @@ Transaction Format ``vActionsOrchard`` and MUST be ordered such that the proof or signature at a given index corresponds to the ``OrchardAction`` at the same index. -* For coinbase transactions, the ``spendsEnabledOrchard`` bit MUST be set to ``0``. +* For coinbase transactions, the ``enableSpendsOrchard`` bit MUST be set to ``0``. The encodings of ``tx_in``, and ``tx_out`` are as in a version 4 transaction (i.e. unchanged from Canopy). The encodings of ``SpendDescriptionV5``, ``OutputDescriptionV5`` From 7ccbf44c309648cdff1a8a5cf15e6925cc33135b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 14:48:32 +0000 Subject: [PATCH 21/41] NCC audit: Define \mathbb{G} in \crossref{concretegrouphashpallasandvesta}. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 747a5633..76ede533 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10435,6 +10435,8 @@ Define $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} as in \crossref{endian}, and similarly for $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$. +Let $\GroupG{}$ be either $\GroupP$ or $\GroupV$. + Define $\reprG{} \typecolon \GroupG{} \rightarrow \ReprG{}$ such that \vspace{-1ex} @@ -13938,6 +13940,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. by changing $\Poseidon$ to $\PoseidonHash$. \item Restrict the definition of a \swEllipticCurve in \crossref{pallasandvesta} to base fields of characteristic greater than $3$. + \item Define $\GroupG{}$ in \crossref{concretegrouphashpallasandvesta}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From 5d15a3d91e47fba66e9dd9f681828864a7331132 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 14:48:45 +0000 Subject: [PATCH 22/41] NCC audit: Fix type confusion between integers and field elements (including additional cases not found in the audit, involving nullifiers and cm_x). Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 38 +++++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 76ede533..32f7284c 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -5188,7 +5188,7 @@ where \item $\rt{Orchard} \typecolon \MerkleHash{Orchard}$ is an \anchor (\crossref{blockchain}) for the output \treestate of a previous \block; \vspace{-0.25ex} - \item $\nf \typecolon \PRFOutputNfOrchard$ is the \nullifier for the input \note; + \item $\nf \typecolon \range{0}{\ParamP{q}-1}$ is the \nullifier for the input \note; \vspace{-0.25ex} \item $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard}$ is a randomized \validatingKey that should be used to validate $\spendAuthSig$; @@ -5196,7 +5196,7 @@ where \item $\spendAuthSig \typecolon \SpendAuthSigSignature{Orchard}$ is a \spendAuthSignature, validated as specified in \crossref{spendauthsig}; \vspace{-0.25ex} - \item $\cmX \typecolon \GroupPx$ is the result of applying $\ExtractP$ to the \noteCommitment for + \item $\cmX \typecolon \range{0}{\ParamP{q}-1}$ is the result of applying $\ExtractP$ to the \noteCommitment for the output \note; \vspace{-0.25ex} \item $\EphemeralPublic \typecolon \KAPublic{Orchard}$ is @@ -5246,7 +5246,13 @@ $\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrc \end{consensusrules} \vspace{-1.5ex} -\nnote{$\cv$, $\AuthSignRandomizedPublic$, and $\EphemeralPublic$ can be the zero point $\ZeroP$.} +\begin{nnotes} + \vspace{-0.25ex} + \item $\cv$, $\AuthSignRandomizedPublic$, and $\EphemeralPublic$ can be the zero point $\ZeroP$. + \vspace{-0.25ex} + \item Despite the return type of $\ExtractP$ being $\GroupPx$, $\nf$ and $\cmX$ are \emph{not} checked + to be in $\GroupPx$; they are only checked to encode integers in $\range{0}{\ParamP{q}-1}$. +\end{nnotes} } %nufive @@ -6724,9 +6730,9 @@ A valid instance of a \defining{\actionStatement}, $\Proof{}$, assures that give \begin{formulae} \item $\oparen\rt{Orchard} \typecolon \MerkleHash{Orchard},\\ \hparen\cvNet{} \typecolon \ValueCommitOutput{Orchard},\\ - \hparen\nfOld{} \typecolon \PRFOutputNfOrchard,\\ + \hparen\nfOld{} \typecolon \range{0}{\ParamP{q}-1},\\ \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard},\\ - \hparen\cmX \typecolon \GroupPx,\vspace{0.2ex}\\ + \hparen\cmX \typecolon \range{0}{\ParamP{q}-1},\vspace{0.2ex}\\ \hparen\enableSpends \typecolon \bit,\vspace{0.4ex}\\ \hparen\enableOutputs \typecolon \bit\cparen$, \end{formulae} @@ -6793,7 +6799,7 @@ $\ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRandNew{}}(\DiversifiedTransmi \vNew{}, \NoteUniqueRandNew{}, \NoteNullifierRandNew)\kern-0.1em\big) \in \setof{\cmX, \bot}$, -where $\NoteUniqueRandNew{} = \nfOld{}$. +where $\NoteUniqueRandNew{} = \nfOld{} \pmod{\ParamP{q}}$. \vspace{-0.5ex} \snarkcondition{Enable spend flag}{actionenablespend} @@ -6823,7 +6829,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h ($\AuthSignBase{Orchard}$ is as defined in \crossref{concretespendauthsig}.) \item The validity of $\DiversifiedTransmitBaseRepr$ and $\DiversifiedTransmitPublicRepr$ are - \emph{not} checked in this circuit. + \emph{not} checked in this circuit. Also, $\cmX$ is \emph{not} checked to be in $\GroupPx$. \end{pnotes} \vspace{-1ex} @@ -9150,7 +9156,7 @@ Let $\EdDSABase$ be the base point given in \cite{BDLSY2012}. Define $\ItoLEOSP{}$, $\LEOStoBSP{}$, and $\LEBStoIP{}$ as in \crossref{endian}. Define $\reprBytesEdSpecific \typecolon \GroupEdSpecific \rightarrow \ReprEdSpecificBytes$ such -that $\reprBytesEdSpecific\Of{x, y} = \ItoLEOSP{256}\big(y + 2^{255} \smult \tilde{x}\big)$, where +that $\reprBytesEdSpecific\Of{(x, y)} = \ItoLEOSP{256}\big(\kern-0.1em(y \bmod p) + 2^{255} \smult \tilde{x}\big)$, where $\tilde{x} = x \bmod 2$.\footnotewithlabel{coordinatenames}{Here we use the $(x, y)$ naming of coordinates in \cite{BDLSY2012}, which is different from the $(u, \varv)$ naming used for coordinates of \ctEdwardsCurves in \crossref{jubjub} and in \crossref{ecbackground}.} @@ -9804,7 +9810,7 @@ instantiated as follows using $\SinsemillaShortCommitAlg$: \SinsemillaShortCommit{\CommitIvkRand}\big(\ascii{z.cash:Orchard-CommitIvk},$ \vspace{-1ex} \item \hspace{20.5em} $\ItoLEBSP{\BaseLength{Orchard}}(\AuthSignPublic) \bconcat - \ItoLEBSP{\BaseLength{Orchard}}(\NullifierKey)\kern-0.1em\big) \pmod{\ParamP{r}}$ + \ItoLEBSP{\BaseLength{Orchard}}(\NullifierKey)\kern-0.1em\big)$ \item $\CommitIvkGenTrapdoor()$ generates the uniform distribution on $\GF{\ParamP{r}}$. \end{formulae} @@ -10197,7 +10203,7 @@ as in \crossref{endian}, and similarly for $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$. Define $\reprJ \typecolon \GroupJ \rightarrow \ReprJ$ such -that $\reprJ\Of{u, \varv} = \ItoLEBSP{256}\big(\varv + 2^{255} \smult \tilde{u}\big)$, where +that $\reprJ\big((u, \varv)\big) = \ItoLEBSP{256}\big(\kern-0.1em(\varv \bmod \ParamJ{q}) + 2^{255} \smult \tilde{u}\big)$, where $\tilde{u} = u \bmod 2$. \vspace{-1ex} @@ -10442,7 +10448,7 @@ Define $\reprG{} \typecolon \GroupG{} \rightarrow \ReprG{}$ such that \vspace{-1ex} \begin{tabular}{@{\hskip 1.5em}r@{\;}l} $\reprG{}\big(\ZeroG{}\big)$ &$= \ItoLEBSP{256}(0)$ \\ - $\reprG{}\big((x, y)\big)$ &$= \ItoLEBSP{256}\big(x + 2^{255} \smult \tilde{y}\big)$, where $\tilde{y} = y \bmod 2$. + $\reprG{}\big((x, y)\big)$ &$= \ItoLEBSP{256}\big(\kern-0.1em(x \bmod \ParamG{q}) + 2^{255} \smult \tilde{y}\big)$, where $\tilde{y} = y \bmod 2$. \end{tabular} \vspace{1ex} @@ -10476,8 +10482,12 @@ $\abstJ\Of{P\Repr}$ is computed as follows: \vspace{-1ex} Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, and $\ParamP{b}$ be as defined in \crossref{pallasandvesta}. -Define $\GroupPstarx$ be the set of $x$-coordinates of points on the \pallasCurve, -i.e.\ $\setof{x \typecolon \GF{\ParamP{q}} \suchthat x^3 + \ParamP{b}\text{ is square in }\GF{\ParamP{q}}}$. +Define $\GroupPstarx$ as the set of $x$-coordinates (as integers) of points on the \pallasCurve, i.e. + +\vspace{-1ex} +\begin{formulae} + \item $\GroupPstarx := \bigsetof{x \typecolon \range{0}{\ParamP{q}-1} \suchthat x^3 + \ParamP{b} \pmod{\ParamP{q}} \text{ is square in }\GF{\ParamP{q}}}$. +\end{formulae} \vspace{-0.5ex} Define $\GroupPx := \GroupPstarx \union \setof{0}$. @@ -13941,6 +13951,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Restrict the definition of a \swEllipticCurve in \crossref{pallasandvesta} to base fields of characteristic greater than $3$. \item Define $\GroupG{}$ in \crossref{concretegrouphashpallasandvesta}. + \item Fix type confusion between integers and field elements (including additional + cases not found in the audit, involving \nullifiers and $\cmX$). \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From 9d62142142caa0c5e4db5d731e901fb47216c4f0 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 15:24:04 +0000 Subject: [PATCH 23/41] NCC audit: Fix a discrepancy between \crossref{concretegrouphashpallasandvesta} and \cite{ID-hashtocurve}. The zero padding in expand_message_xmd should be 128 bytes (matching the input block size of BLAKE2b), rather than 64 bytes. See also https://github.com/zcash/pasta/pull/2 and https://github.com/zcash/pasta_curves/issues/7 Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 32f7284c..93b5687c 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -1342,6 +1342,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\DST}{\mathsf{DST}} \newcommand{\leninbytes}{\mathsf{len\_in\_bytes}} \newcommand{\binbytes}{\mathsf{b\_in\_bytes}} +\newcommand{\rinbytes}{\mathsf{r\_in\_bytes}} \newcommand{\tx}{\mathsf{tx}} \newcommand{\ReceivedSet}{\mathsf{ReceivedSet}} @@ -10624,7 +10625,7 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type \vspace{-1ex} \begin{algorithm} \item let $\DST' = \DST \bconcat\, [\,\length(\DST)\,]$ - \item let $\msg' = \zerobytes{64} \bconcat \msg \bconcat\, [\,0, 128\,] \bconcat\, [\,0\,] \bconcat \DST'$ + \item let $\msg' = \zerobytes{128} \bconcat \msg \bconcat\, [\,0, 128\,] \bconcat\, [\,0\,] \bconcat \DST'$ \item let $b_0 = \BlakeTwob{512}\big(\zerobytes{16}, \msg'\big)$ \item let $b_1 = \BlakeTwob{512}\big(\zerobytes{16}, b_0 \bconcat\, [\,1\,] \bconcat \DST'\big)$ \item let $b_2 = \BlakeTwob{512}\big(\zerobytes{16}, (b_0 \xor b_1) \bconcat\, [\,2\,] \bconcat \DST'\big)$ @@ -10639,9 +10640,9 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type the function $\XMDBlakeTwob$ corresponding to $\expandmessagexmd$ defined in \cite[section 5.4.1]{ID-hashtocurve}, and with domain separation tag $\DST$. In $\expandmessagexmd$, $\mathsf{H}$ is instantiated as $\BlakeTwob{512}$ with - $\binbytes = 64$, and we specialize to $\leninbytes = 128$ since that is the only - case we need. In the event of any discrepancy or change to the Internet Draft, - the definition here takes precedence. + $\binbytes = 64$ and $\rinbytes = 128$, and we specialize to $\leninbytes = 128$ + since that is the only case we need. In the event of any discrepancy or change to + the Internet Draft, the definition here takes precedence. \vspace{-0.25ex} \item Unlike other uses of $\BlakeTwobGeneric$ in \Zcash, zero bytes are used for the $\BlakeTwobGeneric$ personalization, in order to follow the Internet Draft which @@ -10651,7 +10652,7 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type to follow the Internet Draft.\!\! \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{64}$, since this state does + used to compute $b_0$ after processing $\zerobytes{128}$, since this state does not depend on the message. \end{nnotes} @@ -13953,6 +13954,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Define $\GroupG{}$ in \crossref{concretegrouphashpallasandvesta}. \item Fix type confusion between integers and field elements (including additional cases not found in the audit, involving \nullifiers and $\cmX$). + \item Fix a discrepancy between \crossref{concretegrouphashpallasandvesta} and + \cite{ID-hashtocurve}: the zero padding in $\expandmessagexmd$ should be + $128$ bytes (matching the input block size of $\BlakeTwobGeneric$), rather + than $64$ bytes. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From ab0e248036fd79464f065803990552109a0b6ed2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 15:40:42 +0000 Subject: [PATCH 24/41] NCC audit: Document that the use of k = 256 in hash_to_field is intentional, despite the Pallas curve only having 126-bit conjectured security against generic attacks. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 93b5687c..2ba77e0a 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10644,6 +10644,14 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type since that is the only case we need. In the event of any discrepancy or change to the Internet Draft, the definition here takes precedence. \vspace{-0.25ex} + \item The ``security level'' $k$ in the Internet Draft is taken to be $256$. Although + this is greater than the conjectured $126$-bit security of the \pallasCurve against + generic (e.g.\ Pollard rho) attacks \cite{Hopwood2020}, this design choice is + consistent with other instances of extracting a uniformly distributed field element + from a hash output in the \Orchard protocol, such as $\ToScalar{Orchard}$ and + $\ToBase{Orchard}$ defined in \crossref{orchardkeycomponents}, and + $\RedDSAHashToScalar$ defined in \crossref{concretereddsa}. + \vspace{-0.25ex} \item Unlike other uses of $\BlakeTwobGeneric$ in \Zcash, zero bytes are used for the $\BlakeTwobGeneric$ personalization, in order to follow the Internet Draft which encodes $\DST$ in the hash inputs instead. @@ -13958,6 +13966,9 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \cite{ID-hashtocurve}: the zero padding in $\expandmessagexmd$ should be $128$ bytes (matching the input block size of $\BlakeTwobGeneric$), rather than $64$ bytes. + \item Document that the use of $k = 256$ when extracting field elements + in $\hashtofield$ is intentional, despite the \pallasCurve only having + $126$-bit conjectured security against generic attacks. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From fa2b1c6ce9d24fc1174390e651c83ced9fb8ab44 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 15:44:27 +0000 Subject: [PATCH 25/41] Correct the output type of sqrt_ratio. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 2ba77e0a..650141ce 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10666,7 +10666,7 @@ Define $\hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg \type \introlist Let $\ParamG{\lambda}$ be any fixed nonsquare in $\GF{\ParamG{q}}$. -Define $\sqrtratioG(\num, \xdiv) \typecolon \GF{\ParamG{q}} \times \GFstar{\ParamG{q}} \rightarrow \GF{\ParamG{q}}$ as follows: +Define $\sqrtratioG(\num, \xdiv) \typecolon \GF{\ParamG{q}} \times \GFstar{\ParamG{q}} \rightarrow \GF{\ParamG{q}} \times \bit$ as follows: \begin{formulae} \item $\sqrtratioG(\num, \xdiv) = \begin{cases} @@ -13969,6 +13969,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Document that the use of $k = 256$ when extracting field elements in $\hashtofield$ is intentional, despite the \pallasCurve only having $126$-bit conjectured security against generic attacks. + \item Correct the output type of $\sqrtratioG$. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From a68c7d24d0bf16e1c5be715dd0ceceb10a0eba50 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 16:01:13 +0000 Subject: [PATCH 26/41] =?UTF-8?q?NCC=20audit:=20Document=20that=20the=20ch?= =?UTF-8?q?oice=20of=20nonsquare=20for=20=CE=BB=5FG=20in=20\crossref{concr?= =?UTF-8?q?etegrouphashpallasandvesta}=20makes=20no=20difference=20to=20th?= =?UTF-8?q?e=20output=20of=20map=5Fto=5Fcurve=5Fsimple=5Fswu.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 650141ce..e1702812 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10677,6 +10677,8 @@ Define $\sqrtratioG(\num, \xdiv) \typecolon \GF{\ParamG{q}} \times \GFstar{\Para \vspace{-1ex} \begin{nnotes} \item An arbitrary square root may be chosen in either case of the definition. The result is never $\bot$. + \item The choice of the nonsquare $\ParamG{\lambda}$ is also arbitrary and will not affect the output + of $\maptocurvesimpleswuIsoG$ defined below. \item The computation of $\sqrtratioG$ can be optimized as described in \todo{}. \end{nnotes} @@ -13970,6 +13972,9 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. in $\hashtofield$ is intentional, despite the \pallasCurve only having $126$-bit conjectured security against generic attacks. \item Correct the output type of $\sqrtratioG$. + \item Document that the choice of nonsquare for $\ParamG{\lambda}$ in + \crossref{concretegrouphashpallasandvesta} makes no difference to the + output of $\maptocurvesimpleswuIsoG$. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From bfc6a8e33c8c27fbe7c79d2c610ad4c6bdfac17b Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 16:12:03 +0000 Subject: [PATCH 27/41] NCC audit: Document the limitation on the domain separation string for the group hash into Pallas/Vesta. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index e1702812..cc12cffb 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10727,12 +10727,17 @@ is calculated as follows: \begin{algorithm} \item let $\DST = D \bconcat \ascii{-} \bconcat \curveNameG \bconcat \ascii{\_XMD:BLAKE2b\_SSWU\_RO\_}$ - \item let $[\,u_0, u_1\,] = \hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(\msg, \DST)$ + \item fail if $\length(\DST) > 255$ + \vspace{-1.5ex} + \item let $[\,u_0, u_1\,] = \hashtofield_{\XMDBlakeTwob}^{\typeexp{\GF{\ParamG{q}}\!}{2}}(M, \DST)$ \item let $Q_i = \maptocurvesimpleswuIsoG(u_i)$ for $i \in \{0, 1\}$ \item return $\IsoMapG(Q_0 + Q_1)$. \end{algorithm} \begin{nnotes} + \item The length of $D$ is in practice limited to $233 - \length(\curveNameG)$ bytes + due to the restriction of $\DST$ to at most $255$ bytes. This limit is not exceeded + by any use of $\GroupPHash$ or $\GroupVHash$ in this specification. \item $\GroupPHash$ and $\GroupVHash$ are intended to be instantiations of \texttt{hash\_to\_curve} using ``Simplified SWU for $AB = 0$'' described in \cite[section 6.6.3]{ID-hashtocurve}. In the event of any discrepancy or change @@ -13975,6 +13980,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Document that the choice of nonsquare for $\ParamG{\lambda}$ in \crossref{concretegrouphashpallasandvesta} makes no difference to the output of $\maptocurvesimpleswuIsoG$. + \item Document the limitation on the domain separation string for the \groupHash + into \Pallas and \Vesta. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. From 5fef9270e2241270bd9c298d8076b838203da7c1 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 16:30:40 +0000 Subject: [PATCH 28/41] NCC audit: Correct the sizes of SpendDescriptionV5 and OutputDescriptionV5 in the version transaction format. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 6 ++++-- zip-0225.rst | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index cc12cffb..dfb95e64 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11960,13 +11960,13 @@ A \blockHeight in the range $\range{1}{499999999}$ after which the \transaction & \Varies & $\nSpendsSapling$ & \type{compactSize} & The number of \spendDescriptions in $\vSpendsSapling$.\! \\ \hline -& \Longunderstack{$362 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendsSapling$ & \type{SpendDescriptionV5} \type{[$\nSpendsSapling$]} & +& \Longunderstack{$96 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendsSapling$ & \type{SpendDescriptionV5} \type{[$\nSpendsSapling$]} & A sequence of \spendDescriptions{}, encoded per \crossref{spendencodingandconsensus}.\! \\ \hline & \Varies & $\nOutputsSapling\!$ & \type{compactSize} & The number of \outputDescriptions in $\vOutputsSapling$.\! \\ \hline -& \Longunderstack{$948 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputsSapling\!$ & \type{OutputDescriptionV5} \type{[$\nOutputsSapling$]} & +& \Longunderstack{$756 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputsSapling\!$ & \type{OutputDescriptionV5} \type{[$\nOutputsSapling$]} & A sequence of \outputDescriptions{}, encoded per \crossref{outputencodingandconsensus}.\! \\ \hline $\ddagger$ & $8$ & $\valueBalance{Sapling}\!$ & \type{int64} & @@ -13982,6 +13982,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. output of $\maptocurvesimpleswuIsoG$. \item Document the limitation on the domain separation string for the \groupHash into \Pallas and \Vesta. + \item Correct the sizes of \type{SpendDescriptionV5} and \type{OutputDescriptionV5} + in the version 5 \transaction format. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. diff --git a/zip-0225.rst b/zip-0225.rst index cf1d08e9..f12121c6 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -106,7 +106,7 @@ Transaction Format +-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+ |``varies`` |``nSpendsSapling`` |``compactSize`` |Number of Sapling Spend descriptions in ``vSpendsSapling``. | +-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+ -|``128 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV5[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per | +|``96 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV5[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per | | | | |protocol §7.3 ‘Spend Description Encoding and Consensus’. | +-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+ |``varies`` |``nOutputsSapling`` |``compactSize`` |Number of Sapling Output Decriptions in ``vOutputsSapling``. | From 3d386eeec0e60d151cb6788e07a114efb5547d51 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:30:58 +0000 Subject: [PATCH 29/41] ZIP 225: Update references. Signed-off-by: Daira Hopwood --- zip-0225.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/zip-0225.rst b/zip-0225.rst index f12121c6..b5f1cf5f 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -25,7 +25,7 @@ Abstract ======== This proposal defines an update to the Zcash peer-to-peer transaction format to include -support for data elements required to support the Orchard protocol [#protocol-orchard]_. +support for data elements required to support the Orchard protocol [#protocol-nu5]_. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements. @@ -476,10 +476,10 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-orchard] `Zcash Protocol Specification, Version 2021.1.17 or later `_ -.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.4: Spend Descriptions `_ -.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.5: Output Descriptions `_ -.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.6: Action Descriptions `_ +.. [#protocol-nu5] `Zcash Protocol Specification, Version 2021.1.20 or later `_ +.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.4: Spend Descriptions `_ +.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.5: Output Descriptions `_ +.. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.6: Action Descriptions `_ .. [#zip-0222] `ZIP 222: Transparent Zcash Extensions `_ .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability `_ .. [#zip-0307] `ZIP 307: Light Client Protocol for Payment Detection `_ From eff39611f8acba24a46e7010fbb191412c863f53 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:08:22 +0000 Subject: [PATCH 30/41] ZIP 225: Correct the size of the outCiphertext field in a Sapling Output description. Signed-off-by: Daira Hopwood --- zip-0225.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zip-0225.rst b/zip-0225.rst index b5f1cf5f..6500910d 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -216,7 +216,7 @@ Sapling Output Description (``OutputDescriptionV5``) +-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ |``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. | +-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``80`` |``outCiphertext`` |``byte[580]`` |The encrypted contents of the byte string created by | +|``80`` |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by | | | | |concatenation of the transmission key with the ephemeral | | | | |secret key. | +-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ @@ -244,7 +244,7 @@ Orchard Action Description (``OrchardAction``) +-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ |``580`` |``encCiphertext`` |``byte[580]`` |The encrypted contents of the note plaintext. | +-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ -|``80`` |``outCiphertext`` |``byte[580]`` |The encrypted contents of the byte string created by | +|``80`` |``outCiphertext`` |``byte[80]`` |The encrypted contents of the byte string created by | | | | |concatenation of the transmission key with the ephemeral | | | | |secret key. | +-----------------------------+--------------------------+--------------------------------------+------------------------------------------------------------+ From 55af963e5391968a4faea94b730f9961ced038cd Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:17:23 +0000 Subject: [PATCH 31/41] NCC audit: Add a definition for the section symbol in \crossref{introduction}, before its first use. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 21 ++++++++++++--------- zip-0225.rst | 3 +++ 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index dfb95e64..24de2315 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -2459,6 +2459,17 @@ transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with \emph{shielded} payment scheme secured by zero-knowledge succinct non-interactive arguments of knowledge (\zkSNARKs). +\vspace{1ex} +In this document, technical terms for concepts that play an important rôle in \Zcash are +written in \defining{\term{slanted text}}, which links to an index entry. +\emph{Italics} are used for emphasis and for references between sections of the document. +The symbol \S{} precedes section numbers in cross-references. + +The key words \defining{\MUST, \MUSTNOT, \SHOULD, \SHOULDNOT, \RECOMMENDED, \MAY, and \OPTIONAL} +in this document are to be interpreted as described in \cite{RFC-2119} when +they appear in \defining{\ALLCAPS}. These words may also appear in this document in +lower case as plain English words, absent their normative meanings. + \vspace{1ex} The most significant changes from the original \Zerocash are explained in \crossref{differences}. @@ -2484,15 +2495,6 @@ All of these are also changes from \Zerocash. The name \Sprout is used for the \Zcash protocol prior to \Sapling (both before and after \Overwinter), and in particular its shielded protocol. -Technical terms for concepts that play an important rôle in \Zcash are -written in \defining{\term{slanted text}}. \emph{Italics} are used for emphasis and -for references between sections of the document. - -The key words \defining{\MUST, \MUSTNOT, \SHOULD, \SHOULDNOT, \RECOMMENDED, \MAY, and \OPTIONAL} -in this document are to be interpreted as described in \cite{RFC-2119} when -they appear in \defining{\ALLCAPS}. These words may also appear in this document in -lower case as plain English words, absent their normative meanings. - \vspace{2ex} \introlist This specification is structured as follows: @@ -13990,6 +13992,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Various rationale updates for \NUFive. } %nufive + \item Add a definition for the \S{} symbol in \crossref{introduction}, before its first use. \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). \item Remove magenta highlighting of differences from \Zerocash. diff --git a/zip-0225.rst b/zip-0225.rst index 6500910d..2d0a4278 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -20,6 +20,9 @@ Terminology The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]_ +The character § is used when referring to sections of the Zcash Protocol Specification +[#protocol-nu5]_. + Abstract ======== From 5e55821889cb47c88695b1b2c34a5507596b4e95 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 16:40:39 +0000 Subject: [PATCH 32/41] NCC audit: Make the description of when fields are included in v5 transactions consistent between the protocol specification and ZIP 225. Also regenerate the HTML for ZIP 225. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 39 +++++++++++++-------------- zip-0225.html | 62 ++++++++++++++++++++++++------------------- zip-0225.rst | 12 +++++---- 3 files changed, 60 insertions(+), 53 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 24de2315..18ca74f0 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11977,13 +11977,13 @@ The net value of \Sapling{} spends minus outputs.\! \\ \hline $\ddagger$ & $32$ & $\anchorField{Sapling}$ & \type{byte[32]} & A \merkleRoot of the \Sapling \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Sapling}\big)$.\! \\ \hline -$\ddagger$ & \Longunderstack{$192 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendProofsSapling$ & \type{byte[192]} \type{[$\nSpendsSapling$]} & +& \Longunderstack{$192 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendProofsSapling$ & \type{byte[192]} \type{[$\nSpendsSapling$]} & Encodings of the \zkSNARKProofs for each \Sapling \spendDescription.\! \\ \hline -$\ddagger$ & \Longunderstack{$64 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendAuthSigs{Sapling}$ & \type{byte[64]} \type{[$\nSpendsSapling$]} & -Authorizing signatures for each \Sapling \outputDescription.\! \\ \hline +& \Longunderstack{$64 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendAuthSigs{Sapling}$ & \type{byte[64]} \type{[$\nSpendsSapling$]} & +Authorizing signatures for each \Sapling \spendDescription.\! \\ \hline -$\ddagger$ & \Longunderstack{$192 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputProofsSapling$ & \type{byte[192]} \type{[$\nOutputsSapling$]} & +& \Longunderstack{$192 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputProofsSapling$ & \type{byte[192]} \type{[$\nOutputsSapling$]} & Encodings of the \zkSNARKProofs for each \Sapling \outputDescription.\! \\ \hline $\ddagger$ & $64$ & $\bindingSig{Sapling}$ & \type{byte[64]} & @@ -12015,7 +12015,7 @@ The length of the aggregated \zkSNARKProof $\ProofAction$.\! \\ \hline $\mathsection$ & \!$\sizeProofsOrchard$\! & $\proofsOrchard$ & \type{byte[$\sizeProofsOrchard$]}\!\! & The aggregated \zkSNARKProof $\ProofAction$ (see \crossref{halo2}).\! \\ \hline -$\mathsection$ & \Longunderstack{$64 \mult$ \\$\!\nActionsOrchard\!$} & $\vSpendAuthSigs{Orchard}$ & \type{byte[64]} \type{[$\nActionsOrchard$]} & +& \Longunderstack{$64 \mult$ \\$\!\nActionsOrchard\!$} & $\vSpendAuthSigs{Orchard}$ & \type{byte[64]} \type{[$\nActionsOrchard$]} & Authorizing signatures for each spend of an \Orchard \actionDescription.\! \\ \hline $\mathsection$ & $64$ & $\bindingSig{Orchard}$ & \type{byte[64]} & @@ -12026,17 +12026,16 @@ An \orchardBindingSignature on the \sighashTxHash, validated per \crossref{concr } %scalebox \vspace{-0.3ex} -$\ddagger$ & The fields \valueBalance{Sapling}, \anchorField{Sapling}, \vSpendProofsSapling, -\vSpendAuthSigs{Sapling}, \vOutputProofsSapling, and \bindingSig{Sapling} are present if and -only if $\nSpendsSapling + \nOutputsSapling > 0$. If \valueBalance{Sapling} is not present, -then $\vBalance{Sapling}$ is defined to be $0$. \\[-0.5ex] \scalebox{0.87}{ \begin{tabularx}{1.14\textwidth}{@{\!\!}l@{\hskip 1em}X@{}} +$\ddagger$ & \valueBalance{Sapling}, \anchorField{Sapling}, and \bindingSig{Sapling} +are present if and only if $\nSpendsSapling + \nOutputsSapling > 0$. If \valueBalance{Sapling} +is not present, then $\vBalance{Sapling}$ is defined to be $0$. \\[-0.5ex] $\mathsection$ & The fields \flagsOrchard, \valueBalance{Orchard}, \anchorField{Orchard}, -\sizeProofsOrchard, \proofsOrchard, \vSpendAuthSigs{Orchard}, and \bindingSig{Orchard} -are present if and only if $\nActionsOrchard > 0$. If \valueBalance{Orchard} is not present, -then $\vBalance{Orchard}$ is defined to be $0$. +\sizeProofsOrchard, \proofsOrchard, and \bindingSig{Orchard} are present if and only if +$\nActionsOrchard > 0$. If \valueBalance{Orchard} is not present, then $\vBalance{Orchard}$ +is defined to be $0$. \end{tabularx} } %scalebox \end{center} @@ -12204,9 +12203,9 @@ each \spendDescription\, (\crossref{spendencodingandconsensus}),\,\notnufive{ an be enforceable in the combined \actionTransfer design. Second, if a security vulnerability were found that affected only the input side, or only the output side of the \actionCircuit, it would be possible to use these flags in a soft fork (i.e.\ - a strictly contracting consensus change) to effectively ``switch off'' non-zero-value transfers - only on the relevant side. -} %nufive + a strictly contracting consensus change) to effectively ``switch off'' non-zero-valued transfers + only on the relevant side. Setting either of these flags to $0$ does not affect the presence or + validation of \spendAuthSignatures, or other consensus rules associated with \actionDescriptions.\!\!} %nufive \nufiveonwarditem{Because \enableSpendsOrchard{} is set to $0$ in version 5 \coinbaseTransactions\ --which disables non-zero-valued \Orchard spends-- the $\valueBalance{Orchard}$ field of a \coinbaseTransaction must have a negative or zero value.} @@ -12227,11 +12226,9 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B \overwinteronwarditem{The field $\nVersionGroupId$ has been added.} \saplingonwarditem{The following fields have been added: $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, $\vOutputsSapling$, and $\bindingSig{Sapling}$.} - \nufiveonwarditem{In version 5 \transactions, the $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, - and $\vOutputsSapling$ fields are renamed to $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, - and $\vOutputsSapling$ respectively.} - \nufiveonwarditem{The $\nActionsOrchard$, $\vActionsOrchard$, and $\bindingSig{Orchard}$ fields - have been added.} + \nufiveonwarditem{In version 5 \transactions, these fields have been added: $\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 at least one of $\nJoinSplit$\sapling{, $\nSpendsSapling$,\notnufive{ and} $\nOutputsSapling$}\nufive{, and $\nActionsOrchard$} are nonzero. @@ -13986,6 +13983,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. into \Pallas and \Vesta. \item Correct the sizes of \type{SpendDescriptionV5} and \type{OutputDescriptionV5} in the version 5 \transaction format. + \item Make the description of when fields are included in v5 \transactions consistent + between the protocol specification and \cite{ZIP-225}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. diff --git a/zip-0225.html b/zip-0225.html index 49b994bf..e58e6129 100644 --- a/zip-0225.html +++ b/zip-0225.html @@ -3,6 +3,7 @@ ZIP 225: Version 5 Transaction Format +
@@ -20,10 +21,11 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/440>

Terminology

The key words "MUST" and "MAY" in this document are to be interpreted as described in RFC 2119. 1

+

The character § is used when referring to sections of the Zcash Protocol Specification 2.

Abstract

-

This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol 2. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.

-

This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 7.

+

This proposal defines an update to the Zcash peer-to-peer transaction format to include support for data elements required to support the Orchard protocol 2. The new transaction format defines well-bounded regions of the serialized form to serve each of the existing pools of funds, and adds and describes a new region containing Orchard-specific elements.

+

This ZIP also depends upon and defines modifications to the computation of the values TxId Digest, Signature Digest, and Authorizing Data Commitment defined by ZIP 244 7.

Motivation

The new Orchard shielded pool requires serialized data elements that are distinct from any previous Zcash transaction. In addition, with the activation of ZIP 244, the serialized transaction format will no longer be consensus-critical. It makes sense at this point to define a format that can readily accommodate future extension in a systematic fashion, where elements required for support for a given pool are kept separate.

@@ -124,7 +126,7 @@ Discussions-To: <https://g Number of Sapling Spend descriptions in vSpendsSapling. - 128 * nSpendsSapling + 96 * nSpendsSapling vSpendsSapling SpendDescriptionV5[nSpendsSapling] A sequence of Sapling Spend descriptions, encoded per protocol §7.3 ‘Spend Description Encoding and Consensus’. @@ -201,8 +203,8 @@ Discussions-To: <https://g
An 8-bit value representing a set of flags. Ordered from LSB to MSB:
    -
  • spendsEnabledOrchard
    • -
  • outputsEnabledOrchard
    • +
  • enableSpendsOrchard
    • +
  • enableOutputsOrchard
  • The remaining bits are set to 0.
@@ -248,12 +250,16 @@ Discussions-To: <https://g
    -
  • The valueBalanceSapling, anchorSapling, and bindingSigSapling fields are present if and only if nSpendsSapling + nOutputsSapling > 0. If valueBalanceSapling is not present, then valueBalanceSapling is defined to be 0.
    • -
  • The valueBalanceOrchard, anchorOrchard, and bindingSigOrchard fields are present if and only if nActionsOrchard > 0. If valueBalanceOrchard is not present, then valueBalanceOrchard is defined to be 0.
    • +
  • The fields valueBalanceSapling, anchorSapling, and bindingSigSapling are present if and only if nSpendsSapling + nOutputsSapling > 0. If valueBalanceSapling is not present, then + \(\mathsf{v^{balanceSapling}}\) + is defined to be 0.
    • +
  • The fields flagsOrchard, valueBalanceOrchard, anchorOrchard, sizeProofsOrchard, proofsOrchard, and bindingSigOrchard are present if and only if nActionsOrchard > 0. If valueBalanceOrchard is not present, then + \(\mathsf{v^{balanceOrchard}}\) + is defined to be 0.
  • The elements of vSpendProofsSapling and vSpendAuthSigsSapling have a 1:1 correspondence to the elements of vSpendsSapling and MUST be ordered such that the proof or signature at a given index corresponds to the SpendDescriptionV5 at the same index.
  • The elements of vOutputProofsSapling have a 1:1 correspondence to the elements of vOutputsSapling and MUST be ordered such that the proof at a given index corresponds to the OutputDescriptionV5 at the same index.
  • The proofs aggregated in proofsOrchard, and the elements of vSpendAuthSigsOrchard, each have a 1:1 correspondence to the elements of vActionsOrchard and MUST be ordered such that the proof or signature at a given index corresponds to the OrchardAction at the same index.
    • -
  • For coinbase transactions, the spendsEnabledOrchard bit MUST be set to 0.
    • +
  • For coinbase transactions, the enableSpendsOrchard bit MUST be set to 0.

The encodings of tx_in, and tx_out are as in a version 4 transaction (i.e. unchanged from Canopy). The encodings of SpendDescriptionV5, OutputDescriptionV5 and OrchardAction are described below. The encoding of Sapling Spends and Outputs has changed relative to prior versions in order to better separate data that describe the effects of the transaction from the proofs of and commitments to those effects, and for symmetry with this separation in the Orchard-related parts of the transaction format.

@@ -288,7 +294,7 @@ Discussions-To: <https://g -

The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification 3.

+

The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification 3.

Sapling Output Description (OutputDescriptionV5)

@@ -328,12 +334,12 @@ Discussions-To: <https://g - +
80 outCiphertextbyte[580]byte[80] The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key.
-

The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification 4.

+

The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification 4.

Orchard Action Description (OrchardAction)

@@ -385,22 +391,22 @@ Discussions-To: <https://g - +
80 outCiphertextbyte[580]byte[80] The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key.
-

The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification 5.

+

The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification 5.

Modifications to ZIP 244

TxId Digest

-

The tree of hashes defined by ZIP 244 7 is re-structured to include a new branch for Orchard hashes. The orchard_digest branch is the only new addition to the tree; header_digest, transparent_digest, sprout_digest, and sapling_digest are as in ZIP 244:

+

The tree of hashes defined by ZIP 244 7 is re-structured to include a new branch for Orchard hashes. The orchard_digest branch is the only new addition to the tree; header_digest, transparent_digest, sprout_digest, and sapling_digest are as in ZIP 244:

txid_digest
 ├── header_digest
 ├── transparent_digest
 ├── sapling_digest
 └── orchard_digest
-
txid_digest
+
txid_digest

The top hash of the txid_digest tree is modified from the ZIP 244 structure to be a BLAKE2b-256 hash of the following values

T.1: header_digest      (32-byte hash output)
 T.2: transparent_digest (32-byte hash output)
@@ -419,7 +425,7 @@ T.4e: valueBalanceOrchard                 (64-bit signed little-endian)
"ZTxIdOrchardHash"
T.4b: orchard_actions_compact_digest
-

A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 8 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

+

A BLAKE2b-256 hash of the subset of Orchard Action information intended to be included in an updated version of the ZIP-307 8 CompactBlock format for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

T.4b.i  : nullifier            (field encoding bytes)
 T.4b.ii : cmx                  (field encoding bytes)
 T.4b.iii: ephemeralKey         (field encoding bytes)
@@ -434,7 +440,7 @@ T.4b.iv : encCiphertext[..52]  (First 52 bytes of field encoding)
"ZTxIdOrcOutMHash"
T.4d: orchard_actions_noncompact_digest
-

A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 8 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

+

A BLAKE2b-256 hash of the remaining subset of Orchard Action information not intended for inclusion in an updated version of the the ZIP 307 8 CompactBlock format, for all Orchard Actions belonging to the transaction. For each Action, the following elements are included in the hash:

T.4d.i  : cv                    (field encoding bytes)
 T.4d.ii : rk                    (field encoding bytes)
 T.4d.iii: encCiphertext[564..]  (post-memo suffix of field encoding)
@@ -444,14 +450,14 @@ T.4d.iv : outCiphertext         (field encoding bytes)

Signature Digest

-

The signature digest creation algorithm defined by ZIP 244 7 is modified to include a new branch for Orchard hashes. The orchard_digest branch is the only new addition to the tree; header_digest, transparent_digest, sprout_digest, and sapling_digest are as in ZIP 244:

+

The signature digest creation algorithm defined by ZIP 244 7 is modified to include a new branch for Orchard hashes. The orchard_digest branch is the only new addition to the tree; header_digest, transparent_digest, sprout_digest, and sapling_digest are as in ZIP 244:

signature_digest
 ├── header_digest
 ├── transparent_digest
 ├── sprout_digest
 ├── sapling_digest
 └── orchard_digest
-
signature_digest
+
signature_digest

A BLAKE2b-256 hash of the following values

S.1: header_digest      (32-byte hash output)
 S.2: transparent_digest (32-byte hash output)
@@ -464,14 +470,14 @@ S.4: orchard_digest     (32-byte hash output)

Authorizing Data Commitment

-

The tree of hashes defined by ZIP 244 7 for authorizing data commitments is re-structured to include a new branch for Orchard Actions. The orchard_digest branch is the only new addition to the tree; transparent_digest, and sprout_digest sapling_digest are as in ZIP 244:

+

The tree of hashes defined by ZIP 244 7 for authorizing data commitments is re-structured to include a new branch for Orchard Actions. The orchard_digest branch is the only new addition to the tree; transparent_digest, and sprout_digest sapling_digest are as in ZIP 244:

auth_digest
 ├── transparent_scripts_digest
 ├── sprout_auth_digest
 ├── sapling_auth_digest
 └── orchard_auth_digest
auth_digest
-

The tree of hashes defined by ZIP 244 7 for authorizing data commitments is re-structured to include a new branch for Orchard authorizing data. The orchard_auth_digest branch is the only new addition to the tree; transparent_auth_digest, sprout_auth_digest, and sapling_auth_digest are as in ZIP 244:

+

The tree of hashes defined by ZIP 244 7 for authorizing data commitments is re-structured to include a new branch for Orchard authorizing data. The orchard_auth_digest branch is the only new addition to the tree; transparent_auth_digest, sprout_auth_digest, and sapling_auth_digest are as in ZIP 244:

A.1: transparent_scripts_digest (32-byte hash output)
 A.2: sprout_auth_digest         (32-byte hash output)
 A.3: sapling_auth_digest        (32-byte hash output)
@@ -497,9 +503,9 @@ A.4c: bindingSigOrchard        (field encoding bytes)

Removing these fields reduces the complexity of the NU5 upgrade in the following ways:

  • V5 parsing and serialization code does not need to take these fields into account.
    • -
  • ZIP 244 7 transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.
    • +
  • ZIP 244 7 transaction identifier, signature hash, and authorizing data commitment computations are simplified by excluding consideration of these fields.
-

Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 6 extension or by other means not yet determined.

+

Removal of these fields means that that in the future, removing the support for the V4 transaction format will also effectively end support for Sprout transactions on the Zcash network, though it might be possible to restore limited support for migration via a future ZIP 222 6 extension or by other means not yet determined.

The original definitions for the transaction fields that have been removed are:

@@ -548,11 +554,11 @@ A.4c: bindingSigOrchard (field encoding bytes)
- +
- +
2Zcash Protocol Specification, Version 2021.1.17 or laterZcash Protocol Specification, Version 2021.1.20 or later
@@ -560,7 +566,7 @@ A.4c: bindingSigOrchard (field encoding bytes) 3 - Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.4: Spend Descriptions + Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.4: Spend Descriptions @@ -568,7 +574,7 @@ A.4c: bindingSigOrchard (field encoding bytes) 4 - Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.5: Output Descriptions + Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.5: Output Descriptions @@ -576,7 +582,7 @@ A.4c: bindingSigOrchard (field encoding bytes) 5 - Zcash Protocol Specification, Version 2021.1.17 or later. Section 4.6: Action Descriptions + Zcash Protocol Specification, Version 2021.1.20 or later. Section 4.6: Action Descriptions diff --git a/zip-0225.rst b/zip-0225.rst index 2d0a4278..066ec43a 100644 --- a/zip-0225.rst +++ b/zip-0225.rst @@ -157,13 +157,15 @@ Transaction Format |``64`` |``bindingSigOrchard`` |``byte[64]`` |An Orchard binding signature on the SIGHASH transaction hash. | +-----------------------------+--------------------------+----------------------------------------+---------------------------------------------------------------------+ -* The ``valueBalanceSapling``, ``anchorSapling``, and ``bindingSigSapling`` fields are +* The fields ``valueBalanceSapling``, ``anchorSapling``, and ``bindingSigSapling`` are present if and only if ``nSpendsSapling + nOutputsSapling > 0``. If - ``valueBalanceSapling`` is not present, then ``valueBalanceSapling`` is defined to be 0. + ``valueBalanceSapling`` is not present, then :math:`\mathsf{v^{balanceSapling}}`` is + defined to be 0. -* The ``valueBalanceOrchard``, ``anchorOrchard``, and ``bindingSigOrchard`` fields are - present if and only if ``nActionsOrchard > 0``. If ``valueBalanceOrchard`` is not - present, then ``valueBalanceOrchard`` is defined to be 0. +* The fields ``flagsOrchard``, ``valueBalanceOrchard``, ``anchorOrchard``, + ``sizeProofsOrchard``, ``proofsOrchard``, and ``bindingSigOrchard`` are present + if and only if ``nActionsOrchard > 0``. If ``valueBalanceOrchard`` is not present, then + :math:`\mathsf{v^{balanceOrchard}}` is defined to be 0. * The elements of ``vSpendProofsSapling`` and ``vSpendAuthSigsSapling`` have a 1:1 correspondence to the elements of ``vSpendsSapling`` and MUST be ordered such that the From 212fdc87522c805f08a6a95b9eda689d16bdb6ac Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:05:19 +0000 Subject: [PATCH 33/41] Add references for the halo2 book. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 5 +++-- protocol/zcash.bib | 8 ++++++++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 18ca74f0..bc61f62e 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -10681,7 +10681,7 @@ Define $\sqrtratioG(\num, \xdiv) \typecolon \GF{\ParamG{q}} \times \GFstar{\Para \item An arbitrary square root may be chosen in either case of the definition. The result is never $\bot$. \item The choice of the nonsquare $\ParamG{\lambda}$ is also arbitrary and will not affect the output of $\maptocurvesimpleswuIsoG$ defined below. - \item The computation of $\sqrtratioG$ can be optimized as described in \todo{}. + \item The computation of $\sqrtratioG$ can be optimized as described in \cite[section 3.2.1 Fields]{Zcash-halo2}. \end{nnotes} Define $\ParamIsoG{Z} := -13 \pmod{\ParamG{q}}$. (This value is suitable for both \IsoPallas and \IsoVesta.) @@ -10946,7 +10946,7 @@ verifier \MUST check, for the encoding of each element, that: \lsubsubsubsection{\HaloTwoText}{halo2} For \Orchard \actionDescriptions in version 5 \transactions, \Zcash uses \zkSNARKs with the -\defining{\HaloTwo} \provingSystem described in \todo{}. +\defining{\HaloTwo} \provingSystem described in \cite{Zcash-halo2}. \introlist \lsubsubsubsubsection{Encoding of \HaloTwoText{} Proofs}{halo2encoding} @@ -13987,6 +13987,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. between the protocol specification and \cite{ZIP-225}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} + \item Add references to \cite{Zcash-halo2}. \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Various rationale updates for \NUFive. diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 3c13e13d..8f041922 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -1840,3 +1840,11 @@ Proceedings of the 19th Annual International Cryptology Conference url={https://zcash.github.io/orchard/}, urldate={2021-03-02} } + +@misc{Zcash-halo2, + presort={Zcash-halo2}, + author={Daira Hopwood and Sean Bowe and Jack Grigg and Kris Nuttycombe and Ying Tong Lai and Steven Smith}, + title={The halo2 Book}, + url={https://zcash.github.io/halo2/}, + urldate={2021-03-23} +} From bbc6131f2979382edddadee2430fbb7467642b7c Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:28:06 +0000 Subject: [PATCH 34/41] Update specification of Poseidon. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 33 +++++++++++++++++++++------------ protocol/zcash.bib | 19 +++++++++++++++++++ 2 files changed, 40 insertions(+), 12 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index bc61f62e..1fdb1787 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -8534,6 +8534,10 @@ inside a circuit. $\Poseidon$ is a cryptographic permutation described in \cite{GKRRS2019}. It operates over a sequence of finite field elements, which we instantiate as $\typeexp{\GF{\ParamP{q}}}{3}$. +The following specification is intended to follow \cite{GKRRS2019} and Version 1.1 of the $\Poseidon$ +reference implementation \cite{Poseidon-1.1}.\footnote{\nufive{Previous versions of the reference implementation +were inconsistent with the paper.}} + The S-box function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and the number of partial rounds $R_P$ is $58$. @@ -8541,8 +8545,9 @@ We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise a $\GF{\ParamP{q}}$ replacing exclusive-or of bit strings\footnote{\nufive{The sponge construction was originally proposed as operating on an arbitrary group. \cite{BDPA2007}}}) to construct a \hashFunction. The sponge capacity is one field element, the rate is two field elements, and -the output is one field element. We do not append any padding to the input message; this does -not affect security because the input length is fixed. +the output is one field element. We use the ``Constant-Input-Length''\strut mode described in +\cite[section 4.2]{GKRRS2019}: for a $2$-element input, the initial value of the capacity +element is $2^{65}$, and no padding of the input message is needed. That is, if $f \typecolon \typeexp{\GF{\ParamP{q}}}{3} \rightarrow \typeexp{\GF{\ParamP{q}}}{3}$ is the $\Poseidon$ permutation, then the \hashFunction @@ -8553,11 +8558,13 @@ is specified as: \item $\PoseidonHash(x, y) = f([x, y, 2^{65}])_1$ (using $1$-based indexing). \end{formulae} -\todo{Specify the MDS matrix.} +The MDS matrix is as generated by \texttt{generate\_parameters\_grain.sage} in Version 1.1 of the +reference implementation. \begin{nnotes} \item The choice of MDS matrix and the number of rounds take into account cryptanalytic - results in \cite{KR2020} and \cite{BCD+2020}. \todo{check.} + results in \cite{KR2020} and \cite{BCD+2020}. A detailed analysis of related matrix + properties is given in \cite{GRS2020}. \item \cite{BCD+2020} says that ``... finite fields $\mathbb{F}_q$ with a limited number of multiplicative subgroups might be preferable, i.e.\ one might want to avoid $q-1$ being smooth. This implies that the fields which are @@ -8565,8 +8572,8 @@ is specified as: $\GF{\ParamP{q}}$ is such a field; the factorization of $\ParamP{q}-1$ is $2^{32} \mult 3 \mult 463 \mult 539204044132271846773 \mult 8999194758858563409123804352480028797519453$. - Furthermore, cryptanalysis of $\Poseidon$ has focussed mainly on the case of S-box - $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because + Furthermore, previous cryptanalysis of $\Poseidon$ has focussed mainly on the case + of S-box $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because $x \mapsto x^3$ would not be a permutation. $\alpha = 5$ is the smallest integer for which $x \mapsto x^\alpha$ is a permutation in $\GF{\ParamP{q}}$. @@ -8581,19 +8588,20 @@ is specified as: sponge mode limits an adversary to only being able to influence part of the $\Poseidon$ permutation input, and we use it only to construct a PRF ($\PRFnf{Orchard}{}$ as described in \crossref{concreteprfs}). Half of the sponge input is a random key $\NullifierKey$, - known only to holders of a \fullViewingKey, and the remaining half $\NoteUniqueRandRepr$ - is also chosen randomly by the \note creator (both are derived using $\PRFexpand{}$, - from $\SpendingKey$ and $\NoteSeedBytes$ respectively). Then the PRF is used to enhance - the security of a discrete-log-based nullifier construction (described in \crossref{...}) + known only to holders of a \fullViewingKey, and the remaining half $\NoteUniqueRand$ + comes from a previous \nullifier which is effectively a random $x$-coordinate on the + \pallasCurve. Then the PRF is used to enhance the security of a discrete-logarithm-based + nullifier construction (described in \cite[Section 3.5 Nullifiers]{Zcash-Orchard}) against a potential discrete-log-breaking adversary. Given the weak assumption that the $\PoseidonHash$ sponge produces output that preserves sufficient entropy - from the inputs $\NullifierKey$ and $\NoteUniqueRandRepr$, this nullifier + from the inputs $\NullifierKey$ and $\NoteUniqueRand$, this nullifier construction would still be secure under a decisional Diffie--Hellman assumption on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from an ideal PRF. The recommended number of partial rounds for these parameters in the Poseidon paper - is $57$, but we prefer an even number of partial rounds for circuit efficiency. + is $57$, but we prefer an even number of partial rounds to simplify the circuit + implementation. \item The constant $2^{65}$ comes from \cite[section 4.2]{GKRRS2019}: ``Constant-Input-Length Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ where $o$ is the output length.'' In this case the input length ($\mathit{length}$) is @@ -13987,6 +13995,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. between the protocol specification and \cite{ZIP-225}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} + \item Update specification of $\Poseidon$. \item Add references to \cite{Zcash-halo2}. \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 8f041922..2a93dd60 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -501,6 +501,15 @@ Received March~20, 2012.} Last updated December~16, 2020.} } +@misc{Poseidon-1.1, + presort={Poseidon-1.1}, + author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger}, + title={Poseidon reference implementation, Version 1.1}, + date={2021-03-07}, + url={https://extgit.iaik.tugraz.at/krypto/hadeshash/-/commit/7ecf9a7d4f37e777ea27e4c4d379443151270563}, + urldate={2021-03-23} +} + @misc{BDPA2007, presort={BDPA2007}, author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, @@ -600,6 +609,16 @@ Last revised November~11, 2020.}, Lecture Notes in Computer Science; Springer, 2020.} } +@misc{GRS2020, + presort={GRS2020}, + author={Lorenzo Grassi and Christian Rechberger and Markus Schofnegger}, + title={Proving Resistance Against Infinitely Long Subspace Trails: {H}ow to Choose the Linear Layer}, + url={https://eprint.iacr.org/2020/500}, + urldate={2021-03-23}, + howpublished={Cryptology ePrint Archive: Report 2020/500. +Last revised January~27, 2021.} +} + @misc{AGRRT2017, presort={AGRRT2017}, author={Martin Albrecht and Lorenzo Grassi and Christian Rechberger and From 4d3204b8e15bdd883d9f18286d93edd0489a2d1e Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:44:36 +0000 Subject: [PATCH 35/41] Describe the recommended way to encode a Sapling or unified payment address as a QR code. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 10 ++++++++++ protocol/zcash.bib | 10 ++++++++++ 2 files changed, 20 insertions(+) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 1fdb1787..0fd2fb15 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -11080,6 +11080,12 @@ compatibility with software that only accepts previous address formats is requir A \unifiedPaymentAddress is encoded with \Bechm \cite{BIP-350} rather than \Bech. } %nufive +\vspace{1ex} +\xPaymentAddresses \MAY be encoded as QR codes; in this case, the \RECOMMENDED format +for a \Sapling\nufive{ or unified} \paymentAddress is the \Bech\nufive{ or \Bechm} +form converted to uppercase, using the Alphanumeric mode \cite[sections 7.3.4 and 7.4.4]{ISO2015}. +} %sapling + \introsection \lsubsubsection{Transparent Encodings}{transparentencodings} @@ -14001,6 +14007,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Various rationale updates for \NUFive. } %nufive +\sapling{ + \item Describe the recommended way to encode a \Sapling\nufive{ or unified} \paymentAddress + as a QR code. +} %sapling \item Add a definition for the \S{} symbol in \crossref{introduction}, before its first use. \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 2a93dd60..14e0b325 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -1491,6 +1491,16 @@ Last revised February~5, 2018.} doi={10.1109/IEEESTD.2004.94612} } +@misc{ISO2015, + author={ISO/IEC}, + title={International {S}tandard {ISO/IEC} 18004:2015(E): {I}nformation {T}echnology -- +{A}utomatic identification and data capture techniques -- {QR} {C}ode bar code symbology specification.}, + howpublished={Third edition}, + date={2015-02-01}, + url={https://raw.githubusercontent.com/yansikeim/QR-Code/master/ISO%20IEC%2018004%202015%20Standard.pdf}, + urldate={2021-03-22} +} + @misc{Zcash-libsnark, presort={Zcash-libsnark}, title={libsnark: {C}++ library for {zkSNARK} proofs (Zcash fork)}, From 74dfa801942067474be877df28971d1248556339 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:55:51 +0000 Subject: [PATCH 36/41] Fix errors in Orchard due to cut-and-paste from Sapling. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 0fd2fb15..dfc0dc4d 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -7361,7 +7361,7 @@ from $\TransmitPlaintext{}$ 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 - $\reprJ\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$.\!\!\nufive{\; For + $\reprG{}\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$.\!\!\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 @@ -10465,7 +10465,7 @@ Define $\reprG{} \typecolon \GroupG{} \rightarrow \ReprG{}$ such that \vspace{1ex} \introlist Define $\abstG{} \typecolon \ReprG{} \rightarrow \maybe{\GroupG{}}$ such that -$\abstJ\Of{P\Repr}$ is computed as follows: +$\abstG{}\Of{P\Repr}$ is computed as follows: \begin{formulae} \item let ${x\Repr} \typecolon \bitseq{255}$ be the first $255$ bits of $P\Repr$ and let $\tilde{y} \typecolon \bit$ be the last bit. @@ -12458,9 +12458,9 @@ $32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendA $\LEBStoOSP{256}\big(\reprP\Of{\AuthSignRandomizedPublic}\kern-0.1em\big)$. \\ \hline $32$ & $\cmxField$ & \type{byte[32]} & The $x$-coordinate of the \noteCommitment for the output \note, -$\LEBStoOSPOf{256}{\cmX}$ where $\cmU = \ExtractJ(\cm)$. \\ \hline +$\LEBStoOSPOf{256}{\cmX}$ where $\cmX = \ExtractP(\cm)$. \\ \hline -$32$ & $\ephemeralKey$ & \type{byte[32]} & An encoding of an ephemeral \Jubjub \publicKey, +$32$ & $\ephemeralKey$ & \type{byte[32]} & An encoding of an ephemeral \Pallas \publicKey, $\LEBStoOSP{256}\big(\reprP\Of{\EphemeralPublic}\kern-0.1em\big)$. \\ \hline $580$ & $\encCiphertext$ & \type{byte[580]} & A ciphertext component for the @@ -14002,6 +14002,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} \item Update specification of $\Poseidon$. + \item Fix errors in \Orchard due to cut-and-paste from \Sapling. \item Add references to \cite{Zcash-halo2}. \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. From cd1b4de8f93c324aa42215cb5597f012c26fb8d9 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:01:53 +0000 Subject: [PATCH 37/41] Update the hashFinalSaplingRoot/hashLightClientRoot/hashBlockCommitments field for NU5. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index dfc0dc4d..489d12ab 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -1961,6 +1961,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\hashFinalSaplingRoot}{\mathtt{hashFinalSaplingRoot}} \newcommand{\hashLightClientRoot}{\mathtt{hashLightClientRoot}} \newcommand{\hashChainHistoryRoot}{\mathtt{hashChainHistoryRoot}} +\newcommand{\hashBlockCommitments}{\mathtt{hashBlockCommitments}} \newcommand{\nTimeField}{\mathtt{nTime}} \newcommand{\nTime}{\mathsf{nTime}} \newcommand{\nBitsField}{\mathtt{nBits}} @@ -12507,12 +12508,16 @@ $32$ & $\hashMerkleRoot$ & \type{byte[32]} & A \shadHash hash in internal byte o merkle root is derived from the hashes of all \transactions included in this \block, ensuring that none of those \transactions can be modified without modifying the \header. \\ \hline -$32$ & \Longunderstack[l]{$\hashReserved$ /\\ \sapling{$\hashFinalSaplingRoot$} \notbeforeheartwood{/}\\ \heartwood{$\hashLightClientRoot$} } & +$32$ & \Longunderstack[l]{$\hashReserved$ /\\ \sapling{$\hashFinalSaplingRoot$} \notbeforeheartwood{/}\\ \heartwood{$\hashLightClientRoot$} +\notbeforenufive{/}\\ \nufive{$\hashBlockCommitments$}} & \type{byte[32]} & -\presapling{A reserved field which should be ignored.} -\saplingandblossom{The \merkleRoot $\LEBStoOSPOf{256}{\rt{Sapling}}$ of the \Sapling{} -\noteCommitmentTree corresponding to the final \Sapling \treestate of this \block.} -\heartwoodonward{The $\hashChainHistoryRoot$ of this \block.} \\ \hline +{\raggedright +\presapling{A reserved field, to be ignored.} \\ +\saplingandblossom{The \merkleRoot $\LEBStoOSP{256}\big(\rt{Sapling}\big)$ of the \Sapling{} +\noteCommitmentTree corresponding to the final \Sapling \treestate of this \block.\\} +\heartwoodonward{The $\hashChainHistoryRoot$ of this \block as defined in \cite{ZIP-221}.\\} +\nufiveonward{The $\hashBlockCommitments$ of this \block as defined in \cite{ZIP-244}.} +} \\ \hline $4$ & $\nTimeField$ & \type{uint32} & The \defining{\blockTimestamp} is a Unix epoch time (UTC) when the miner started hashing the \header (according to the miner). \\ \hline @@ -12622,6 +12627,13 @@ rejected by this rule at a given point in time may later be accepted. \item For \Heartwood, the $\hashFinalSaplingRoot$ field is renamed to $\hashLightClientRoot$. Once \Heartwood activates, the meaning of this field changes according to \cite{ZIP-221}. } +\canopy{ + \item There are no changes to the \blockVersionNumber or format for \Canopy. +} +\nufive{ + \item For \NUFive, the $\hashLightClientRoot$ field is renamed to $\hashBlockCommitments$. + Once \NUFive activates, the meaning of this field changes according to \cite{ZIP-244}. +} \end{pnotes} \introlist @@ -14001,6 +14013,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. between the protocol specification and \cite{ZIP-225}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} + \item Update the $\hashFinalSaplingRoot$/$\hashLightClientRoot$/$\hashBlockCommitments$ field for + \NUFive. \item Update specification of $\Poseidon$. \item Fix errors in \Orchard due to cut-and-paste from \Sapling. \item Add references to \cite{Zcash-halo2}. From b27213dfd3c7843daea7c056e492d826bf5ac5f9 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:04:06 +0000 Subject: [PATCH 38/41] =?UTF-8?q?Move=20the=20definition=20of=20=E2=8A=A5?= =?UTF-8?q?=20to=20before=20its=20first=20use.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 489d12ab..e816d086 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -2713,6 +2713,9 @@ $\setof{x \typecolon T \suchthat e_x \not\in V}$ and range $U$. $\powerset{T}$ means the powerset of $T$. +$\bot$ is a distinguished value used to indicate unavailable information, +or a failed decryption or validity check. + $\typeexp{T}{\ell}$, where $T$ is a type and $\ell$ is an integer, means the type of sequences of length $\ell$ with elements in $T$. For example, $\bitseq{\ell}$ means the set of sequences of $\ell$ bits, and @@ -2854,9 +2857,6 @@ $\ceiling{x}$ means the smallest integer $\geq x$. $\bitlength(x)$, for $x \typecolon \Nat$, means the smallest integer $\ell$ such that $2^\ell > x$. -The symbol $\bot$ is used to indicate unavailable information, or a failed -decryption or validity check. - \introlist The following integer constants will be instantiated in \crossref{constants}: \begin{formulae} @@ -14026,6 +14026,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Describe the recommended way to encode a \Sapling\nufive{ or unified} \paymentAddress as a QR code. } %sapling + \item Move the definition of $\bot$ to before its first use. \item Add a definition for the \S{} symbol in \crossref{introduction}, before its first use. \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). From c50bdbd9ce2036d6ddf0e17af6dd1e430ee753b0 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:05:59 +0000 Subject: [PATCH 39/41] Delete a confusing part of the definition of concatbits that we don't rely on. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index e816d086..65856672 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -2759,9 +2759,7 @@ inclusive, in descending order. $a \bconcat b$ means the concatenation of sequences $a$ then $b$. $\concatbits(S)$ means the sequence of bits obtained by -concatenating the elements of $S$ viewed as bit sequences. If the -elements of $S$ are byte sequences, they are converted to bit sequences -with the \emph{most significant} bit of each byte first. +concatenating the elements of $S$ as bit sequences. $\sorted(S)$ means the sequence formed by sorting the elements of $S$. @@ -14027,6 +14025,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. as a QR code. } %sapling \item Move the definition of $\bot$ to before its first use. + \item Delete a confusing part of the definition of $\concatbits$ that we don't rely on. \item Add a definition for the \S{} symbol in \crossref{introduction}, before its first use. \item Remove specification of \memo contents, which will be in \cite{ZIP-302}. \item Remove support for building the \Sprout-only specification (\texttt{sprout.pdf}). From aa86282e1601c2335ee9207acfc76336b2c41115 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:18:04 +0000 Subject: [PATCH 40/41] Change the specifications of note decryption to return the note and memo, rather than a note plaintext. Generalize the specification of block chain scanning to support Orchard. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 131 +++++++++++++++++++++++------------------- 1 file changed, 71 insertions(+), 60 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 65856672..73972aec 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -6982,8 +6982,10 @@ is defined as follows: \NoteCommitRand_i \typecolon \NoteCommitTrapdoor{Sprout}, \Memo_i \typecolon \MemoType)$ from $\TransmitPlaintext{i}$ \vspace{-0.4ex} - \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}((\AuthPublic, \Value_i, \NoteUniqueRand_i, - \NoteCommitRand_i)) \neq \cm_i$, return $\bot$, else return $\NotePlaintext{i}$. + \item let $\NoteTuple{i} = (\AuthPublic, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i)$ + \vspace{-0.4ex} + \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}(\NoteTuple{i}) \neq \cm_i$, return $\bot$ + \item return $(\NoteTuple{i}, \Memo_i)$. \end{formulae} \introlist @@ -7057,7 +7059,9 @@ For both encryption and decryption, instantiated in \crossref{notes}; \vspace{-0.25ex} \item let $\ToScalar{}$ be $\ToScalar{Sapling}$ defined in \crossref{saplingkeycomponents}\nufive{ or - $\ToScalar{Orchard}$ defined in \crossref{orchardkeycomponents}}. + $\ToScalar{Orchard}$ defined in \crossref{orchardkeycomponents}}; + \vspace{-0.25ex} + \item $\LEBStoOSP{}$, $\LEOStoIP{}$, $\ItoLEBSP{}$, and $\ItoLEOSP{}$ are defined in \crossref{endian}. \end{itemize} } %sapling @@ -7201,9 +7205,7 @@ from $\TransmitPlaintext{}$ } %canopy \item let $\DiversifiedTransmitPublic = \KADerivePublic{}(\InViewingKey, \DiversifiedTransmitBase)$ \vspace{-0.25ex} - \item \notbeforenufive{for \Sapling,} let $\cmstar' = \ExtractJ{}\big(\NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase}, - \reprJ\Of{\DiversifiedTransmitPublic}, - \Value)\kern-0.1em\big)$. + \item \notbeforenufive{for \Sapling,} let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand)$ \nufive{ \item for \Orchard: \vspace{-0.3ex} @@ -7211,21 +7213,26 @@ from $\TransmitPlaintext{}$ \vspace{-0.6ex} \item \tab let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. \vspace{-0.2ex} - \item \tab let $\cmstar' = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, - \reprP\Of{\DiversifiedTransmitPublic}, - \Value, - \NoteUniqueRand, - \NoteNullifierRand)\kern-0.1em\big)$ + \item \tab let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$ \item \blank } %nufive - \item if $\LEBStoOSPOf{256}{\cmstar'} \neq \cmstarField$, return $\bot$ -\vspace{-0.25ex} - \item return $\NotePlaintext{}$. + \item let $\cmstar' = \NoteCommitment{}\Of{\NoteTuple{}}$ + \vspace{-0.2ex} +\nufive{ + \item if (for \Orchard) $\cmstar' = \bot$, return $\bot$ + \vspace{-0.2ex} +} %nufive + \item if $\ItoLEOSP{256}\big(\ExtractG{}(\cmstar')\kern-0.1em\big) \neq \cmstarField$, return $\bot$ + \vspace{-1ex} + \item return $(\NoteTuple{}, \Memo)$. \end{algorithm} \vspace{-1.5ex} \begin{pnotes} \vspace{-0.5ex} + \item $\DiversifiedTransmitBase$ has already been computed when applying $\NoteCommitment{}$, and need + not be computed again. + \vspace{-0.5ex} \item For \Sapling, 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 $\KDF{Sapling}$\canopy{, and @@ -7248,8 +7255,7 @@ from $\TransmitPlaintext{}$ \vspace{-0.5ex} \item A client \MAY attempt to decrypt a \noteCiphertextSapling of a \transaction in the \mempool\canopy{, using the next \blockHeight for $\BlockHeight$}. However, in that case it \MUSTNOT assume that - the \transaction will be mined and \MUST treat the decrypted information as provisional. It - will not be able to calculate the $\NoteUniqueRand$ value. + the \transaction will be mined and \MUST treat the decrypted information as provisional, and private. \end{pnotes} } %sapling @@ -7323,14 +7329,8 @@ from $\TransmitPlaintext{}$ \item let $\NoteCommitRand = \LEOStoIPOf{256}{\NoteCommitRandBytes}$ and $\DiversifiedTransmitBase = \DiversifyHash{}(\Diversifier)$ \vspace{-0.6ex} - \item if $\NoteCommitRand \geq \ParamG{r}$, return $\bot$ -\notbeforenufive{ - \item for \Sapling: -} - \item \notbeforenufive{\tab} if $\DiversifiedTransmitBase = \bot$ or $\DiversifiedTransmitPublic \not\in \SubgroupJ$, return $\bot$ - \item \notbeforenufive{\tab} let $\cmstar' = \ExtractJ{}\big(\NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase}, - \reprJ\Of{\DiversifiedTransmitPublic}, - \Value)\kern-0.1em\big)$. + \item if $\NoteCommitRand \geq \ParamG{r}$ or\notbeforenufive{ (for \Sapling)} $\DiversifiedTransmitBase = \bot$ or $\DiversifiedTransmitPublic \not\in \SubgroupJ$, return $\bot$ + \item \notbeforenufive{for \Sapling,} let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand)$ \nufive{ \item for \Orchard: \vspace{-0.4ex} @@ -7338,23 +7338,35 @@ from $\TransmitPlaintext{}$ \vspace{-0.75ex} \item \tab let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. \vspace{-0.4ex} - \item \tab let $\cmstar' = \ExtractP\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, - \reprP\Of{\DiversifiedTransmitPublic}, - \Value, - \NoteUniqueRand, - \NoteNullifierRand)\kern-0.1em\big)$ + \item \tab let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$ \item \vspace{-3.5ex} } %nufive - \item if $\LEBStoOSPOf{256}{\cmstar'} \neq \cmstarField$, return $\bot$ + \item let $\cmstar' = \NoteCommitment{}\Of{\NoteTuple{}}$ + \vspace{-0.4ex} +\nufive{ + \item if (for \Orchard) $\cmstar' = \bot$, return $\bot$ + \vspace{-0.4ex} +} %nufive + \item if $\ItoLEOSP{256}\big(\ExtractG{}(\cmstar')\kern-0.1em\big) \neq \cmstarField$, return $\bot$ \vspace{-1ex} \item if $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big) \neq \ephemeralKey$, return $\bot$ \vspace{-0.4ex} - \item return $\NotePlaintext{}$. + \item return $(\NoteTuple{}, \Memo)$. \end{algorithm} \vspace{-2ex} \begin{pnotes} + \vspace{-0.75ex} + \item $\DiversifiedTransmitBase$ has already been computed when applying $\NoteCommitment{}$, and need + not be computed again. + \notnufive{\introlist} + \vspace{-0.5ex} + \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. + \notbeforenufive{\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 @@ -7369,11 +7381,6 @@ from $\TransmitPlaintext{}$ \nufiveonwarditem{This procedure returns $\bot$ if $\DiversifiedTransmitPublicRepr$ is \nonCanonicalPoint (which can only occur for \Sapling \notes), as specified in \cite{ZIP-216}.} \vspace{-0.5ex} - \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 $\SubgroupJ$ (i.e.\ the condition - ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJ$, return $\bot$``). That did not match the - implementation in \zcashd, which does require $\DiversifiedTransmitPublic$ to be in the subgroup. - The specification has been changed to match \zcashd. \item The comments in \crossref{decryptivk} concerning calculation of $\NoteUniqueRand$, detection of spent \notes, and decryption of \noteCiphertextsSapling for \transactions in the \mempool also apply to \notes decrypted by this procedure. @@ -7438,10 +7445,7 @@ to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \mem \item \tab \tab \tab Attempt to decrypt the \notesCiphertextSprout component $(\EphemeralPublic, \TransmitCiphertext{i})$ using $\InViewingKey$ with the \vspace{-1.2ex} - \item \tab \tab \tab algorithm in \crossref{sproutdecrypt}. If this succeeds giving $\NotePlaintext{}$: - \item \tab \tab \tab \tab Extract $\NoteTuple{}$ and $\Memo \typecolon \MemoType$ from $\NotePlaintext{}$ - (taking the $\AuthPublic$ field of the \note to be $\AuthPublic$ from - $\InViewingKey$). + \item \tab \tab \tab algorithm in \crossref{sproutdecrypt}. If this succeeds with $(\NoteTuple{}, \Memo)$: \item \tab \tab \tab \tab Add $(\NoteTuple{}, \Memo)$ to $\ReceivedSet$. \item \tab \tab \tab \tab Calculate the nullifier $\nf$ of $\NoteTuple{}$ using $\AuthPrivate$ as described in \crossref{notes}. @@ -7459,47 +7463,50 @@ to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \mem \sapling{ \extralabel{saplingscan}{\lsubsection{Block Chain Scanning (\SaplingAndOrchardText)}{scan}} -\nufive{\todo{generalize for \Orchard}} - -In \Sapling, \blockChain scanning requires only the $\NullifierKey$ and $\InViewingKey$ +In \SaplingAndOrchard, \blockChain scanning requires only the $\NullifierKey$ and $\InViewingKey$ key components, rather than a \spendingKey as in \Sprout. Typically, these components are derived from a \fullViewingKey as described in -\crossref{saplingkeycomponents}. +\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}. \vspace{1ex} Let $\PRFOutputLengthNfSapling$ be as defined in \crossref{constants}. -Let $\NoteType{Sapling}$ be as defined in \crossref{notes}. +\nufive{ +Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. +} %nufive -Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}. +Let $\NoteType{}$ be $\NoteType{Sapling}$\nufive{ or $\NoteType{Orchard}$} as defined in \crossref{notes}. + +Let $\KA{}$ be\notbeforenufive{ either} $\KA{Sapling}$ as defined in \crossref{concretesaplingkeyagreement}\nufive{, or +$\KA{Orchard}$ as defined in \crossref{concreteorchardkeyagreement}}. + +Let $\NullifierType$ be $\PRFOutputNfSapling$\notbeforenufive{ for \Sapling}\nufive{, or $\GF{\ParamP{q}}$ for \Orchard}. \introsection \vspace{1ex} -The following algorithm can be used, given the \blockChain and -$(\NullifierKey \typecolon \SubgroupJ, \InViewingKey \typecolon \InViewingKeyTypeSapling)$, -to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \memo field, -and its final status (spent or unspent). +The following algorithm can be used, given the \blockChain and $(\NullifierKey, \InViewingKey)$, +to obtain each \note sent to the corresponding \shieldedPaymentAddress, its \memo, and its final +status (spent or unspent). \begin{algorithm} - \item let mutable $\ReceivedSet \typecolon \powerset{\NoteType{Sapling} \times \MemoType} \leftarrow \setof{}$ - \item let mutable $\SpentSet \typecolon \powerset{\NoteType{Sapling}} \leftarrow \setof{}$ - \item let mutable $\NullifierMap \typecolon \PRFOutputNfSapling \rightarrow \NoteType{Sapling} \leftarrow$ the empty mapping + \item let mutable $\ReceivedSet \typecolon \powerset{\NoteType{} \times \MemoType} \leftarrow \setof{}$ + \item let mutable $\SpentSet \typecolon \powerset{\NoteType{}} \leftarrow \setof{}$ \vspace{0.2ex} + \item let mutable $\NullifierMap \typecolon (\NullifierType \rightarrow \NoteType{}) \leftarrow$ the empty mapping \vspace{1ex} \item for each \transaction $\tx$: - \item \tab for each \outputDescription in $\tx$ with \notePosition $\NotePosition$: + \item \tab for each \outputDescription\nufive{ or \actionDescription} in $\tx$: \item \tab \tab Attempt to decrypt the \noteCiphertextSapling components $\EphemeralPublic$ and $\TransmitCiphertext{}$ using $\InViewingKey$ with the algorithm\vspace{-1.2ex}% - \item \tab \tab in \crossref{decryptivk}. If this succeeds giving $\NotePlaintext{}$: - \item \tab \tab \tab Extract $\NoteTuple{}$ and $\Memo \typecolon \MemoType$ from $\NotePlaintext{}$ - \item \tab \tab \tab Add $(\NoteTuple{}, \Memo)$ to $\ReceivedSet$ + \item \tab \tab \crossref{decryptivk}. If this succeeds \notbeforenufive{\vspace{-1.2ex}\item \tab \tab }with $(\NoteTuple{}, \Memo)$: + \item \tab \tab \tab Add $(\NoteTuple{}, \Memo)$ to $\ReceivedSet$. \item \tab \tab \tab Calculate the nullifier $\nf$ of $\NoteTuple{}$ using $\NullifierKey$ - and $\NotePosition$ as described in \crossref{notes}. + as described in \crossref{notes}. (This also requires $\NotePosition$\vspace{-1.2ex} + \item \tab \tab \tab from the \outputDescription\notbeforenufive{ for \Sapling \notes}.) \item \tab \tab \tab Add the mapping $\nf \rightarrow \NoteTuple{}$ to $\NullifierMap$. \item \blank - \item \tab for each \spendDescription in $\tx$: - \item \tab \tab let $\nf$ be the \nullifier of the \spendDescription + \item \tab for each \nullifier $\nf$ of a \spendDescription\nufive{ or \actionDescription} in $\tx$: \item \tab \tab if $\nf$ is present in $\NullifierMap$, add $\NullifierMap(\nf)$ to $\SpentSet$ \item \blank \item return $(\ReceivedSet, \SpentSet)$. @@ -14011,6 +14018,10 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. between the protocol specification and \cite{ZIP-225}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} + \item Change the specifications of \note decryption in \crossref{sproutinband} and + \crossref{saplingandorchardinband} to return the \note and \memo, rather than + a \notePlaintext. + \item Generalize the specification of \blockChain scanning in \crossref{scan} to support \Orchard. \item Update the $\hashFinalSaplingRoot$/$\hashLightClientRoot$/$\hashBlockCommitments$ field for \NUFive. \item Update specification of $\Poseidon$. From 2f246ce24db6837b96737512bccb00e3ae9e9944 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 18:18:25 +0000 Subject: [PATCH 41/41] Other fixes to the Orchard specification, including generation of dummy notes and output notes. fixes #465 Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 204 +++++++++++++++++++++++++----------------- 1 file changed, 121 insertions(+), 83 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 73972aec..277d2dbb 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -1611,6 +1611,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\NoteCommitRandOrSeedBytes}{\notcanopy{\NoteCommitRand}\canopy{\NoteSeedBytes}} \newcommand{\NoteCommitRandBytesOrSeedBytes}{\notcanopy{\NoteCommitRandBytes}\canopy{\NoteSeedBytes}} \newcommand{\NoteUniqueRand}{\mathsf{\uprho}} +\newcommand{\NoteUniqueRandPoint}{\NoteUniqueRand^{\GroupP}} \newcommand{\NoteUniqueRandRepr}{{\NoteUniqueRand\Repr}} \newcommand{\NoteUniqueRandOld}[1]{\NoteUniqueRand^\mathsf{old}_{#1}} \newcommand{\NoteUniqueRandNew}[1]{\NoteUniqueRand^\mathsf{new}_{#1}} @@ -4330,7 +4331,7 @@ A \defining{\representedGroup} $\GroupG{}$ consists of: \item a bit-length parameter $\ellG{} \typecolon \Nat$; \item a representation function \smash{$\reprG{} \typecolon \GroupG{} \rightarrow \bitseq{\ellG{}}$} and an abstraction function \smash{$\abstG{} \typecolon \bitseq{\ellG{}} \rightarrow \maybe{\GroupG{}}$}, - such that $\abstG{}$ is the left inverse of $\reprG{}$, i.e. for all $P \in \GroupG{}$, + such that $\abstG{}$ is a left inverse of $\reprG{}$, i.e. for all $P \in \GroupG{}$, $\abstG{}\big(\reprG{}(P)\kern-0.1em\big) = P$. \end{itemize} @@ -4727,7 +4728,8 @@ For each \spendingKey, there is also a \defining{\defaultDiversifiedPaymentAddre with a ``random-looking'' \diversifier. This allows an implementation that does not expose diversified addresses as a user-visible feature, to use a default address that cannot be distinguished (without knowledge of the \spendingKey) from one with a random -\diversifier as above. +\diversifier as above. Note however that the \zcashd wallet picks \diversifiers as in +\cite{ZIP-32}, rather than using this procedure. \introlist Let $\first \typecolon (\byte \rightarrow \maybe{T}) \rightarrow \maybe{T}$ @@ -4787,8 +4789,6 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. {\reprJ\big(\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}} \typecolon \SubgroupReprJ\big)$ is bijective, the distribution of $\reprJ\Of{\NullifierKey}$ will be computationally indistinguishable from uniform on $\SubgroupReprJ$ (the keyspace of $\PRFnf{Sapling}{}$). - \item The \zcashd wallet picks \diversifiers as in \cite{ZIP-32}, rather than using the default - \diversifier specified above. \end{nnotes} \vspace{-2ex} } %sapling @@ -4893,26 +4893,27 @@ The resulting \diversifiedPaymentAddress is $(\Diversifier \typecolon \DiversifierType, \DiversifiedTransmitPublic \typecolon \KAPublic{Orchard})$. \vspace{1ex} -For each \spendingKey, there is also a \defining{\defaultDiversifiedPaymentAddress} -with a ``random-looking'' \diversifier, which is derived as specified in \cite{ZIP-32}. +The \diversifiedPaymentAddress with \diversifierIndex $0$ is called the \defining{\defaultDiversifiedPaymentAddress}. \vspace{1ex} \begin{pnotes} \item The protocol does not prevent using the \diversifier $\Diversifier$ to produce - \quotedtermnoindex{vanity} addresses that start with a meaningful string when - encoded in \Bech (see \crossref{orchardpaymentaddrencoding}). + \quotedtermnoindex{vanity} addresses that start with or contain meaningful + strings when encoded in \Bechm (see \crossref{unifiedpaymentaddrencoding}). Users and writers of software that generates addresses should be aware that this provides weaker privacy properties than a randomly chosen \diversifier, since a vanity address can obviously be distinguished, and might leak more information than intended as to who created it. - \item Similarly, address generators \MAY encode information in the \diversifier - that can be recovered by the recipient of a payment to determine which - \diversifiedPaymentAddress was used. It is \RECOMMENDED that such \diversifiers - be randomly chosen unique values used to index into a database, rather than - directly encoding the needed data. + \item Address generators \MAY encode information in the \diversifierIndex + that can be recovered by the recipient of a payment, given the \diversifierKey. \end{pnotes} -\todo{Security analysis of the uses of $\ToScalar{Orchard}$ and $\ToBase{Orchard}$.} +\vspace{-2ex} +\nnote{ +The uses of $\ToScalar{Orchard}$ and $\ToBase{Orchard}$ produce output that is +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}. +} %nnote } %nufive @@ -5337,19 +5338,17 @@ with one or more \outputDescriptions. Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as specified in \crossref{abstractcommit}. -\vspace{-0.5ex} +\vspace{-0.25ex} Let $\KA{Sapling}$ be as specified in \crossref{abstractkeyagreement}. -\vspace{-0.5ex} +\vspace{-0.25ex} Let $\DiversifyHash{Sapling}$ be as specified in \crossref{abstracthashes}. -\vspace{-0.5ex} +\vspace{-0.25ex} Let $\ToScalar{Sapling}$ be as specified in \crossref{saplingkeycomponents}. Let $\reprJ$ and $\ParamJ{r}$ be as defined in \crossref{jubjub}. -Let $\ItoLEOSP{}$ be as defined in \crossref{endian}. - \vspace{1ex} \introlist Let $\OutViewingKey$ be a \Sapling \outgoingViewingKey that is intended to be able to decrypt @@ -5430,57 +5429,67 @@ The encoded \transaction is submitted to the peer-to-peer network. \nufive{ +\vspace{-1ex} \introlist \lsubsubsection{Sending Notes (\OrchardText)}{orchardsend} +\vspace{-1ex} In order to send \Orchard \shielded value, the sender constructs a \transaction with one or more \actionDescriptions. This section describes how to produce the output-related fields of an \actionDescription. -\vspace{1ex} +\vspace{0.5ex} Let $\ValueCommitAlg{Orchard}$ and $\NoteCommitAlg{Orchard}$ be as specified in \crossref{abstractcommit}. +\vspace{-0.25ex} Let $\PRFexpand{}$ be as specified in \crossref{abstractprfs}. +\vspace{-0.25ex} Let $\KA{Orchard}$ be as specified in \crossref{abstractkeyagreement}. +\vspace{-0.25ex} Let $\DiversifyHash{Orchard}$ be as specified in \crossref{abstracthashes}. +\vspace{-0.25ex} Let $\ToScalar{Orchard}$ and $\ToBase{Orchard}$ be as specified in \crossref{orchardkeycomponents}. +\vspace{-0.25ex} Let $\reprP$ and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. -Let $\ItoLEOSP{}$ be as defined in \crossref{endian}. +Let $\ExtractPbot$ be as defined in \crossref{concreteextractorpallas}. -\vspace{1ex} +\vspace{0.5ex} Let $\OutViewingKey$ be an \Orchard \outgoingViewingKey that is intended to be able to decrypt this payment. The considerations for choosing \outgoingViewingKeys are as described for \Sapling in \crossref{saplingsend}. Let $\NotePlaintextLeadByte$ be the \notePlaintextLeadByte, which \MUST be $\hexint{02}$. -\introlist +\vspace{0.5ex} For each \actionDescription, the sender selects a value $\Value \typecolon \range{0}{\MAXMONEY}$ -and a destination \Orchard \shieldedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, -and then performs the following steps: +and a destination \Orchard \shieldedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, and +performs the following steps: \begin{algorithm} + \vspace{-0.25ex} \item Check that $\DiversifiedTransmitPublic$ is of type $\KAPublic{Orchard}$, i.e.\ it \MUST be a valid \swCurve point on the \pallasCurve (as defined in \crossref{pallasandvesta}). \item Calculate $\DiversifiedTransmitBase = \DiversifyHash{Orchard}(\Diversifier)$. - \item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Orchard}()$. \vspace{-0.25ex} + \item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Orchard}()$. \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$. \item Derive $\EphemeralPrivate = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$. \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$. \item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$. \item Let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. - \item Let $\cv = \ValueCommit{Orchard}{\ValueCommitRand}(\Value)$. - \item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, - \reprP\Of{\DiversifiedTransmitPublic}, - \Value, \NoteUniqueRand, \NoteNullifierRand)$. - \vspace{0.25ex} - \item If $\cm = \bot$, return $\bot$. + \item Let $\cvNet{}$ be the \valueCommitment to the value of the input \note minus the value $\Value$ + of the output \note for this \actionTransfer, using $\ValueCommitRand$, as described in \crossref{orchardbalance}. + \vspace{-0.25ex} + \item Let $\cmX = \ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase}, + \reprP\Of{\DiversifiedTransmitPublic}, + \Value, \NoteUniqueRand, \NoteNullifierRand)\kern-0.1em\big)$. + \vspace{0.2ex} + \item If $\cmX = \bot$, return $\bot$. \item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteSeedBytes, \Memo)$. \vspace{0.25ex} \item Encrypt $\NotePlaintext{}$ to the recipient @@ -5488,11 +5497,12 @@ and then performs the following steps: \diversifiedBase $\DiversifiedTransmitBase$, and to the \outgoingViewingKey $\OutViewingKey$, giving the \noteCiphertextOrchard $(\EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext)$. - This procedure is described in \crossref{saplingandorchardencrypt}; it also uses - $\cvField$ and $\cmxField$ to derive $\OutCipherKey$, and takes + This procedure is described in \crossref{saplingandorchardencrypt}; it uses + $\cvNet{}$ and $\cmX$ to derive $\OutCipherKey$, and takes $\EphemeralPrivate$ as input. - \item Generate a proof $\Proof{}$ for the \actionStatement in \crossref{actionstatement}. - \item Return $(\cv, \cm, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \Proof{})$. + \item Fill in the spending side of the \actionTransfer (\crossref{spendauthsig}), + and generate a proof $\Proof{}$ for the \actionStatement in \crossref{actionstatement}. + \item Return $(\cv, \cmX, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \Proof{})$. \end{algorithm} \vspace{-1ex} @@ -5643,7 +5653,8 @@ constructed as follows: \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$. \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.11em\big)$. \item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9])\kern-0.09em\big)$. - \item Let $\NoteUniqueRand$ be equal to $\nfOld{}$ from the same \actionDescription. + \item Choose uniformly random $\NoteUniqueRandPoint \leftarrowR \GroupP$. + \item Let $\NoteUniqueRand = \ExtractP(\NoteUniqueRandPoint)$. \item Let $\cv = \ValueCommit{Orchard}{\ValueCommitRand}(\Value)$. \item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}\big(\reprP\Of{\DiversifiedTransmitBase}, \reprP\Of{\DiversifiedTransmitPublic}, @@ -6280,24 +6291,27 @@ both.} Knowledge of the \spendingKey could have been proven directly in the \spendStatement\nufive{ or \actionStatement}, similar to the check in \crossref{sproutspendauthority} that is part of the \joinSplitStatement. The motivation for a separate signature is to allow devices that are limited in -memory and computational capacity, such as hardware wallets, to authorize a \Sapling shielded Spend. -Typically such devices cannot create, and may not be able to verify, \zkSNARKProofs for -a \statement of the size needed using the \BCTV or \Groth proving systems. +memory and computational capacity, such as hardware wallets, to authorize a \SaplingOrOrchard +shielded Spend. Typically such devices cannot create, and may not be able to verify, \zkSNARKProofs +for a \statement of the size needed using the \BCTV\notnufive{ or \Groth}\notbeforenufive{, +\Groth\nufive{, or \HaloTwo}} proving systems. \vspace{1ex} -The \validatingKey of the signature must be revealed in the \spendDescription so that -the signature can be checked by validators. To ensure that the \validatingKey cannot -be linked to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we -use a \rerandomizableSignatureScheme. The \spendStatement proves that this \validatingKey -is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ with a \randomizer -known to the signer. The \defining{\spendAuthSignature} is over the \sighashTxHash, so that it cannot be -replayed in other \transactions. +The \validatingKey of the signature must be revealed in the \spendDescription so that the +signature can be checked by validators. To ensure that the \validatingKey cannot be linked +to the \shieldedPaymentAddress or \spendingKey from which the \note was spent, we use a +\rerandomizableSignatureScheme. The \spendStatement\nufive{ or \actionStatement} proves that +this \validatingKey is a re-randomization of the \defining{\spendAuthAddressKey} $\AuthSignPublic$ +with a \randomizer known to the signer. The \defining{\spendAuthSignature} is over the +\sighashTxHash, so that it cannot be replayed in other \transactions. \vspace{2ex} -Let $\SigHash$ be the \sighashTxHash as defined in \cite{ZIP-243}, not associated with an input, -using the \sighashType $\SIGHASHALL$. +Let $\SigHash$ be the \sighashTxHash as defined in \cite{ZIP-243}\nufive{ or as defined in +\cite{ZIP-244} modified by \cite{ZIP-225}}, not associated with an input, using the +\sighashType $\SIGHASHALL$. -Let $\AuthSignPrivate$ be the \defining{\spendAuthPrivateKey} as defined in \crossref{saplingkeycomponents}. +Let $\AuthSignPrivate$ be the \defining{\spendAuthPrivateKey} as defined in +\crossref{saplingkeycomponents}\nufive{ or in \crossref{orchardkeycomponents}}. \notbeforenufive{ Let $\SpendAuthSig{}$ be $\SpendAuthSig{Sapling}$\nufive{ or $\SpendAuthSig{Orchard}$ as applicable}. @@ -6305,7 +6319,8 @@ Let $\SpendAuthSig{}$ be $\SpendAuthSig{Sapling}$\nufive{ or $\SpendAuthSig{Orch \introsection \vspace{2ex} -For each \spendDescription, the signer chooses a fresh \defining{\spendAuthRandomizer} $\AuthSignRandomizer$: +For each \spendDescription\nufive{ or \actionDescription}, the signer chooses a fresh +\defining{\spendAuthRandomizer} $\AuthSignRandomizer$: \begin{enumerate} \item Choose $\AuthSignRandomizer \leftarrowR \SpendAuthSigGenRandom{\maybeSapling}()$. @@ -6384,10 +6399,16 @@ $\NoteUniqueRandRepr = \reprJ(\NoteUniqueRand)$. \nufive{ The derivation of \nullifiers for \Orchard \notes is a little more complicated. +Let $\GroupP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. + +Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}. + +Let $\GroupPHash$ be as defined in \crossref{concretegrouphashpallasandvesta}. + Define $\NullifierBaseOrchard := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{K}}\,$. To avoid repetition, we define a function $\DeriveNullifierAlg \typecolon -\NullifierKeyTypeOrchard \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \GroupP$ +\NullifierKeyTypeOrchard \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \GroupP \rightarrow \GF{\ParamP{q}}$ as follows: \begin{formulae} @@ -7015,9 +7036,10 @@ engineering rationale behind this encryption scheme. \extralabel{saplinginband}{\lsubsection{In-band secret distribution (\SaplingAndOrchardText)}{saplingandorchardinband}} \vspace{-1ex} -In \SaplingAndOrchard, the secrets that need to be transmitted to a recipient of funds -in order for them to later spend, are $\Diversifier$, $\Value$, and $\NoteCommitRand$. -A \memo (\crossref{noteptconcept}) is also transmitted. +In \SaplingAndOrchard, the secrets that need to be transmitted to a recipient +of a \note so that they can later spend it, are $\Diversifier$, $\Value$, and +$\NoteCommitRand$\canopy{ or $\NoteSeedBytes$}. A \memo (\crossref{noteptconcept}) +is also transmitted. To transmit these secrets securely to a recipient \emph{without} requiring an out-of-band communication channel, the \diversifiedTransmissionKey @@ -7025,8 +7047,7 @@ $\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's possession of the associated \incomingViewingKey $\InViewingKey$ is used to reconstruct the original \note and \memo. -Unlike in a \Sprout \joinSplitDescription, each \SaplingOrOrchard \shieldedOutput -is encrypted by a fresh \ephemeralPublicKey. +Unlike in \Sprout, each \SaplingOrOrchard \shieldedOutput is encrypted by a fresh \ephemeralPublicKey. \vspace{0.5ex} \introlist @@ -7088,12 +7109,12 @@ spent, or an \outgoingViewingKey associated with a \cite{ZIP-32} account, or $\b Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$ be the \SaplingOrOrchard \notePlaintext. - $\NotePlaintext{}$ is encoded as defined in \crossref{notept}. -Let $\cv$ be the \valueCommitment for the new \note, and let $\cm$ be the \noteCommitment. -(These are needed to derive the \defining{\outgoingCipherKey} $\OutCipherKey$ in order to produce the -\defining{\outgoingCiphertext} $\OutCiphertext$.) +Let $\cv$ be the \valueCommitment for the \outputDescription\nufive{ or \actionDescription (for \Orchard, +this also depends on the value of the \note being spent)}, and let $\cm$ be the \noteCommitment. +These are needed to derive the \defining{\outgoingCipherKey} $\OutCipherKey$ in order to produce the +\defining{\outgoingCiphertext} $\OutCiphertext$. \introlist \vspace{1ex} @@ -7159,6 +7180,7 @@ $u$-coordinate\nufive{ or $x$-coordinate} of the \noteCommitment, i.e.\ $\Extrac \vspace{-0.25ex} Let the constant $\CanopyActivationHeight$ be as defined in \crossref{constants}. +\vspace{-0.25ex} Let $\BlockHeight$ be the \blockHeight of the \block containing this \transaction. } %canopy @@ -7760,7 +7782,7 @@ $\BlakeTwobGeneric$ is used to instantiate $\hSigCRH$, $\EquihashGen{}$, and $\KDF{Sprout}$. \overwinter{From \Overwinter onward, it is used to compute \sighashTxHashes as specified in \cite{ZIP-143}\sapling{, or as in \cite{ZIP-243} after -\Sapling activation}.} +\Sapling activation}\nufive{, or as in \cite{ZIP-244} for version 5 \transactions}.} \sapling{For \Sapling, it is also used to instantiate $\PRFexpand{}$, $\PRFock{Sapling}{}$, $\KDF{Sapling}$, and in the $\RedJubjub$ \signatureScheme which instantiates $\SpendAuthSig{Sapling}$ and $\BindingSig{Sapling}$.} @@ -9680,7 +9702,9 @@ The windowed Pedersen commitments defined in the preceding section are highly efficient, but they do not support the homomorphic property we need when instantiating $\ValueCommitAlg{}$. -For more details on the use of this property, see \crossref{saplingbalance}\nufive{, \crossref{orchardbalance},} and \crossref{spendsandoutputs}. +For more details on the use of this property, see \crossref{saplingbalance}\nufive{ and \crossref{orchardbalance}}. + +Useful background is given in \crossref{spendsandoutputs}\nufive{ and \crossref{actions}}. \defining{In order to support this property, we also define \homomorphicPedersenCommitments for \Sapling:} @@ -10339,13 +10363,6 @@ $\ExtractJ$ is injective on $\SubgroupJ$. \lsubsubsubsection{Group Hash into \JubjubText}{concretegrouphashjubjub} \vspace{-1ex} -Let $\GroupJHashInput := \byteseq{8} \times \byteseqs$, and -let $\GroupJHashURSType := \byteseq{64}$. - -(The input element with type $\byteseq{8}$ is intended to act as a -``personalization'' parameter to distinguish uses of the \groupHash for -different purposes.) - Let $\URS$ be the MPC randomness beacon defined in \crossref{beacon}. \vspace{-0.25ex} @@ -10357,6 +10374,13 @@ Let $\LEOStoIP{}$ be as defined in \crossref{endian}. \vspace{-0.25ex} Let $\SubgroupJ$, $\SubgroupJstar$, and $\abstJ$ be as defined in \crossref{jubjub}. +Let $\GroupJHashInput := \byteseq{8} \times \byteseqs$, and +let $\GroupJHashURSType := \byteseq{64}$. + +(The input element with type $\byteseq{8}$ is intended to act as a +``personalization'' parameter to distinguish uses of the \groupHash for +different purposes.) + Let $D \typecolon \byteseq{8}$ be an $8$-byte domain separator, and let $M \typecolon \byteseqs$ be the hash input. @@ -11073,12 +11097,11 @@ instead of \BaseFiftyEightCheck. \nnote{ZIP 173 is similar to \Bitcoin's BIP 173, except for dropping the limit of 90 characters on an encoded \Bech string (which does not hold for \Sapling viewing keys, for example), and requirements specific to Bitcoin's Segwit addresses.} -} %sapling \nufive{ \vspace{1ex} -\Orchard introduces a new address format called a \unifiedPaymentAddress. This can -encode an \Orchard address, but also a \Sapling address, a \transparentAddress, +\Orchard introduces a new address format called a \defining{\unifiedPaymentAddress}. +This can encode an \Orchard address, but also a \Sapling address, a \transparentAddress, and potentially future address formats, all in the same \unifiedPaymentAddress. It is \RECOMMENDED to use \unifiedPaymentAddresses for all new applications, unless compatibility with software that only accepts previous address formats is required. @@ -11767,8 +11790,10 @@ A fifth upgrade, called \defining{\Canopy}, activated on \Mainnet on 18~November at \blockHeight $1046400$ (coinciding with the first \blockSubsidy \halving) \cite{Zcash-Canopy} \cite{ZIP-251}. +\nufive{ This draft specification describes a set of changes codenamed \NUFive, which are proposed to activate in a future \networkUpgrade. +} %nufive This section summarizes the strategy for upgrading from \Sprout to subsequent versions of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, and \Canopy), and for @@ -12256,11 +12281,6 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B a corresponding standard rule but no consensus rule. \end{itemize} -\preoverwinter{ -Software that creates \transactions \SHOULD use version 1 for \transactions with no -\joinSplitDescriptions. -} - \introsection \extralabel{joinsplitencoding}{\lsubsection{JoinSplit Description Encoding and Consensus}{joinsplitencodingandconsensus}} @@ -12333,8 +12353,15 @@ Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}. Let $\reprJ$ and $\ParamJ{q}$ be as defined in \crossref{jubjub}. \vspace{-0.5ex} +Let $\spendAuthSig$ be the \spendAuthSignature for this \spendTransfer, and let $\ProofSpend$ be the +\zkSNARKProof of the corresponding \spendStatement. In a version 4 \transaction these are encoded in +the $\spendAuthSigField$ field and $\zkproof$ field respectively of the \spendDescription.\nufive{ In +a version 5 \transaction, \spendAuthSignatures in $\vSpendAuthSigs{Sapling}$ and proofs in +$\vSpendProofsSapling$ are in one-to-one correspondence with \spendDescriptions in $\vSpendsSapling$.} + +\introsection An abstract \spendDescription, as described in \crossref{spendsandoutputs}, is encoded in -a \transaction as an instance of a \type{SpendDescription} type as follows: +a \transaction as an instance of a \type{SpendDescriptionV4}\nufive{ or \type{SpendDecriptionV5}} type: \vspace{-1.5ex} \begin{center} @@ -12354,7 +12381,7 @@ $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline $32$ & $\rkField$ & \type{byte[32]} & -The randomized \validatingKey for $\spendAuthSigField$, $\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline +The randomized \validatingKey for $\spendAuthSig$, $\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline $192\nufive{\;\dagger}$ & $\zkproof$ & \type{byte[192]} & An encoding of the \zkSNARKProof $\ProofSpend$ (see \crossref{groth}). \\ \hline @@ -12386,9 +12413,13 @@ Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}. \vspace{-0.5ex} Let $\reprJ$ and $\ParamJ{q}$ be as in \crossref{jubjub}, and $\ExtractJ$ as in \crossref{concreteextractorjubjub}. +Let $\ProofOutput$ be the \zkSNARKProof of the \outputStatement for this \outputStatement. In a version 4 +\transaction this is encoded in the $\zkproof$ field of the \spendDescription.\nufive{ In a v5 \transaction, +proofs in $\vOutputProofsSapling$ are in one-to-one correspondence with \outputDescriptions in $\vOutputsSapling$.} + \vspace{-0.5ex} An abstract \outputDescription, described in \crossref{spendsandoutputs}, is encoded in -a \transaction as an instance of an \type{OutputDescription} type as follows: +a \transaction as an instance of an \type{OutputDescriptionV4}\nufive{ or \type{OutputDecriptionV5}} type: \vspace{-2.5ex} \begin{center} @@ -12444,6 +12475,12 @@ Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}. Let $\reprP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. \vspace{-0.5ex} +Let $\spendAuthSig$ be the \spendAuthSignature for this \actionTransfer from $\vSpendAuthSigs{Orchard}$, +and let $\ProofAction$ be the \zkSNARKProof of the corresponding \actionStatement. \xSpendAuthSignatures +in the $\vSpendAuthSigs{Orchard}$ field of a version 5 \transaction and aggregated proofs in the +$\proofsOrchard$ field are in one-to-one correspondence with \actionDescriptions in $\vActionsOrchard$. + +\vspace{0.5ex} An abstract \actionDescription, as described in \crossref{actions}, is encoded in a \transaction as an instance of an \type{ActionDescription} type: @@ -12460,7 +12497,7 @@ minus the output \note, $\LEBStoOSP{256}\big(\reprP\Of{\cv}\kern-0.1em\big)$. \\ $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline -$32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSigField$, +$32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSig$, $\LEBStoOSP{256}\big(\reprP\Of{\AuthSignRandomizedPublic}\kern-0.1em\big)$. \\ \hline $32$ & $\cmxField$ & \type{byte[32]} & The $x$-coordinate of the \noteCommitment for the output \note, @@ -13974,7 +14011,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \lsection{Change History}{changehistory} -\historyentry{2021.1.20}{2021-03-23} +\historyentry{2021.1.20}{2021-03-25} \begin{itemize} \item Credit Eirik Ogilvie-Wigley as a designer of the Zcash protocol. Add Andre Serrano, Brad Miller, Charlie O'Keefe, David Campbell, Elena Giralt, Francisco Gindre, Joseph Van~Geffen, Josh Swihart, @@ -14030,6 +14067,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. \item Various rationale updates for \NUFive. + \item Other fixes to the \Orchard specification, including generation of \dummyNotes and output \notes. } %nufive \sapling{ \item Describe the recommended way to encode a \Sapling\nufive{ or unified} \paymentAddress