zips/protocol/protocol.tex

\documentclass{article}
\usepackage{ifxetex}
\usepackage{ifluatex}

% <https://tex.stackexchange.com/a/488473/78411>
\ifluatex
\directlua{
  luatexbase.add_to_callback("luaotfload.patch_font", function (fontdata)
    local parameters = fontdata.parameters
    if not parameters then return end
    if not (parameters.x_height or parameters[5] or 0) == 0 then return end
    if fontdata.characters and fontdata.characters[120] then
      parameters.x_height = fontdata.characters[120].height
    else
      parameters.x_height = (parameters.ascender or 0)*0.5
    end
  end, "Fix x-height")
}
\fi

% Load cmap before fontenc.
\usepackage{cmap}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{bytefield}
\usepackage{graphicx}
\usepackage{mathtools}
\usepackage{xspace}
\usepackage{url}
\usepackage{changepage}
\usepackage{enumitem}
\usepackage{tabularx}
\usepackage{hhline}
\usepackage[usestackEOL]{stackengine}
\usepackage{comment}
\usepackage{needspace}
\usepackage[nobottomtitles,explicit]{titlesec}
\usepackage[hang]{footmisc}
\usepackage{xstring}
\usepackage[dvipsnames]{xcolor}
\usepackage{etoolbox}
\usepackage{subdepth}
\usepackage{fix-cm}
\usepackage{hyphenat}
\usepackage{tocloft}
\usepackage{pict2e}
\usepackage{zref-savepos}
\usepackage{soul}
\usepackage[space]{accsupp}

% Must be loaded before hyperref. <https://tex.stackexchange.com/a/22014/78411>
% noautomatic is used because either latexmk or the Makefile will take care of running
% mymakeindex.sh (which runs makeindex and then fixes duplicate page numbers).
\usepackage[nonewpage]{imakeidx}
\makeindex[noautomatic,columnsep=2.5em]

% This is used by the output of mymakeindex.sh in some cases.
% <https://stackoverflow.com/a/49406814/393146>
\newcommand{\increment}[1]{\the\numexpr #1+1\relax}

% Shortcut for \nohyphens from hyphenat.
\newcommand{\nh}[1]{\nohyphens{#1}}

% \nh doesn't work in the bibliography.
% <https://latex.org/forum/viewtopic.php?p=14024&sid=384d9985bc8c99de907976f40ab838cf#p14024>
\makeatletter
\newcommand*\nbh{\hbox{-}\nobreak\hskip\z@skip}
\makeatother

% The destlabel option creates "destination names" in the PDF, which allows
% linking to sections in URL fragments when viewing the PDF in a web browser:
% <https://tex.stackexchange.com/a/65049/78411>
%
% The Makefile previously supported processing the PDF through Ghostscript in
% order to optimize its size. Since TeXLive 2019, this is no longer an effective
% optimization. However, in case processing through Ghostscript is needed for other
% reasons, we retain the pdfa option, which has the side effect of preserving
% hyperlinks through such processing. (An alternative way of doing that would be
% to use -dPrinted=false on the Ghostscript command line.) The resulting document
% will not actually be PDF/A.
%
% To preserve destination names through Ghostscript processing, extractpdfmark
% would need to be used as described at <https://github.com/trueroad/extractpdfmark>.
%
\usepackage[unicode,bookmarksnumbered,bookmarksopen,allbordercolors=MidnightBlue,
            citebordercolor=Plum,urlbordercolor=BrickRed,pdfa,destlabel]{hyperref}

\usepackage[amsmath,amsthm,thmmarks,hyperref]{ntheorem}

\usepackage[printocg=never,exportocg=never]{ocgx2}

\usepackage{cleveref}
\usepackage{nameref}

\usepackage{silence}
\WarningFilter{latex}{Reference}
\WarningFilter{latex}{Citation}
\WarningFilter{latex}{Hyper reference}
\WarningFilter{imakeidx}{Remember to run}
\WarningFilter{microtype}{Unknown slot number of character}

\usepackage{microtype}

% Target biblatex >= v3.5. <https://tex.stackexchange.com/a/231215/78411>
\WarningFilter{biblatex}{'edtf'}
\WarningFilter{biblatex}{'\mkdaterangeedtf'}

\usepackage[style=alphabetic,maxbibnames=99,dateabbrev=false,urldate=edtf,seconds=true,
            backref=true,backrefstyle=none,backend=biber]{biblatex}
\addbibresource{zcash.bib}

% Fonts
\usepackage{lmodern}
\usepackage{quattrocento}
\usepackage[bb=ams]{mathalfa}
\usepackage[scr]{rsfso}
\usepackage{upgreek}
\usepackage{fontawesome} % for \faSearch

% Specify how the content should be read out, assuming that the PDF reader supports
% BDC entries as documented in [Adobe2008, section 14.9.4]. For abbreviations that
% should be spelled out, use \readasunicode with U+200B ZERO WIDTH SPACE between characters.
%
% Note that we prioritize screen readers over copy-paste (getting the output right
% for the former does help to preserve the semantic content for the latter).
%
% [Adobe2008] https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf
\newcommand{\readas}[2]{\BeginAccSupp{method=pdfstringdef,ActualText=\text{#1}}{#2}\EndAccSupp{}}
\newcommand{\readasunicode}[2]{\BeginAccSupp{method=hex,unicode,ActualText={#1}}{#2}\EndAccSupp{}}

% Presentation that should not be read out.
\newcommand{\present}[1]{\BeginAccSupp{ActualText=}{#1}\EndAccSupp{}}

% Overlap the same content with a horizontal offset.
\newcommand{\overlap}[2]{\rlap{#2}\present{\hspace{#1}{#2}}}

% Fake bold.
\sodef\spaced{}{0.01em}{0.25em plus 0.1em}{0em}
\newcommand{\fakebold}[1]{\overlap{0.02em}{\overlap{0.01em}{\spaced{#1}}}}

% Quattrocento is beautiful but doesn't have an italic face. So we scale
% New Century Schoolbook italic to fit in with slanted Quattrocento and
% match its x height.
% (This has the side effect of making all italic text into boxes, so
% it won't linebreak, which has pluses and minuses.)
%
% XeTeX and LuaLaTeX require the \fontencoding{T1}:
% <https://tex.stackexchange.com/a/426300/78411>
%
% New Century Schoolbook italic bold is too wide, so we use a terrible hack
% to fake it while in \emph.
\let\oldtextbf\textbf
\newcommand{\schoolbook}[1]{\fontencoding{T1}\fontfamily{pnc}\selectfont\scalebox{1.02}[0.999]{#1}}
\renewcommand{\emph}[1]{\hspace{0.12em}{\schoolbook{\let\textbf\fakebold\textit{#1}\let\textbf\oldtextbf}}\hspace{0.12em}}

% While we're at it, let's match the tt x height to Quattrocento as well,
% and compress it a little to save space in tables.
\let\oldtexttt\texttt
\let\oldmathtt\mathtt
\renewcommand{\texttt}[1]{\scalebox{0.97}[1.07]{\oldtexttt{#1}}}
\renewcommand{\mathtt}[1]{\scalebox{0.97}[1.07]{$\oldmathtt{#1}$}}

% <https://tex.stackexchange.com/a/236822/78411>
\makeatletter
\def\@idxitem{\par\vspace{0.75ex plus 0.1ex minus 0.1ex}\hangindent 4em}
\def\subitem{\par\hangindent 6.5em \hspace*{2.5em}}
\def\subsubitem{\par\hangindent 9em \hspace*{5em}}
\makeatother

\crefformat{footnote}{#2\footnotemark[#1]#3}

\DeclareLabelalphaTemplate{
  \labelelement{\field{citekey}}
}

\DefineBibliographyStrings{english}{
  page  = {page},
  pages = {pages},
  backrefpage = {\mbox{$\uparrow$ p\!}},
  backrefpages = {\mbox{$\uparrow$ p\!}}
}

\setlength{\oddsidemargin}{-0.25in}
\setlength{\textwidth}{7in}
\setlength{\topmargin}{-0.75in}
\setlength{\textheight}{9.2in}
\setlength{\parindent}{0ex}

\newcommand{\defaultarraystretch}{1.4}
\renewcommand{\arraystretch}{\defaultarraystretch}

% <https://tex.stackexchange.com/a/49898/78411>
\makeatletter
\renewcommand{\@pnumwidth}{2em}
\makeatother

\newcommand{\pagenumfont}{\fontencoding{T1}\fontfamily{pnc}\selectfont\rule[-.2\baselineskip]{0pt}{1.32\baselineskip}}
\renewcommand{\cftsecpagefont}{\pagenumfont}
\renewcommand{\cftsubsecpagefont}{\pagenumfont}
\renewcommand{\cftsubsubsecpagefont}{\pagenumfont}
\renewcommand{\cftparapagefont}{\pagenumfont}

\hfuzz=3.5pt
\vfuzz=2pt
\overfullrule=2cm

\renewcommand{\footnotelayout}{\leftskip=1.4em}
\setlength{\footnotemargin}{0.55em}
\setlength{\footnotesep}{2ex}
\addtolength{\skip\footins}{3ex}

\renewcommand{\bottomtitlespace}{8ex}

% Use rubber lengths between paragraphs to improve default pagination.
% <https://tex.stackexchange.com/questions/17178/vertical-spacing-pagination-and-ideal-results>
\setlength{\parskip}{1.5ex plus 2pt minus 2pt}
%\setlength{\parskip}{6.3pt plus 2pt minus 2pt}

\widowpenalties 3 10000 1000 0

\setlength{\bibitemsep}{1.2ex}  % default is too cramped!
\setlength{\biblabelsep}{0.5em} % default is not cramped enough! :-)

\setlist[enumerate]{itemsep=0.3ex,before=\vspace{-1.2ex}}
\setlist[itemize]{itemsep=0.3ex,topsep=0.2ex,before=\vspace{-0.8ex},after=\vspace{1.5ex}}

\newlist{compactitemize}{itemize}{3}
\setlist[compactitemize]{itemsep=-1ex,topsep=0ex,before=\vspace{-0.2ex},leftmargin=1.2em,label=$\cdot$,after=\vspace{-3.3ex}}

\newlist{formulae}{itemize}{3}
\setlist[formulae]{itemsep=0.2ex,topsep=0ex,leftmargin=1.5em,label=,after=\vspace{1.5ex}}

\newlist{algorithm}{itemize}{3}
\setlist[algorithm]{itemsep=0ex,topsep=0ex,leftmargin=1.5em,label=,after=\vspace{1.5ex}}

\newlist{lines}{itemize}{3}
\setlist[lines]{itemsep=-0.5ex,topsep=0ex,before=\vspace{1ex},leftmargin=1.6em,label=,after=\vspace{1ex}}

\newlist{poetry}{itemize}{3}
\setlist[poetry]{itemsep=-0.5ex,topsep=0ex,leftmargin=0em,label=}

% <https://tex.stackexchange.com/a/15255/78411>
\xspaceaddexceptions{]\}}

% <https://tex.stackexchange.com/a/12712/78411> (with X in place of m)
\newcolumntype{L}[1]{>{\raggedright\let\newline\\\arraybackslash\hspace{0pt}}X{#1}}

% <https://tex.stackexchange.com/a/112585/78411>
\newcolumntype{R}{>{$}r<{,\,\;$}}
\newcolumntype{S}{>{$}r<{\;$}}
\newcolumntype{T}{>{$}l<{\;$}}
\newcolumntype{U}{>{$}l<{$}}
\newcolumntype{C}{>{$}c<{$}}

\makeatletter
\renewcommand*{\@fnsymbol}[1]{\ensuremath{\ifcase#1\or \dagger\or \ddagger\or \mathsection\or \mathparagraph\else\@ctrerr\fi}}
\makeatother
\newcommand{\footnotestar}{\raisebox{0.25ex}{\kern0.04em *}}

\newcommand{\cedilla}[1]{#1\!\!¸\kern0.088em}

% biblatex really doesn't want to support Unicode citation labels, but I will not be beaten.
% <https://tex.stackexchange.com/a/285834/78411>
\NewDocumentCommand{\citesub}{m}{%
  \saveexpandmode\noexpandarg
  \def\tempstring{#1}%
  \xStrSubstitute{\tempstring}{MAEA2010}{MÁEÁ2010}[\tempstring]%
  \xStrSubstitute{\tempstring}{Hisil2010}{Hı\cedilla{s}ıl2010}[\tempstring]%
  \xStrSubstitute{\tempstring}{Damgard1989}{Damgård1989}[\tempstring]%
  \tempstring
  \restoreexpandmode
}
\newcommand*{\xStrSubstitute}{%
  \expandafter\StrSubstitute\expandafter
}

% Fix the height of citation link underlines.
\newcommand{\linkstrut}{\rule[-0.4ex]{0ex}{\fontcharht\font`X}}
\DeclareFieldFormat{labelalpha}{\linkstrut\smash{\citesub{#1}}}
\DeclareFieldFormat{postnote}{\linkstrut\smash{#1}}
\let\oldcite\cite
\renewcommand{\cite}[2][]{\raisebox{0ex}{\oldcite[{#1}]{#2}}}

\let\oldfootnote\footnote
\renewcommand{\footnote}[1]{\hairspace\oldfootnote{#1}}
\newcommand{\footnotewithlabel}[2]{\hairspace\oldfootnote{\label{#1}{#2}}}

\newcommand{\noborders}[1]{% no nations
  \hypersetup{pdfborderstyle=/W 0}{#1}\hypersetup{pdfborderstyle=/S/U/W 0.7}}

\newcommand{\headingandlabel}[2]{\texorpdfstring{\noborders{\switchocg{labels}{#1}}}{}\hfill%
  \begin{ocg}{Labels}{labels}{false}\fcolorbox{black}{\labelcolor}{%
  \normalfont\normalsize\noborders{\href{\baseurl#2}{\color{black}\raisebox{0.2ex}{\linkstrut}\smash{#2}}}}\end{ocg}}

\newcommand{\refprefix}{\readas{section}{\linkstrut\S\!\!}}
\newcommand{\page}{\readas{page}{p.}\,}
\newcommand{\crossref}[1]{\raisebox{0ex}{\refprefix\autoref{#1}}\hspace{0.2em}\emph{`\nameref*{#1}\kern -0.05em'} on \page\pageref*{#1}}
\newcommand{\shortcrossref}[1]{\raisebox{0ex}{\refprefix\autoref{#1}} on \page\pageref*{#1}}
\newcommand{\theoremref}[1]{\raisebox{0ex}{\hyperref[#1]{Theorem \ref*{#1}\vphantom{,}}} on \page\pageref*{#1}}
\newcommand{\lemmaref}[1]{\raisebox{0ex}{\hyperref[#1]{Lemma \ref*{#1}\vphantom{,}}} on \page\pageref*{#1}}
\newcommand{\footnoteref}[1]{\hairspace\raisebox{0ex}{\cref{#1}}}
\newcommand{\snarkref}[2]{\raisebox{0ex}{\hyperref[#2]{\linkstrut\smash{\textbf{#1}}}}}
\newcommand{\historyref}[1]{\raisebox{0ex}{\hyperref[#1]{\linkstrut\smash{v#1}}}}
\newcommand{\zcashdref}[1]{\href{https://github.com/zcash/zcash/releases/tag/#1}{\textsf{zcashd #1}}}
\newcommand{\zebraref}[1]{\href{https://github.com/ZcashFoundation/zebra/releases/tag/#1}{\textsf{zebra #1}}}

\newcommand{\callout}[2]{\vspace{1ex plus 2pt minus 2pt}#1\textbf{#2}\hspace{1em}}
\newcommand{\historyentry}[2]{\introlist\extralabel{#1}{\headingandlabel{\callout{}{#1}{#2}}{\##1}}}

\renewcommand{\appendixautorefname}{ }
\renewcommand{\sectionautorefname}{ }
\renewcommand{\subsectionautorefname}{ }
\renewcommand{\subsubsectionautorefname}{ }
\renewcommand{\paragraphautorefname}{ }
\renewcommand{\subparagraphautorefname}{ }

%\let\oldhref\href
%\renewcommand{\href}[2]{\raisebox{0ex}{\oldhref{#1}{\linkstrut\smash{#2}}}}
%\let\oldurl\url
%\renewcommand{\url}[1]{\href{#1}{\nolinkurl{#1}}}

% <https://tex.stackexchange.com/a/60212/78411>
\newcommand{\subsubsubsection}[1]{\paragraph{#1}}
\newcommand{\subsubsubsubsection}[1]{\subparagraph{#1}}
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}

\newcommand{\slightlylarge}{\fontsize{10.5}{10.5}\selectfont}
\newcommand{\notsolarge}{\fontsize{11}{11}\selectfont}
\newcommand{\largeish}{\fontsize{12}{12}\selectfont}
\newcommand{\larger}{\fontsize{13}{13}\selectfont}
\newcommand{\Larger}{\fontsize{16}{16}\selectfont}

\titleformat{\section}{\Large\bfseries}{\thesection}{1em}{\headingandlabel{#1}{\#\sectionlabel}}
\titleformat{\subsection}{\larger\bfseries}{\thesubsection}{1em}{\headingandlabel{#1}{\#\sectionlabel}}
\titleformat{\subsubsection}{\largeish\bfseries}{\thesubsubsection}{1em}{\headingandlabel{#1}{\#\sectionlabel}}
\titleformat{\paragraph}{\notsolarge\bfseries}{\theparagraph}{1em}{\headingandlabel{#1}{\#\sectionlabel}}
\titleformat{\subparagraph}{\slightlylarge\bfseries}{\thesubparagraph}{1em}{\headingandlabel{#1}{\#\sectionlabel}}

\newcommand{\extralabel}[2]{\zsaveposy{before-#1}#2\zsaveposy{after-#1}\vspace{\dimexpr\zposy{after-#1}sp-\zposy{before-#1}sp}\phantomsection\label{#1}\vspace{\dimexpr\zposy{before-#1}sp-\zposy{after-#1}sp}}

\newcommand{\addparttocontents}[1]{\phantomsection\addcontentsline{toc}{section}{\larger{#1}}}

\newcommand{\phantompart}[2]{\def\sectionlabel{#2} \addparttocontents{#1}\label{#2}}
\newcommand{\lpart}[2]{\def\sectionlabel{#2} \intropart\vspace{20ex}\addparttocontents{#1}\section*{\nh{#1}}\label{#2}}
\newcommand{\lsection}[2]{\def\sectionlabel{#2} \section{#1}\label{#2}}
\newcommand{\lsubsection}[2]{\def\sectionlabel{#2} \subsection{#1}\label{#2}}
\newcommand{\lsubsubsection}[2]{\def\sectionlabel{#2} \subsubsection{#1}\label{#2}}
\newcommand{\lsubsubsubsection}[2]{\def\sectionlabel{#2} \subsubsubsection{#1}\label{#2}}
\newcommand{\lsubsubsubsubsection}[2]{\def\sectionlabel{#2} \subsubsubsubsection{#1}\label{#2}}

\newcommand{\introlist}{\needspace{15ex}}
\newcommand{\introsection}{\needspace{35ex}}
\newcommand{\intropart}{\needspace{55ex}}

\newcommand{\theoremlabel}[1]{\def\sectionlabel{#1}}

\theorempreskip{5ex}

% <https://tex.stackexchange.com/a/30265/78411>
% <https://stackoverflow.com/a/36706487/393146> for the \phantomsection hack (to link to exactly the right place).
\newtheoremstyle{labelledtheorem}%
  {\item[] \headingandlabel{\normalfont\bfseries ##1\ ##2.\hspace{1em}}{\#\sectionlabel}\phantomsection\label{\sectionlabel}\normalfont\itshape}%
  {\item[] \headingandlabel{\normalfont\bfseries ##1\ ##2.\hspace{1em}\normalfont\itshape ##3.}{\#\sectionlabel}\phantomsection\label{\sectionlabel}\normalfont\itshape}
\theoremstyle{labelledtheorem} % switch to newly defined theorem style

% \cftdotfill{\cftdotsep} matches the dot spacing from the Contents (found in the documentation of tocloft).
\newcommand{\theoremlistentry}[5]{\vspace{0.5ex}\makebox[\textwidth][l]{\hyperlink{#5}{\vphantom{p}\makebox[4.5em][l]{#1}\makebox[3em][l]{#2}#3}\cftdotfill{\cftdotsep} #4}\\}

% We intentionally pass only 4 parameters to \theoremlistentry. The extra one (the target link)
% is effectively "curried". This works around a bug in ntheorem when its \newtheoremlisttype macro
% is used with hyperref.
\newtheoremlisttype{labelledtheorem}%
{\begin{tabular*}{\textwidth}{@{}l}}%
{\theoremlistentry{##1}{##2}{##3}{##4}}%
{\end{tabular*}}
\theoremlisttype{labelledtheorem}

% Theorems and lemmata are numbered together and consecutively within a subsection.
\newtheorem{theorem}{Theorem}[subsection]
\newtheorem{lemma}[theorem]{Lemma}


\newcommand{\search}{\faSearch}

\mathchardef\mhyphen="2D
\mathchardef\mcolon="3A

\newcommand{\lrarrow}{\texorpdfstring{$\leftrightarrow$}{↔}}

% Using the astral plane character 𝕊 works, but triggers bugs in PDF readers 😛
\newcommand{\rS}{\texorpdfstring{$\ParamS{r}$}{rS}}

% <https://tex.stackexchange.com/a/309445/78411>
\DeclareFontFamily{U}{FdSymbolA}{}
\DeclareFontShape{U}{FdSymbolA}{m}{n}{
    <-> s*[.4] FdSymbolA-Regular
}{}
\DeclareSymbolFont{fdsymbol}{U}{FdSymbolA}{m}{n}
\DeclareMathSymbol{\smallcirc}{\mathord}{fdsymbol}{"60}

\makeatletter
\newcommand{\hollowcolon}{\mathpalette\hollow@colon\relax}
\newcommand{\hollow@colon}[2]{
  \mspace{0.7mu}
  \vbox{\hbox{$\m@th#1\smallcirc$}\nointerlineskip\kern.45ex \hbox{$\m@th#1\smallcirc$}\kern-.06ex}
  \mspace{1mu}
}
\makeatother
\newcommand{\typecolon}{\;\hollowcolon\;}

% <https://tex.stackexchange.com/a/235120/78411>
\makeatletter
\newcommand*\bigcdot{\mathpalette\bigcdot@{.5}}
\newcommand*\bigcdot@[2]{\mathbin{\vcenter{\hbox{\scalebox{#2}{$\m@th#1\bullet$}}}}}
\makeatother

% <https://tex.stackexchange.com/a/269020/78411>, with explicit size parameter
\makeatletter
\newcommand*{\bigboxplus}[1]{\mathop{\mathpalette\big@boxplus{#1}\relax}\slimits@}
\newcommand*{\bigboxminus}[1]{\mathop{\mathpalette\big@boxminus{#1}\relax}\slimits@}
\newcommand*{\bigdiamondplus}[1]{\mathop{\mathpalette\big@diamondplus{#1}\relax}\slimits@}
\newcommand*{\bigdiamondminus}[1]{\mathop{\mathpalette\big@diamondminus{#1}\relax}\slimits@}
\newcommand*{\bigvartimes}[1]{\mathop{\mathpalette\big@vartimes{#1}\relax}\slimits@}

\newcommand{\big@boxplus}[2]{%
  \vcenter{\m@th\bigbox@thickness{#1}\hbox{%
    \setlength{\unitlength}{#2}%
    \begin{picture}(1,1)
    \polyline(0.1,0.1)(0.9,0.1)(0.9,0.9)(0.1,0.9)(0.1,0.1)(0.5,0.1)
    \polyline(0.5,0.1)(0.5,0.9)
    \polyline(0.1,0.5)(0.9,0.5)
    \end{picture}}}}

\newcommand{\big@boxminus}[2]{%
  \vcenter{\m@th\bigbox@thickness{#1}\hbox{%
    \setlength{\unitlength}{#2}%
    \begin{picture}(1,1)
    \polyline(0.1,0.1)(0.9,0.1)(0.9,0.9)(0.1,0.9)(0.1,0.1)(0.5,0.1)
    \polyline(0.1,0.5)(0.9,0.5)
    \end{picture}}}}

\newcommand{\big@diamondplus}[2]{%
  \vcenter{\m@th\bigbox@thickness{#1}\hbox{%
    \setlength{\unitlength}{#2}%
    \begin{picture}(1,1)
    \polyline(0,0.5)(0.5,0)(1,0.5)(0.5,1)(0,0.5)(0.5,0)
    \polyline(0.5,0)(0.5,1)
    \polyline(0,0.5)(1,0.5)
    \end{picture}}}}

\newcommand{\big@diamondminus}[2]{%
  \vcenter{\m@th\bigbox@thickness{#1}\hbox{%
    \setlength{\unitlength}{#2}%
    \begin{picture}(1,1)
    \polyline(0,0.5)(0.5,0)(1,0.5)(0.5,1)(0,0.5)(0.5,0)
    \polyline(0,0.5)(1,0.5)
    \end{picture}}}}

\newcommand{\big@vartimes}[2]{%
  \vcenter{\m@th\bigbox@thickness{#1}\hbox{%
    \setlength{\unitlength}{#2}%
    \begin{picture}(1,1)
    \polyline(0.2,0.08)(0.8,1)
    \polyline(0.2,1)(0.8,0.08)
    \end{picture}}}}

\newcommand{\bigbox@thickness}[1]{%
  \ifx#1\displaystyle
    \linethickness{0.2ex}%
  \else
    \ifx#1\textstyle
      \linethickness{0.16ex}%
    \else
      \ifx#1\scriptstyle
        \linethickness{0.12ex}%
      \else
        \linethickness{0.1ex}%
      \fi
    \fi
  \fi
}
\makeatother

% We just want one ampersand symbol from boisik.
\DeclareSymbolFont{bskadd}{U}{bskma}{m}{n}
\DeclareFontFamily{U}{bskma}{\skewchar\font130 }
\DeclareFontShape{U}{bskma}{m}{n}{<->bskma10}{}
\DeclareMathSymbol{\binampersand}{\mathbin}{bskadd}{"EE}

% We just want one fivedots symbol from MnSymbol.
\DeclareSymbolFont{MnSyC}{U}{MnSymbolC}{m}{n}
\DeclareFontFamily{U}{MnSymbolC}{}
\DeclareFontShape{U}{MnSymbolC}{m}{n}{<->MnSymbolC10}{}
\DeclareMathSymbol{\fivedots}{\mathbin}{MnSyC}{15}

% $v$ is too close to $u$.
% <https://tex.stackexchange.com/questions/130569/sharp-or-angled-v-in-math-mode-varv>
\DeclareSymbolFont{matha}{OML}{txmi}{m}{it}
\DeclareMathSymbol{\varv}{\mathord}{matha}{118}

% These are defined by newtxmath, but that's a very opinionated package that causes a
% bunch of regressions (IMO) to math fonts and rendering.
\DeclareSymbolFont{AMSm}{U}{ntxsym}{m}{n}
\SetSymbolFont{AMSm}{bold}{U}{ntxsym}{b}{n}
\DeclareFontSubstitution{U}{ntxsym}{m}{n}

\DeclareMathSymbol{\Game}{\mathord}{AMSm}{97}
\DeclareMathSymbol{\ggg}{\mathrel}{AMSm}{239}
\DeclareMathSymbol{\circledast}{\mathbin}{AMSm}{254}

% end of characters from newtxmath

\newcommand{\hairspace}{~\!}
\newcommand{\oparen}{\big(}
\newcommand{\hparen}{\phantom{\oparen}}
\newcommand{\cparen}{\big)}
\newcommand{\mhspace}[1]{\mbox{\hspace{#1}}}
\newcommand{\tab}{\hspace{1.8em}}
\newcommand{\blank}{\vspace{-3ex}}

\newcommand{\raisedstrut}{\raisebox{0.3ex}{\strut}}

% <https://tex.stackexchange.com/a/415155/78411>
\newcommand{\clasp}[3][0pt]{\stackengine{0pt}{#3}{\kern#1#2}{O}{c}{F}{F}{L}}

\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}}

\newcommand{\hfrac}[2]{\scalebox{0.8}{$\genfrac{}{}{0.5pt}{0}{#1}{#2}$}}

% <https://en.wikibooks.org/wiki/LaTeX/Mathematics#Roots>
\def\hksqrt{\mathpalette\DHLhksqrt}
\def\DHLhksqrt#1#2{%
\setbox0=\hbox{$#1\sqrt{#2\,}$}\dimen0=\ht0
\advance\dimen0-0.2\ht0
\setbox2=\hbox{\vrule height\ht0 depth -\dimen0}%
{\box0\lower0.4pt\box2}}

\newcommand{\possqrt}[1]{\,{}^+\hspace{-0.7em}\hksqrt{#1\vphantom{b}}}
\newcommand{\optsqrt}[1]{\,{}^?\hspace{-0.7em}\hksqrt{#1\vphantom{b}}}

\newcommand{\sbitbox}[2]{\bitbox{#1}{\strut #2}}


\newcommand{\docversion}{Version unavailable (check protocol.ver)}
\newcommand{\SaplingSpec}{Overwinter+Sapling}
\newcommand{\BlossomSpec}{Overwinter+Sapling+Blossom}
\newcommand{\HeartwoodSpec}{Overwinter+Sapling+Blossom+Heartwood}
\newcommand{\CanopySpec}{Overwinter+Sapling+Blossom+Heartwood+Canopy}
\newcommand{\NUFiveSpec}{NU5}
\newtoggle{issapling}
\togglefalse{issapling}
\newtoggle{isblossom}
\togglefalse{isblossom}
\newtoggle{isheartwood}
\togglefalse{isheartwood}
\newtoggle{iscanopy}
\togglefalse{iscanopy}
\newtoggle{isnufive}
\togglefalse{isnufive}
\InputIfFileExists{protocol.ver}{}{}

\newcommand{\doctitle}{Zcash Protocol Specification}
\newcommand{\leadauthor}{Daira-Emma Hopwood}
\newcommand{\coauthora}{Sean Bowe}
\newcommand{\coauthorb}{Taylor Hornby}
\newcommand{\coauthorc}{Nathan Wilcox}

\newcommand{\keywords}{anonymity, applications, cryptographic protocols,\
electronic commerce and payment, financial privacy, proof of work, zero knowledge}


% <https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips>

\newcommand{\todo}[1]{{\color{Sepia}\sf{TODO: #1}}}
\definecolor{green}{RGB}{0,100,10}

\newcommand{\vulncolor}{BrickRed}
\newcommand{\setwarning}{\color{\warningcolor}}
\newcommand{\warningcolor}{BrickRed}
\newcommand{\saplingcolor}{green}
\newcommand{\saplingcolorname}{\saplingcolor}
\newcommand{\overwintercolor}{blue}
\newcommand{\overwintercolorname}{\overwintercolor}
\newcommand{\blossomcolor}{red}
\newcommand{\blossomcolorname}{\blossomcolor}
\newcommand{\heartwoodcolor}{red!30!orange}
\newcommand{\heartwoodcolorname}{orange}
\newcommand{\canopycolor}{red!50!blue!85}
\newcommand{\canopycolorname}{purple}
\newcommand{\nufivecolor}{black!25!blue!65!green!65}
\newcommand{\nufivecolorname}{slate blue}
\newcommand{\labelcolor}{yellow!20}

\iftoggle{isnufive}{
  \providecommand{\baseurl}{https://zips.z.cash/protocol/protocol.pdf}
  \toggletrue{iscanopy}
  \newcommand{\setnufive}{\color{\nufivecolor}}
  \newcommand{\nufive}[1]{\texorpdfstring{{\setnufive{#1}}}{#1}}
  \newcommand{\notnufive}[1]{}
  \newcommand{\notbeforenufive}[1]{#1}
} {
  \newcommand{\setnufive}{}
  \newcommand{\nufive}[1]{}
  \newcommand{\notnufive}[1]{#1}
  \newcommand{\notbeforenufive}[1]{}
}

\iftoggle{iscanopy}{
  \providecommand{\baseurl}{https://zips.z.cash/protocol/canopy.pdf}
  \toggletrue{isheartwood}
  \newcommand{\setcanopy}{\color{\canopycolor}}
  \newcommand{\canopy}[1]{\texorpdfstring{{\setcanopy{#1}}}{#1}}
  \newcommand{\notcanopy}[1]{}
  \newcommand{\notbeforecanopy}[1]{#1}
} {
  \newcommand{\setcanopy}{}
  \newcommand{\canopy}[1]{}
  \newcommand{\notcanopy}[1]{#1}
  \newcommand{\notbeforecanopy}[1]{}
}

\iftoggle{isheartwood}{
  \providecommand{\baseurl}{https://zips.z.cash/protocol/heartwood.pdf}
  \toggletrue{isblossom}
  \newcommand{\setheartwood}{\color{\heartwoodcolor}}
  \newcommand{\heartwood}[1]{\texorpdfstring{{\setheartwood{#1}}}{#1}}
  \newcommand{\notheartwood}[1]{}
  \newcommand{\notbeforeheartwood}[1]{#1}
} {
  \newcommand{\setheartwood}{}
  \newcommand{\heartwood}[1]{}
  \newcommand{\notheartwood}[1]{#1}
  \newcommand{\notbeforeheartwood}[1]{}
}

\iftoggle{isblossom}{
  \providecommand{\baseurl}{https://zips.z.cash/protocol/blossom.pdf}
  \toggletrue{issapling}
  \newcommand{\setblossom}{\color{\blossomcolor}}
  \newcommand{\blossom}[1]{\texorpdfstring{{\setblossom{#1}}}{#1}}
  \newcommand{\notblossom}[1]{}
  \newcommand{\notbeforeblossom}[1]{#1}
} {
  \newcommand{\setblossom}{}
  \newcommand{\blossom}[1]{}
  \newcommand{\notblossom}[1]{#1}
  \newcommand{\notbeforeblossom}[1]{}
}

\iftoggle{issapling}{
  \providecommand{\baseurl}{https://zips.z.cash/protocol/sapling.pdf}
  \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{\setsapling}{}
  \newcommand{\sapling}[1]{}
  \newcommand{\setoverwinter}{}
  \newcommand{\overwinter}[1]{}
}


\hypersetup{
  pdfborderstyle={/S/U/W 0.7},
  pdfinfo={
    Title={\doctitle, \docversion},
    Author={\leadauthor, \coauthora, \coauthorb, \coauthorc},
    Keywords={\keywords}
  },
  baseurl={\baseurl}
}


% Terminology

\newcommand{\indextype}{normalstyle}
\newcommand{\normalstyle}[1]{#1}
\newcommand{\definingstyle}[1]{\textit{\textbf{#1}}\kern 0.05em}
\newcommand{\defining}[1]{{\renewcommand{\indextype}{definingstyle}#1}}

% The arguments are: {link_as_formatted}{index_sort_key}{index_as_formatted}.
%
% \index goes after the term so that the page reference is correct if at the start of a page (see
% <https://tex.stackexchange.com/questions/476644/how-can-i-define-an-new-index-command-that-works-better-for-paragraphs>,
% although our solution is different).
% The method of linking to the index is inspired by <https://tex.stackexchange.com/a/399776/78411>.
% \texorpdfstring doesn't actually work here other than to cause an error if we would end up with a
% link in a heading, rather than a hang.
\newcommand{\indexlink}[3]{\texorpdfstring{\hypersetup{pdfborderstyle=/W 0}\hyperlink{index:#2}{#1}%
\hypersetup{pdfborderstyle={/S/U/W 0.7}}\index{#2@{\protect\hypertarget{index:#2}{}\linkstrut\smash{#3}}|\indextype}}{}\xspace}

\newcommand{\codesearchurl}[1]{https://github.com/zcash/zcash/search?q=#1}
\newcommand{\consensuslink}[1]{\fcolorbox{black}{\labelcolor}{%
  \normalfont\normalsize\noborders{\href{\codesearchurl{#1}}{\color{black}\raisebox{0.2ex}{\linkstrut}\smash{{\small \search}\, #1}}}}\,}

\newcommand{\rawterm}[1]{\textsl{\nh{#1}}\kern 0.05em}
\newcommand{\termnoindex}[1]{\rawterm{#1}\xspace}
\newcommand{\termandindex}[2]{\indexlink{\rawterm{#1}}{#2}{#2}}
\newcommand{\termandindexx}[2]{\indexlink{#1}{#2}{#1}}
\newcommand{\term}[1]{\termandindex{#1}{#1}}
\newcommand{\terms}[1]{\termandindex{#1s}{#1}}
\newcommand{\termes}[1]{\termandindex{#1es}{#1}}
\newcommand{\termx}[1]{\termandindex{\MakeUppercase #1}{#1}}
\newcommand{\termxs}[1]{\termandindex{\MakeUppercase #1s}{#1}}
\newcommand{\termxes}[1]{\termandindex{\MakeUppercase #1es}{#1}}
\newcommand{\termbfnoindex}[1]{\textbf{#1}\xspace}
\newcommand{\termbf}[1]{\termandindexx{\textbf{#1}}{#1}}
\newcommand{\termsf}[1]{\termandindexx{$\mathsf{#1}$}{#1}}
\newcommand{\conformance}[1]{\termandindexx{\textbf{#1}}{#1}}
\newcommand{\quotedtermnoindex}[1]{``~\!\!\termnoindex{#1}''}
\newcommand{\quotedtermandindex}[2]{``~\!\!\termandindex{#1}{#2}''}
\newcommand{\quotedterm}[1]{``~\!\!\term{#1}''}
\newcommand{\definingquotedterm}[1]{\defining{\quotedterm{#1}}}

\newcommand{\Zcash}{\termbf{Zcash}}
\newcommand{\Zerocash}{\termbf{Zerocash}}
\newcommand{\ZerocashText}{\textbf{Zerocash}}
\newcommand{\Sprout}{\termbf{Sprout}}
\newcommand{\SproutText}{\textbf{Sprout}}
\newcommand{\Overwinter}{\termbf{Overwinter}}
\newcommand{\OverwinterText}{\textbf{Overwinter}}
\newcommand{\Sapling}{\termbf{Sapling}}
\newcommand{\SaplingText}{\textbf{Sapling}}
\newcommand{\Blossom}{\termbf{Blossom}}
\newcommand{\BlossomText}{\textbf{Blossom}}
\newcommand{\Heartwood}{\termbf{Heartwood}}
\newcommand{\HeartwoodText}{\textbf{Heartwood}}
\newcommand{\Canopy}{\termbf{Canopy}}
\newcommand{\CanopyText}{\textbf{Canopy}}
\newcommand{\NUFive}{\readasunicode{004e200b0055200b0035}{\termbf{NU5}}\xspace}
%\newcommand{\NUFiveText}{\textbf{NU5}}
\newcommand{\Orchard}{\termbf{Orchard}}
\newcommand{\OrchardText}{\textbf{Orchard}}
\newcommand{\SaplingOrOrchard}{\Sapling{}\nufive{ or \Orchard{}}\xspace}
\newcommand{\SaplingAndOrchard}{\Sapling{}\nufive{ and \Orchard{}}\xspace}
\newcommand{\SaplingAndOrchardText}{\SaplingText\notbeforenufive{ and \OrchardText}}
\newcommand{\Bitcoin}{\termbf{Bitcoin}}
\newcommand{\BitcoinText}{\textbf{Bitcoin}}
\newcommand{\CryptoNote}{\termbf{CryptoNote}}
\newcommand{\Mimblewimble}{\termbf{Mimblewimble}}
\newcommand{\Bulletproofs}{\termbf{Bulletproofs}}
\newcommand{\ZEC}{\termbf{ZEC}}
\newcommand{\TAZ}{\termbf{TAZ}}
\newcommand{\zatoshi}{\term{zatoshi}}
\newcommand{\zcashd}{\termsf{zcashd}}
\newcommand{\zebra}{\termsf{zebra}}
\newcommand{\librustzcash}{\termsf{librustzcash}}
\newcommand{\BitcoinCore}{\termandindexx{\textsf{Bitcoin\kern0.2em Core}}{Bitcoin Core}}
\newcommand{\Makefile}{\texttt{Makefile}\xspace}

\newcommand{\MUST}{\conformance{MUST}}
\newcommand{\MUSTNOT}{\conformance{MUST NOT}}
\newcommand{\SHOULD}{\conformance{SHOULD}}
\newcommand{\SHOULDNOT}{\conformance{SHOULD NOT}}
\newcommand{\RECOMMENDED}{\conformance{RECOMMENDED}}
\newcommand{\MAY}{\conformance{MAY}}
\newcommand{\OPTIONAL}{\conformance{OPTIONAL}}
\newcommand{\ALLCAPS}{\conformance{ALL CAPS}}

\newcommand{\collisionResistant}{\termandindex{collision-resistant}{collision resistance}}
\newcommand{\collisionResistance}{\term{collision resistance}}
\newcommand{\xCollisionResistance}{\termx{collision resistance}}
\newcommand{\binding}{\termandindex{binding}{binding (commitment scheme)}}
\newcommand{\hiding}{\termandindex{hiding}{hiding (commitment scheme)}}
\newcommand{\quotedBinding}{\quotedtermandindex{binding}{binding (commitment scheme)}}
\newcommand{\quotedHiding}{\quotedtermandindex{hiding}{hiding (commitment scheme)}}
\newcommand{\reRandomized}{\term{re-randomized}}
\newcommand{\xReRandomized}{\termx{re-randomized}}
\newcommand{\reRandomizable}{\termandindex{re-randomizable}{re-randomized}}
\newcommand{\reRandomization}{\termandindex{re-randomization}{re-randomized}}
\newcommand{\randomOracle}{\term{random oracle}}
\newcommand{\randomOracles}{\terms{random oracle}}
\newcommand{\randomOracleAdjective}{\termandindex{random-oracle}{random oracle}}
\newcommand{\nonCanonicalPoint}{\termandindex{non-canonical}{non-canonical (compressed encoding of a point)}}
\newcommand{\nonCanonicalFieldElement}{\termandindex{non-canonical}{non-canonical (encoding of a field element)}}
\newcommand{\nonCanonicallyFieldElement}{\termandindex{non-canonically}{non-canonical (encoding of a field element)}}
\newcommand{\smallOrder}{\termandindex{small order}{small order (of a group element)}}
\newcommand{\smallOrderAdjective}{\termandindex{small-order}{small order (of a group element)}}
\newcommand{\primeOrder}{\termandindex{prime order}{prime order (of a group element)}}
\newcommand{\primeOrderAdjective}{\termandindex{prime-order}{prime order (of a group element)}}
\newcommand{\primeOrderGroup}{\term{prime-order group}}
\newcommand{\primeOrderSubgroup}{\term{prime-order subgroup}}
\newcommand{\primeOrderCurve}{\term{prime-order curve}}
\newcommand{\primeOrderCurves}{\terms{prime-order curve}}
\newcommand{\hashToCurve}{\term{hash-to-curve}}
\newcommand{\xDiscreteLogarithmProblem}{\term{Discrete Logarithm Problem}}
\newcommand{\xDiscreteLogarithm}{\termandindex{Discrete Logarithm}{Discrete Logarithm Problem}}
\newcommand{\xDecisionalDiffieHellmanProblem}{\term{Decisional Diffie--Hellman Problem}}
\newcommand{\xDecisionalDiffieHellman}{\termandindex{Decisional Diffie--Hellman}{Decisional Diffie--Hellman Problem}}
\newcommand{\partitioningOracleAttack}{\term{partitioning oracle attack}}
\newcommand{\partitioningOracleAttacks}{\terms{partitioning oracle attack}}
\newcommand{\sideChannel}{\term{side-channel}}
\newcommand{\multiPartyComputation}{\term{multi-party computation}}

\newcommand{\doubleSpend}{\term{double-spend}}
\newcommand{\doubleSpends}{\terms{double-spend}}
\newcommand{\doubleSpending}{\termandindex{double-spending}{double-spend}}
\newcommand{\proofOfWork}{\term{proof-of-work}}
\newcommand{\peerToPeerProtocol}{\term{peer-to-peer protocol}}
\newcommand{\peerToPeerNetwork}{\termandindex{peer-to-peer network}{peer-to-peer protocol}}
\newcommand{\inBand}{\term{in-band}}
\newcommand{\outOfBand}{\term{out-of-band}}
\newcommand{\xUSASCII}{\term{US-ASCII}}
\newcommand{\bitSequence}{\term{bit sequence}}
\newcommand{\bitSequences}{\terms{bit sequence}}
\newcommand{\bitSequenceAdjective}{\termandindex{bit-sequence}{bit sequence}}
\newcommand{\byteSequence}{\term{byte sequence}}
\newcommand{\byteSequences}{\terms{byte sequence}}
\newcommand{\byteSequenceAdjective}{\termandindex{byte-sequence}{byte sequence}}
\newcommand{\littleEndian}{\term{little-endian}}
\newcommand{\bigEndian}{\term{big-endian}}

\newcommand{\shaHash}{\termandindexx{$\SHAFull$}{SHA-256}}
\newcommand{\shadHash}{\termandindexx{$\SHAFulld$}{SHA-256d}}
\newcommand{\shaCompress}{\termandindexx{$\SHACompress$}{SHA256Compress}}
\newcommand{\shaHashText}{\texorpdfstring{$\SHAFull$}{SHA-256}}
\newcommand{\shadHashText}{\texorpdfstring{$\SHAFulld$}{SHA-256d}}
\newcommand{\shaCompressText}{\texorpdfstring{$\SHACompress$}{SHA256Compress}}
\newcommand{\bigShaHash}{\termandindexx{$\BigSHAFull$}{SHA-512}}
\newcommand{\bigShaHashText}{\texorpdfstring{$\BigSHAFull$}{SHA-512}}

\newcommand{\publicKey}{\term{public key}}
\newcommand{\publicKeys}{\terms{public key}}
\newcommand{\privateKey}{\term{private key}}
\newcommand{\privateKeys}{\terms{private key}}
\newcommand{\keyPrivacy}{\term{key privacy}}
\newcommand{\xKeyPrivacy}{\termx{key privacy}}
\newcommand{\keyPrivate}{\termandindex{key-private}{key privacy}}
\newcommand{\xKeyPrivate}{\termandindex{Key-private}{key privacy}}
\newcommand{\ephemeralPublicKey}{\term{ephemeral public key}}
\newcommand{\ephemeralPrivateKey}{\term{ephemeral private key}}

\newcommand{\note}{\term{note}}
\newcommand{\notes}{\terms{note}}
\newcommand{\dummy}{\termandindex{dummy}{dummy note}}
\newcommand{\dummyNote}{\term{dummy note}}
\newcommand{\dummyNotes}{\terms{dummy note}}
\newcommand{\commitmentScheme}{\term{commitment scheme}}
\newcommand{\commitmentSchemes}{\terms{commitment scheme}}
\newcommand{\commitmentTrapdoor}{\term{commitment trapdoor}}
\newcommand{\commitmentTrapdoors}{\terms{commitment trapdoor}}
\newcommand{\trapdoor}{\termandindex{trapdoor}{commitment trapdoor}}
\newcommand{\trapdoors}{\termandindex{trapdoors}{commitment trapdoor}}
\newcommand{\noteCommitment}{\term{note commitment}}
\newcommand{\noteCommitments}{\terms{note commitment}}
\newcommand{\xNoteCommitments}{\termxs{note commitment}}
\newcommand{\notesCommitment}{\termandindex{note's commitment}{note commitment}}
\newcommand{\noteCommitmentScheme}{\term{note commitment scheme}}
\newcommand{\noteCommitmentTree}{\term{note commitment tree}}
\newcommand{\noteCommitmentTrees}{\terms{note commitment tree}}
\newcommand{\notePosition}{\term{note position}}
\newcommand{\notePositions}{\terms{note position}}
\newcommand{\positionedNote}{\term{positioned note}}
\newcommand{\positionedNotes}{\terms{positioned note}}
\newcommand{\noteTraceabilitySet}{\term{note traceability set}}
\newcommand{\noteTraceabilitySets}{\terms{note traceability set}}
\newcommand{\valueCommitment}{\term{value commitment}}
\newcommand{\valueCommitments}{\terms{value commitment}}
\newcommand{\valueCommitmentScheme}{\term{value commitment scheme}}
\newcommand{\joinSplitDescription}{\term{JoinSplit description}}
\newcommand{\joinSplitDescriptions}{\terms{JoinSplit description}}
\newcommand{\joinSplitTransfer}{\term{JoinSplit transfer}}
\newcommand{\joinSplitTransfers}{\terms{JoinSplit transfer}}
\newcommand{\joinSplitSignature}{\term{JoinSplit signature}}
\newcommand{\joinSplitSignatures}{\terms{JoinSplit signature}}
\newcommand{\joinSplitSigningKey}{\term{JoinSplit signing key}}
\newcommand{\joinSplitValidatingKey}{\term{JoinSplit validating key}}
\newcommand{\joinSplitCircuit}{\term{JoinSplit circuit}}
\newcommand{\joinSplitStatement}{\term{JoinSplit statement}}
\newcommand{\joinSplitStatements}{\terms{JoinSplit statement}}
\newcommand{\joinSplitProof}{\term{JoinSplit proof}}
\newcommand{\shieldedTransfer}{\term{shielded transfer}}
\newcommand{\shieldedTransfers}{\terms{shielded transfer}}
\newcommand{\shieldedSpend}{\term{shielded Spend}}
\newcommand{\shieldedSpends}{\terms{shielded Spend}}
\newcommand{\shieldedInput}{\term{shielded input}}
\newcommand{\shieldedInputs}{\terms{shielded input}}
\newcommand{\spendDescription}{\term{Spend description}}
\newcommand{\spendDescriptions}{\terms{Spend description}}
\newcommand{\spendTransfer}{\term{Spend transfer}}
\newcommand{\spendTransfers}{\terms{Spend transfer}}
\newcommand{\spendCircuit}{\term{Spend circuit}}
\newcommand{\spendStatement}{\term{Spend statement}}
\newcommand{\spendStatements}{\terms{Spend statement}}
\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}}
\newcommand{\spendAuthAddressKeys}{\term{spend authorization address key}}
\newcommand{\spendAuthPrivateKey}{\term{spend authorization private key}}
\newcommand{\spendAuthPrivateKeys}{\term{spend authorization private key}}
\newcommand{\spendAuthSignatureScheme}{\term{spend authorization signature scheme}}
\newcommand{\spendingAuthority}{\term{spending authority}}
\newcommand{\outputDescription}{\term{Output description}}
\newcommand{\outputDescriptions}{\terms{Output description}}
\newcommand{\outputTransfer}{\term{Output transfer}}
\newcommand{\outputTransfers}{\terms{Output transfer}}
\newcommand{\outputCircuit}{\term{Output circuit}}
\newcommand{\outputStatement}{\term{Output statement}}
\newcommand{\outputStatements}{\terms{Output statement}}
\newcommand{\outputProof}{\term{Output proof}}
\newcommand{\actionDescription}{\term{Action description}}
\newcommand{\actionDescriptions}{\terms{Action description}}
\newcommand{\actionTransfer}{\term{Action transfer}}
\newcommand{\actionTransfers}{\terms{Action transfer}}
\newcommand{\actionCircuit}{\term{Action circuit}}
\newcommand{\actionStatement}{\term{Action statement}}
\newcommand{\actionStatements}{\terms{Action statement}}
\newcommand{\actionProof}{\term{Action proof}}
\newcommand{\saplingBindingSignature}{\termandindex{Sapling binding signature}{binding signature (Sapling)}}
\newcommand{\saplingBindingSignatures}{\termandindex{Sapling binding signatures}{binding signature (Sapling)}}
\newcommand{\orchardBindingSignature}{\termandindex{Orchard binding signature}{binding signature (Orchard)}}
\newcommand{\orchardBindingSignatures}{\termandindex{Orchard binding signatures}{binding signature (Orchard)}}
\newcommand{\bindingSignature}{\term{binding signature}}
\newcommand{\bindingSignatures}{\terms{binding signature}}
\newcommand{\bindingSignatureScheme}{\term{binding signature scheme}}
\newcommand{\txBindingValidatingKey}{\term{transaction binding validating key}}
\newcommand{\saplingBalancingValue}{\term{Sapling balancing value}}
\newcommand{\orchardBalancingValue}{\term{Orchard balancing value}}
\newcommand{\shieldedOutput}{\term{shielded output}}
\newcommand{\shieldedOutputs}{\terms{shielded output}}
\newcommand{\statement}{\term{statement}}
\newcommand{\statements}{\terms{statement}}
\newcommand{\proofNonmalleability}{\termandindex{nonmalleability}{nonmalleability (of proofs)}}
\newcommand{\proofBatchEntries}{\termandindex{proof batch entries}{proof batch entry}}
\newcommand{\ppzkSNARK}{\termandindex{preprocessing zk-SNARK}{proving system (preprocessing zk-SNARK)}}
\newcommand{\provingSystem}{\termandindex{proving system}{proving system (preprocessing zk-SNARK)}}
\newcommand{\provingSystems}{\termandindex{proving systems}{proving system (preprocessing zk-SNARK)}}
\newcommand{\zeroKnowledgeProvingSystem}{\termandindex{zero-knowledge proving system}{proving system (preprocessing zk-SNARK)}}
\newcommand{\zeroKnowledgeProvingSystems}{\termandindex{zero-knowledge proving systems}{proving system (preprocessing zk-SNARK)}}
\newcommand{\zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge}{\termandindex{zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARKs)}{proving system (preprocessing zk-SNARK)}}
\newcommand{\quadraticConstraintProgram}{\term{quadratic constraint program}}
\newcommand{\quadraticConstraintPrograms}{\terms{quadratic constraint program}}
\newcommand{\quadraticArithmeticProgram}{\term{Quadratic Arithmetic Program}}
\newcommand{\quadraticArithmeticPrograms}{\terms{Quadratic Arithmetic Program}}
\newcommand{\linearCombination}{\term{linear combination}}
\newcommand{\linearCombinations}{\terms{linear combination}}
\newcommand{\representedGroup}{\term{represented group}}
\newcommand{\representedGroups}{\terms{represented group}}
\newcommand{\representedSubgroup}{\term{represented subgroup}}
\newcommand{\representedSubgroups}{\terms{represented subgroup}}
\newcommand{\coordinateExtractor}{\term{coordinate extractor}}
\newcommand{\groupHash}{\term{group hash}}
\newcommand{\groupHashes}{\termes{group hash}}
\newcommand{\familyOfGroupHashesIntoTheSubgroup}{\termandindex{family of group hashes into the subgroup}{family of group hashes into a subgroup}}
\newcommand{\familiesOfGroupHashes}{\termandindex{families of group hashes}{family of group hashes into a subgroup}}
\newcommand{\representedPairing}{\term{represented pairing}}
\newcommand{\BCTV}{\termsf{BCTV14}}
\newcommand{\Groth}{\termsf{Groth16}}
\newcommand{\HaloTwo}{\termandindexx{$\mathsf{Halo}\;\mathsf{2}$}{Halo 2}}
\newcommand{\halotwo}{\termandindexx{$\mathsf{halo2}$}{halo2 (library)}}
\newcommand{\PLONK}{\termsf{PLONK}}
\newcommand{\BCTVText}{\texorpdfstring{$\mathsf{BCTV14}$}{BCTV14}}
\newcommand{\GrothText}{\texorpdfstring{$\mathsf{Groth16}$}{Groth16}}
\newcommand{\HaloTwoText}{\texorpdfstring{$\mathsf{Halo}\;\mathsf{2}$}{Halo 2}}
\newcommand{\BNPairing}{\termandindexx{$\mathsf{BN\mhyphen254}$}{BN-254}}
\newcommand{\BLSPairing}{\termandindexx{$\mathsf{BLS12\mhyphen381}$}{BLS12-381}}
\newcommand{\BNPairingText}{\texorpdfstring{$\mathsf{BN\mhyphen254}$}{BN-254}}
\newcommand{\BLSPairingText}{\texorpdfstring{$\mathsf{BLS12\mhyphen381}$}{BLS12-381}}
\newcommand{\Jubjub}{\termandindexx{$\mathsf{Jubjub}$}{Jubjub}}
\newcommand{\jubjubCurve}{\indexlink{Jubjub curve}{Jubjub}{$\mathsf{Jubjub}$}}
\newcommand{\JubjubText}{\texorpdfstring{$\mathsf{Jubjub}$}{Jubjub}}
\newcommand{\Pallas}{\termandindexx{$\mathsf{Pallas}$}{Pallas}}
\newcommand{\pallasCurve}{\indexlink{Pallas curve}{Pallas}{$\mathsf{Pallas}$}}
\newcommand{\PallasText}{\texorpdfstring{$\mathsf{Pallas}$}{Pallas}}
\newcommand{\IsoPallas}{\termandindexx{$\mathsf{iso}\kern0.05em\mhyphen\kern-0.05em\mathsf{Pallas}$}{iso-Pallas}}
\newcommand{\Vesta}{\termandindexx{$\mathsf{Vesta}$}{Vesta}}
\newcommand{\vestaCurve}{\indexlink{Vesta curve}{Vesta}{$\mathsf{Vesta}$}}
\newcommand{\VestaText}{\texorpdfstring{$\mathsf{Vesta}$}{Vesta}}
\newcommand{\IsoVesta}{\termandindexx{$\mathsf{iso}\kern0.05em\mhyphen\kern-0.05em\mathsf{Vesta}$}{iso-Vesta}}
\newcommand{\PallasAndVestaText}{\texorpdfstring{$\mathsf{Pallas}$ and $\mathsf{Vesta}$}{Pallas and Vesta}}
\newcommand{\secpCurve}{\indexlink{secp256k1 curve}{secp256k1}{$\mathsf{secp256k1}$}}
\newcommand{\completeTwistedEdwardsEllipticCurve}{\term{complete twisted Edwards elliptic curve}}
\newcommand{\completeTwistedEdwardsEllipticCurves}{\terms{complete twisted Edwards elliptic curve}}
\newcommand{\xCtEdwards}{\term{ctEdwards}}
\newcommand{\ctEdwardsCurve}{\termandindex{ctEdwards curve}{complete twisted Edwards elliptic curve}}
\newcommand{\ctEdwardsCurves}{\termandindex{ctEdwards curves}{complete twisted Edwards elliptic curve}}
\newcommand{\ctEdwardsCompressedEncoding}{\termandindex{ctEdwards compressed encoding}{complete twisted Edwards compressed encoding}}
\newcommand{\ctEdwardsCompressedEncodings}{\termandindex{ctEdwards compressed encodings}{complete twisted Edwards compressed encoding}}
\newcommand{\affineCtEdwards}{\termandindex{affine-ctEdwards}{complete twisted Edwards affine coordinates}}
\newcommand{\xAffineCtEdwards}{\termandindex{Affine-ctEdwards}{complete twisted Edwards affine coordinates}}
\newcommand{\MontgomeryEllipticCurve}{\term{Montgomery elliptic curve}}
\newcommand{\MontgomeryEllipticCurves}{\terms{Montgomery elliptic curve}}
\newcommand{\MontgomeryCurve}{\termandindex{Montgomery curve}{Montgomery elliptic curve}}
\newcommand{\MontgomeryCurves}{\termandindex{Montgomery curves}{Montgomery elliptic curve}}
\newcommand{\affineMontgomery}{\termandindex{affine-Montgomery}{Montgomery affine coordinates}}
\newcommand{\xAffineMontgomery}{\termandindex{Affine-Montgomery}{Montgomery affine coordinates}}
\newcommand{\swEllipticCurve}{\term{short Weierstrass elliptic curve}}
\newcommand{\swEllipticCurves}{\terms{short Weierstrass elliptic curve}}
\newcommand{\swCurve}{\termandindex{short Weierstrass curve}{short Weierstrass elliptic curve}}
\newcommand{\swCurves}{\termandindex{short Weierstrass curves}{short Weierstrass elliptic curve}}
\newcommand{\swCompressedEncoding}{\term{short Weierstrass compressed encoding}}
\newcommand{\swCompressedEncodings}{\terms{short Weierstrass compressed encoding}}
\newcommand{\affineSW}{\termandindex{affine-short-Weierstrass}{short Weierstrass affine coordinates}}
\newcommand{\xAffineSW}{\termandindex{Affine-short-Weierstrass}{short Weierstrass affine coordinates}}
\newcommand{\uniformRandomString}{\term{Uniform Random String}}
\newcommand{\uniformRandomStrings}{\terms{Uniform Random String}}
\newcommand{\provingKey}{\termandindex{proving key}{proving key (for a zk-SNARK)}}
\newcommand{\provingKeys}{\termandindex{proving keys}{proving key (for a zk-SNARK)}}
\newcommand{\zkProvingKeys}{\termandindex{zero-knowledge proving keys}{proving key (for a zk-SNARK)}}
\newcommand{\verifyingKey}{\termandindex{verifying key}{verifying key (for a zk-SNARK)}}
\newcommand{\verifyingKeys}{\termandindex{verifying keys}{verifying key (for a zk-SNARK)}}
\newcommand{\zkVerifyingKeys}{\termandindex{zero-knowledge verifying keys}{verifying key (for a zk-SNARK)}}
\newcommand{\joinSplitParameters}{\term{JoinSplit parameters}}
\newcommand{\rankOneConstraintSystem}{\term{Rank 1 Constraint System}}
\newcommand{\primary}{\termandindex{primary}{primary input}}
\newcommand{\xPrimary}{\termandindex{Primary}{primary input}}
\newcommand{\primaryInput}{\term{primary input}}
\newcommand{\primaryInputs}{\terms{primary input}}
\newcommand{\auxiliaryInput}{\term{auxiliary input}}
\newcommand{\auxiliaryInputs}{\terms{auxiliary input}}
\newcommand{\fullValidator}{\term{full validator}}
\newcommand{\fullValidators}{\terms{full validator}}
\newcommand{\consensusRuleChange}{\term{consensus rule change}}
\newcommand{\networkUpgrade}{\term{network upgrade}}
\newcommand{\networkUpgrades}{\terms{network upgrade}}
\newcommand{\network}{\term{network}}
\newcommand{\networks}{\terms{network}}
\newcommand{\Mainnet}{\term{Mainnet}}
\newcommand{\Testnet}{\term{Testnet}}
\newcommand{\settled}{\term{settled}}
\newcommand{\rpcByteOrder}{\term{RPC byte order}}
\newcommand{\anchor}{\term{anchor}}
\newcommand{\anchors}{\terms{anchor}}
\newcommand{\block}{\term{block}}
\newcommand{\blocks}{\terms{block}}
\newcommand{\blockHash}{\term{block hash}}
\newcommand{\blockHashes}{\termes{block hash}}
\newcommand{\header}{\termandindex{header}{block header}}
\newcommand{\headers}{\termandindex{headers}{block header}}
\newcommand{\blockHeader}{\term{block header}}
\newcommand{\blockHeaders}{\terms{block header}}
\newcommand{\Blockheader}{\termx{block header}}
\newcommand{\blockVersionNumber}{\term{block version number}}
\newcommand{\blockVersionNumbers}{\terms{block version number}}
\newcommand{\Blockversions}{\termandindex{Block versions}{block version number}}
\newcommand{\blockTargetSpacing}{\term{block target spacing}}
\newcommand{\blockTimestamp}{\term{block timestamp}}
\newcommand{\blockHeight}{\term{block height}}
\newcommand{\blockHeights}{\terms{block height}}
\newcommand{\activationBlock}{\term{activation block}}
\newcommand{\activationHeight}{\term{activation block height}}
\newcommand{\activationHeights}{\terms{activation block height}}
\newcommand{\genesisBlock}{\term{genesis block}}
\newcommand{\genesisBlocks}{\terms{genesis block}}
\newcommand{\medianTimePast}{\term{median-time-past}}
\newcommand{\transaction}{\term{transaction}}
\newcommand{\transactions}{\terms{transaction}}
\newcommand{\transactionID}{\term{transaction ID}}
\newcommand{\transactionIDs}{\terms{transaction ID}}
\newcommand{\xTransactionIDs}{\termxs{transaction ID}}
\newcommand{\wtxid}{\term{wtxid}}
\newcommand{\wtxids}{\terms{wtxid}}
\newcommand{\transactionFee}{\term{transaction fee}}
\newcommand{\transactionFees}{\terms{transaction fee}}
\newcommand{\transactionVersion}{\termandindex{transaction version}{transaction version number}}
\newcommand{\transactionVersions}{\termandindex{transaction versions}{transaction version number}}
\newcommand{\transactionVersionNumber}{\term{transaction version number}}
\newcommand{\transactionVersionNumbers}{\terms{transaction version number}}
\newcommand{\versionNumber}{\termandindex{version number}{transaction version number}}
\newcommand{\Transactionversion}{\termandindex{Transaction version}{transaction version number}}
\newcommand{\versionGroupID}{\term{version group ID}}
\newcommand{\consensusBranchID}{\term{consensus branch ID}}
\newcommand{\xConsensusBranchID}{\termx{consensus branch ID}}
\newcommand{\coinbaseTransaction}{\term{coinbase transaction}}
\newcommand{\coinbaseTransactions}{\terms{coinbase transaction}}
\newcommand{\prevout}{\termandindex{prevout}{prevout (previous output)}}
\newcommand{\prevouts}{\termandindex{prevouts}{prevout (previous output)}}
\newcommand{\transparent}{\term{transparent}}
\newcommand{\xTransparent}{\termx{transparent}}
\newcommand{\transparentAddress}{\term{transparent address}}
\newcommand{\transparentAddresses}{\termes{transparent address}}
\newcommand{\xTransparentAddresses}{\termxes{transparent address}}
\newcommand{\transparentInput}{\term{transparent input}}
\newcommand{\transparentInputs}{\terms{transparent input}}
\newcommand{\xTransparentInputs}{\termxs{transparent input}}
\newcommand{\transparentOutput}{\term{transparent output}}
\newcommand{\transparentOutputs}{\terms{transparent output}}
\newcommand{\xTransparentOutputs}{\termxs{transparent output}}
\newcommand{\transparentTxValuePool}{\termandindex{transparent transaction value pool}{transaction value pool (transparent)}}
% There is no Sprout transaction value pool, since JoinSplits are balanced individually.
\newcommand{\SaplingTxValuePool}{\termandindex{\textbf{Sapling} transaction value pool}{transaction value pool (Sapling)}}
\newcommand{\OrchardTxValuePool}{\termandindex{\textbf{Orchard} transaction value pool}{transaction value pool (Orchard)}}
\newcommand{\SproutChainValuePoolBalance}{\termandindex{\textbf{Sprout} chain value pool balance}{chain value pool balance (Sprout)}}
\newcommand{\SaplingChainValuePoolBalance}{\termandindex{\textbf{Sapling} chain value pool balance}{chain value pool balance (Sapling)}}
\newcommand{\OrchardChainValuePoolBalance}{\termandindex{\textbf{Orchard} chain value pool balance}{chain value pool balance (Orchard)}}
\newcommand{\chainValuePool}{\term{chain value pool}}
\newcommand{\chainValuePools}{\terms{chain value pool}}
\newcommand{\shielded}{\term{shielded}}
\newcommand{\blockChain}{\term{block chain}}
\newcommand{\blockChains}{\terms{block chain}}
\newcommand{\validBlockChain}{\term{valid block chain}}
\newcommand{\bestValidBlockChain}{\term{best valid block chain}}
\newcommand{\blockChainReorganization}{\term{block chain reorganization}}
\newcommand{\blockChainReorganizations}{\terms{block chain reorganization}}
\newcommand{\consensusBranch}{\term{consensus branch}}
\newcommand{\consensusBranches}{\termes{consensus branch}}
\newcommand{\mempool}{\term{mempool}}
\newcommand{\treestate}{\term{treestate}}
\newcommand{\treestates}{\terms{treestate}}
\newcommand{\xTreestates}{\termxs{treestate}}
\newcommand{\nullifier}{\term{nullifier}}
\newcommand{\nullifiers}{\terms{nullifier}}
\newcommand{\xNullifier}{\termx{nullifier}}
\newcommand{\xNullifiers}{\termxs{nullifier}}
\newcommand{\nullifierSet}{\term{nullifier set}}
\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}}
\newcommand{\unifiedPaymentAddresses}{\termes{unified payment address}}
\newcommand{\xUnifiedPaymentAddresses}{\termxes{unified payment address}}
\newcommand{\unifiedIncomingViewingKey}{\term{unified incoming viewing key}}
\newcommand{\unifiedIncomingViewingKeys}{\terms{unified incoming viewing key}}
\newcommand{\unifiedFullViewingKey}{\term{unified full viewing key}}
\newcommand{\unifiedFullViewingKeys}{\terms{unified full viewing key}}
\newcommand{\Bech}{\term{Bech32}}
\newcommand{\Bechm}{\term{Bech32m}}
\newcommand{\BechOptm}{\termandindex{Bech32[m]}{Bech32m}}
\newcommand{\BaseFiftyEightCheck}{\term{Base58Check}}
\newcommand{\diversifiedPaymentAddress}{\term{diversified payment address}}
\newcommand{\diversifiedPaymentAddresses}{\termes{diversified payment address}}
\newcommand{\defaultDiversifiedPaymentAddress}{\term{default diversified payment address}}
\newcommand{\diversifiedBase}{\term{diversified base}}
\newcommand{\diversifiedBases}{\terms{diversified base}}
\newcommand{\diversifier}{\term{diversifier}}
\newcommand{\diversifiers}{\terms{diversifier}}
\newcommand{\diversifierKey}{\term{diversifier key}}
\newcommand{\diversifierIndex}{\term{diversifier index}}
\newcommand{\diversifierIndices}{\termandindex{diversifier indices}{diversifier index}}
\newcommand{\xDiversifierIndices}{\termandindex{Diversifier indices}{diversifier index}}
\newcommand{\incomingViewingKey}{\term{incoming viewing key}}
\newcommand{\incomingViewingKeys}{\terms{incoming viewing key}}
\newcommand{\outgoingViewingKey}{\term{outgoing viewing key}}
\newcommand{\outgoingViewingKeys}{\terms{outgoing viewing key}}
\newcommand{\outgoingCipherKey}{\term{outgoing cipher key}}
\newcommand{\outgoingCipherKeys}{\terms{outgoing cipher key}}
\newcommand{\fullViewingKey}{\term{full viewing key}}
\newcommand{\fullViewingKeys}{\terms{full viewing key}}
\newcommand{\receivingKey}{\term{receiving key}}
\newcommand{\receivingKeys}{\terms{receiving key}}
\newcommand{\spendingKey}{\term{spending key}}
\newcommand{\spendingKeys}{\terms{spending key}}
\newcommand{\expandedSpendingKey}{\term{expanded spending key}}
\newcommand{\expandedSpendingKeys}{\terms{expanded spending key}}
\newcommand{\extendedSpendingKey}{\term{extended spending key}}
\newcommand{\extendedSpendingKeys}{\terms{extended spending key}}
\newcommand{\payingKey}{\term{paying key}}
\newcommand{\transmissionKey}{\term{transmission key}}
\newcommand{\transmissionKeys}{\terms{transmission key}}
\newcommand{\diversifiedTransmissionKey}{\term{diversified transmission key}}
\newcommand{\diversifiedTransmissionKeys}{\terms{diversified transmission key}}
\newcommand{\authSigningKey}{\term{Spend authorizing key}}
\newcommand{\authSigningKeys}{\terms{Spend authorizing key}}
\newcommand{\authValidatingKey}{\term{Spend validating key}}
\newcommand{\authValidatingKeys}{\terms{Spend validating key}}
\newcommand{\authRandomizedValidatingKey}{\term{randomized Spend validating key}}
\newcommand{\authRandomizedValidatingKeys}{\terms{randomized Spend validating key}}
\newcommand{\authProvingKey}{\term{proof authorizing key}}
\newcommand{\authProvingKeys}{\terms{proof authorizing key}}
\newcommand{\authNullifierKey}{\term{nullifier private key}}
\newcommand{\authNullifierKeys}{\terms{nullifier private key}}
\newcommand{\nullifierDerivingKey}{\term{nullifier deriving key}}
\newcommand{\nullifierDerivingKeys}{\terms{nullifier deriving key}}
\newcommand{\commitIvkRandomness}{\termandindexx{$\CommitIvk{}$ randomness}{Commit^ivk randomness}}
\newcommand{\rawEncoding}{\term{raw encoding}}
\newcommand{\rawEncodings}{\terms{raw encoding}}
\newcommand{\hdWallet}{\term{Hierarchical Deterministic Wallet}}
\newcommand{\humanReadablePart}{\term{Human-Readable Part}}
\newcommand{\notePlaintext}{\term{note plaintext}}
\newcommand{\notePlaintexts}{\terms{note plaintext}}
\newcommand{\notePlaintextLeadByte}{\term{note plaintext lead byte}}
\newcommand{\notePlaintextLeadBytes}{\terms{note plaintext lead byte}}
\newcommand{\notesCiphertextSprout}{\termandindex{transmitted notes ciphertext}{transmitted notes ciphertext (Sprout)}}
\newcommand{\noteCiphertext}{\term{transmitted note ciphertext}}
\newcommand{\noteCiphertexts}{\terms{transmitted note ciphertext}}
\newcommand{\noteCiphertextSapling}{\termandindex{transmitted note ciphertext}{transmitted note ciphertext (Sapling)}}
\newcommand{\noteCiphertextsSapling}{\termandindex{transmitted note ciphertexts}{transmitted note ciphertext (Sapling)}}
\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{\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)}}
\newcommand{\merkleNodes}{\termandindex{nodes}{node (of a Merkle tree)}}
\newcommand{\merkleHash}{\termandindex{hash value}{hash value (of a Merkle tree node)}}
\newcommand{\merkleHashes}{\termandindex{hash values}{hash value (of a Merkle tree node)}}
\newcommand{\merkleLeafNode}{\termandindex{leaf node}{leaf node (of a Merkle tree)}}
\newcommand{\merkleLeafNodes}{\termandindex{leaf nodes}{leaf node (of a Merkle tree)}}
\newcommand{\merkleInternalNode}{\termandindex{internal node}{internal node (of a Merkle tree)}}
\newcommand{\merkleInternalNodes}{\termandindex{internal nodes}{internal node (of a Merkle tree)}}
\newcommand{\MerkleInternalNodes}{\termandindex{Internal nodes}{internal node (of a Merkle tree)}}
\newcommand{\merklePath}{\term{Merkle path}}
\newcommand{\merkleLayer}{\termandindex{layer}{layer (of a Merkle tree)}}
\newcommand{\merkleLayers}{\termandindex{layers}{layer (of a Merkle tree)}}
\newcommand{\merkleIndex}{\termandindex{index}{index (of a Merkle tree node)}}
\newcommand{\merkleIndices}{\termandindex{indices}{index (of a Merkle tree node)}}
\newcommand{\zkSNARK}{\termandindex{zk-SNARK}{proving system (preprocessing zk-SNARK)}}
\newcommand{\zkSNARKs}{\termandindex{zk-SNARKs}{proving system (preprocessing zk-SNARK)}}
\newcommand{\zkProof}{\termandindex{zk~proof}{zk-SNARK proof}}
\newcommand{\zeroKnowledgeProof}{\termandindex{zero-knowledge proof}{zk-SNARK proof}}
\newcommand{\zeroKnowledgeProofs}{\termandindex{zero-knowledge proofs}{zk-SNARK proof}}
\newcommand{\zkSNARKProof}{\termandindex{zk-SNARK proof}{zk-SNARK proof}}
\newcommand{\zkSNARKProofs}{\termandindex{zk-SNARK proofs}{zk-SNARK proof}}
\newcommand{\zkSNARKCircuit}{\termandindex{zk-SNARK circuit}{zk-SNARK circuit}}
\newcommand{\zkSNARKCircuits}{\termandindex{zk-SNARK circuits}{zk-SNARK circuit}}
\newcommand{\libsnark}{\termandindex{libsnark}{libsnark (Zcash fork)}}
\newcommand{\bellman}{\term{bellman}}
\newcommand{\memo}{\term{memo field}}
\newcommand{\memos}{\terms{memo field}}
\newcommand{\keyAgreementScheme}{\term{key agreement scheme}}
\newcommand{\keyAgreementSchemes}{\terms{key agreement scheme}}
\newcommand{\keyDerivationFunction}{\term{Key Derivation Function}}
\newcommand{\keyDerivationFunctions}{\terms{Key Derivation Function}}
\newcommand{\hashFunction}{\term{hash function}}
\newcommand{\hashFunctions}{\terms{hash function}}
\newcommand{\encryptionScheme}{\term{encryption scheme}}
\newcommand{\oneTime}{\termandindex{one-time}{one-time (authenticated symmetric encryption)}}
\newcommand{\symmetricEncryptionScheme}{\termandindex{authenticated one-time symmetric encryption scheme}{authenticated one-time symmetric encryption}}
\newcommand{\signatureScheme}{\term{signature scheme}}
\newcommand{\signatureSchemes}{\terms{signature scheme}}
\newcommand{\oneTimeSignatureScheme}{\termandindex{one-time signature scheme}{one-time (signature scheme)}}
\newcommand{\rerandomizableSignatureScheme}{\termandindex{signature scheme with re-randomizable keys}{signature scheme with re-randomizable keys}}
\newcommand{\keyMonomorphicSignatureScheme}{\term{signature scheme with key monomorphism}}
\newcommand{\monomorphism}{\term{monomorphism}}
\newcommand{\sigNonmalleable}{\termandindex{nonmalleable}{nonmalleability (of signatures)}}
\newcommand{\sigBatchEntries}{\termandindex{signature batch entries}{signature batch entry}}
\newcommand{\signingKey}{\term{signing key}}
\newcommand{\signingKeys}{\terms{signing key}}
\newcommand{\validatingKey}{\termandindex{validating key}{validating key (for a signature scheme)}}
\newcommand{\validatingKeys}{\termandindex{validating keys}{validating key (for a signature scheme)}}
\newcommand{\randomizer}{\term{randomizer}}
\newcommand{\randomizers}{\terms{randomizer}}
\newcommand{\xPRF}{\termandindex{PRF}{Pseudo Random Function}}
\newcommand{\xPRFs}{\termandindex{PRFs}{Pseudo Random Function}}
\newcommand{\pseudoRandomFunction}{\term{Pseudo Random Function}}
\newcommand{\pseudoRandomFunctions}{\terms{Pseudo Random Function}}
\newcommand{\pseudoRandomPermutation}{\term{Pseudo Random Permutation}}
\newcommand{\pseudoRandomGenerators}{\termnoindex{Pseudo Random Generators}} % only in history
\newcommand{\expandedSeed}{\term{expanded seed}}
\newcommand{\xPedersenHash}{\term{Pedersen hash}}
\newcommand{\xPedersenHashes}{\termes{Pedersen hash}}
\newcommand{\xPedersenCommitment}{\term{Pedersen commitment}}
\newcommand{\xPedersenCommitments}{\terms{Pedersen commitment}}
\newcommand{\xPedersenValueCommitment}{\term{Pedersen value commitment}}
\newcommand{\xPedersenValueCommitments}{\terms{Pedersen value commitment}}
\newcommand{\windowedPedersenCommitment}{\term{windowed Pedersen commitment}}
\newcommand{\windowedPedersenCommitments}{\terms{windowed Pedersen commitment}}
\newcommand{\homomorphicPedersenCommitment}{\term{homomorphic Pedersen commitment}}
\newcommand{\homomorphicPedersenCommitments}{\terms{homomorphic Pedersen commitment}}
\newcommand{\xSinsemillaHash}{\term{Sinsemilla hash}}
\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)}}
\newcommand{\distinctXCriterion}{\term{distinct-$x$ criterion}}
\newcommand{\Nary}{\mbox{$N$-ary}}

% Conventions

% requires #1 and #2 to be simple
\newcommand{\pow}[2]{\readas{#1 to the #2}{{#1}^{#2}}}
\newcommand{\bytes}[1]{\underline{\raisebox{-0.3ex}{}\smash{#1}}}
\newcommand{\zeros}[1]{[0]^{#1}}
\newcommand{\zerobytes}[1]{[\hexint{00}]^{#1}}
\newcommand{\ones}[1]{[1]^{#1}}
\newcommand{\bit}{\mathbb{B}}
\newcommand{\byte}{\mathbb{B}\kern -0.1em\raisebox{0.55ex}{\overlap{0.0001em}{\scalebox{0.7}{$\mathbb{Y}$}}}}
\newcommand{\Nat}{\mathbb{N}}
\newcommand{\PosInt}{\mathbb{N}^+}
\newcommand{\Int}{\mathbb{Z}}
\newcommand{\Rat}{\mathbb{Q}}
\newcommand{\GF}[1]{\mathbb{F}_{\!#1}}
\newcommand{\GFstar}[1]{\mathbb{F}^\ast_{#1}}
\newcommand{\typeexp}[2]{{#1}\vphantom{)}^{[{#2}]}}
\newcommand{\bitseq}[1]{\typeexp{\bit}{#1}}
\newcommand{\bitseqs}{\bitseq{\Nat}}
\newcommand{\byteseq}[1]{\typeexp{\byte}{#1}}
\newcommand{\byteseqs}{\byteseq{\Nat}}
\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}}
\newcommand{\for}{\text{ for }}
\newcommand{\from}{\text{ from }}
\newcommand{\upto}{\text{ up to }}
\newcommand{\downto}{\text{ down to }}
\newcommand{\tand}{\text{ \;and\, }}
\newcommand{\tor}{\text{ \;or\, }}
\newcommand{\squash}{\!\!\!}
\newcommand{\caseif}{\squash\text{if }}
\newcommand{\caseotherwise}{\squash\text{otherwise}}
\newcommand{\sorted}{\mathsf{sorted}}
\newcommand{\length}{\mathsf{length}}
\newcommand{\truncate}[1]{\mathsf{truncate}_{#1}}
\newcommand{\mean}{\mathsf{mean}}
\newcommand{\median}{\mathsf{median}}
\newcommand{\bound}[2]{\mathsf{bound\,}_{#1}^{#2}}
\newcommand{\Lower}{\mathsf{lower}}
\newcommand{\Upper}{\mathsf{upper}}
\newcommand{\bitlength}{\mathsf{bitlength}}
\newcommand{\size}{\mathsf{size}}
\newcommand{\mantissa}{\mathsf{mantissa}}
\newcommand{\ToCompact}{\mathsf{ToCompact}}
\newcommand{\ToTarget}{\mathsf{ToTarget}}
\newcommand{\ToScalar}[1]{\mathsf{ToScalar^{#1\kern-0.1em}}}
\newcommand{\ToBase}[1]{\mathsf{ToBase^{#1\kern-0.1em}}}
\newcommand{\hexint}[1]{\mathtt{0x{#1}}}
\newcommand{\dontcare}{\kern -0.06em\raisebox{0.1ex}{\footnotesize{$\times$}}}
\newcommand{\ascii}[1]{\textbf{``\texttt{#1}''}}
\newcommand{\Justthebox}[2][-1.35ex]{\raisebox{#1}{\;\usebox{#2}\;}}
\newcommand{\setof}[1]{\{{#1}\}}
\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}}}
\newcommand{\bigrange}[2]{\bigsetof{\barerange{#1}{#2}}}
\newcommand{\rangenozero}[2]{\range{#1}{#2} \setminus \setof{0}}
\newcommand{\bigrangenozero}[2]{\bigrange{#1}{#2} \setminus \setof{0}}
\newcommand{\binaryrange}[1]{\range{0}{2^{#1}\!\!-\!1}}
\newcommand{\oneto}[1]{\mathrm{1}..{#1}}
\newcommand{\alln}{\oneto{n}}
\newcommand{\allm}{\oneto{m}}
\newcommand{\minimum}{\mathsf{min}}
\newcommand{\maximum}{\mathsf{max}}
\newcommand{\floor}[1]{\mathsf{floor}\!\left({#1}\right)}
\newcommand{\trunc}[1]{\mathsf{trunc}\!\left({#1}\right)}
\newcommand{\ceiling}[1]{\mathsf{ceiling}\kern-0.06em\left({#1}\right)}
\newcommand{\sceiling}[1]{\mathsf{ceiling}\left({#1}\right)}
\newcommand{\vop}[3]{\,\raisebox{0.29ex}{\scalebox{0.89}{$\smashoperator[r]{#3_{#1}^{#2}}$\,}}}
\newcommand{\sop}[3]{\!\scalebox{0.89}{$\scalebox{1.404}{$\strut#3$}_{#1}^{#2}$}}
\newcommand{\vsum}[2]{\vop{#1}{#2}{\sum}}
\newcommand{\ssum}[2]{\sop{#1}{#2}{\sum}}
\newcommand{\vproduct}[2]{\vop{#1}{#2}{\prod}}
\newcommand{\sproduct}[2]{\sop{#1}{#2}{\prod}}
\newcommand{\vxor}[2]{\vop{#1}{#2}{\bigoplus}}
\newcommand{\sxor}[2]{\sop{#1}{#2}{\bigoplus}}
\newcommand{\vcombsum}[2]{\vop{#1}{#2}{\biggercombplus}}
\newcommand{\scombsum}[2]{\sop{#1}{#2}{\bigcombplus}}
\newcommand{\vgrpsum}[2]{\vop{#1}{#2}{\biggergrpplus}}
\newcommand{\sgrpsum}[2]{\sop{#1}{#2}{\biggrpplus}}
\newcommand{\xor}{\oplus}
\newcommand{\biggercombplus}{\bigdiamondplus{4.6ex}}
\newcommand{\bigcombplus}{\bigdiamondplus{3.3ex}}
\newcommand{\combplus}{\bigdiamondplus{1.8ex}\,}
\newcommand{\subcombplus}{\bigdiamondplus{1.4ex}}
\newcommand{\combzero}{\Zero_{\subcombplus}}
\newcommand{\combminus}{\bigdiamondminus{1.8ex}\,}
\newcommand{\combneg}{\bigdiamondminus{1.8ex}}
\newcommand{\biggergrpplus}{\bigboxplus{4.6ex}}
\newcommand{\biggrpplus}{\bigboxplus{3.3ex}}
\newcommand{\grpplus}{\bigboxplus{1.8ex}\,}
\newcommand{\subgrpplus}{\bigboxplus{1.4ex}}
\newcommand{\grpzero}{\Zero_{\subgrpplus}}
\newcommand{\grpminus}{\bigboxminus{1.8ex}\,}
\newcommand{\grpneg}{\bigboxminus{1.8ex}}
\newcommand{\incompleteadd}{\,\fivedots\,}
\newcommand{\vartimes}{\bigvartimes{1.8ex}}
\newcommand{\band}{\binampersand}
\newcommand{\bor}{\lor}
\newcommand{\suband}{\raisebox{-0.6ex}{\kern-0.06em\scalebox{0.65}{$\binampersand$}}}
\newcommand{\bchoose}{\;\scalebox{1.2}[1]{\textsf{?}}\;}
\newcommand{\rotr}{\ggg}
\newcommand{\mult}{\cdot}
\newcommand{\smult}{\!\cdot\!}
\newcommand{\scalarmult}[2]{\boldsymbol{[}{#1}\boldsymbol{]}\,{#2}}
\newcommand{\bigscalarmult}[2]{\big[{#1}\big]\,{#2}}
\newcommand{\Bigscalarmult}[2]{\Big[{#1}\Big]{#2}}
\newcommand{\Biggscalarmult}[2]{\Bigg[{#1}\Bigg]{#2}}
\newcommand{\rightarrowR}{\mathop{\clasp[-0.18em]{\raisebox{1.15ex}{\scriptsize R}}{$\,\rightarrow\,$}}}
\newcommand{\leftarrowR}{\mathop{\clasp[0.15em]{\raisebox{1.15ex}{\scriptsize R}}{$\,\leftarrow\,$}}}
\newcommand{\union}{\cup}
\newcommand{\intersection}{\cap}
\newcommand{\suchthat}{\,\vert\;}
\newcommand{\paramdot}{\bigcdot}
\newcommand{\lincomb}[1]{\left(\strut\kern-.025em{#1}\kern-0.04em\right)}
\newcommand{\constraint}[3]{\lincomb{#1}\hairspace \vartimes\hairspace \lincomb{#2}\hairspace =\hairspace \lincomb{#3}}
\newcommand{\lconstraint}[1]{\lincomb{#1}\hairspace \vartimes\mhspace{0.25em}}
\newcommand{\maybe}[1]{{#1} \union \setof{\bot}}
\newcommand{\Of}[1]{\!\left({#1}\right)\!}

% <https://tex.stackexchange.com/a/87423/78411>
\newcommand{\hexints}[1]{
  \def\nextitem{\def\nextitem{, }}
  \renewcommand*{\do}[1]{\nextitem\hexint{##1}}
  \docsvlist{#1}
}
\newcommand{\hexarray}[1]{[\,\hexints{#1}\,]}


% Hashes

\newcommand{\hSigCRH}{\mathsf{hSigCRH}}
\newcommand{\hSigLength}{\mathsf{\ell_{hSig}}}
\newcommand{\hSigType}{\bitseq{\hSigLength}}
\newcommand{\EquihashGen}[1]{\mathsf{EquihashGen}_{#1}}
\newcommand{\CRH}{\mathsf{CRH}}
\newcommand{\SHACompress}{\mathsf{SHA256Compress}}
\newcommand{\SHACompressBox}[1]{\SHACompress\left(\Justthebox{#1}\right)}
\newcommand{\SHAFull}{\mathsf{SHA\mhyphen256}}
\newcommand{\SHAFullBox}[1]{\SHAFull\left(\Justthebox{#1}\right)}
\newcommand{\SHAFulld}{\mathsf{SHA\mhyphen256d}}
\newcommand{\BigSHAFull}{\mathsf{SHA\mhyphen512}}
\newcommand{\BlakeTwoGeneric}{\mathsf{BLAKE2}}
\newcommand{\BlakeTwobGeneric}{\mathsf{BLAKE2b}}
\newcommand{\BlakeTwob}[1]{\mathsf{BLAKE2b\kern 0.05em\mhyphen{#1}}}
\newcommand{\BlakeTwobOf}[2]{\BlakeTwob{#1}\!\left({#2}\right)}
\newcommand{\XMDBlakeTwob}{\mathsf{XMD\mcolon BLAKE2b}}
\newcommand{\XMDBlakeTwobOf}[1]{\XMDBlakeTwob\!\left({#1}\right)}
\newcommand{\BlakeTwosGeneric}{\mathsf{BLAKE2s}}
\newcommand{\BlakeTwos}[1]{\mathsf{BLAKE2s\kern 0.05em\mhyphen{#1}}}
\newcommand{\BlakeTwosOf}[2]{\BlakeTwos{#1}\!\left({#2}\right)}
\newcommand{\BlakeParamBlock}{\mathsf{PB}}
\newcommand{\BlakeIV}{\mathsf{IV}}
\newcommand{\CRHivk}{\mathsf{CRH^{\InViewingKey}}}
\newcommand{\CRHivkText}{\texorpdfstring{$\CRHivk$}{CRHivk}}
\newcommand{\CRHivkOutput}{\CRHivk\mathsf{.Output}}
\newcommand{\CRHivkBox}[1]{\CRHivk\!\left(\Justthebox{#1}\right)}
\newcommand{\Poseidon}{\mathsf{Poseidon}}
\newcommand{\PoseidonText}{\texorpdfstring{$\Poseidon$}{Poseidon}}
\newcommand{\PoseidonHash}{\mathsf{PoseidonHash}}
\newcommand{\PoseidonHashText}{\texorpdfstring{$\PoseidonHash$}{PoseidonHash}}
\newcommand{\DiversifyHash}[1]{\mathsf{DiversifyHash}^\mathsf{#1\kern-0.1em}}
\newcommand{\DiversifyHashText}[1]{\texorpdfstring{$\DiversifyHash{#1}$}{DiversifyHash{#1}}}
\newcommand{\DefaultDiversifier}{\mathsf{DefaultDiversifier}}
\newcommand{\CheckDiversifier}{\mathsf{CheckDiversifier}}
\newcommand{\NotUpMySleeve}{U}
\newcommand{\msg}{\mathsf{msg}}
\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}}
\newcommand{\SpentSet}{\mathsf{SpentSet}}
\newcommand{\NullifierMap}{\mathsf{NullifierMap}}
\newcommand{\NullifierType}{\mathsf{NullifierType}}

% Key pairs

\newcommand{\PaymentAddress}{\mathsf{addr_{pk}}}
\newcommand{\DiversifiedPaymentAddress}{\mathsf{addr_{d}}}
\newcommand{\PaymentAddressLeadByte}{\hexint{16}}
\newcommand{\PaymentAddressSecondByte}{\hexint{9A}}
\newcommand{\InViewingKey}{\mathsf{ivk}}
\newcommand{\InViewingKeyLength}[1]{\ell^\mathsf{#1\vphantom{p}}_{\InViewingKey}\!}
\newcommand{\InViewingKeyTypeSapling}{\binaryrange{\InViewingKeyLength{Sapling}}}
\newcommand{\InViewingKeyTypeOrchard}{\range{1}{\ParamP{q}-1}}
\newcommand{\InViewingKeyRepr}{{\InViewingKey\Repr}}
\newcommand{\InViewingKeyLeadByte}{\hexint{A8}}
\newcommand{\InViewingKeySecondByte}{\hexint{AB}}
\newcommand{\InViewingKeyThirdByte}{\hexint{D3}}
\newcommand{\SpendingKeyLeadByte}{\hexint{AB}}
\newcommand{\SpendingKeySecondByte}{\hexint{36}}
\newcommand{\PtoSHAddressLeadByte}{\hexint{1C}}
\newcommand{\PtoSHAddressSecondByte}{\hexint{BD}}
\newcommand{\PtoPKHAddressLeadByte}{\hexint{1C}}
\newcommand{\PtoPKHAddressSecondByte}{\hexint{B8}}
\newcommand{\PaymentAddressTestnetLeadByte}{\hexint{16}}
\newcommand{\PaymentAddressTestnetSecondByte}{\hexint{B6}}
\newcommand{\InViewingKeyTestnetLeadByte}{\hexint{A8}}
\newcommand{\InViewingKeyTestnetSecondByte}{\hexint{AC}}
\newcommand{\InViewingKeyTestnetThirdByte}{\hexint{0C}}
\newcommand{\SpendingKeyTestnetLeadByte}{\hexint{AC}}
\newcommand{\SpendingKeyTestnetSecondByte}{\hexint{08}}
\newcommand{\PtoSHAddressTestnetLeadByte}{\hexint{1C}}
\newcommand{\PtoSHAddressTestnetSecondByte}{\hexint{BA}}
\newcommand{\PtoPKHAddressTestnetLeadByte}{\hexint{1D}}
\newcommand{\PtoPKHAddressTestnetSecondByte}{\hexint{25}}
\newcommand{\NotePlaintextLeadByte}{\mathsf{leadByte}}
\newcommand{\AuthPublic}{\mathsf{a_{pk}}}
\newcommand{\AuthPublicSub}[1]{\mathsf{a_{pk,\mathnormal{#1}}}}
\newcommand{\AuthPrivate}{\mathsf{a_{sk}}}
\newcommand{\AuthPrivateSup}[1]{\mathsf{a^\mathrm{#1}_{sk}}}
\newcommand{\AuthPrivateLength}{\mathsf{\ell_{\AuthPrivate}}}
\newcommand{\AuthPublicOld}[1]{\mathsf{a^{old}_{pk,\mathnormal{#1}}}}
\newcommand{\AuthPrivateOld}[1]{\mathsf{a^{old}_{sk,\mathnormal{#1}}}}
\newcommand{\AuthEmphPublicOld}[1]{\mathsf{a^{old}_{\textsf{\textbf{pk}},\mathnormal{#1}}}}
\newcommand{\AuthPublicOldX}[1]{\mathsf{a^{old}_{pk,\mathrm{#1}}}}
\newcommand{\AuthPrivateOldX}[1]{\mathsf{a^{old}_{sk,\mathrm{#1}}}}
\newcommand{\AuthPublicNew}[1]{\mathsf{a^{new}_{pk,\mathnormal{#1}}}}
\newcommand{\AuthPrivateNew}[1]{\mathsf{a^{new}_{sk,\mathnormal{#1}}}}
\newcommand{\AddressPublicNew}[1]{\mathsf{addr^{new}_{pk,\mathnormal{#1}}}}
\newcommand{\ScalarLength}[1]{\ell^\mathsf{#1\vphantom{p}}_{\mathsf{scalar}}}
\newcommand{\BaseLength}[1]{\ell^\mathsf{#1\vphantom{p}}_{\mathsf{base}}}
\newcommand{\enc}{\mathsf{enc}}
\newcommand{\DHSecret}[1]{\mathsf{sharedSecret}_{#1}}
\newcommand{\EphemeralPublic}{\mathsf{epk}}
\newcommand{\Repr}{\star}
\newcommand{\MakeRepr}[2]{{#1}\rlap{\raisebox{-0.32ex}{$\Repr$}}\rule{0ex}{2.2ex}^{#2}}
\newcommand{\EphemeralPublicRepr}{{\EphemeralPublic\Repr}}
\newcommand{\EphemeralPrivate}{\mathsf{esk}}
\newcommand{\EphemeralPrivateRepr}{{\EphemeralPrivate\Repr}}
\newcommand{\EphemeralPrivateBytes}{\bytes{\EphemeralPrivate}}
\newcommand{\EphemeralPrivateBytesType}{\byteseq{32}}
\newcommand{\EphemeralPrivatePre}{\mathsf{pre\_esk}}
\newcommand{\TransmitPublic}{\mathsf{pk_{enc}}}
\newcommand{\TransmitPublicSup}[1]{\mathsf{pk}^{#1}_\mathsf{enc}}
\newcommand{\TransmitPublicNew}[1]{\mathsf{pk^{new}_{\enc,\mathnormal{#1}}}}
\newcommand{\TransmitPublicSub}[1]{\mathsf{pk_{\enc,\mathnormal{#1}}}}
\newcommand{\TransmitPrivate}{\mathsf{sk_{enc}}}
\newcommand{\TransmitPrivateSup}[1]{\mathsf{sk}^{#1}_\mathsf{enc}}
\newcommand{\TransmitBase}{\mathsf{g}}

% Sapling and Orchard

\newcommand{\Internal}[1]{{#1}_{\mathsf{internal}}}
\newcommand{\SpendingKey}{\mathsf{sk}}
\newcommand{\SpendingKeyLength}{\mathsf{\ell_{\SpendingKey}}}
\newcommand{\SpendingKeyType}{\bitseq{\SpendingKeyLength}}
\newcommand{\AuthSignPrivate}{\mathsf{ask}}
\newcommand{\AuthSignBase}[1]{\mathcal{G}^{\mathsf{#1}\!}}
\newcommand{\AuthSignPublic}{\mathsf{ak}}
\newcommand{\AuthSignPublicPoint}{\mathsf{ak}^\GroupP}
\newcommand{\AuthSignPublicRepr}{{\AuthSignPublic\Repr}}
\newcommand{\AuthSignPublicTypeOrchard}{\range{0}{\ParamP{q}-1}}
\newcommand{\AuthSignRandomizedPublic}{\mathsf{rk}}
\newcommand{\AuthSignRandomizedPublicRepr}{{\AuthSignRandomizedPublic\Repr}}
\newcommand{\AuthSignRandomizedPrivate}{\mathsf{rsk}}
\newcommand{\AuthSignRandomizer}{\alpha}
\newcommand{\AuthSignRandomizerRepr}{{\AuthSignRandomizer\Repr}}
\newcommand{\AuthProvePrivate}{\mathsf{nsk}}
\newcommand{\AuthProvePrivateRepr}{{\AuthProvePrivate\Repr}}
\newcommand{\AuthProveBaseSapling}{\mathcal{H}^\mathsf{Sapling}}
\newcommand{\NullifierKey}{\mathsf{nk}}
\newcommand{\NullifierKeyRepr}{{\NullifierKey\Repr}}
\newcommand{\NullifierKeyTypeOrchard}{\GF{\ParamP{q}}}
\newcommand{\NullifierBaseOrchard}{\mathcal{K}^\mathsf{Orchard}}
\newcommand{\NullifierTypeOrchard}{\GF{\ParamP{q}}}
\newcommand{\OutViewingKey}{\mathsf{ovk}}
\newcommand{\OutViewingKeyLength}{\mathsf{\ell_{\OutViewingKey}}}
\newcommand{\OutViewingKeyType}{\byteseq{\OutViewingKeyLength/8}}
\newcommand{\OutCipherKey}{\mathsf{ock}}
\newcommand{\NotePosition}{\mathsf{pos}}
\newcommand{\NotePositionRepr}{{\NotePosition\Repr}}
\newcommand{\NotePositionBaseSapling}{\mathcal{J}^\mathsf{Sapling}}
\newcommand{\NotePositionType}[1]{\binaryrange{\MerkleDepth{#1}}}
\newcommand{\Diversifier}{\mathsf{d}}
\newcommand{\DiversifierLength}{\mathsf{\ell_{\Diversifier}}}
\newcommand{\DiversifierType}{\bitseq{\DiversifierLength}}
\newcommand{\DiversifierKey}{\mathsf{dk}}
\newcommand{\DiversifierKeyLength}{\mathsf{\ell_{\DiversifierKey}}}
\newcommand{\DiversifierKeyType}{\byteseq{\DiversifierKeyLength/8}}
\newcommand{\DiversifierIndex}{\mathsf{index}}
\newcommand{\FVK}{\mathsf{FVK}}
\newcommand{\DeriveInternalFVKOrchard}{\mathsf{DeriveInternalFVK^{Orchard}}}
\newcommand{\DiversifiedTransmitBase}{\mathsf{g_d}}
\newcommand{\DiversifiedTransmitBaseRepr}{\mathsf{g\Repr_d}}
\newcommand{\DiversifiedTransmitBaseOld}{\mathsf{g^{old}_d}}
\newcommand{\DiversifiedTransmitBaseOldRepr}{\mathsf{g\Repr^{old}_d}}
\newcommand{\DiversifiedTransmitBaseNew}{\mathsf{g^{new}_d}}
\newcommand{\DiversifiedTransmitBaseNewRepr}{\mathsf{g\Repr^{new}_d}}
\newcommand{\DiversifiedTransmitPublic}{\mathsf{pk_d}}
\newcommand{\DiversifiedTransmitPublicRepr}{\mathsf{pk\Repr_d}}
\newcommand{\DiversifiedTransmitPublicOld}{\mathsf{pk^{old}_d}}
\newcommand{\DiversifiedTransmitPublicOldRepr}{\mathsf{pk\Repr^{old}_d}}
\newcommand{\DiversifiedTransmitPublicNew}{\mathsf{pk^{new}_d}}
\newcommand{\DiversifiedTransmitPublicNewRepr}{\mathsf{pk\Repr^{new}_d}}
\newcommand{\vOldRepr}{\MakeRepr{\mathsf{v}}{\mathsf{old}}}

% PRFs

\newcommand{\PRF}[2]{\mathsf{{PRF}^{#2}_\mathnormal{#1}}}
\newcommand{\PRFaddr}[1]{\PRF{#1}{addr}}
\newcommand{\PRFexpand}[1]{\PRF{#1}{expand}}
\newcommand{\PRFock}[2]{\PRF{#2}{ock#1}}
\newcommand{\PRFnf}[2]{\PRF{#2}{nf\kern-0.01em #1}}
\newcommand{\PRFsn}[1]{\PRF{#1}{sn}}
\newcommand{\PRFpk}[1]{\PRF{#1}{pk}}
\newcommand{\PRFrho}[1]{\PRF{#1}{\NoteUniqueRand}}
\newcommand{\PRFOutputLengthSprout}{\mathsf{\ell^{Sprout}_{PRF}}}
\newcommand{\PRFOutputSprout}{\bitseq{\PRFOutputLengthSprout}}
\newcommand{\PRFOutputLengthNfSapling}{\mathsf{\ell_{PRFnfSapling}}}
\newcommand{\PRFOutputNfSapling}{\byteseq{\PRFOutputLengthNfSapling/8}}
\newcommand{\PRFOutputNfOrchard}{\GF{\ParamP{q}}}
\newcommand{\PRFOutputLengthExpand}{\mathsf{\ell_{PRFexpand}}}
\newcommand{\PRFOutputExpand}{\byteseq{\PRFOutputLengthExpand/8}}
\newcommand{\PRFInputExpand}{\byteseqs}

% PRPs

\newcommand{\PRP}[2]{\mathsf{{PRP}^{#2}_\mathnormal{#1}}}
\newcommand{\PRPd}[1]{\PRP{#1}{d}}

% Commitments

\newcommand{\Uncommitted}[1]{\mathsf{Uncommitted}^\mathsf{#1\kern-0.1em}}
\newcommand{\NoteCommitment}[1]{\mathsf{NoteCommitment}^\mathsf{#1\kern-0.1em}}

\newcommand{\CommitAlg}{\mathsf{COMM}}
\newcommand{\Commit}[1]{\CommitAlg_{#1}}
\newcommand{\CommitTrapdoor}{\CommitAlg\mathsf{.Trapdoor}}
\newcommand{\CommitGenTrapdoor}{\CommitAlg\mathsf{.GenTrapdoor}}
\newcommand{\CommitInput}{\CommitAlg\mathsf{.Input}}
\newcommand{\CommitOutput}{\CommitAlg\mathsf{.Output}}
\newcommand{\NoteCommitAlg}[1]{\mathsf{NoteCommit}^\mathsf{#1\kern-0.1em}}
\newcommand{\NoteCommit}[2]{\NoteCommitAlg{#1}_{\vphantom{l}#2}}
\newcommand{\NoteCommitTrapdoor}[1]{\NoteCommitAlg{#1}\mathsf{.Trapdoor}}
\newcommand{\NoteCommitTrapdoorBytes}{\byteseq{32}}
\newcommand{\NoteCommitGenTrapdoor}[1]{\NoteCommitAlg{#1}\mathsf{.GenTrapdoor}}
\newcommand{\NoteCommitInput}[1]{\NoteCommitAlg{#1}\mathsf{.Input}}
\newcommand{\NoteCommitOutput}[1]{\NoteCommitAlg{#1}\mathsf{.Output}}
\newcommand{\CommitPrimeAlg}{\mathsf{COMM}'}
\newcommand{\CommitPrime}[1]{\CommitPrimeAlg_{#1}}
\newcommand{\ValueCommitAlg}[1]{\mathsf{ValueCommit}^\mathsf{#1\kern-0.1em}}
\newcommand{\ValueCommit}[2]{\ValueCommitAlg{#1}_{#2}}
\newcommand{\ValueCommitTrapdoor}[1]{\ValueCommitAlg{#1}\mathsf{.Trapdoor}}
\newcommand{\ValueCommitGenTrapdoor}[1]{\ValueCommitAlg{#1}\mathsf{.GenTrapdoor}}
\newcommand{\ValueCommitInput}[1]{\ValueCommitAlg{#1}\mathsf{.Input}}
\newcommand{\ValueCommitOutput}[1]{\ValueCommitAlg{#1}\mathsf{.Output}}
\newcommand{\ValueCommitValueBase}[1]{\mathcal{V}^\mathsf{#1\kern-0.1em}}
\newcommand{\ValueCommitRandBase}[1]{\mathcal{R}^\mathsf{#1\kern-0.1em}}
\newcommand{\CommitIvkAlg}{\mathsf{Commit}^{\InViewingKey}}
\newcommand{\CommitIvk}[1]{\CommitIvkAlg_{#1}}
\newcommand{\CommitIvkTrapdoor}{\CommitIvkAlg\mathsf{.Trapdoor}}
\newcommand{\CommitIvkGenTrapdoor}{\CommitIvkAlg\mathsf{.GenTrapdoor}}
\newcommand{\CommitIvkInput}{\CommitIvkAlg\mathsf{.Input}}
\newcommand{\CommitIvkOutput}{\CommitIvkAlg\mathsf{.Output}}
\newcommand{\CommitIvkOutputType}{\maybe{\range{0}{\ParamP{q}-1}}}
\newcommand{\DeriveNullifierAlg}{\mathsf{DeriveNullifier}}
\newcommand{\DeriveNullifier}[1]{\DeriveNullifierAlg_{#1}}

% Symmetric encryption

\newcommand{\Sym}{\mathsf{Sym}}
\newcommand{\SymEncrypt}[1]{\Sym\mathsf{.Encrypt}_{#1}}
\newcommand{\SymDecrypt}[1]{\Sym\mathsf{.Decrypt}_{#1}}
\newcommand{\SymSpecific}{\mathsf{AEAD\_CHACHA20\_POLY1305}}
\newcommand{\SymCipher}{\mathsf{ChaCha20}}
\newcommand{\SymAuth}{\mathsf{Poly1305}}
\newcommand{\Ptext}{\mathsf{P}}
\newcommand{\Plaintext}{\mathsf{Sym.}\mathbf{P}}
\newcommand{\Ctext}{\mathsf{C}}
\newcommand{\Ciphertext}{\mathsf{Sym.}\mathbf{C}}
\newcommand{\Key}{\mathsf{K}}
\newcommand{\Keyspace}{\mathsf{Sym.}\mathbf{K}}
\newcommand{\TransmitPlaintext}[1]{\Ptext^\enc_{#1}}
\newcommand{\TransmitCiphertext}[1]{\Ctext^\enc_{#1}}
\newcommand{\TransmitKey}[1]{\Key^\enc_{#1}}
\newcommand{\OutCiphertext}{\Ctext^\mathsf{out}}
\newcommand{\Extractor}[1]{\mathcal{E}_{\kern-0.05em{#1}}}
\newcommand{\Adversary}{\mathcal{A}}
\newcommand{\Oracle}{\mathsf{O}}
\newcommand{\CryptoBoxSeal}{\mathsf{crypto\_box\_seal}}

\newcommand{\FFOne}{\mathsf{FF1}}
\newcommand{\FFOneAESAlg}{\mathsf{FF1\mhyphen{}AES256}}
\newcommand{\FFOneAES}[1]{\FFOneAESAlg_{#1}}
\newcommand{\AES}{\mathsf{AES}}

% Key agreement

\newcommand{\KA}[1]{\mathsf{KA}^\mathsf{#1\kern-0.1em}}
\newcommand{\KAPublic}[1]{\KA{#1}\mathsf{.Public}}
\newcommand{\KAPublicPrimeSubgroup}[1]{\KA{#1}\mathsf{.PublicPrimeSubgroup}}
\newcommand{\KAPrivate}[1]{\KA{#1}\mathsf{.Private}}
\newcommand{\KASharedSecret}[1]{\KA{#1}\mathsf{.SharedSecret}}
\newcommand{\KAFormatPrivate}[1]{\KA{#1}\mathsf{.FormatPrivate}}
\newcommand{\KADerivePublic}[1]{\KA{#1}\mathsf{.DerivePublic}}
\newcommand{\KAAgree}[1]{\KA{#1}\mathsf{.Agree}}
\newcommand{\KABase}[1]{\KA{#1}\mathsf{.Base}}

\newcommand{\KASproutCurve}{\mathsf{Curve25519}}
\newcommand{\KASproutCurveMultiply}{\mathsf{Curve25519}}
\newcommand{\KASproutCurveBase}{\bytes{9}}
\newcommand{\KASproutCurveClamp}{\mathsf{clamp_{Curve25519}}}

% KDF

\newcommand{\KDF}[1]{\mathsf{KDF}^\mathsf{#1\kern-0.1em}}
\newcommand{\kdftag}{\mathsf{kdftag}}
\newcommand{\kdfinput}{\mathsf{kdfinput}}

% Notes

\newcommand{\Value}{\mathsf{v}}
\newcommand{\ValueNew}[1]{\Value^\mathsf{new}_{#1}}
\newcommand{\ValueOld}[1]{\Value^\mathsf{old}_{#1}}
\newcommand{\ValueNet}[1]{\Value^\mathsf{net}_{#1}}
\newcommand{\ValueLength}{\ell_{\mathsf{value}}}
\newcommand{\ValueType}{\binaryrange{\ValueLength}}
\newcommand{\SignedValueFieldType}{\range{-2^{63}}{2^{63}-1}}
\newcommand{\SignedValueDifferenceType}{\range{-2^{64}+1}{2^{64}-1}}
\newcommand{\ValueCommitTypeSapling}{\bigrange{-\SignedScalarLimitJ}{\SignedScalarLimitJ}}
\newcommand{\ValueCommitTypeOrchard}{\bigrange{-\SignedScalarLimitP}{\SignedScalarLimitP}}
\newcommand{\ValueCommitRand}{\mathsf{rcv}}
\newcommand{\ValueCommitRandRepr}{{\ValueCommitRand\Repr}}
\newcommand{\ValueCommitRandLength}{\mathsf{\ell_{\ValueCommitRand}}}
\newcommand{\ValueCommitRandOld}[1]{\ValueCommitRand^\mathsf{old}_{#1}}
\newcommand{\ValueCommitRandNew}[1]{\ValueCommitRand^\mathsf{new}_{#1}}
\newcommand{\ValueCommitRandNet}[1]{\ValueCommitRand^\mathsf{net}_{#1}}
\newcommand{\NoteTuple}[1]{\mathbf{n}_{#1}}
\newcommand{\NoteType}[1]{\mathsf{Note}^\mathsf{#1\kern-0.1em}}
\newcommand{\NotePlaintext}[1]{\mathbf{np}_{#1}}
\newcommand{\OutPlaintext}{\mathbf{op}}
\newcommand{\NoteSeedBytes}{\mathsf{rseed}}
\newcommand{\NoteSeedBytesType}{\byteseq{32}}
\newcommand{\NoteCommitRand}{\mathsf{rcm}}
\newcommand{\NoteCommitRandRepr}{{\NoteCommitRand\Repr}}
\newcommand{\NoteCommitRandBytes}{\bytes{\NoteCommitRand}}
\newcommand{\NoteCommitRandLengthSprout}{\mathsf{\ell^{Sprout}_{\NoteCommitRand}}}
\newcommand{\NoteCommitRandOld}[1]{\NoteCommitRand^\mathsf{old}_{#1}}
\newcommand{\NoteCommitRandNew}[1]{\NoteCommitRand^\mathsf{new}_{#1}}
\newcommand{\NoteCommitRandOrSeedBytes}{\notcanopy{\NoteCommitRand}\canopy{\NoteSeedBytes}}
\newcommand{\NoteCommitRandBytesOrSeedBytes}{\notcanopy{\NoteCommitRandBytes}\canopy{\NoteSeedBytes}}
\newcommand{\NoteCommitRandPre}{\mathsf{pre\_rcm}}
\newcommand{\NoteUniqueRand}{\mathsf{\uprho}}
\newcommand{\NoteUniqueRandText}{\texorpdfstring{$\NoteUniqueRand$}{ρ}}
\newcommand{\NoteUniqueRandPoint}{\NoteUniqueRand^{\GroupP}}
\newcommand{\NoteUniqueRandRepr}{{\NoteUniqueRand\Repr}}
\newcommand{\NoteUniqueRandBytes}{\bytes{\NoteUniqueRand}}
\newcommand{\NoteUniqueRandOld}[1]{\NoteUniqueRand^\mathsf{old}_{#1}}
\newcommand{\NoteUniqueRandNew}[1]{\NoteUniqueRand^\mathsf{new}_{#1}}
\newcommand{\NoteUniqueRandTypeOrchard}{\GF{\ParamP{q}}}
\newcommand{\NoteUniquePreRand}{\mathsf{\upvarphi}}
\newcommand{\NoteUniquePreRandLength}{\mathsf{\ell^{Sprout}_{\NoteUniquePreRand}}}
\newcommand{\NoteNullifierRand}{\mathsf{\uppsi}}
\newcommand{\NoteNullifierRandOld}{\mathsf{\uppsi^{old}}}
\newcommand{\NoteNullifierRandNew}{\mathsf{\uppsi^{new}}}
\newcommand{\NoteNullifierRandType}{\GF{\ParamP{q}}}
\newcommand{\NoteNullifierRandPre}{\mathsf{pre\_}\NoteNullifierRand}
\newcommand{\NoteCommitS}{\mathsf{s}}
\newcommand{\CommitIvkRand}{\mathsf{rivk}}
\newcommand{\CommitIvkRandType}{\GF{\ParamP{r}}}
\newcommand{\cv}{\mathsf{cv}}
\newcommand{\cvOld}[1]{\cv^\mathsf{old}_{#1}}
\newcommand{\cvNew}[1]{\cv^\mathsf{new}_{#1}}
\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}}
\newcommand{\cmstar}{\cm_{\kern -0.06em \ast}}
\newcommand{\cmOld}[1]{\cm^\mathsf{old}_{#1}}
\newcommand{\cmNew}[1]{\cm^\mathsf{new}_{#1}}
\newcommand{\snOld}[1]{\mathsf{sn}^\mathsf{old}_{#1}}
\newcommand{\nf}{\mathsf{nf}}
\newcommand{\nfOld}[1]{\nf^\mathsf{old}_{#1}}
\newcommand{\nfOldRepr}[1]{{\MakeRepr{\nf}{\mathsf{old}}}_{#1}}
\newcommand{\enableSpends}{\mathsf{enableSpends}}
\newcommand{\enableOutputs}{\mathsf{enableOutputs}}
\newcommand{\Memo}{\mathsf{memo}}
\newcommand{\MemoByteLength}{512}
\newcommand{\MemoType}{\byteseq{\MemoByteLength}}
\newcommand{\DecryptNoteSprout}{\mathtt{DecryptNoteSprout}}
\newcommand{\ReplacementCharacter}{\textsf{U+FFFD}}
\newcommand{\maybeSapling}{\notnufive{Sapling}}

% Money supply

\newcommand{\MAXMONEY}{\mathsf{MAX\_MONEY}}
\newcommand{\BlockSubsidy}{\mathsf{BlockSubsidy}}
\newcommand{\MinerSubsidy}{\mathsf{MinerSubsidy}}
\newcommand{\FoundersReward}{\mathsf{FoundersReward}}
\newcommand{\FundingStreams}{\mathsf{FundingStreams}}
\newcommand{\fs}{\mathsf{fs}}
\newcommand{\fsNumerator}{\fs\mathsf{.Numerator}}
\newcommand{\fsDenominator}{\fs\mathsf{.Denominator}}
\newcommand{\fsStartHeight}{\fs\mathsf{.StartHeight}}
\newcommand{\fsEndHeight}{\fs\mathsf{.EndHeight}}
\newcommand{\fsValue}{\fs\mathsf{.Value}}
\newcommand{\fsAddressList}{\fs\mathsf{.AddressList}}
\newcommand{\fsAddressIndex}{\fs\mathsf{.AddressIndex}}
\newcommand{\fsNumAddresses}{\fs\mathsf{.NumAddresses}}
\newcommand{\fsRedeemScriptHash}{\fs\mathsf{.RedeemScriptHash}}
\newcommand{\SlowStartInterval}{\mathsf{SlowStartInterval}}
\newcommand{\SlowStartShift}{\mathsf{SlowStartShift}}
\newcommand{\SlowStartRate}{\mathsf{SlowStartRate}}
\newcommand{\PreBlossomHalvingInterval}{\mathsf{\notbeforeblossom{PreBlossom}HalvingInterval}}
\newcommand{\PostBlossomHalvingInterval}{\mathsf{PostBlossomHalvingInterval}}
\newcommand{\MaxBlockSubsidy}{\mathsf{MaxBlockSubsidy}}
\newcommand{\NumFounderAddresses}{\mathsf{NumFounderAddresses}}
\newcommand{\FounderAddressChangeInterval}{\mathsf{FounderAddressChangeInterval}}
\newcommand{\FoundersFraction}{\mathsf{FoundersFraction}}
\newcommand{\FundingStreamAddressChangeInterval}{\mathsf{FundingStreamAddressChangeInterval}}
\newcommand{\FundingStreamAddressPeriod}{\mathsf{FundingStreamAddressPeriod}}
\newcommand{\BlockHeight}{\mathsf{height}}
\newcommand{\FounderAddressAdjustedHeight}{\mathsf{FounderAddressAdjustedHeight}}
\newcommand{\FoundersRewardLastBlockHeight}{\mathsf{FoundersRewardLastBlockHeight}}
\newcommand{\Halving}{\mathsf{Halving}}
\newcommand{\HalvingNum}{\mathsf{halving}}
\newcommand{\HeightForHalving}{\mathsf{HeightForHalving}}
\newcommand{\FounderAddress}{\mathsf{FounderAddress}}
\newcommand{\FounderAddressList}{\mathsf{FounderAddressList}}
\newcommand{\FounderAddressIndex}{\mathsf{FounderAddressIndex}}
\newcommand{\FounderRedeemScriptHash}{\mathsf{FounderRedeemScriptHash}}
\newcommand{\heightBytes}{\mathsf{heightBytes}}

\newcommand{\blockSubsidy}{\term{block subsidy}}
\newcommand{\minerSubsidy}{\term{miner subsidy}}
\newcommand{\foundersReward}{\term{Founders' Reward}}
\newcommand{\slowStartPeriod}{\term{slow-start period}}
\newcommand{\halvingInterval}{\term{halving interval}}
\newcommand{\halving}{\term{halving}}
\newcommand{\halvings}{\terms{halving}}
\newcommand{\utxoSet}{\termandindex{UTXO set}{UTXO (unspent transaction output) set}}
\newcommand{\utxoSetFull}{\term{UTXO (unspent transaction output) set}}
\newcommand{\utxo}{\termandindex{UTXO}{UTXO (unspent transaction output)}}
\newcommand{\utxos}{\termandindex{UTXOs}{UTXO (unspent transaction output)}}
\newcommand{\utxosFull}{\termandindex{UTXOs (unspent transaction outputs)}{UTXO (unspent transaction output)}}
\newcommand{\fundingStream}{\term{funding stream}}
\newcommand{\fundingStreams}{\terms{funding stream}}

\newcommand{\BlossomActivationHeight}{\mathsf{BlossomActivationHeight}}
\newcommand{\IsBlossomActivated}{\mathsf{IsBlossomActivated}}
\newcommand{\CanopyActivationHeight}{\mathsf{CanopyActivationHeight}}
\newcommand{\NUFiveActivationHeight}{\mathsf{NUFiveActivationHeight}}
\newcommand{\ZIPTwoOneTwoGracePeriod}{\mathsf{ZIP212GracePeriod}}

\newcommand{\PoWLimit}{\mathsf{PoWLimit}}
\newcommand{\PoWAveragingWindow}{\mathsf{PoWAveragingWindow}}
\newcommand{\PoWMedianBlockSpan}{\mathsf{PoWMedianBlockSpan}}
\newcommand{\PoWMaxAdjustDown}{\mathsf{PoWMaxAdjustDown}}
\newcommand{\PoWMaxAdjustUp}{\mathsf{PoWMaxAdjustUp}}
\newcommand{\PoWDampingFactor}{\mathsf{PoWDampingFactor}}
\newcommand{\PreBlossomPoWTargetSpacing}{\mathsf{\notbeforeblossom{PreBlossom}PoWTargetSpacing}}
\newcommand{\PostBlossomPoWTargetSpacing}{\mathsf{PostBlossomPoWTargetSpacing}}
\newcommand{\BlossomPoWTargetSpacingRatio}{\mathsf{BlossomPoWTargetSpacingRatio}}
\newcommand{\PoWTargetSpacingFunc}{\mathsf{PoWTargetSpacing}}
\newcommand{\MeanTarget}{\mathsf{MeanTarget}}
\newcommand{\MedianTime}{\mathsf{MedianTime}}
\newcommand{\AveragingWindowTimespan}{\mathsf{AveragingWindowTimespan}}
\newcommand{\MinActualTimespan}{\mathsf{MinActualTimespan}}
\newcommand{\MaxActualTimespan}{\mathsf{MaxActualTimespan}}
\newcommand{\ActualTimespan}{\mathsf{ActualTimespan}}
\newcommand{\ActualTimespanDamped}{\mathsf{ActualTimespanDamped}}
\newcommand{\ActualTimespanBounded}{\mathsf{ActualTimespanBounded}}
\newcommand{\Threshold}{\mathsf{Threshold}}
\newcommand{\ThresholdBits}{\mathsf{ThresholdBits}}

\newcommand{\targetThreshold}{\term{target threshold}}
\newcommand{\targetThresholds}{\terms{target threshold}}

% Signatures

\newcommand{\Sig}{\mathsf{Sig}}
\newcommand{\SigPublic}{\Sig\mathsf{.Public}}
\newcommand{\SigPrivate}{\Sig\mathsf{.Private}}
\newcommand{\SigMessage}{\Sig\mathsf{.Message}}
\newcommand{\SigSignature}{\Sig\mathsf{.Signature}}
\newcommand{\SigGenPrivate}{\Sig\mathsf{.GenPrivate}}
\newcommand{\SigGen}{\Sig\mathsf{.Gen}}
\newcommand{\SigDerivePublic}{\Sig\mathsf{.DerivePublic}}
\newcommand{\SigSign}[1]{\Sig\mathsf{.Sign}_{#1}}
\newcommand{\SigValidate}[1]{\Sig\mathsf{.Validate}_{#1}}
\newcommand{\SigRandom}{\Sig\mathsf{.Random}}
\newcommand{\SigGenRandom}{\Sig\mathsf{.GenRandom}}
\newcommand{\SigRandomizePublic}{\Sig\mathsf{.RandomizePublic}}
\newcommand{\SigRandomizePrivate}{\Sig\mathsf{.RandomizePrivate}}
\newcommand{\SigRandomizerId}{\Zero_{\SigRandom}}
\newcommand{\SigRandomizer}{\alpha}
\newcommand{\Entry}[1]{\mathsf{entry}_{#1}}

\newcommand{\RedDSA}{\mathsf{RedDSA}}
\newcommand{\RedDSAPublic}{\RedDSA\mathsf{.Public}}
\newcommand{\RedDSAPrivate}{\RedDSA\mathsf{.Private}}
\newcommand{\RedDSAMessage}{\RedDSA\mathsf{.Message}}
\newcommand{\RedDSASignature}{\RedDSA\mathsf{.Signature}}
\newcommand{\RedDSAGenPrivate}{\RedDSA\mathsf{.GenPrivate}}
\newcommand{\RedDSADerivePublic}{\RedDSA\mathsf{.DerivePublic}}
\newcommand{\RedDSASign}[1]{\RedDSA\mathsf{.Sign}_{#1}}
\newcommand{\RedDSAValidate}[1]{\RedDSA\mathsf{.Validate}_{#1}}
\newcommand{\RedDSABatchValidate}{\RedDSA\mathsf{.BatchValidate}}
\newcommand{\RedDSABatchEntry}{\RedDSA\mathsf{.BatchEntry}}
\newcommand{\RedDSARandom}{\RedDSA\mathsf{.Random}}
\newcommand{\RedDSAGenRandom}{\RedDSA\mathsf{.GenRandom}}
\newcommand{\RedDSARandomizePublic}{\RedDSA\mathsf{.RandomizePublic}}
\newcommand{\RedDSARandomizePrivate}{\RedDSA\mathsf{.RandomizePrivate}}
\newcommand{\RedDSARandomizerId}{\Zero_{\RedDSARandom}}
\newcommand{\RedDSARandomizer}{\alpha}
\newcommand{\RedDSASigR}[1]{R_{#1}}
\newcommand{\RedDSASigS}[1]{S_{#1}}
\newcommand{\RedDSAReprR}[1]{\bytes{\RedDSASigR{#1}}}
\newcommand{\RedDSAReprS}[1]{\bytes{\RedDSASigS{#1}}}
\newcommand{\RedDSASigc}[1]{c_{#1}}
\newcommand{\RedDSAHash}{\mathsf{H}}
\newcommand{\RedDSAHashToScalar}{\RedDSAHash^{\circledast}}
\newcommand{\RedDSAHashLength}{\ell_{\RedDSAHash}}
\newcommand{\RedDSAText}{\texorpdfstring{$\RedDSA$}{RedDSA}}
\newcommand{\RedJubjub}{\mathsf{RedJubjub}}
\newcommand{\RedJubjubText}{\texorpdfstring{$\RedJubjub$}{RedJubjub}}
\newcommand{\RedJubjubHashName}{\BlakeTwob{512}}
\newcommand{\RedPallas}{\mathsf{RedPallas}}
\newcommand{\RedPallasText}{\texorpdfstring{$\RedPallas$}{RedPallas}}
\newcommand{\RedPallasHashName}{\BlakeTwob{512}}

\newcommand{\EdSpecific}{\termsf{Ed25519}}
\newcommand{\EdSpecificAlg}{\mathsf{Ed25519}}
\newcommand{\GroupEdSpecific}{\mathsf{Ed25519}}
\newcommand{\EdSpecificText}{\texorpdfstring{$\EdSpecificAlg$}{Ed25519}}
\newcommand{\EdDSASigR}[1]{R_{#1}}
\newcommand{\EdDSASigS}[1]{S_{#1}}
\newcommand{\EdDSASigA}[1]{A_{#1}}
\newcommand{\EdDSAReprR}[1]{\bytes{\EdDSASigR{#1}}}
\newcommand{\EdDSAReprS}[1]{\bytes{\EdDSASigS{#1}}}
\newcommand{\EdDSAReprA}[1]{\bytes{\EdDSASigA{#1}}}
\newcommand{\EdDSASigc}[1]{c_{#1}}
\newcommand{\EdDSABase}{B}
\newcommand{\EdSpecificPublic}{\EdSpecificAlg\mathsf{.Public}}
\newcommand{\EdSpecificPrivate}{\EdSpecificAlg\mathsf{.Private}}
\newcommand{\EdSpecificMessage}{\EdSpecificAlg\mathsf{.Message}}
\newcommand{\EdSpecificSignature}{\EdSpecificAlg\mathsf{.Signature}}
\newcommand{\EdSpecificBatchValidate}{\EdSpecificAlg\mathsf{.BatchValidate}}
\newcommand{\EdSpecificBatchEntry}{\EdSpecificAlg\mathsf{.BatchEntry}}
\newcommand{\PreCanopyExcludedPointEncodings}{\mathsf{PreCanopyExcludedPointEncodings}}
\newcommand{\reprBytesEdSpecific}{\reprBytes_{\GroupEdSpecific}}
\newcommand{\abstBytesEdSpecific}{\abstBytes_{\GroupEdSpecific}}
\newcommand{\ReprEdSpecificBytes}{\byteseq{32}}

\newcommand{\ECDSA}{\termsf{ECDSA}}

\newcommand{\JoinSplitSig}{\mathsf{JoinSplitSig}}
\newcommand{\JoinSplitSigPublic}{\JoinSplitSig\mathsf{.Public}}
\newcommand{\JoinSplitSigPrivate}{\JoinSplitSig\mathsf{.Private}}
\newcommand{\JoinSplitSigMessage}{\JoinSplitSig\mathsf{.Message}}
\newcommand{\JoinSplitSigSignature}{\JoinSplitSig\mathsf{.Signature}}
\newcommand{\JoinSplitSigGenPrivate}{\JoinSplitSig\mathsf{.GenPrivate}}
\newcommand{\JoinSplitSigDerivePublic}{\JoinSplitSig\mathsf{.DerivePublic}}
\newcommand{\JoinSplitSigSign}[1]{\JoinSplitSig\mathsf{.Sign}_{#1}}
\newcommand{\JoinSplitSigValidate}[1]{\JoinSplitSig\mathsf{.Validate}_{#1}}

\newcommand{\SpendAuthSig}[1]{\mathsf{SpendAuthSig}^\mathsf{#1\kern-0.1em}}
\newcommand{\SpendAuthSigPublic}[1]{\SpendAuthSig{#1}\mathsf{.Public}}
\newcommand{\SpendAuthSigPrivate}[1]{\SpendAuthSig{#1}\mathsf{.Private}}
\newcommand{\SpendAuthSigMessage}[1]{\SpendAuthSig{#1}\mathsf{.Message}}
\newcommand{\SpendAuthSigSignature}[1]{\SpendAuthSig{#1}\mathsf{.Signature}}
\newcommand{\SpendAuthSigGenPrivate}[1]{\SpendAuthSig{#1}\mathsf{.GenPrivate}}
\newcommand{\SpendAuthSigDerivePublic}[1]{\SpendAuthSig{#1}\mathsf{.DerivePublic}}
\newcommand{\SpendAuthSigSign}[2]{\SpendAuthSig{#1}\mathsf{.Sign}_{#2}}
\newcommand{\SpendAuthSigValidate}[2]{\SpendAuthSig{#1}\mathsf{.Validate}_{#2}}
\newcommand{\SpendAuthSigRandom}[1]{\SpendAuthSig{#1}\mathsf{.Random}}
\newcommand{\SpendAuthSigGenRandom}[1]{\SpendAuthSig{#1}\mathsf{.GenRandom}}
\newcommand{\SpendAuthSigRandomizePublic}[1]{\SpendAuthSig{#1}\mathsf{.RandomizePublic}}
\newcommand{\SpendAuthSigRandomizePrivate}[1]{\SpendAuthSig{#1}\mathsf{.RandomizePrivate}}
\newcommand{\SpendAuthSigRandomizerId}[1]{\SpendAuthSig{#1}\mathsf{.Id}}
\newcommand{\SpendAuthSigRandomizer}{\alpha}
\newcommand{\spendAuthSig}{\mathsf{spendAuthSig}}

\newcommand{\BindingSig}[1]{\mathsf{BindingSig}^\mathsf{#1\kern-0.1em}}
\newcommand{\BindingSigPublic}[1]{\BindingSig{#1}\mathsf{.Public}}
\newcommand{\BindingSigPrivate}[1]{\BindingSig{#1}\mathsf{.Private}}
\newcommand{\BindingSigMessage}[1]{\BindingSig{#1}\mathsf{.Message}}
\newcommand{\BindingSigSignature}[1]{\BindingSig{#1}\mathsf{.Signature}}
\newcommand{\BindingSigGenPrivate}[1]{\BindingSig{#1}\mathsf{.GenPrivate}}
\newcommand{\BindingSigDerivePublic}[1]{\BindingSig{#1}\mathsf{.DerivePublic}}
\newcommand{\BindingSigSign}[2]{\BindingSig{#1}\mathsf{.Sign}_{#2}}
\newcommand{\BindingSigValidate}[2]{\BindingSig{#1}\mathsf{.Validate}_{#2}}
\newcommand{\BindingPublic}[1]{\mathsf{bvk}^\mathsf{#1}}
\newcommand{\BindingPrivate}[1]{\mathsf{bsk}^\mathsf{#1}}

\newcommand{\RandomSeedLength}{\mathsf{\ell_{Seed}}}
\newcommand{\RandomSeedType}{\bitseq{\mathsf{\ell_{Seed}}}}
\newcommand{\pksig}{\mathsf{pk_{sig}}}
\newcommand{\sk}{\mathsf{sk}}
\newcommand{\hSigInput}{\mathsf{hSigInput}}
\newcommand{\crhInput}{\mathsf{crhInput}}
\newcommand{\ockInput}{\mathsf{ockInput}}
\newcommand{\dataToBeSigned}{\mathsf{dataToBeSigned}}
\newcommand{\vBalance}[1]{\mathsf{v^{balance#1}}}
\newcommand{\vBad}{\mathsf{v^{bad}}}
\newcommand{\vSum}{\mathsf{v^{*}}}
\newcommand{\OracleNewAddress}{\Oracle^{\mathsf{NewAddress}}}
\newcommand{\OracleDH}{\Oracle^{\mathsf{DH}}}

% Merkle tree

\newcommand{\MerkleDepth}[1]{\mathsf{MerkleDepth}^\mathsf{#1\kern-0.1em}}
\newcommand{\MerkleNode}[2]{\mathsf{M}^\mathsf{#1}_{#2}}
\newcommand{\MerkleSibling}{\mathsf{sibling}}
\newcommand{\MerkleCRH}[1]{\mathsf{MerkleCRH}^\mathsf{#1\kern-0.1em}}
\newcommand{\MerkleHashLength}[1]{\mathsf{\ell}^\mathsf{#1\vphantom{p}}_\mathsf{Merkle}}
\newcommand{\MerkleHash}[1]{\bitseq{\MerkleHashLength{#1}}}
\newcommand{\MerkleHashOrchard}{\range{0}{\ParamP{q}-1}}
\newcommand{\MerkleLayer}[1]{\range{0}{\MerkleDepth{#1}-1}}
\newcommand{\hash}{\mathsf{hash}}
\newcommand{\layerInput}{\mathsf{layer}}
\newcommand{\layerRepr}{{l\Repr}}
\newcommand{\leftInput}{\mathsf{left}}
\newcommand{\leftRepr}{{\leftInput\Repr}}
\newcommand{\rightInput}{\mathsf{right}}
\newcommand{\rightRepr}{{\rightInput\Repr}}

% Transactions

\newcommand{\headerField}{\mathtt{header}}
\newcommand{\fOverwintered}{\mathtt{fOverwintered}}
\newcommand{\versionField}{\mathtt{version}}
\newcommand{\effectiveVersion}{\mathsf{effectiveVersion}}
\newcommand{\nVersionGroupId}{\mathtt{nVersionGroupId}}
\newcommand{\nConsensusBranchId}{\mathtt{nConsensusBranchId}}
\newcommand{\txInCount}{\mathtt{tx\_in\_count}}
\newcommand{\txIn}{\mathtt{tx\_in}}
\newcommand{\prevoutField}{\mathtt{prevout}}
\newcommand{\txOutCount}{\mathtt{tx\_out\_count}}
\newcommand{\txOut}{\mathtt{tx\_out}}
\newcommand{\lockTime}{\mathtt{lock\_time}}
\newcommand{\nExpiryHeight}{\mathtt{nExpiryHeight}}
\newcommand{\nJoinSplit}{\mathtt{nJoinSplit}}
\newcommand{\vJoinSplit}{\mathtt{vJoinSplit}}
\newcommand{\valueBalance}[1]{\mathtt{valueBalance#1}}
\newcommand{\nShieldedSpend}{\mathtt{nShieldedSpend}}
\newcommand{\vShieldedSpend}{\mathtt{vShieldedSpend}}
\newcommand{\nShieldedOutput}{\mathtt{nShieldedOutput}}
\newcommand{\vShieldedOutput}{\mathtt{vShieldedOutput}}
\newcommand{\nSpendsSapling}{\mathtt{nSpendsSapling}}
\newcommand{\vSpendsSapling}{\mathtt{vSpendsSapling}}
\newcommand{\nOutputsSapling}{\mathtt{nOutputsSapling}}
\newcommand{\vOutputsSapling}{\mathtt{vOutputsSapling}}
\newcommand{\vSpendProofsSapling}{\mathtt{vSpendProofsSapling}}
\newcommand{\vSpendAuthSigs}[1]{\mathtt{vSpendAuthSigs{#1}}}
\newcommand{\vOutputProofsSapling}{\mathtt{vOutputProofsSapling}}
\newcommand{\nActionsOrchard}{\mathtt{nActionsOrchard}}
\newcommand{\vActionsOrchard}{\mathtt{vActionsOrchard}}
\newcommand{\flagsOrchard}{\mathtt{flagsOrchard}}
\newcommand{\enableSpendsOrchard}{\mathtt{enableSpendsOrchard}}
\newcommand{\enableOutputsOrchard}{\mathtt{enableOutputsOrchard}}
\newcommand{\sizeProofsOrchard}{\mathtt{sizeProofsOrchard}}
\newcommand{\proofsOrchard}{\mathtt{proofsOrchard}}
\newcommand{\vpubOldField}{\mathtt{vpub\_old}}
\newcommand{\vpubNewField}{\mathtt{vpub\_new}}
\newcommand{\anchorField}[1]{\mathtt{anchor#1}}
\newcommand{\joinSplitSig}{\mathtt{joinSplitSig}}
\newcommand{\joinSplitPrivKey}{\mathtt{joinSplitPrivKey}}
\newcommand{\joinSplitPubKey}{\mathtt{joinSplitPubKey}}
\newcommand{\bindingSig}[1]{\mathtt{bindingSig#1}}
\newcommand{\nullifierField}{\mathtt{nullifier}}
\newcommand{\nullifiersField}{\mathtt{nullifiers}}
\newcommand{\rkField}{\mathtt{rk}}
\newcommand{\cvField}{\mathtt{cv}}
\newcommand{\cmstarField}{\mathtt{cm*}}
\newcommand{\cmuField}{\mathtt{cmu}}
\newcommand{\cmxField}{\mathtt{cmx}}
\newcommand{\commitmentsField}{\mathtt{commitments}}
\newcommand{\ephemeralKey}{\mathtt{ephemeralKey}}
\newcommand{\encCiphertext}{\mathtt{encCiphertext}}
\newcommand{\encCiphertexts}{\mathtt{encCiphertexts}}
\newcommand{\outCiphertext}{\mathtt{outCiphertext}}
\newcommand{\randomSeed}{\mathtt{randomSeed}}
\newcommand{\spendAuthSigField}{\mathtt{spendAuthSig}}
\newcommand{\Varies}{\textit{\!Varies}}
\newcommand{\heading}[1]{\multicolumn{1}{c|}{#1}}
\newcommand{\type}[1]{\texttt{#1}}
\newcommand{\overwintertype}[1]{\textcolor{\overwintercolor}{\type{#1}}}
\newcommand{\saplingtype}[1]{\textcolor{\saplingcolor}{\type{#1}}}
\newcommand{\nufivetype}[1]{\textcolor{\nufivecolor}{\type{#1}}}
\newcommand{\typecodeField}{\mathtt{typecode}}
\newcommand{\lengthField}{\mathtt{length}}
\newcommand{\addrField}{\mathtt{addr}}

% Tx hashing and scripts

\newcommand{\sighashAlgorithm}{\term{SIGHASH algorithm}}
\newcommand{\sighashTxHash}{\term{SIGHASH transaction hash}}
\newcommand{\sighashTxHashes}{\termes{SIGHASH transaction hash}}
\newcommand{\sighashType}{\term{SIGHASH type}}
\newcommand{\sighashTypes}{\terms{SIGHASH type}}
\newcommand{\SIGHASHALL}{\mathsf{SIGHASH\_ALL}}
\newcommand{\SIGHASHSINGLE}{\mathsf{SIGHASH\_SINGLE}}
\newcommand{\SigHash}{\mathsf{SigHash}}
\newcommand{\scriptSig}{\mathtt{scriptSig}}
\newcommand{\scriptPubKey}{\mathtt{scriptPubKey}}
\newcommand{\ScriptOP}[1]{\texttt{OP\_{#1}}}

% Equihash and block headers

\newcommand{\Equihash}{\term{Equihash}}
\newcommand{\validEquihashSolution}{\term{valid Equihash solution}}
\newcommand{\powtag}{\mathsf{powtag}}
\newcommand{\powheader}{\mathsf{powheader}}
\newcommand{\powcount}{\mathsf{powcount}}
\newcommand{\nVersion}{\mathtt{nVersion}}
\newcommand{\hashPrevBlock}{\mathtt{hashPrevBlock}}
\newcommand{\hashMerkleRoot}{\mathtt{hashMerkleRoot}}
\newcommand{\hashReserved}{\mathtt{hashReserved}}
\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}}
\newcommand{\nBits}{\mathsf{nBits}}
\newcommand{\nNonce}{\mathtt{nNonce}}
\newcommand{\solutionSize}{\mathtt{solutionSize}}
\newcommand{\solution}{\mathtt{solution}}

% Proving system

\newcommand{\ZK}{\mathsf{ZK}}
\newcommand{\ZKProvingKey}{\mathsf{ZK.ProvingKey}}
\newcommand{\ZKVerifyingKey}{\mathsf{ZK.VerifyingKey}}
\newcommand{\pk}{\mathsf{pk}}
\newcommand{\vk}{\mathsf{vk}}
\newcommand{\vkBytes}[1]{\bytes{\vk_{#1}}}
\newcommand{\ZKGen}{\mathsf{ZK.Gen}}
\newcommand{\ZKProof}{\mathsf{ZK.Proof}}
\newcommand{\ZKPrimary}{\mathsf{ZK.PrimaryInput}}
\newcommand{\ZKAuxiliary}{\mathsf{ZK.AuxiliaryInput}}
\newcommand{\ZKSatisfying}{\mathsf{ZK.SatisfyingInputs}}
\newcommand{\ZKProve}[1]{\mathsf{ZK.}\mathtt{Prove}_{#1}}
\newcommand{\ZKVerify}[1]{\mathsf{ZK.}\mathtt{Verify}_{#1}}
\newcommand{\Simulator}{\mathcal{S}}
\newcommand{\Distinguisher}{\mathcal{D}}
\newcommand{\JoinSplit}{\mathsf{ZKJoinSplit}}
\newcommand{\JoinSplitVerify}{\JoinSplit\mathsf{.Verify}}
\newcommand{\JoinSplitProve}{\JoinSplit\mathsf{.Prove}}
\newcommand{\JoinSplitProof}{\JoinSplit\mathsf{.Proof}}
\newcommand{\Spend}{\mathsf{ZKSpend}}
\newcommand{\SpendVerify}{\Spend\mathsf{.Verify}}
\newcommand{\SpendProve}{\Spend\mathsf{.Prove}}
\newcommand{\SpendProof}{\Spend\mathsf{.Proof}}
\newcommand{\Output}{\mathsf{ZKOutput}}
\newcommand{\OutputVerify}{\Output\mathsf{.Verify}}
\newcommand{\OutputProve}{\Output\mathsf{.Prove}}
\newcommand{\OutputProof}{\Output\mathsf{.Proof}}
\newcommand{\Action}{\mathsf{ZKAction}}
\newcommand{\ActionVerify}{\Action\mathsf{.Verify}}
\newcommand{\ActionProve}{\Action\mathsf{.Prove}}
\newcommand{\ActionProof}{\Action\mathsf{.Proof}}
\newcommand{\Proof}[1]{\pi_{\kern-0.1em{#1}}}
\newcommand{\ProofJoinSplit}{\pi_\JoinSplit}
\newcommand{\ProofSpend}{\pi_\Spend}
\newcommand{\ProofOutput}{\pi_\Output}
\newcommand{\ProofAction}{\pi_\Action}
\newcommand{\zkproof}{\mathtt{zkproof}}
\newcommand{\POUR}{\texttt{POUR}}
\newcommand{\Prob}[2]{\mathrm{Pr}\scalebox{0.88}{\ensuremath{
  \left[\!\!\begin{array}{c}#1\end{array} \middle| \begin{array}{l}#2\end{array}\!\!\right]
}}}
\newcommand{\BNImpl}{\mathtt{ALT\_BN128}}

% JoinSplit

\newcommand{\hSig}{\mathsf{h_{Sig}}}
\newcommand{\hSigText}{\texorpdfstring{$\hSig$}{hSig}}
\newcommand{\h}[1]{\mathsf{h_{\mathnormal{#1}}}}
\newcommand{\rmN}{\mathrm{N}}
\newcommand{\NOld}{\rmN^\mathsf{old}}
\newcommand{\NNew}{\rmN^\mathsf{new}}
\newcommand{\allN}[1]{\oneto{\rmN^\mathsf{#1}}}
\newcommand{\allOld}{\allN{old}}
\newcommand{\allNew}{\allN{new}}
\newcommand{\setofOld}{\setof{\allOld}}
\newcommand{\setofNew}{\setof{\allNew}}
\newcommand{\vmacs}{\mathtt{vmacs}}
\newcommand{\vpubOld}{\mathsf{v_{pub}^{old}}}
\newcommand{\vpubNew}{\mathsf{v_{pub}^{new}}}
\newcommand{\nOld}[1]{\NoteTuple{#1}^\mathsf{old}}
\newcommand{\nNew}[1]{\NoteTuple{#1}^\mathsf{new}}
\newcommand{\vOld}[1]{\mathsf{v}_{#1}^\mathsf{old}}
\newcommand{\vNew}[1]{\mathsf{v}_{#1}^\mathsf{new}}
\newcommand{\vNet}[1]{\mathsf{v}_{#1}^\mathsf{net}}
\newcommand{\RandomSeed}{\mathsf{randomSeed}}
\newcommand{\rt}[1]{\mathsf{rt}^\mathsf{#1}}
\newcommand{\TreePath}[1]{\mathsf{path}_{#1}}
\newcommand{\Receive}{\mathsf{Receive}}
\newcommand{\EnforceMerklePath}[1]{\mathsf{enforceMerklePath}_{~\!\!#1}}

% Elliptic curve stuff

\newcommand{\Curve}{E}
\newcommand{\Zero}{\mathcal{O}}
\newcommand{\Generator}{\mathcal{P}}
\newcommand{\Selectu}{\scalebox{1.53}{$u$}}
\newcommand{\Selectv}{\scalebox{1.53}{$\varv$}}
\newcommand{\Selectx}{\scalebox{1.53}{$x$}}
\newcommand{\Selecty}{\scalebox{1.53}{$y$}}
\newcommand{\subgroupr}{(\kern-0.075emr\kern-0.075em)}
\newcommand{\Extract}{\mathsf{Extract}}
\newcommand{\GroupHash}{\mathsf{GroupHash}}
\newcommand{\FindGroupHash}{\mathsf{FindGroupHash}}
\newcommand{\Accum}[1]{\mathsf{Accum}_{#1}}

\newcommand{\bbPair}{\mbox{$\mathbb{P}\kern -0.1em\overlap{0.0001em}{\scalebox{0.7}{$\mathbb{AIR}$}}$}}
\newcommand{\sbbPair}{\scalebox{0.7}{\bbPair}}
\newcommand{\ParamPair}[1]{{{#1}_{\sbbPair}}}
\newcommand{\ParamPairexp}[2]{{{#1}_{\sbbPair\!}}^{#2}}
\newcommand{\GroupPair}[1]{\bbPair_{#1}}
\newcommand{\GroupPairstar}[1]{\GroupPair{#1}^{\ast}}
\newcommand{\SubgroupPair}[1]{\GroupPair{#1}^{\subgroupr}}
\newcommand{\SubgroupPairstar}[1]{\GroupPair{#1}^{\subgroupr\ast}}
\newcommand{\SubgroupReprPair}{\MakeRepr{\GroupPair{}}{\subgroupr}}
\newcommand{\CurvePair}[1]{\Curve_{\GroupPair{#1}}}
\newcommand{\ZeroPair}[1]{\Zero_{\GroupPair{#1}}}
\newcommand{\OnePair}{\ParamPair{\mathbf{1}}}
\newcommand{\GenPair}[1]{\Generator_{\GroupPair{#1}}}
\newcommand{\ellPair}[1]{\ell_{\GroupPair{#1}}}
\newcommand{\reprPair}[1]{\repr_{\GroupPair{#1}}}
\newcommand{\abstPair}[1]{\abst_{\GroupPair{#1}}}
\newcommand{\PairingPair}{\ParamPair{\hat{e}}}

\newcommand{\ParamG}[1]{{{#1}_\mathbb{G}}}
\newcommand{\ParamGexp}[2]{{{#1}_\mathbb{G}\!}^{#2}}
\newcommand{\GroupG}[1]{\mathbb{G}_{#1}}
\newcommand{\GroupGstar}[1]{\GroupG{#1}^{\ast}}
\newcommand{\SubgroupG}[1]{\GroupG{#1}^{\subgroupr}}
\newcommand{\SubgroupGstar}[1]{\GroupG{#1}^{\subgroupr\ast}}
\newcommand{\SubgroupReprG}{\MakeRepr{\GroupG{}}{\subgroupr}}
\newcommand{\CurveG}[1]{\Curve_{\GroupG{#1}}}
\newcommand{\ZeroG}[1]{\Zero_{\GroupG{#1}}}
\newcommand{\OneG}{\ParamG{\mathbf{1}}}
\newcommand{\GenG}[1]{\Generator_{\GroupG{#1}}}
\newcommand{\ellG}[1]{\ell_{\GroupG{#1}}}
\newcommand{\ReprG}[1]{\bitseq{\ellG{#1}}}
\newcommand{\reprG}[1]{\repr_{\GroupG{#1}}}
\newcommand{\abstG}[1]{\abst_{\GroupG{#1}}}
\newcommand{\PairingG}{\ParamG{\hat{e}}}

\newcommand{\ExtractG}{\Extract_{\SubgroupG{}}}
\newcommand{\SubgroupGHash}[1]{\GroupHash^{\SubgroupG{}}_{#1}}
\newcommand{\SubgroupGHashURSType}{\SubgroupGHash{}\mathsf{.URSType}}
\newcommand{\SubgroupGHashInput}{\SubgroupGHash{}\mathsf{.Input}}
\newcommand{\URS}{\mathsf{URS}}
\newcommand{\GroupGHash}{\GroupHash^{\GroupG{}}}
\newcommand{\GroupGHashURSType}{\GroupGHash\mathsf{.URSType}}
\newcommand{\GroupGHashInput}{\GroupGHash\mathsf{.Input}}

\newcommand{\ParamIsoG}[1]{{{#1}_{\GroupIsoG}}}
\newcommand{\ParamIsoGexp}[2]{{{#1}_{\GroupIsoG\!}^{#2}}}
\newcommand{\GroupIsoG}{\mathsf{iso}\mhyphen\kern-0.05em\mathbb{G}}
\newcommand{\GroupIsoGstar}{\GroupIsoG^{\ast}}
\newcommand{\CurveIsoG}{\Curve_{\GroupIsoG}}
\newcommand{\ZeroIsoG}{\Zero_{\GroupIsoG}}
\newcommand{\IsoMapG}{\mathsf{iso\_map}^{\GroupG{}}}
\newcommand{\IsoConstG}[1]{\mathcal{C}^{\GroupG{}}_{#1}}

\newcommand{\ParamS}[1]{{{#1}_\mathbb{\hskip 0.03em S}}}
\newcommand{\ParamSexp}[2]{{{#1}_\mathbb{\hskip 0.03em S}\!}^{#2}}
\newcommand{\GroupS}[1]{\mathbb{S}_{#1}}
\newcommand{\GroupSstar}[1]{\GroupS{#1}^{\ast}}
\newcommand{\SubgroupS}[1]{\GroupS{#1}^{\subgroupr}}
\newcommand{\SubgroupSstar}[1]{\GroupS{#1}^{\subgroupr\ast}}
\newcommand{\SubgroupReprS}{\MakeRepr{\GroupS{}}{\subgroupr}}
\newcommand{\CurveS}[1]{\Curve_{\GroupS{#1}}}
\newcommand{\ZeroS}[1]{\Zero_{\GroupS{#1}}}
\newcommand{\OneS}{\ParamS{\mathbf{1}}}
\newcommand{\GenS}[1]{\Generator_{\GroupS{#1}}}
\newcommand{\ellS}[1]{\ell_{\GroupS{#1}}}
\newcommand{\reprS}[1]{\repr_{\GroupS{#1}}}
\newcommand{\abstS}[1]{\abst_{\GroupS{#1}}}
\newcommand{\PairingS}{\ParamS{\hat{e}}}
\newcommand{\MillerLoopS}{\ParamS{\mathsf{MillerLoop}}}
\newcommand{\FinalExpS}{\ParamS{\mathsf{FinalExp}}}
\newcommand{\GrothS}{\mathsf{Groth16}_{\kern 0.05em\mathbb{S}}}
\newcommand{\GrothSProof}{\GrothS\mathsf{.Proof}}
\newcommand{\GrothSPrimaryInput}{\GrothS\mathsf{.PrimaryInput}}
\newcommand{\GrothSBatchEntry}{\GrothS\mathsf{.BatchEntry}}
\newcommand{\GrothSBatchVerify}{\GrothS\mathsf{.BatchVerify}}

\newcommand{\ParamJ}[1]{{{#1}_\mathbb{\hskip 0.01em J}}}
\newcommand{\ParamJexp}[2]{{{#1}_\mathbb{\hskip 0.01em J}\!}^{#2}}
\newcommand{\GroupJ}{\mathbb{J}}
\newcommand{\SubgroupJ}{\GroupJ^{\subgroupr}}
\newcommand{\SubgroupJstar}{\GroupJ^{\subgroupr\ast}}
\newcommand{\SubgroupReprJ}{\MakeRepr{\GroupJ}{\subgroupr}}
\newcommand{\CurveJ}{\Curve_{\GroupJ}}
\newcommand{\ZeroJ}{\Zero_{\GroupJ}}
\newcommand{\GenJ}{\Generator_{\GroupJ}}
\newcommand{\ellJ}{\ell_{\GroupJ}}
\newcommand{\ReprJ}{\bitseq{\ellJ}}
\newcommand{\ReprJBytes}{\byteseq{\ellJ/8}}
\newcommand{\reprJ}{\repr_{\GroupJ}}
\newcommand{\reprMaybeJ}{\notnufive{\repr_{\GroupJ}}\nufive{\repr}}
\newcommand{\abstJ}{\abst_{\GroupJ}}
\newcommand{\abstMaybeJ}{\notnufive{\abst_{\GroupJ}}\nufive{\abst}}
\newcommand{\SignedScalarLimitJ}{\frac{\ParamJ{r}-1}{2}}

\newcommand{\ExtractJ}{\Extract_{\SubgroupJ}}
\newcommand{\GroupJHash}[1]{\GroupHash^{\SubgroupJstar}_{#1}}
\newcommand{\GroupJHashURSType}{\GroupJHash{}\mathsf{.URSType}}
\newcommand{\GroupJHashInput}{\GroupJHash{}\mathsf{.Input}}
\newcommand{\HashOutput}{\bytes{H}}
\newcommand{\FindGroupJHash}{\FindGroupHash^{\SubgroupJstar}}

\newcommand{\MontCurve}{\mathbb{M}}
\newcommand{\ParamM}[1]{{{#1}_\mathbb{\hskip 0.03em M}}}
\newcommand{\ParamMexp}[2]{{{#1}_\mathbb{\hskip 0.03em M}\!}^{#2}}

\newcommand{\ParamP}[1]{{{#1}_\mathbb{\hskip 0.01em P}}}
\newcommand{\ParamPexp}[2]{{{#1}_\mathbb{\hskip 0.01em P}\!}^{#2}}
\newcommand{\GroupP}{\mathbb{P}}
\newcommand{\GroupPstar}{\GroupP^{\ast}}
\newcommand{\CurveP}{\Curve_{\GroupP}}
\newcommand{\ZeroP}{\Zero_{\GroupP}}
\newcommand{\ellP}{\ell_{\GroupP}}
\newcommand{\ReprP}{\bitseq{\ellP}}
\newcommand{\ReprPBytes}{\byteseq{\ellP/8}}
\newcommand{\reprP}{\repr_{\GroupP}}
\newcommand{\abstP}{\abst_{\GroupP}}
\newcommand{\SignedScalarLimitP}{\frac{\ParamP{r}-1}{2}}

\newcommand{\ParamIsoP}[1]{{{#1}_{\GroupIsoP}}}
\newcommand{\ParamIsoPexp}[2]{{{#1}_{\GroupIsoP\!}^{#2}}}
\newcommand{\GroupIsoP}{\mathsf{iso}\mhyphen\kern-0.05em\mathbb{P}}
\newcommand{\GroupIsoPstar}{\GroupIsoP^{\ast}}
\newcommand{\CurveIsoP}{\Curve_{\GroupIsoP}}
\newcommand{\ZeroIsoP}{\Zero_{\GroupIsoP}}
\newcommand{\IsoMapP}{\mathsf{iso\_map}^{\GroupP}}
\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}}

\newcommand{\ParamV}[1]{{{#1}_\mathbb{\hskip 0.01em V}}}
\newcommand{\ParamVexp}[2]{{{#1}_\mathbb{\hskip 0.01em V}\!}^{#2}}
\newcommand{\GroupV}{\mathbb{V}}
\newcommand{\GroupVstar}{\GroupV^{\ast}}
\newcommand{\CurveV}{\Curve_{\GroupV}}
\newcommand{\ZeroV}{\Zero_{\GroupV}}
\newcommand{\ellV}{\ell_{\GroupV}}
\newcommand{\ReprV}{\bitseq{\ellV}}
\newcommand{\ReprVBytes}{\byteseq{\ellV/8}}
\newcommand{\reprV}{\repr_{\GroupV}}
\newcommand{\abstV}{\abst_{\GroupV}}
\newcommand{\SignedScalarLimitV}{\frac{\ParamV{r}-1}{2}}

\newcommand{\ParamIsoV}[1]{{{#1}_{\GroupIsoV}}}
\newcommand{\ParamIsoVexp}[2]{{{#1}_{\GroupIsoV\!}^{#2}}}
\newcommand{\GroupIsoV}{\mathsf{iso}\mhyphen\kern-0.15em\mathbb{V}}
\newcommand{\GroupIsoVstar}{\GroupIsoV^{\ast}}
\newcommand{\CurveIsoV}{\Curve_{\GroupIsoV}}
\newcommand{\ZeroIsoV}{\Zero_{\GroupIsoV}}
\newcommand{\IsoMapV}{\mathsf{iso\_map}^{\GroupV}}
\newcommand{\IsoConstV}[1]{\mathcal{C}^{\GroupV}_{#1}}

\newcommand{\ExtractV}{\Extract_{\GroupV}}
\newcommand{\GroupVHash}{\GroupHash^{\GroupV}}
\newcommand{\GroupVHashInput}{\GroupVHash\mathsf{.Input}}
\newcommand{\GroupVHashURSType}{\GroupVHash\mathsf{.URSType}}

\newcommand{\ctEdwards}[1]{E_{\kern 0.03em\mathsf{ctEdwards}({#1})}}
\newcommand{\Edwards}[1]{E_{\kern 0.03em\mathsf{Edwards}({#1})}} % only in history
\newcommand{\Montgomery}[1]{E_{\mathsf{Mont}({#1})}}
\newcommand{\ShortWeierstrass}[1]{E_{\mathsf{SW}({#1})}}

\newcommand{\curveNameG}{\ParamG{\mathsf{curveName}}}
\newcommand{\sqrtratioG}{\mathsf{sqrt\_ratio}_{\GF{\ParamG{q}}}\!}
\newcommand{\num}{\mathsf{num}}
\newcommand{\xdiv}{\mathsf{div}}
\newcommand{\expandmessage}{\mathsf{expand\_message}}
\newcommand{\expandmessagexmd}{\mathsf{expand\_message\_xmd}}
\newcommand{\hashtofield}{\mathsf{hash\_to\_field}}
\newcommand{\hashtocurve}{\mathsf{hash\_to\_curve}}
\newcommand{\maptocurvesimpleswuIsoG}{\mathsf{map\_to\_curve\_simple\_swu}^{\GroupIsoG}}
\newcommand{\clearcofactor}{\mathsf{clear\_cofactor}}

\newcommand{\pack}{\mathsf{pack}}

\newcommand{\Acc}{\mathsf{Acc}}
\newcommand{\Base}{\mathsf{Base}}
\newcommand{\Addend}{\mathsf{Addend}}
\newcommand{\Sum}{\mathsf{Sum}}
\newcommand{\Ainv}{A_{\mathsf{inv}}}
\newcommand{\Inv}[1]{{#1}_{\mathsf{inv}}}

\newcommand{\repr}{\mathsf{repr}}
\newcommand{\abst}{\mathsf{abst}}
\newcommand{\reprBytes}{\mathsf{reprBytes}}
\newcommand{\abstBytes}{\mathsf{abstBytes}}
\newcommand{\xP}{{x_{\hspace{-0.12em}P}}}
\newcommand{\yP}{{y_{\hspace{-0.03em}P}}}

% Conversions

\newcommand{\ECtoOSP}{\mathsf{EC2OSP}}
\newcommand{\ECtoOSPXL}{\mathsf{EC2OSP\mhyphen{}XL}}
\newcommand{\ECtoOSPXS}{\mathsf{EC2OSP\mhyphen{}XS}}
\newcommand{\FEtoIP}{\mathsf{FE2IP}}
\newcommand{\FEtoIPP}{\mathsf{FE2IPP}}
\newcommand{\ItoLEBSP}[1]{\mathsf{I2LEBSP}_{#1}}
\newcommand{\ItoLEBSPOf}[2]{\ItoLEBSP{#1}\!\left({#2}\right)}
\newcommand{\ItoLEOSP}[1]{\mathsf{I2LEOSP}_{#1}}
\newcommand{\ItoLEOSPOf}[2]{\ItoLEOSP{#1}\!\left({#2}\right)}
\newcommand{\ItoBEBSP}[1]{\mathsf{I2BEBSP}_{#1}}
\newcommand{\ItoBEBSPOf}[2]{\ItoBEBSP{#1}\!\left({#2}\right)}
\newcommand{\LEBStoIP}[1]{\mathsf{LEBS2IP}_{#1}}
\newcommand{\LEBStoIPOf}[2]{\LEBStoIP{#1}\!\left({#2}\right)}
\newcommand{\LEOStoIP}[1]{\mathsf{LEOS2IP}_{#1}}
\newcommand{\LEOStoIPOf}[2]{\LEOStoIP{#1}\!\left({#2}\right)}
\newcommand{\LEBStoOSP}[1]{\mathsf{LEBS2OSP}_{#1}}
\newcommand{\LEBStoOSPOf}[2]{\LEBStoOSP{#1}\!\left({#2}\right)}
\newcommand{\LEOStoBSP}[1]{\mathsf{LEOS2BSP}_{#1}}
\newcommand{\LEOStoBSPOf}[2]{\LEOStoBSP{#1}\!\left({#2}\right)}
\newcommand{\BEOStoIP}[1]{\mathsf{BEOS2IP}_{#1}}
\newcommand{\BEOStoIPOf}[2]{\BEOStoIP{#1}\!\left({#2}\right)}

% Sapling and Orchard circuits

\newcommand{\DecompressValidate}{\mathsf{DecompressValidate}}
\newcommand{\MontToCtEdwards}{\mathsf{MontToCtEdwards}}
\newcommand{\CtEdwardsToMont}{\mathsf{CtEdwardsToMont}}
\newcommand{\AffineCtEdwardsJubjub}{\mathsf{AffineCtEdwardsJubjub}}
\newcommand{\AffineMontJubjub}{\mathsf{AffineMontJubjub}}
\newcommand{\CompressedCtEdwardsJubjub}{\mathsf{CompressedCtEdwardsJubjub}}
\newcommand{\AffineSWPallas}{\mathsf{AffineSWPallas}}
\newcommand{\CompressedSWPallas}{\mathsf{CompressedSWPallas}}
\newcommand{\AffineSWVesta}{\mathsf{AffineSWVesta}}
\newcommand{\CompressedSWVesta}{\mathsf{CompressedSWVesta}}
\newcommand{\PedersenHash}{\mathsf{PedersenHash}}
\newcommand{\PedersenGen}{\mathcal{I}}
\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{\PedersenHashToPoint}{\mathsf{PedersenHashToPoint}}
\newcommand{\MixingPedersenHash}{\mathsf{MixingPedersenHash}}
\newcommand{\WindowedPedersenCommitAlg}{\mathsf{WindowedPedersenCommit}}
\newcommand{\WindowedPedersenCommit}[1]{\WindowedPedersenCommitAlg_{#1}}
\newcommand{\HomomorphicPedersenCommitAlg}[1]{\mathsf{HomomorphicPedersenCommit}^\mathsf{#1\kern-0.1em}}
\newcommand{\HomomorphicPedersenCommit}[2]{\HomomorphicPedersenCommitAlg{#1}_{#2}}
\newcommand{\Digits}{\mathsf{Digits}}
\newcommand{\PedersenRangeOffset}{\mathsf{\Delta}}
\newcommand{\Sign}{\mathsf{\Theta}}
\newcommand{\SinsemillaHash}{\mathsf{SinsemillaHash}}
\newcommand{\SinsemillaGenInit}{\mathcal{Q}}
\newcommand{\SinsemillaGenBase}{\mathcal{S}}
\newcommand{\SinsemillaHashToPoint}{\mathsf{SinsemillaHashToPoint}}
\newcommand{\SinsemillaCommitAlg}{\mathsf{SinsemillaCommit}}
\newcommand{\SinsemillaCommit}[1]{\SinsemillaCommitAlg_{#1}}
\newcommand{\SinsemillaShortCommitAlg}{\mathsf{SinsemillaShortCommit}}
\newcommand{\SinsemillaShortCommit}[1]{\SinsemillaShortCommitAlg_{#1}}
\newcommand{\pad}{\mathsf{pad}}
\newcommand{\Mpadded}{M^{\mathsf{padded}}}
\newcommand{\Mpieces}{M^{\mathsf{pieces}}}

% Consensus rules

\newcommand{\consensusrule}[1]{\needspace{4ex}\vspace{2ex}\callout{}{Consensus rule:}{#1}}
\newenvironment{consensusrules}{\introlist\callout{}{Consensus rules:}\begin{itemize}}{\end{itemize}}

\newcommand{\prenufiveitem}[1]{\item \prenufive{#1}}
\newcommand{\nufiveonwarditem}[1]{\nufive{\item {[\NUFive onward]}\, {#1}}}
\newcommand{\precanopyitem}[1]{\item \precanopy{#1}}
\newcommand{\canopyonwarditem}[1]{\canopy{\item {[\Canopy onward]}\, {#1}}}
\newcommand{\preheartwooditem}[1]{\item \preheartwood{#1}}
\newcommand{\heartwoodonwarditem}[1]{\heartwood{\item {[\Heartwood onward]}\, {#1}}}
\newcommand{\heartwoodandcanopyitem}[1]{\heartwood{\item \heartwoodandcanopy{#1}}}
\newcommand{\preblossomitem}[1]{\item \preblossom{#1}}
\newcommand{\blossomonwarditem}[1]{\blossom{\item {[\Blossom onward]}\, {#1}}}
\newcommand{\presaplingitem}[1]{\item \presapling{#1}}
\newcommand{\saplingonwarditem}[1]{\sapling{\item {[\Sapling onward]}\, {#1}}}
\newcommand{\saplingandblossomitem}[1]{\sapling{\item \saplingandblossom{#1}}}
\newcommand{\saplingprenufiveitem}[1]{\sapling{\item \saplingprenufive{#1}}}
\newcommand{\preoverwinteritem}[1]{\item \preoverwinter{#1}}
\newcommand{\overwinteronlyitem}[1]{\overwinter{\item {[\Overwinter only, \sapling{pre-\Sapling}]}\, {#1}}}
\newcommand{\overwinteronwarditem}[1]{\overwinter{\item {[\Overwinter onward]}\, {#1}}}
\newcommand{\overwinterprenufiveitem}[1]{\overwinter{\item \overwinterprenufive{#1}}}
\newcommand{\sproutspecificitem}[1]{\item \sproutspecific{#1}}

\newcommand{\prenufive}[1]{\notbeforenufive{\nufive{[Pre-\NUFive\!]\,}} {#1}}
\newcommand{\nufiveonward}[1]{\nufive{[\NUFive onward]\, {#1}}}
\newcommand{\precanopy}[1]{\notbeforecanopy{\canopy{[Pre-\Canopy\!]\,}} {#1}}
\newcommand{\canopyonward}[1]{\canopy{[\Canopy onward]\, {#1}}}
\newcommand{\preheartwood}[1]{\notbeforeheartwood{\heartwood{[Pre-\Heartwood\!]\,}} {#1}}
\newcommand{\heartwoodonward}[1]{\heartwood{[\Heartwood onward]\, {#1}}}
\newcommand{\heartwoodandcanopy}[1]{\heartwood{[\Heartwood\notbeforecanopy{ and \Canopy}\nufive{ only, pre-\NUFive}]\, {#1}}}
\newcommand{\preblossom}[1]{\notbeforeblossom{\blossom{[Pre-\Blossom\!]\,}} {#1}}
\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\notbeforeblossom{ and \Blossom}\heartwood{ only, pre-\Heartwood}]\, {#1}}}
\newcommand{\saplingprenufive}[1]{\sapling{[\Sapling \notnufive{onward}\notbeforenufive{ to \Canopy inclusive, \nufive{pre-\NUFive}}]\, {#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{\overwinterprenufive}[1]{\overwinter{[\Overwinter \notnufive{onward}\notbeforenufive{ to \Canopy inclusive, \nufive{pre-\NUFive}}]\, {#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}}
\newcommand{\vuln}[1]{\needspace{3ex}{\color{\vulncolor}\callout{}{Vulnerability disclosure:}{#1}}}
\newcommand{\pnote}[1]{\callout{}{Note:}{#1}}
\newenvironment{pnotes}{\introlist\callout{}{Notes:}\begin{itemize}}{\end{itemize}}
\newcommand{\nnote}[1]{\needspace{4ex}\vspace{2ex}\callout{}{Non-normative note:}{#1}}
\newenvironment{nnotes}{\introlist\callout{}{Non-normative notes:}\begin{itemize}}{\end{itemize}}

\newcommand{\nufiveonwardnnote}[1]{\nufive{\callout{[\NUFive onward]\,\,}{Non-normative note:}{#1}}}
\newcommand{\nufiveonwardpnote}[1]{\nufive{\callout{[\NUFive onward]\,\,}{Note:}{#1}}}
\newcommand{\canopyonwardnnote}[1]{\canopy{\callout{[\Canopy onward]\,\,}{Non-normative note:}{#1}}}
\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{\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{[\Sprout\!]\,\,}{Note:}{#1}}

\newcommand{\fact}[1]{\callout{}{Fact:}{#1}}
\newcommand{\facts}[1]{\callout{}{Facts:}{#1}}
\newcommand{\snarkcondition}[2]{\callout{}{#1}\phantomsection\label{#2}}

\newcommand{\affiliation}{\hairspace$^\dagger$\;}

\begin{document}
\pdfbookmark[1]{Title page}{titlepage}

\title{\textbf{\doctitle} \\
\Large \docversion}
\author{
\Large \leadauthor\hairspace\thanks{\;Electric Coin Company} \\
\Large \coauthora\affiliation — \coauthorb\affiliation — \coauthorc\affiliation}
\date{\today}
\maketitle
\vspace{-6ex}

\begin{center}
\hspace{0.6em}\includegraphics[scale=.1]{jubjub}
\footnote{Jubjub bird image credit: Peter Newell 1902; \nh{Daira-Emma} Hopwood 2018.}
\end{center}
\vspace{-6ex}

\renewcommand{\abstractname}{}
\begin{abstract}
\normalsize \noindent \textbf{Abstract.}
\defining{\Zcash} is an implementation of the \term{Decentralized Anonymous Payment scheme}
\Zerocash, with security fixes and improvements to performance and functionality.
It bridges the existing transparent payment scheme used by \Bitcoin with a \emph{shielded}
payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge.
It attempted to address the problem of mining centralization by use of the \Equihash
memory-hard \proofOfWork algorithm.

\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.
Protocol differences from \Zerocash and \Bitcoin are also explained.}}
\notheartwood{\blossom{\noindent This specification defines the \Zcash consensus protocol
at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, and
\Blossom. It is a work in progress. Protocol differences from \Zerocash and
\Bitcoin are also explained.}}
\notcanopy{\heartwood{\noindent This specification defines the \Zcash consensus protocol
at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom,
and \Heartwood. It is a work in progress. Protocol differences from \Zerocash and
\Bitcoin are also explained.}}
\notnufive{\canopy{\noindent This specification defines the \Zcash consensus protocol
at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom,
\Heartwood, and \Canopy. It is a work in progress. Protocol differences from \Zerocash and
\Bitcoin are also explained.}}
\nufive{\noindent This specification defines the \Zcash consensus protocol
at launch, and after each of the upgrades codenamed \Overwinter, \Sapling, \Blossom,
\Heartwood, \Canopy, and \NUFive. It is a work in progress. Protocol differences from
\Zerocash and \Bitcoin are also explained.}

\vspace{2.5ex}
\noindent \textbf{Keywords:}~ \StrSubstitute[0]{\keywords}{,}{, }.

\ifxetex
\vspace{12pt}
\noindent {\setwarning
This document was built with Xe\TeX, which is \href{https://github.com/zcash/zips/issues/249}{not recommended}.
In particular, vertical spacing will be too cramped due to incorrect metrics for the Quattrocento font.}
\fi
\ifluatex
\vspace{12pt}
\noindent {\setwarning
This document was built with Lua\TeX, which is \href{https://github.com/zcash/zips/issues/249}{not recommended}.}
\fi

\end{abstract}

\phantompart{Contents}{contents}

\renewcommand{\contentsname}{}
% <https://tex.stackexchange.com/a/182744/78411>
\renewcommand{\baselinestretch}{0.84}\normalsize
\tableofcontents
\renewcommand{\baselinestretch}{1.0}\normalsize
\newpage


\lsection{Introduction}{introduction}

\Zcash is an implementation of the \defining{\term{Decentralized Anonymous Payment scheme}
\Zerocash \cite{BCGGMTV2014}}, with security fixes and improvements
to performance and functionality. It bridges the existing
transparent payment scheme used by \defining{\Bitcoin \cite{Nakamoto2008}} with a
\emph{shielded} payment scheme secured by \zeroKnowledgeSuccinctNoninteractiveArgumentsOfKnowledge.

\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}.

Changes specific to the \Overwinter upgrade
are highlighted in \overwinter{\overwintercolorname}.

Changes specific to the \Sapling upgrade following \Overwinter
are highlighted in \sapling{\saplingcolorname}.

\notbeforeblossom{Changes specific to the \Blossom upgrade following \Sapling
are highlighted in \blossom{\blossomcolorname}.}

\notbeforeheartwood{Changes specific to the \Heartwood upgrade following \Blossom
are highlighted in \heartwood{\heartwoodcolorname}.}

\notbeforecanopy{Changes specific to the \Canopy upgrade following \Heartwood
are highlighted in \canopy{\canopycolorname}.}

\notbeforenufive{Changes specific to the \NUFive upgrade following \Canopy
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.

\vspace{2ex}
\introlist
This specification is structured as follows:

\begin{itemize}
  \item Notation — definitions of notation used throughout the document;
  \item Concepts — the principal abstractions needed to understand the protocol;
  \item Abstract Protocol — a \nh{high-level} description of the protocol in terms
        of ideal cryptographic components;
  \item Concrete Protocol — how the functions and encodings of the abstract
        protocol are instantiated;
  \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}.
  \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}


\lsubsection{Caution}{caution}

\Zcash security depends on consensus. Should a program interacting with the
\Zcash network diverge from consensus, its security will be weakened or destroyed.
The cause of the divergence doesn't matter: it could be a bug in your program,
it could be an error in this documentation which you implemented as described,
or it could be that you do everything right but other software on the network
behaves unexpectedly. The specific cause will not matter to the users of your
software whose wealth is lost.

Having said that, a specification of \emph{intended} behaviour is essential
for security analysis, understanding of the protocol, and maintenance of
\Zcash and related software. If you find any mistake in this specification,
please file an issue at \url{https://github.com/zcash/zips/issues} or contact
\texttt{<security@z.cash>}.

\lsubsection{High-level Overview}{overview}

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. This overview applies to
\notnufive{both \Sprout and \Sapling}\notbeforenufive{\Sprout, \Sapling, and \Orchard},
differences in the cryptographic constructions used notwithstanding.

\introsection
All value in \Zcash belongs to some \defining{\chainValuePool}. There is a single
\defining{\transparent} \chainValuePool, and also a \chainValuePool for each
\defining{\shielded} protocol (\Sprout\sapling{ or \Sapling}\nufive{ or \Orchard}).
Transfers of \transparent value work essentially as in \Bitcoin and have the
same privacy properties.
Value in a \shielded \chainValuePool is carried by \notes\footnotewithlabel{notesandnullifiers}{In
\Zerocash \cite{BCGGMTV2014}, \notes were called
\defining{\quotedtermandindex{coins}{coins (in Zerocash)}},
and \nullifiers were called
\defining{\quotedtermandindex{serial numbers}{serial numbers (in Zerocash)}}.},
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.

To each \note there is cryptographically associated a \noteCommitment. Once the
\transaction creating a \note has been mined, the \note is associated with a fixed
\notePosition in a tree of \noteCommitments, and with a \nullifier\footnoteref{notesandnullifiers}
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 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}.
It also can include \joinSplitDescriptions,\sapling{ \spendDescriptions,\notnufive{ and}
\outputDescriptions}\nufive{ and \actionDescriptions}. Together these describe
\defining{\shieldedTransfers} which take in \defining{\shieldedInput} \notes,
and/or produce \defining{\shieldedOutput} \notes.
(For \Sprout, each \joinSplitDescription handles up to two \shieldedInputs and
up to two \shieldedOutputs.\sapling{ For \Sapling, each \shieldedInput or \shieldedOutput
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 \chainValuePools,
either \transparent or \shielded; this always reveals the amount transferred.

In each \shieldedTransfer, 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). 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,

\begin{itemize}
  \item \saplingonward{there is a revealed \valueCommitment to the same value as
        the input \note;\nufive{\footnotewithlabel{orchardvaluecommitments}{\nufive{For
        \Orchard, each Action reveals a single \valueCommitment to the net value
        spent by the Action, rather than one \valueCommitment for the input \note
        and one for the output \note.}}}}
  \item if the value is nonzero, some revealed \noteCommitment exists for this \note;
  \item the prover knew the \authProvingKey of the \note;
  \item the \nullifier and \noteCommitment are computed correctly.
\end{itemize}

\vspace{-1.5ex}
and for each \shieldedOutput,

\vspace{0.5ex}
\begin{itemize}
  \item \saplingonward{there is a revealed \valueCommitment to the same value as
        the output \note;\nufive{\footnoteref{orchardvaluecommitments}}}
  \item the \noteCommitment is computed correctly;
  \item it is infeasible to cause the \nullifier of the output \note to collide
        with the \nullifier of any other \note.
\end{itemize}

For \Sprout, the \joinSplitStatement also includes an explicit balance check.
\sapling{For \SaplingAndOrchard, the \valueCommitments corresponding to the inputs and
outputs are checked to balance (together with any net \transparent input or output)
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.

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 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.

\sapling{
In \SaplingAndOrchard, for each \spendingKey there is a \fullViewingKey that allows
recognizing both incoming and outgoing \notes without having \spendingAuthority.
This is implemented by an additional ciphertext in each
\outputDescription\nufive{ or \actionDescription}.
}

The basis of the privacy properties of \Zcash is that when a \note is spent,
the spender only proves that some commitment for it had been revealed, without
revealing which one. This implies that a spent \note cannot be linked to the
\transaction in which it was created. That is, from an adversary's point of
view the set of possibilities for a given \note input to a \transaction{}
---its \defining{\noteTraceabilitySet}--- includes \emph{all} previous notes that the
adversary does not control or know to have been spent.\footnotewithlabel{securitycaveat}{We
make this claim only for \emph{fully shielded} \transactions. It does not exclude the
possibility that an adversary may use data present in the cleartext of a \transaction
such as the number of inputs and outputs, or metadata-based heuristics such as timing,
to make probabilistic inferences about \transaction linkage.
For consequences of this in the case of partially shielded \transactions,
see \cite{Peterson2017}, \cite{Quesnelle2017}, and \cite{KYMM2018}.} This contrasts with
other proposals for private payment systems, such as CoinJoin \cite{Bitcoin-CoinJoin}
or \CryptoNote \cite{vanSaberh2014}, that are based on mixing of a limited number of
transactions and that therefore have smaller \noteTraceabilitySets.

The \nullifiers are necessary to prevent \doubleSpending: each \note on the
\blockChain only has one valid \nullifier, and so attempting to spend a \note
twice would reveal the \nullifier twice, which would cause the second \transaction
to be rejected.


\introsection
\lsection{Notation}{notation}

\vspace{-2ex}
$\bit$ means the type of bit values, i.e.\ $\setof{0, 1}$.
$\byte$ means the type of byte values, i.e.\ $\range{0}{255}$.

$\Nat$ means the type of nonnegative integers. $\PosInt$~means
the type of positive integers. $\Int$~means the type of integers.
$\Rat$~means the type of rationals.

$x \typecolon T$ is used to specify that $x$ has type $T$.
A cartesian product type is denoted by $S \times T$, and a function type
by $S \rightarrow T$. An argument to a function can determine other argument
or result types.

The type of a randomized algorithm is denoted by $S \rightarrowR T$.
The domain of a randomized algorithm may be $()$, indicating that it requires
no arguments. Given $f \typecolon S \rightarrowR T$ and $s \typecolon S$,
sampling a variable $x \typecolon T$ from the output of $f$ applied to $s$
is denoted by $x \leftarrowR f(s)$.

Initial arguments to a function or randomized algorithm may be
written as subscripts, e.g.\ if $x \typecolon X$, $y \typecolon Y$, and
$f \typecolon X \times Y \rightarrow Z$, then an invocation of
$f(x, y)$ can also be written $f_x(y)$.

$\setof{x \typecolon T \suchthat p_x}$ means the subset of $x$ from $T$
for which $p_x$ (a boolean expression depending on $x$) holds.

$T \subseteq U$ indicates that $T$ is an inclusive subset or subtype of $U$.

$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}$.

$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}$.

$\fun{x \typecolon T}{e_x \typecolon U}$ means the function of type $T \rightarrow U$
mapping formal parameter $x$ to $e_x$ (an expression depending on~$x$).
The types $T$ and $U$ are always explicit.

$\exclusivefun{x \typecolon T}{e_x \typecolon U}{V}$ means
$\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$.

$\bot$ is a distinguished value used to indicate unavailable information,
a failed decryption or validity check, or an exceptional case.

$\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
$\byteseq{k}$ means the set of sequences of $k$ bytes.

$\byteseqs$ means the type of \byteSequences of arbitrary length.

$\length(S)$ means the length of (number of elements in) $S$.

$\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.
$\zerobytes{\ell}$ means the sequence of $\ell$ zero bytes.

$\ascii{...}$ means the given string represented as a
sequence of bytes in \xUSASCII. For example, $\ascii{abc}$ represents the
\byteSequence $\hexarray{61,62,63}$.

$\zeros{\ell}$ means the sequence of $\ell$ zero 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,
$\AuthPublicNew{\allNew}$ means the sequence
$\vphantom{\mathsf{a_a}}\smash{[\AuthPublicNew{\mathrm{1}}, \AuthPublicNew{\mathrm{2}}, ...\,\AuthPublicNew{\NNew}]}$.
(For consistency with the notation in \cite{BCGGMTV2014} and in \cite{BK2016},
this specification uses 1-based indexing and inclusive ranges,
\raisedstrut notwithstanding the compelling arguments to the contrary made in
\cite{EWD-831}.)

$\range{a}{b}$ means the set or type of integers from $a$ through
$b$ inclusive.

$\listcomp{f(x) \for x \from a \upto b}$ means the sequence
formed by evaluating $f$ on each integer from $a$ to $b$ inclusive, in
ascending order. Similarly, $\listcomp{f(x) \for x \from a \downto b}$ means
the sequence formed by evaluating $f$ on each integer from $a$ to $b$
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$ as \bitSequences.

$\sorted(S)$ means the sequence formed by sorting the elements
of $S$.

$\GF{n}$ means the finite field with $n$ elements, and
$\GFstar{n}$ means its group under multiplication (which excludes $0$).

Where there is a need to make the distinction, we denote the unique
representative of $a \typecolon \GF{n}$ in the range $\range{0}{n-1}$
(or the unique representative of $a \typecolon \GFstar{n}$ in the range
$\range{1}{n-1}$) as $a \bmod n$. Conversely, we denote the element
of $\GF{n}$ corresponding to an integer $k \typecolon \Int$
as $k \pmod{n}$. We also use the latter notation in the context of
an equality $k = k' \pmod{n}$ as shorthand for $k \bmod n = k' \bmod n$,
and similarly $k \neq k' \pmod{n}$ as shorthand for $k \bmod n \neq k' \bmod n$.
(When referring to constants such as $0$ and $1$ it is usually not
necessary to make the distinction between field elements and their
representatives, since the meaning is normally clear from context.)

$\GF{n}[z]$ means the ring of polynomials over $z$ with coefficients
in $\GF{n}$.

$a + b$ means the sum of $a$ and $b$. This may refer to addition of
integers, rationals, finite field elements, or group elements
(see \crossref{abstractgroup}) according to context.

$-a$ means the value of the appropriate integer, rational,
finite field, or group type such that $(-a) + a = 0$
(or when $a$ is an element of a group $\GroupG{}$, $(-a) + a = \ZeroG{}$),
and $a - b$ means $a + (-b)$.

$a \mult b$ means the product of multiplying $a$ and $b$.
This may refer to multiplication of integers, rationals, or
finite field elements according to context (this notation is not
used for group elements).

$a / b$, also written $\hfrac{a}{b}$, means the value of the
appropriate integer, rational, or finite field type such that
$(a / b) \mult b = a$.

$a \bmod q$, for $a \typecolon \Nat$ and $q \typecolon \PosInt$,
means the remainder on dividing $a$ by $q$. (This usage does not
conflict with the notation above for the unique representative of
a field element.)

$a \xor b$ means the \nh{bitwise-exclusive-or} of $a$ and $b$,
and $a \band b$ means the \nh{bitwise-and} of $a$ and $b$. These are
defined on integers (which include bits and bytes), or elementwise
on equal-length sequences of integers, according to context.

\vspace{-0.5ex}
$\!\vsum{i=1}{\rmN} a_i$ means the sum of $a_{\allN{}}$.\;
$\vproduct{i=1}{\rmN} a_i$ means the product of $a_{\allN{}}$.\;
$\vxor{i=1}{\rmN} a_i$ means the \nh{bitwise-exclusive-or} of $a_{\allN{}}$.

When $N = 0$ these yield the appropriate neutral element, i.e.
$\ssum{i=1}{0} a_i = 0$, $\sproduct{i=1}{0} a_i = 1$, and
$\sxor{i=1}{0} a_i = 0$ or the \nh{all-zero} \bitSequence 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}{\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
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$,
i.e.
\begin{formulae}
  \item $a^b := \begin{cases}
          \sproduct{i=1}{b}  \kern 0.15em a, &\caseif b \geq 0 \\[1.5ex]
          \sproduct{i=1}{-b} \kern 0.1em \hfrac{1}{a}, &\caseotherwise.
        \end{cases}$
\end{formulae}

The $\scalarmult{k}{P}$ notation for scalar multiplication in a group is
defined in \crossref{abstractgroup}.

The convention of affixing $\Repr$ to a variable name is used
for variables that denote \bitSequence representations of group elements.

The binary relations $<$, $\leq$, $=$, $\geq$, and $>$ have their conventional
meanings on integers and rationals, and are defined lexicographically on
sequences of integers.

$\floor{x}$ means the largest integer $\leq x$.
$\ceiling{x}$ means the smallest integer $\geq x$.

$\bitlength(x)$, for $x \typecolon \Nat$, means the smallest integer
$\ell$ such that $2^\ell > x$.

\introlist
The following integer constants will be instantiated in \crossref{constants}:
\begin{formulae}
  \item \begin{flushleft}
    $\MerkleDepth{Sprout}$,\sapling{ $\MerkleDepth{Sapling}$,}\nufive{ $\MerkleDepth{Orchard}$,}
    $\MerkleHashLength{Sprout}$,\sapling{ $\MerkleHashLength{Sapling}$,}\nufive{ $\MerkleHashLength{Orchard}$,}
    $\NOld$, $\NNew$, $\ValueLength$, $\hSigLength$, $\PRFOutputLengthSprout$,\sapling{ $\PRFOutputLengthExpand$,
    $\PRFOutputLengthNfSapling$,} $\NoteCommitRandLengthSprout$, $\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$,}\strut\nufive{ $\NUFiveActivationHeight$,}
    $\SlowStartInterval$, $\PreBlossomHalvingInterval$, $\MaxBlockSubsidy$, $\NumFounderAddresses$,
    $\PoWLimit$, $\PoWAveragingWindow$, $\PoWMedianBlockSpan$, $\PoWDampingFactor$,
    \notblossom{and }$\PreBlossomPoWTargetSpacing$\blossom{, and $\PostBlossomPoWTargetSpacing$}.
  \end{flushleft}
\end{formulae}

The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$;\notnufive{ and}
the \bitSequenceAdjective constants $\Uncommitted{Sprout} \typecolon \bitseq{\smash{\MerkleHashLength{Sprout}}}$\sapling{ and
$\Uncommitted{Sapling} \typecolon \bitseq{\smash{\MerkleHashLength{Sapling}}}$}\nufive{; and the constant
$\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$} will also be defined in that section.

We use the abbreviation ``\defining{\xCtEdwards}'' to refer to \completeTwistedEdwardsEllipticCurves and
coordinates (see \crossref{jubjub}).


\pagebreak
\lsection{Concepts}{concepts}

\lsubsection{Payment Addresses and Keys}{addressesandkeys}

Users who wish to receive shielded payments in the \Zcash protocol must have a
\defining{\shieldedPaymentAddress, which is generated from a \spendingKey.}

\introlist
The following diagrams depict the relations between key
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.

\readas{Image description: three diagrams showing the derivation of Sprout, Sapling, and Orchard key components.
The key components are shown by their mathematical abbreviations. They are collected into ovals for each named
abstraction, which are colour-coded from purple to green in the direction of derivation, or from more-secret to
less-secret values. The information in the diagram is otherwise mostly redundant with the textual description
of the key components and their derivation that follows it.}{\begin{center}
\notnufive{\includegraphics[scale=.5]{key_components_sapling}}
\nufive{\includegraphics[scale=.385]{key_components_orchard}}
\end{center}}

\sproutspecific{
\defining{The \receivingKey $\TransmitPrivate$, \incomingViewingKey
$\InViewingKey = (\AuthPublic, \TransmitPrivate)$, and \shieldedPaymentAddress
$\PaymentAddress = (\AuthPublic, \TransmitPublic)$ are derived from the
\spendingKey $\AuthPrivate$, as described in \crossref{sproutkeycomponents}.}
} %sproutspecific

\saplingonward{
\defining{An \expandedSpendingKey is composed of a \authSigningKey $\AuthSignPrivate$,
a \authNullifierKey $\AuthProvePrivate$, and an \outgoingViewingKey $\OutViewingKey$.
From these components we can derive a \authProvingKey $(\AuthSignPublic, \AuthProvePrivate)$,
a \fullViewingKey $(\AuthSignPublic, \NullifierKey, \OutViewingKey)$,
an \incomingViewingKey $\InViewingKey$, and a set of \diversifiedPaymentAddresses
$\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$,
as described in \crossref{saplingkeycomponents}.}

The consensus protocol does not depend on how an \expandedSpendingKey is constructed.
Two methods of doing so are defined:
\begin{enumerate}
  \item Generate a \spendingKey $\SpendingKey$ at random and derive the \expandedSpendingKey
        $(\AuthSignPrivate, \AuthProvePrivate, \OutViewingKey)$ from it, as shown in the
        diagram above and described in \crossref{saplingkeycomponents}.
  \item Obtain an \extendedSpendingKey as specified in \cite{ZIP-32}; this includes a superset
        of the components of an \expandedSpendingKey. This method is used in the context of a
        \hdWallet.
\end{enumerate}
} %saplingonward

\nufiveonward{
An \Orchard \spendingKey $\SpendingKey$ is used to derive a \authSigningKey $\AuthSignPrivate$,
and a \fullViewingKey $(\AuthSignPublic, \NullifierKey, \CommitIvkRand)$. From the \fullViewingKey
we can also derive an \incomingViewingKey (composed of a \diversifierKey $\DiversifierKey$ and a
$\KA{Orchard}$ \privateKey $\InViewingKey$), an \outgoingViewingKey $\OutViewingKey$, and a set of
\diversifiedPaymentAddresses $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$,
as described in \crossref{orchardkeycomponents}.
} %nufiveonward

\vspace{-2ex}
\sapling{\nnote{In \zcashd, all \SaplingAndOrchard keys and addresses are derived according to \cite{ZIP-32}.}}

\vspace{2ex}
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, \incomingViewingKey\sapling{, or \fullViewingKey}
from a \spendingKey\sapling{ or \extendedSpendingKey}.

Users can accept payment from multiple parties with a single
\shieldedPaymentAddress and the fact that these payments are destined to
the same payee is not revealed on the \blockChain, even to the
paying parties. \emph{However} if two parties collude to compare a
\shieldedPaymentAddress they can trivially determine they are the same. In the
case that a payee wishes to prevent this they should create a distinct
\shieldedPaymentAddress for each payer.

\saplingonward{
\notnufive{\Sapling provides}\notbeforenufive{\Sapling and \Orchard provide}
a mechanism to allow the efficient creation of \diversifiedPaymentAddresses
with the same \spendingAuthority. A group of such addresses shares the same
\fullViewingKey and \incomingViewingKey\!\!, and so creating as many unlinkable
addresses as needed does not increase the cost of scanning the \blockChain for
relevant \transactions.
} %saplingonward

\pnote{
It is conventional in cryptography to call the key used to encrypt
a message in an asymmetric encryption scheme a ``\defining{\publicKey}''.
However, the \publicKey used as \defining{the \transmissionKey component of an address
($\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$})} need not be
publically distributed; it has the same distribution as the \shieldedPaymentAddress itself.
As mentioned above, limiting the distribution of the \shieldedPaymentAddress is important
for some use cases. This also helps to reduce reliance of the overall protocol
on the security of the cryptosystem used for \note encryption
(see \crossref{sproutinband}\sapling{ and \crossref{saplingandorchardinband}}),
since an adversary would have to know
$\TransmitPublic$\sapling{ or some $\DiversifiedTransmitPublic$}
in order to exploit a hypothetical weakness in that cryptosystem.
}

\introsection
\lsubsection{Notes}{notes}

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.

\vspace{1ex}
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}.

\sapling{
Let $\NoteCommitAlg{Sapling}$ be as defined in \crossref{concretesaplingnotecommit}.

Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}.

Let $\DiversifyHash{Sapling}$ be as defined in \crossref{concretediversifyhash}.} %sapling

\nufive{
Let $\NoteCommitAlg{Orchard}$ be as defined in \crossref{concreteorchardnotecommit}.

Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.

Let $\DiversifyHash{Orchard}$ be as defined in \crossref{concretediversifyhash}.

Let $\PRFnf{Orchard}{}$ be as defined in \crossref{concreteprfs}.

Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.
} %nufive

\vspace{2ex}
\introlist
A \Sprout \note is a tuple $(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$,
where:
\begin{itemize}
  \item $\AuthPublic \typecolon \PRFOutputSprout$ is the \defining{\payingKey} of the
        recipient's \shieldedPaymentAddress;
  \item $\Value \typecolon \range{0}{\MAXMONEY}$ is an integer
        representing the value of the \note in \zatoshi
        (\defining{$1$ \ZEC = $\pow{10}{8}$ \zatoshi});
  \item $\NoteUniqueRand \typecolon \PRFOutputSprout$
        is used as input to $\PRFnf{Sprout}{\AuthPrivate}$ to derive the
        \nullifier of the \note;
  \item $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Sprout}$
        is a random \commitmentTrapdoor as defined in \crossref{abstractcommit}.
\end{itemize}

\introlist
Let $\NoteType{Sprout}$ be the type of a \Sprout \note, i.e.
\begin{formulae}
  \item $\NoteType{Sprout} := \PRFOutputSprout \times \range{0}{\MAXMONEY} \times \PRFOutputSprout
           \times \NoteCommitTrapdoor{Sprout}$.
\end{formulae}

\sapling{
\vspace{1ex}
\introsection
A \Sapling \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic,
\Value, \NoteCommitRand)$, where:
\begin{itemize}
  \item $\Diversifier \typecolon \DiversifierType$
        is the \diversifier of the recipient's \shieldedPaymentAddress;
  \item $\DiversifiedTransmitPublic \typecolon \KAPublicPrimeSubgroup{Sapling}$
        is the \diversifiedTransmissionKey of the recipient's \shieldedPaymentAddress;
  \item $\Value \typecolon \range{0}{\MAXMONEY}$ is an integer
        representing the value of the \note in \zatoshi;
  \item $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Sapling}$
        is a random \commitmentTrapdoor as defined in \crossref{abstractcommit}.
\end{itemize}

\introlist
Let $\NoteType{Sapling}$ be the type of a \Sapling \note, i.e.
\begin{formulae}
  \item $\NoteType{Sapling} := \DiversifierType \times \KAPublicPrimeSubgroup{Sapling} \times \range{0}{\MAXMONEY}
           \times \NoteCommitTrapdoor{Sapling}$.
\end{formulae}
} %sapling

\nufive{
\vspace{1ex}
\introlist
An \Orchard \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic,
\Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$, where:
\begin{itemize}
  \item $\Diversifier \typecolon \DiversifierType$
        is the \diversifier of the recipient's \shieldedPaymentAddress;
        \vspace{-0.5ex}
  \item $\DiversifiedTransmitPublic \typecolon \KAPublic{Orchard}$
        is the \diversifiedTransmissionKey of the recipient's \shieldedPaymentAddress;
  \item $\Value \typecolon \ValueType$ is an integer
        representing the value of the \note in \zatoshi;
        \vspace{-0.5ex}
  \item $\NoteUniqueRand \typecolon \NoteUniqueRandTypeOrchard$
        is used as input to $\PRFnf{Orchard}{\NullifierKey}$ as part of deriving
        the \nullifier of the \note;
  \item $\NoteNullifierRand \typecolon \NoteNullifierRandType$
        is additional randomness used in deriving the \nullifier;
        \vspace{-0.5ex}
  \item $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Orchard}$
        is a random \commitmentTrapdoor as defined in \crossref{abstractcommit}.
\end{itemize}

\introlist
Let $\NoteType{Orchard}$ be the type of an \Orchard \note, i.e.
\begin{formulae}
  \item $\NoteType{Orchard} := \DiversifierType \times \KAPublic{Orchard} \times \ValueType
           \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \NoteCommitTrapdoor{Orchard}$.
\end{formulae}
} %nufive

\vspace{2ex}
Creation of new \notes is described in \crossref{send}.

\lsubsubsection{Note Plaintexts and Memo Fields}{noteptconcept}

Transmitted \notes are stored on the \blockChain in encrypted form, together with
a representation of the \noteCommitment $\cm$ described in \crossref{notecommitmentconcept}.

A \notePlaintext also includes 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. \RECOMMENDED{} \nh{non-consensus} constraints on the \memo contents are specified
in \cite{ZIP-302}.

For \Sprout, the \notePlaintexts in each \joinSplitDescription are encrypted to the respective
\transmissionKeys $\TransmitPublicNew{\allNew}$, as specified in \crossref{sproutsend}.

\introlist
Each \Sprout{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists of

\vspace{-0.5ex}
\begin{formulae}
  \item $(\NotePlaintextLeadByte \typecolon \byte,
          \Value \typecolon \ValueType, \NoteUniqueRand \typecolon \PRFOutputSprout,
          \NoteCommitRand \typecolon \NoteCommitTrapdoor{Sprout}, \Memo \typecolon \MemoType)$.
\end{formulae}

\vspace{-1ex}
The field $\NotePlaintextLeadByte$ is always $\hexint{00}$ for \Sprout. The fields $\Value$,
$\NoteUniqueRand$, and $\NoteCommitRand$ are as defined in \crossref{notes}.

\vspace{1.5ex}
\saplingonward{
For \Sapling\nufive{ and \Orchard}, the \notePlaintext in each \outputDescription\nufive{ or \actionDescription}
is encrypted to the \diversifiedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic\kern-0.08em)$,
as specified in \crossref{saplingsend}\nufive{ or \crossref{orchardsend}}.

\introlist
Each \SaplingOrOrchard{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists of

\begin{formulae}
  \item $(\NotePlaintextLeadByte \typecolon \byte,
          \Diversifier \typecolon \DiversifierType, \Value \typecolon \ValueType,
          \NoteCommitRandBytesOrSeedBytes \typecolon \NoteSeedBytesType, \Memo \typecolon \MemoType)$
\end{formulae}

\vspace{-1ex}
The field $\NotePlaintextLeadByte$ indicates the version of the encoding of a \SaplingOrOrchard
\notePlaintext. For \Sapling it is $\hexint{01}$ before activation of the \Canopy
\networkUpgrade\canopy{ and $\hexint{02}$ afterward, as specified in \cite{ZIP-212}}.
\nufive{For \Orchard \notePlaintexts it is always $\hexint{02}$.}

The fields \notcanopy{$\Diversifier$, $\Value$, and $\NoteCommitRandBytes$}\notbeforecanopy{$\Diversifier$ and $\Value$}
are as defined in \crossref{notes}.

\canopy{
The use of the field $\NoteSeedBytes$ is described in \cite{ZIP-212}.
} %canopy
} %saplingonward

\vspace{1.5ex}
Encodings are given in \crossref{noteptencoding}.
The result of encryption forms part of a \noteOrNotesCiphertext.
For further details, see \crossref{sproutinband}\sapling{ and \crossref{saplingandorchardinband}}.

\lsubsubsection{Note Commitments}{notecommitmentconcept}

When a \note is created as an output of a \transaction, only a commitment (see
\crossref{abstractcommit}) to the \note contents is disclosed publically in the associated
\joinSplitDescription\sapling{ or \outputDescription}\nufive{ or \actionDescription}. If the
\transaction is entered into the \blockChain, each such \noteCommitment is appended to the
\noteCommitmentTree of the associated \treestate.
This allows the value and recipient to be kept private, while the commitment is
used by the \zkSNARKProof when the \note is spent, to check that it exists
on the \blockChain.

\xTreestates are described in \crossref{transactions}, and \noteCommitmentTrees are described
in \crossref{notecommitmenttrees}.

\vspace{2ex}
\introlist
A \Sprout{} \defining{\noteCommitment} on a \note
$\NoteTuple{} = (\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$ is computed as

\vspace{-1ex}
\begin{formulae}
  \item $\NoteCommitment{Sprout}(\NoteTuple{}) =
          \NoteCommit{Sprout}{\NoteCommitRand}(\AuthPublic, \Value, \NoteUniqueRand)$,
\end{formulae}
\vspace{-2.5ex}
where $\NoteCommit{Sprout}{}$ is instantiated in \crossref{concretesproutnotecommit}.

\sapling{
\vspace{2ex}
\introlist
A \Sapling{} \defining{\noteCommitment} on a \note
$\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand)$ is computed as

\vspace{-1ex}
\begin{formulae}
  \item $\DiversifiedTransmitBase := \DiversifyHash{Sapling}(\Diversifier)$
        \vspace{-1.5ex}
  \item $\NoteCommitment{Sapling}(\NoteTuple{}) := \begin{cases}
          \bot, &\caseif \DiversifiedTransmitBase = \bot \\
          \NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase},
                                                \reprJ\Of{\DiversifiedTransmitPublic},
                                                \Value), &\caseotherwise.
        \end{cases}$
\end{formulae}
\vspace{-2.5ex}
where $\NoteCommitAlg{Sapling}$ is instantiated in \crossref{concretewindowedcommit}.

Notice that the above definition of a \Sapling \note does not have a
$\NoteUniqueRand$ component. There is in fact a $\NoteUniqueRand$ value associated
with each \Sapling \note, but this can only be computed once its position in the
\noteCommitmentTree (see \crossref{transactions}) is known. We refer to the combination
of a \note and its \notePosition $\NotePosition$, as a \defining{\positionedNote}.

For a \positionedNote, we can compute the value $\NoteUniqueRand$ as described in
\crossref{rhoandnullifiers}.

A \Sapling \noteCommitment is represented in an \outputDescription by the $u$-coordinate
of a \Jubjub curve point, as specified in \crossref{outputdesc}.
} %sapling

\nufive{
\vspace{2ex}
\introlist
An \Orchard{} \defining{\noteCommitment} on a \note
$\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand,
\NoteNullifierRand, \NoteCommitRand)$ is computed as

\vspace{-1ex}
\begin{formulae}
  \item $\DiversifiedTransmitBase := \DiversifyHash{Orchard}(\Diversifier)$
        \vspace{-1ex}
  \item $\NoteCommitment{Orchard}(\NoteTuple{}) :=
          \NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase},
                                                \reprP\Of{\DiversifiedTransmitPublic},
                                                \Value, \NoteUniqueRand, \NoteNullifierRand)$
\end{formulae}
\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$ component; the \note's position in the \noteCommitmentTree does
not need to be known in order to compute this value.

An \Orchard \noteCommitment is represented in an \actionDescription by the $x$-coordinate
of a \Pallas curve point, as specified in \crossref{actiondesc}.
} %nufive

\lsubsubsection{Nullifiers}{nullifierconcept}

The \nullifier for a \note, denoted $\nf$, is a value unique to the \note that is used
to prevent \doubleSpends. When a \transaction that contains one or more
\joinSplitDescriptions\sapling{ or \spendDescriptions}\nufive{ or \actionDescriptions} is
entered into the \blockChain, all of the \defining{\nullifiers} for \notes spent by that
\transaction are added to the \nullifierSet of the associated \treestate. A \transaction
is not valid if it would have added a \nullifier to the \nullifierSet that already exists
in the set.

\xTreestates are described in \crossref{transactions}, and \nullifierSets are described
in \crossref{nullifierset}.

\vspace{1.5ex}
In more detail, when a \note is spent, the spender creates a \zeroKnowledgeProof that
it knows $(\NoteUniqueRand, \AuthPrivate)$\sapling{ or $(\NoteUniqueRand, \AuthSignPublic,
\AuthProvePrivate)$}\nufive{ or $(\NoteUniqueRand, \AuthSignPublic, \NullifierKey)$},
consistent with the publically disclosed \nullifier and some previously committed
\noteCommitment.

Because each \note can have only a single \nullifier, and the same \nullifier value
cannot appear more than once in a \validBlockChain, \doubleSpending is prevented.

\vspace{1.5ex}
The \nullifier for a \Sprout \note is derived from the $\NoteUniqueRand$ value and
the recipient's \spendingKey $\AuthPrivate$.

\sapling{
The \nullifier for a \Sapling \note is derived from the $\NoteUniqueRand$ value and
the recipient's \nullifierDerivingKey $\NullifierKey$.
}

\nufive{
The \nullifier for an \Orchard \note is derived from the $\NoteUniqueRand$ and
$\NoteNullifierRand$ values, the recipient's \nullifierDerivingKey $\NullifierKey$,
and the \noteCommitment.
}

The \nullifier computation uses a \pseudoRandomFunction (see \crossref{abstractprfs}),
as described in \crossref{rhoandnullifiers}.


\lsubsection{The Block Chain}{blockchain}

At a given point in time, each \defining{\fullValidator} is aware of a set of candidate
\blocks. These form a tree rooted at the \genesisBlock, where each node
in the tree refers to its parent via the $\hashPrevBlock$ \blockHeader field
(see \crossref{blockheader}).

A path from the root toward the leaves of the tree consisting of a sequence
of one or more valid \blocks consistent with consensus rules, is called a
\defining{\validBlockChain}.

Each \block in a \defining{\blockChain} has a \defining{\blockHeight}. The \blockHeight
of the \defining{\genesisBlock} is $0$, and the \blockHeight of each subsequent \block
in the \blockChain increments by $1$. Implementations \MUST support \blockHeights up to
and including $2^{31} - 1$. \nufive{As of \NUFive, there is a consensus rule that all
\coinbaseTransactions (see \crossref{coinbasetransactions}) MUST have the $\nExpiryHeight$
field set to the \blockHeight, and this limits the maximum \blockHeight to $2^{32} - 1$,
absent future consensus changes.}

In order to choose the \defining{\bestValidBlockChain} in its view of the
overall \block tree, a node sums the work, as defined in \crossref{workdef}, of
all \blocks in each \validBlockChain, and considers the \validBlockChain with greatest
total work to be best. To break ties between leaf \blocks, a node will prefer the \block
that it received first.

The consensus protocol is designed to ensure that for any given \blockHeight, the vast
majority of well-connected nodes should eventually agree on their \bestValidBlockChain
up to that height. A \fullValidator\footnote{There is reason to follow the requirements
in this section also for \nh{non-full~validators}, but those are outside the scope of this
protocol specification.} \SHOULD attempt to obtain candidate \blocks from multiple
sources in order to increase the likelihood that it will find a \validBlockChain that
reflects a recent consensus state.

A \networkUpgrade is \defining{\settled} on a given \network when there is a social
consensus that it has activated with a given \activationBlock hash. A \fullValidator
that potentially risks \Mainnet funds or displays \Mainnet \transaction information
to a user \MUST do so only for a \blockChain that includes the \activationBlock of
the most recent \settled \networkUpgrade, with the corresponding \activationBlock hash.
Currently, there is social consensus that \NUFive has activated on the \Zcash \Mainnet
and \Testnet with the \activationBlock hashes given in \crossref{networks}.

A \fullValidator \MAY impose a limit on the number of \blocks it will ``roll back'' when
switching from one \bestValidBlockChain to another that is not a descendent. For \zcashd
and \zebra this limit is $100$ \blocks.


\vspace{-1ex}
\lsubsection{Transactions and Treestates}{transactions}

Each \block contains one or more \defining{\transactions}.

Each \transaction has a \defining{\transactionID}. \xTransactionIDs are used to refer to
\transactions in $\txOut$ fields, in \merkleLeafNodes of a \block's \transaction tree
rooted at $\hashMerkleRoot$, and in other parts of the ecosystem; for example they are
shown in \blockChain explorers and can be used in higher-level protocols.
\nufive{Version 5 \transactions also have a \defining{\wtxid}, which is used instead of
the \transactionID when gossiping \transactions in the \peerToPeerProtocol \cite{ZIP-239}.}
The computation of \transactionIDs\nufive{ and \wtxids} is described in \crossref{txnidentifiers}.
\nufive{For more detail on the distinction between these two identifiers and when to
use each of them, see \cite{ZIP-239} and \cite{ZIP-244}.}

\vspace{2ex}
\defining{\xTransparentInputs} to a \transaction insert value into a \defining{\transparentTxValuePool}
associated with the \transaction, and \defining{\transparentOutputs} remove value from this pool.
As in \Bitcoin, the remaining value in the \transparentTxValuePool of a non-coinbase
\transaction is available to miners as a fee. The remaining value in the \transparentTxValuePool
of a \coinbaseTransaction is destroyed.

\vspace{-1ex}
\consensusrule{
The remaining value in the \transparentTxValuePool \MUST be nonnegative.
}
\vspace{2ex}

\introlist
To each \transaction there are associated initial \defining{\treestates}
for \Sprout\sapling{ and for \Sapling}\nufive{ and for \Orchard}. \sapling{Each}
\treestate consists of:

\begin{itemize}
  \item a \noteCommitmentTree (\crossref{notecommitmenttrees});
  \item a \nullifierSet (\crossref{nullifierset}).
\end{itemize}

\vspace{-1ex}
Validation state associated with \transparent inputs and outputs, such as the \utxoSetFull,
is not described in this document; it is used in essentially the same way as in \Bitcoin.

An \defining{\anchor} is a Merkle tree root of a \noteCommitmentTree\sapling{ (either the
\Sprout tree or the \Sapling tree\nufive{ or the \Orchard tree})}. It uniquely identifies
a \noteCommitmentTree state given the assumed security properties of the Merkle tree's
\hashFunction. Since the \nullifierSet is always updated together with the
\noteCommitmentTree, this also identifies a particular state of the associated
\nullifierSet.

\introsection
In a given \blockChain, \sapling{for each of \Sprout and \SaplingAndOrchard,}
\treestates are chained as follows:

\begin{itemize}
  \item The input \treestate of the first \block is the empty \treestate.
  \item The input \treestate of the first \transaction of a \block is the final
        \treestate of the immediately preceding \block.
  \item The input \treestate of each subsequent \transaction in a \block is the
        output \treestate of the immediately preceding \transaction.
  \item The final \treestate of a \block is the output \treestate of its last
        \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
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.
In \Sprout, this kind of value transfer was the primary \Zcash-specific operation
performed by \transactions.

A \joinSplitTransfer spends $\NOld$ \notes $\nOld{\allOld}$ and \transparentInput
$\vpubOld$, and creates $\NNew$ \notes $\nNew{\allNew}$ and \transparentOutput
$\vpubNew$.
It is associated with a \joinSplitStatement instance (\crossref{joinsplitstatement}),
for which it provides a \zkSNARKProof.

Each \transaction has a sequence of \joinSplitDescriptions.

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
\Sprout \treestate.

For each of the $\NOld$ \shieldedInputs, a \nullifier is revealed. This allows
detection of \doubleSpends as described in \crossref{nullifierset}.

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.
This interstitial output \treestate is available for use as the \anchor of subsequent
\joinSplitDescriptions in the same \transaction. In general, therefore, the set
of interstitial \treestates associated with a \transaction forms a tree in which
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.

The input and output values of each \joinSplitTransfer \MUST balance exactly. This
is not a consensus rule since it cannot be checked directly; it is enforced by the
\snarkref{Balance}{sproutbalance} rule of the \joinSplitStatement.

\begin{consensusrules}
  \item For the first \joinSplitDescription of a \transaction, the \anchor \MUST
        be the output \Sprout \treestate of a previous \block.
        \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}


\sapling{
\vspace{-1ex}
\lsubsection{Spend Transfers, Output Transfers, and their Descriptions}{spendsandoutputs}

\vspace{-1ex}
\joinSplitTransfers are not used for \Sapling \notes. \defining{Instead, there is a
separate \spendTransfer for each \shieldedInput, and a separate \outputTransfer
for each \shieldedOutput.}

\defining{\spendDescriptions and \outputDescriptions} are data included in a \transaction
that describe \spendTransfers and \outputTransfers, respectively.

A \spendTransfer spends a \note $\nOld{}$. Its \spendDescription includes a
\defining{\xPedersenValueCommitment} to the value of the \note.
It is associated with an instance of a \spendStatement (\crossref{spendstatement})
for which it provides a \zkSNARKProof.

An \outputTransfer creates a \note $\nNew{}$. Similarly, its \outputDescription
includes a \xPedersenValueCommitment to the \note value.
It is associated with an instance of an \outputStatement (\crossref{outputstatement})
for which it provides a \zkSNARKProof.

Each \transaction has a sequence of \spendDescriptions and a sequence of
\outputDescriptions.

To ensure balance, we use a homomorphic property of \xPedersenCommitments that
allows them to be added and subtracted, as elliptic curve points (\crossref{concretehomomorphiccommit}).
The result of adding two \xPedersenValueCommitments, committing to values $\Value_1$ and
$\Value_2$, is a new \xPedersenValueCommitment that commits to $\Value_1 + \Value_2$.
Subtraction works similarly.

Therefore, balance can be enforced by adding all of the \defining{\valueCommitments} for
\shieldedInputs, subtracting all of the \valueCommitments for \shieldedOutputs,
and proving by use of a \saplingBindingSignature (as described in \crossref{saplingbalance})
that the result commits to a value consistent with the net \transparent value change.
This approach allows all of the \zkSNARK \statements to be independent of
each other, potentially increasing opportunities for precomputation.

A \spendDescription specifies an \anchor, which refers to the output \Sapling \treestate
of a previous \block. It also reveals a \nullifier, which allows detection of \doubleSpends
as described in \crossref{nullifierconcept}.

\vspace{-2ex}
\nnote{
Interstitial \treestates are not necessary for \Sapling, because a \spendTransfer
in a given \transaction cannot spend any of the \shieldedOutputs of the same
\transaction. This is not an onerous restriction because, unlike \Sprout where
each \joinSplitTransfer must balance individually, in \Sapling it is only necessary
for the whole \transaction to balance.
}

\begin{consensusrules}
  \item The \spendTransfers and \actionTransfers of a \transaction \MUST be consistent
        with its $\vBalance{Sapling}$ value as specified in \crossref{saplingbalance}.
  \item The \anchor of each \spendDescription \MUST refer to some earlier \block's final
        \Sapling \treestate. \nufive{The \anchor is encoded separately in each \spendDescription
        for v4 \transactions, or encoded once and shared between all \spendDescriptions
        in a v5 \transaction.}
\end{consensusrules}
} %sapling


\nufive{
\lsubsection{Action Transfers and their Descriptions}{actions}

\Orchard introduces \defining{\actionTransfers}, each of which can optionally perform
a spend, and optionally perform an output.

\defining{\actionDescriptions} are data included in a \transaction that describe
\actionTransfers.

An \actionTransfer spends a \note $\nOld{}$, and creates a \note $\nNew{}$. Its
\actionDescription includes a \defining{\xPedersenValueCommitment} to the net value,
i.e.\ the value of the spent \note minus the value of the created \note.
It is associated with an instance of an \actionStatement (\crossref{actionstatement})
for which it provides a \zkSNARKProof.

Each version 5 \transaction has a sequence of \actionDescriptions. Version 4 \transactions
cannot contain \actionDescriptions.

As in \Sapling, we use the homomorphic property of \xPedersenCommitments to enforce
balance: we add all of the \defining{\valueCommitments} and prove by use of an
\orchardBindingSignature that the result commits to a value consistent with the net
\transparent value change (as described in \crossref{orchardbalance}).
This approach allows all of the \zkSNARK \statements to be independent of
each other, potentially increasing opportunities for precomputation.

The fields of an \actionDescription are essentially a merger of the fields of a
\spendDescription and an \outputDescription, but with only a single \valueCommitment.
Also, the \zkSNARKProof is encoded outside the \actionDescription, in order to more
easily take advantage of space and performance optimizations in the \HaloTwo proof system
(\crossref{halo2}) that apply when multiple proofs are aggregated. Each \actionDescription
does not encode a separate \anchor field, because that is encoded once in the
$\anchorField{Orchard}$ field of the \transaction{}.

\vspace{-1ex}
\nnote{
As with \Sapling, interstitial \treestates are not necessary for \Orchard, because an
\actionTransfer in a given \transaction cannot spend any of the \shieldedOutputs of
the same \transaction.
}
\begin{consensusrules}
  \item The \actionTransfers of a \transaction \MUST be consistent
        with its $\vBalance{Orchard}$ value as specified in \crossref{orchardbalance}.
  \item The $\anchorField{Orchard}$ field of the \transaction, whenever it exists (i.e.\
        when there are any \actionDescriptions), \MUST refer to some earlier \block's
        final \Orchard \treestate.
\end{consensusrules}
} %nufive


\introsection
\extralabel{merkletree}{\lsubsection{Note Commitment Trees}{notecommitmenttrees}}

Let $\MerkleHashLength{Sprout}$, $\MerkleDepth{Sprout}$\sapling{, $\MerkleHashLength{Sapling}$,\notnufive{ and }
$\MerkleDepth{Sapling}$}\nufive{, $\MerkleHashLength{Orchard}$, and $\MerkleDepth{Orchard}$} be as
defined in \crossref{constants}.

\vspace{-1ex}
\begin{center}
\includegraphics[scale=.4]{incremental_merkle}
\end{center}
\vspace{-1ex}

\defining{A \noteCommitmentTree is an \incrementalMerkleTree} of fixed depth used to store
\noteCommitments that \joinSplitTransfers\sapling{ or \spendTransfers}\nufive{ or \actionTransfers}
produce. Just as the \defining{\utxoSetFull} used in \Bitcoin, it is used to express
the existence of value and the capability to spend it. However, unlike the \utxoSet,
it is \emph{not} the job of this tree to protect against \doubleSpending, as it is
append-only.

A \defining{\merkleRoot} of a \noteCommitmentTree is associated with each \treestate
(\crossref{transactions}).

Each \defining{\merkleNode} in the \incrementalMerkleTree is associated with
a \defining{\merkleHash} of size $\MerkleHashLength{Sprout}$\sapling{ or
$\MerkleHashLength{Sapling}$}\nufive{ or $\MerkleHashLength{Orchard}$} bits.
The \defining{\merkleLayer} numbered $h$, counting from \merkleLayer $0$ at the
\merkleRoot, has $2^h$ \merkleNodes with \defining{\merkleIndices} $0$ to $2^h-1$
inclusive. The \merkleHash associated with the \merkleNode at \merkleIndex $i$ in
\merkleLayer $h$ is denoted $\MerkleNode{h}{i}$.

The \merkleIndex of a \notesCommitment at the leafmost layer
($\MerkleDepth{Sprout}$\sapling{ or $\MerkleDepth{Sapling}$}\nufive{ or $\MerkleDepth{Orchard}$})
is called its \defining{\notePosition}.

\begin{consensusrules}
  \item A \block \MUSTNOT add \Sprout \noteCommitments that would result in the
        \Sprout \noteCommitmentTree exceeding its capacity of $2^{\MerkleDepth{Sprout}}$
        \merkleLeafNodes.
  \saplingonwarditem{A \block \MUSTNOT add \Sapling \noteCommitments that would result in the
        \Sapling \noteCommitmentTree exceeding its capacity of $2^{\MerkleDepth{Sapling}}$
        \merkleLeafNodes.}
  \nufiveonwarditem{A \block \MUSTNOT add \Orchard \noteCommitments that would result in the
        \Orchard \noteCommitmentTree exceeding its capacity of $2^{\MerkleDepth{Orchard}}$
        \merkleLeafNodes.}
\end{consensusrules}


\lsubsection{Nullifier Sets}{nullifierset}

Each \fullValidator maintains a \defining{\nullifierSet} logically associated with
each \treestate. As valid \transactions containing \joinSplitTransfers\sapling{ or
\spendTransfers}\nufive{ or \actionTransfers} are processed, the \defining{\nullifiers}
revealed in \joinSplitDescriptions\sapling{ and \spendDescriptions}\nufive{ and
\actionDescriptions} are inserted into the \nullifierSet associated with the new \treestate.
\xNullifiers are enforced to be unique within a \validBlockChain, in order to prevent
\doubleSpends.

\consensusrule{
A \nullifier \MUSTNOT repeat either within a \transaction, or across \transactions
in a \validBlockChain. \sapling{\Sprout and \SaplingAndOrchard \nullifiers are
considered disjoint, even if they have the same bit pattern.}
}


\lsubsection{Block Subsidy\notbeforecanopy{, Funding Streams,} and Founders' Reward}{subsidyconcepts}

Like \Bitcoin, \Zcash creates currency when \blocks are mined. The value created on
mining a \block is called the \defining{\blockSubsidy}.

\precanopy{The \blockSubsidy is composed of a \defining{\minerSubsidy} and a \defining{\foundersReward}.}

\canopyonward{The \blockSubsidy is composed of a \minerSubsidy and a series of \defining{\fundingStreams}.}

As in \Bitcoin, the miner of a \block also receives \defining{\transactionFees}.

The calculations of the \blockSubsidy, \minerSubsidy, \notcanopy{and }\foundersReward\canopy{, and \fundingStreams}
depend on the \blockHeight, as defined in \crossref{blockchain}.

The calculations are described in \crossref{subsidies}.


\lsubsection{Coinbase Transactions}{coinbasetransactions}

A \transaction that has a single \transparentInput with a null \prevoutField{} field, is
called a \defining{\coinbaseTransaction}. Every \block has a single \coinbaseTransaction
as the first \transaction in the \block. The purpose of this \coinbaseTransaction is to
collect and spend any \minerSubsidy, and \transactionFees paid by other \transactions included
in the \block.

\precanopy{As described in \crossref{foundersreward}, the \coinbaseTransaction \MUST also pay
the \foundersReward.}

\canopyonward{As described in \crossref{fundingstreams}, the \coinbaseTransaction \MUST also pay
the \fundingStreams.}


\lsubsection{Mainnet and Testnet}{networks}

The production \Zcash{} \defining{\network}, which supports the \ZEC token, is called \Mainnet. Governance of its
protocol is by agreement between the Electric Coin Company and the Zcash Foundation \cite{ECCZF2019}.
Subject to errors and omissions, each version of this document intends to describe some version
(or planned version) of that agreed protocol.

\defining{All \blockHashes given in this section are in \rpcByteOrder (that is, byte-reversed
relative to the normal order for a $\SHAFull$ hash).}

\Mainnet \genesisBlock: $\mathtt{00040fe8ec8471911baa1db1266ea15dd06b4a8a5c453883c000b031973dce08}$

\Mainnet \NUFive \activationBlock: $\mathtt{0000000000d723156d9b65ffcf4984da7a19675ed7e2f06d9e5d5188af087bf8}$

\introlist
There is also a public test \network called \Testnet. It supports a \TAZ token which is intended to
have no monetary value. By convention, \Testnet activates \networkUpgrades (as described in
\crossref{networkupgrades}) before \Mainnet, in order to allow for errors or ambiguities in
their specification and implementation to be discovered. The \Testnet \blockChain is subject to
being rolled back to a prior \block at any time.

\Testnet \genesisBlock: $\mathtt{05a60a92d99d85997cce3b87616c089f6124d7342af37106edc76126334a2c38}$

\Testnet \NUFive \activationBlock: $\mathtt{0006d75c60b3093d1b671ff7da11c99ea535df9927c02e6ed9eb898605eb7381}$

We call the smallest units of currency (on either \network) \zatoshi.

On \Mainnet, $1$ \ZEC = $\pow{10}{8}$ \zatoshi. On \Testnet, $1$ \TAZ = $\pow{10}{8}$ \zatoshi.

Other \networks using variants of the \Zcash protocol may exist, but are not described by this specification.


\intropart
\extralabel{cautionlinkage}{\lsection{Abstract Protocol}{abstractprotocol}}

\vspace{-1ex}
\hfill\begin{minipage}{0.8\linewidth}
\small
\begin{poetry}
  \item \emph{`We all know that the only mental tool by means of which a very finite piece of reasoning}
  \item \emph{\hphantom{`}can cover a myriad cases is called ``abstraction''; as a result the effective exploitation of}
  \item \emph{\hphantom{`}[their] powers of abstraction must be regarded as one of the most vital activities of a}
  \item \emph{\hphantom{`}competent programmer. In this connection it might be worth-while to point out that the}
  \item \emph{\hphantom{`}purpose of abstracting is \textbf{not} to be vague, but to create a new semantic level in which}
  \item \emph{\hphantom{`}one can be absolutely precise.'}
        \vspace{0.5ex}
  \item \hfill--- Edsger Dijkstra, ``The Humble Programmer'' \cite{EWD-340}\!\!
\end{poetry}
\end{minipage}
\vspace{2ex}

Abstraction is an incredibly important idea in the design of any complex system. Without abstraction,
we would not be able to design anything as ambitious as a computer, or a cryptographic protocol.
Were we to attempt it, the computer would be hopelessly unreliable or the protocol would be insecure,
if they could be completed at all.

The aim of abstraction is primarily to limit how much a human working on a piece of a system has to
keep in mind at one time, in order to apprehend the connections of that piece to the remainder.
The work could be to extend or maintain the system, to understand its security or other properties,
or to explain it to others.

In this specification, we make use wherever possible of abstractions that have been developed by
the cryptography community to model cryptographic primitives: \pseudoRandomFunctions, \commitmentSchemes,
\signatureSchemes, etc.
Each abstract primitive has associated syntax (its interface as used by the rest of the system) and
security properties, as documented in this part. Their instantiations are documented in part
\crossref{concreteprotocol}.

In some cases this syntax or these security requirements have been extended to meet the needs of the
\Zcash protocol. For example, some of the PRFs used in \Zcash need to be \collisionResistant, which
is not part of the usual security requirement for a PRF; some \signatureSchemes need to support
additional functionality and security properties; and so on. Also, security requirements are sometimes
intentionally stronger than what is known to be needed, because the stronger property is simpler
or less error-prone to work with, and/or because it has been studied in the cryptographic literature
in more depth.

We explicitly \emph{do not claim}\!, however, that all of these instantiations satisfying their documented
syntax and security requirements would be sufficient for security or correctness of the overall \Zcash protocol,
or that it is always necessary. The claim is only that it helps to understand the protocol; that is, that
analysis or extension is simplified by making use of the abstraction. In other words,
\emph{a good way to understand} the use of that primitive in the protocol is to model it as an instance
of the given abstraction. And furthermore, if the instantiated primitive does not in fact satisfy the
requirements of the abstraction, then this is an error that should be corrected --whether or not it leads
to a vulnerability-- since that would compromise the facility to understand its use in terms of the abstraction.

In this respect the abstractions play a similar rôle to that of a type system (which we also use): they
add a form of redundancy to the specification that helps to express the intent.

Each property is a claim that may be incorrect (or that may be insufficiently precisely stated to
determine whether it is correct). An example of an incorrect security claim occurs in the \Zerocash protocol
\cite{BCGGMTV2014}: the instantiation of the \noteCommitment scheme used in \Zerocash failed to be \binding
at the intended security level (see \crossref{internalh}).

Another hazard that we should be aware of is that abstractions can be ``leaky'': an instantiation may impose
conditions on its correct or secure use that are not captured by the abstraction's interface and semantics.
Ideally, the abstraction would be changed to explicitly document these conditions, or the protocol changed to
rely only on the original abstraction.

An abstraction can also be incomplete (not quite the same thing as being leaky): it intentionally --usually
for simplicity-- does not model an aspect of behaviour that is important to security or correctness. An example
would be resistance to \sideChannel attacks; this specification says little about \sideChannel defence, among
many other implementation concerns.


\lsubsection{Abstract Cryptographic Schemes}{abstractschemes}

\lsubsubsection{Hash Functions}{abstracthashes}

Let $\MerkleDepth{Sprout}$, $\MerkleHashLength{Sprout}$,
\sapling{$\MerkleDepth{Sapling}$, $\MerkleHashLength{Sapling}$,}
\nufive{$\MerkleDepth{Orchard}$, $\MerkleHashLength{Orchard}$,}
\sapling{$\InViewingKeyLength{Sapling}$, $\DiversifierLength$,}
$\RandomSeedLength$, $\PRFOutputLengthSprout$, $\hSigLength$, and $\NOld$ be as defined in \crossref{constants}.

\sapling{
Let $\GroupJ$, $\SubgroupJ$, $\SubgroupJstar$, $\ParamJ{r}$, and $\ellJ$ be as defined in \crossref{jubjub}.
} %sapling

\nufive{
Let $\GroupPstar$ be as defined in \crossref{pallasandvesta}.
} %nufive

\introlist
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}$\notbeforenufive{ \\
\setnufive  $\MerkleCRH{Orchard}$ &\setnufive  $\typecolon\, \MerkleLayer{Orchard}$ &\setnufive  $\times\; \MerkleHashOrchard$   &\setnufive  $\times\; \MerkleHashOrchard$   &\setnufive  $\rightarrow \MerkleHashOrchard$}.
\end{tabular}

$\MerkleCRH{Sprout}$ is \collisionResistant except on its first argument.
\sapling{$\MerkleCRH{Sapling}$\notnufive{ is}\nufive{ and $\MerkleCRH{Orchard}$ are}
\collisionResistant on all\notnufive{ its}\nufive{ their} arguments.}

These functions are instantiated in \crossref{merklecrh}.

$\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}.

$\EquihashGen{} \typecolon (n \typecolon \PosInt) \times \PosInt \times \byteseqs \times \PosInt \rightarrow \bitseq{n}$
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$
is a \collisionResistant \hashFunction used in \crossref{saplingkeycomponents}
to derive an \incomingViewingKey for a \Sapling \shieldedPaymentAddress. It is also used
in the \spendStatement (\crossref{spendstatement}) to confirm use of the correct
keys for the \note being spent. It is instantiated in \crossref{concretecrhivk}.

$\MixingPedersenHash \typecolon \GroupJ \times \range{0}{\ParamJ{r}-1}
\rightarrow \GroupJ$ is a \hashFunction used in \crossref{rhoandnullifiers}
to derive the unique $\NoteUniqueRand$ value for a \Sapling \note. It is also used
in the \spendStatement to confirm use of the correct $\NoteUniqueRand$ value as an
input to \nullifier derivation. It is instantiated in \crossref{concretemixinghash}.

$\DiversifyHash{Sapling} \typecolon \DiversifierType \rightarrow \maybe{\SubgroupJstar}$\nufive{ and
$\DiversifyHash{Orchard} \typecolon \DiversifierType \rightarrow \GroupPstar$}\notnufive{ is a
\hashFunction}\nufive{ are \hashFunctions} instantiated in \crossref{concretediversifyhash},
satisfying the Unlinkability security property described in that section. \notnufive{It is}\nufive{They are}
used to derive a \diversifiedBase from a \diversifier, which is specified in
\crossref{saplingkeycomponents}\nufive{ and in \crossref{orchardkeycomponents}}.
} %sapling

\introsection
\lsubsubsection{Pseudo Random Functions}{abstractprfs}

$\PRF{x}{}$ denotes a \defining{\pseudoRandomFunction} keyed by $x$.

Let $\AuthPrivateLength$, $\hSigLength$, $\PRFOutputLengthSprout$, $\NoteUniquePreRandLength$,
\sapling{$\SpendingKeyLength$, $\OutViewingKeyLength$, $\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,}
$\NOld$, and $\NNew$ be as defined in \crossref{constants}.

\sapling{
Let $\Sym$ be as defined in \crossref{concretesym}.
} %sapling

\sapling{
\vspace{-0.5ex}
Let $\ellJ$ and $\SubgroupReprJ$ be as defined in \crossref{jubjub}.
} %sapling

\nufive{
Let $\ellP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.
} %nufive

\vspace{1ex}
\introlist
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$ \\
$\PRFrho{}            $&$\typecolon\; \bitseq{\NoteUniquePreRandLength} $&$\times\; \setofNew $&$\times\; \hSigType $&$\rightarrow \PRFOutputSprout$ \\
$\PRFnf{Sprout}{}     $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \PRFOutputSprout $& &$\rightarrow \PRFOutputSprout$
\end{tabular}

These are used in \crossref{joinsplitstatement}; $\PRFaddr{}$ is also used to
derive a \shieldedPaymentAddress from a \spendingKey in \crossref{sproutkeycomponents}.

\sapling{
\vspace{0.5ex}
\introlist
For \Sapling, three additional $\PRF{x}{}$ are needed:

\begin{tabular}{@{\hskip 2em}l@{\hskip 0.5em}l@{\;}l@{\;}l@{\hskip 0.33em}l}
$\PRFexpand{}         $&$\typecolon\; \SpendingKeyType            $&$\times\; \PRFInputExpand $& &$\rightarrow \PRFOutputExpand$ \\
$\PRFock{Sapling}{}   $&$\typecolon\; \OutViewingKeyType          $&$\times\; \ReprJBytes \times \ReprJBytes \times \ReprJBytes $& &$\rightarrow \Keyspace$ \\
$\PRFnf{Sapling}{}    $&$\typecolon\; \SubgroupReprJ              $&$\times\; \ReprJ $& &$\rightarrow \PRFOutputNfSapling$
\end{tabular}
} %sapling

\nufive{
\introlist
For \Orchard, we need $\PRFexpand{}$, and also:

\begin{tabular}{@{\hskip 2em}l@{\;}l@{\;}l@{\;}l@{\,}l}
$\PRFock{Orchard}{}   $&$\typecolon\; \OutViewingKeyType          $&$\times\; \ReprPBytes \times \ReprPBytes \times \ReprPBytes $& &$\rightarrow \Keyspace$ \\
$\PRFnf{Orchard}{}    $&$\typecolon\; \NullifierKeyTypeOrchard    $&$\times\; \NoteUniqueRandTypeOrchard $& &$\rightarrow \PRFOutputNfOrchard$
\end{tabular}
} %nufive

\introlist
$\PRFexpand{}$ is used in the following places:
\begin{itemize}
  \item \sapling{\crossref{saplingkeycomponents}, with inputs $[0]$, $[1]$, $[2]$, and $[3, i \typecolon \byte]$;}
  \nufiveonwarditem{in \crossref{orchardkeycomponents}, with inputs $[6]$, $[7]$, $[8]$, and with first byte $\hexint{82}$
        (the last of these is also specified in \cite{ZIP-32});}
\notnufive{
  \item \sapling{sending (\crossref{saplingsend}) and receiving (\shortcrossref{saplingandorchardinband}) \Sapling \notes,
        with inputs $[4]$ and $[5]$;}
} %notnufive
\notbeforenufive{
  \item \sapling{in the processes of sending (\crossref{saplingsend}\nufive{ and \crossref{orchardsend}}) and of receiving
        (\crossref{saplingandorchardinband}) \notes, with inputs $[4]$ and $[5]$\nufive{, and for \Orchard
        $[t] \bconcat \NoteUniqueRandBytes$ with $t \in \setof{5, 4, 9}$};}
} %notbeforenufive
  \item in \cite{ZIP-32}, \sapling{with inputs $[0]$, $[1]$, $[2]$ (intentionally matching \shortcrossref{saplingkeycomponents}),
        $[\hexint{10}]$, $[\hexint{13}]$, $[\hexint{14}]$, and} with first byte in
        $\setof{\sapling{\hexint{11}, \hexint{12}, \hexint{15}, \hexint{16}, \hexint{17}, \hexint{18},\,}\hexint{80}\nufive{, \hexint{81}, \hexint{82}, \hexint{83}}}$;
  \item in \cite{ZIP-316}, with first byte $\hexint{D0}$.
\end{itemize}

\sapling{
$\PRFock{Sapling}{}$\notnufive{ is}\nufive{ and $\PRFock{Orchard}{}$ are} used in \crossref{saplingandorchardinband}.

$\PRFnf{Sapling}{}$ is used in \crossref{spendstatement}.
} %sapling

\nufive{
$\PRFnf{Orchard}{}$ is used in \crossref{actionstatement}.
} %nufive

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}$, $\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, and similarly for $\PRFrho{}$, $\PRFnf{Sprout}{}$\sapling{,\notnufive{ and}
        $\PRFnf{Sapling}{}$}\nufive{, and $\PRFnf{Orchard}{}$}.
\nufive{
  \item See the note in \crossref{orchardkeycomponents} for a security caveat about the use of $\PRFexpand{}$.
} %nufive
\end{securityrequirements}

\vspace{-2ex}
\nnote{$\PRFnf{Sprout}{}$ was called $\PRFsn{}$ in \Zerocash \cite{BCGGMTV2014}, and just $\PRFnf{}{}$ in
some previous versions of this specification.}


\nufive{
\introsection
\lsubsubsection{Pseudo Random Permutations}{abstractprps}

$\PRP{x}{}$ denotes a \defining{\pseudoRandomPermutation} keyed by $x$.

Let $\DiversifierKeyLength$ and $\DiversifierLength$ be as defined in \crossref{constants}.

\vspace{1ex}
One \pseudoRandomPermutation is used for \Orchard, to generate \diversifiers from a \diversifierKey
and index (an identical construction is also used for \Sapling in \cite{ZIP-32}):

\begin{formulae}
  \item $\PRPd{} \typecolon \DiversifierKeyType \times \DiversifierType \rightarrow \DiversifierType$.
\end{formulae}

It is instantiated in \crossref{concreteprps}.

\vspace{-2ex}
\securityrequirement{
$\PRPd{}$ is a keyed \pseudoRandomPermutation as defined in \cite{BKR2001}.
} %securityrequirement
} %nufive


\introsection
\lsubsubsection{Symmetric Encryption}{abstractsym}

Let $\Sym$ be an \defining{\symmetricEncryptionScheme} with keyspace $\Keyspace$, encrypting
plaintexts in $\Plaintext$ to produce ciphertexts in $\Ciphertext$.

$\SymEncrypt{} \typecolon \Keyspace \times \Plaintext \rightarrow \Ciphertext$
is the encryption algorithm.

$\SymDecrypt{} \typecolon \Keyspace \times \Ciphertext \rightarrow
\maybe{\Plaintext}$ is the decryption algorithm, such that
for any $\Key \in \Keyspace$ and $\Ptext \in \Plaintext$,
$\SymDecrypt{\Key}(\SymEncrypt{\Key}(\Ptext)) = \Ptext$.
$\bot$ is used to represent the decryption of an invalid ciphertext.

\securityrequirement{
$\Sym$ must be \defining{\oneTime} \nh{(INT-CTXT $\wedge$ IND-CPA)-secure} \cite{BN2007}.
\quotedtermnoindex{One-time} here means that an honest protocol participant will
almost surely encrypt only one message with a given key; however, the adversary
may make many adaptive chosen ciphertext queries for a given key.
}

\lsubsubsection{Key Agreement}{abstractkeyagreement}

A \defining{\keyAgreementScheme} is a cryptographic protocol in which two parties agree
a shared secret, each using their \defining{\privateKey} and the other party's \publicKey.

A \keyAgreementScheme $\KA{}$ defines a type of \publicKeys $\KAPublic{}$, a type
of \privateKeys $\KAPrivate{}$, and a type of shared secrets $\KASharedSecret{}$.
\sapling{Optionally, it also defines a type $\KAPublicPrimeSubgroup{} \subseteq \KAPublic{}$.}

\sapling{Optional:} Let $\KAFormatPrivate{} \typecolon \PRFOutputSprout \rightarrow \KAPrivate{}$
be a function to convert a bit string of length $\PRFOutputLengthSprout$ to a $\KA{}$ \privateKey.

Let $\KADerivePublic{} \typecolon \KAPrivate{} \times \KAPublic{} \rightarrow \KAPublic{}$
be a function that derives the $\KA{}$ \publicKey corresponding to a given $\KA{}$
\privateKey and base point.

Let $\KAAgree{} \typecolon \KAPrivate{} \times \KAPublic{} \rightarrow \KASharedSecret{}$
be the agreement function.

\sapling{Optional:} Let $\KABase{} \typecolon \KAPublic{}$ be a public base point.

\pnote{The range of $\KADerivePublic{}$ may be a strict subset of $\KAPublic{}$.}

\begin{securityrequirements}
  \item $\KAFormatPrivate{}$ must preserve sufficient entropy from its input to be used
        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}.
\end{securityrequirements}

More precise formalization of these requirements is beyond the scope of this
specification.


\lsubsubsection{Key Derivation}{abstractkdf}

A \defining{\keyDerivationFunction} is defined for a particular \keyAgreementScheme and
\symmetricEncryptionScheme; it takes the shared secret produced by the key
agreement and additional arguments, and derives a key suitable for the encryption
scheme.

\introlist
\sapling{The inputs to the \keyDerivationFunction differ between the \Sprout and
\SaplingAndOrchard KDFs:}

$\KDF{Sprout}$ takes as input an output index in $\setofNew$, the
value $\hSig$, the shared Diffie--Hellman secret $\DHSecret{}$,
the \ephemeralPublicKey $\EphemeralPublic$, and the recipient's
public \transmissionKey $\TransmitPublic$. It is suitable for use
with $\KA{Sprout}$ and derives keys for $\SymEncrypt{}$.

\begin{formulae}
  \item $\KDF{Sprout} \typecolon \setofNew \times \hSigType \times \KASharedSecret{Sprout}
         \times \KAPublic{Sprout} \times \KAPublic{Sprout} \rightarrow \Keyspace$
\end{formulae}

\sapling{
\introlist
$\KDF{Sapling}$ takes as input the shared Diffie--Hellman secret $\DHSecret{}$ and
the \ephemeralPublicKey $\EphemeralPublic$. (It does not have inputs taking the
place of the output index, $\hSig$, or $\TransmitPublic$.) It is suitable for use
with $\KA{Sapling}$ and derives keys for $\SymEncrypt{}$.

\begin{formulae}
  \item $\KDF{Sapling} \typecolon \KASharedSecret{Sapling} \times \byteseq{\ellJ/8} \rightarrow \Keyspace$
\end{formulae}
} %sapling

\nufive{
\introlist
As in \Sapling, $\KDF{Orchard}$ takes as input the shared Diffie--Hellman secret
$\DHSecret{}$ and the \ephemeralPublicKey $\EphemeralPublic$. It is suitable for use
with $\KA{Orchard}$ and derives keys for $\SymEncrypt{}$.

\begin{formulae}
  \item $\KDF{Orchard} \typecolon \KASharedSecret{Orchard} \times \byteseq{\ellP/8} \rightarrow \Keyspace$
\end{formulae}
} %nufive

\vspace{-1.5ex}
\begin{securityrequirements}
  \item The asymmetric encryption scheme in \crossref{sproutinband}, constructed
        from $\KA{Sprout}$, $\KDF{Sprout}$ and $\Sym$, is required to be \nh{IND-CCA2-secure}
        and \keyPrivate.
  \item \sapling{
        The asymmetric encryption scheme in \crossref{saplingandorchardinband}, constructed
        from $\KA{Sapling}$, $\KDF{Sapling}$ and $\Sym$\nufive{ or from $\KA{Orchard}$,
        $\KDF{Orchard}$ and $\Sym$}, is required to be \nh{IND-CCA2-secure} and \keyPrivate.
        } %sapling
\end{securityrequirements}

\defining{\xKeyPrivacy is defined in \cite{BBDP2001}.}


\vspace{-1ex}
\introlist
\lsubsubsection{Signature}{abstractsig}

\vspace{-1ex}
A \defining{\signatureScheme} $\Sig$ defines:

\begin{itemize}
  \item a type of \defining{\signingKeys} $\SigPrivate$;
  \item a type of \defining{\validatingKeys} $\SigPublic$;
  \item a type of messages $\SigMessage$;
  \item a type of signatures $\SigSignature$;
  \item a randomized \signingKey generation algorithm $\SigGenPrivate \typecolon () \rightarrowR \SigPrivate$;
  \item an injective \validatingKey derivation algorithm $\SigDerivePublic \typecolon \SigPrivate \rightarrow \SigPublic$;
  \item a randomized signing algorithm $\SigSign{} \typecolon \SigPrivate \times \SigMessage \rightarrowR \SigSignature$;
  \item a validating algorithm $\SigValidate{} \typecolon \SigPublic \times \SigMessage \times \SigSignature \rightarrow \bit$;
\end{itemize}

\vspace{-2ex}
such that for any \signingKey $\sk \leftarrowR \SigGenPrivate()$ and corresponding
\validatingKey $\vk = \SigDerivePublic(\sk)$, and
any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrowR \SigSign{\sk}(m)$,
$\SigValidate{\vk}(m, s) = 1$.

\vspace{1ex}
\introlist
\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});
        \vspace{-0.5ex}
  \saplingonwarditem{one called $\SpendAuthSig{}$ which is used to sign authorizations
        of \spendTransfers (instantiated in \crossref{concretespendauthsig});}
        \vspace{-0.5ex}
  \saplingonwarditem{one called $\BindingSig{}$. A \saplingBindingSignature is used to
        enforce balance of \spendTransfers and \outputTransfers, and to prevent their
        replay across \transactions. \nufive{Similarly, an \orchardBindingSignature
        is used to enforce balance of \actionTransfers and to prevent their replay.}
        $\BindingSig{}$ is instantiated\nufive{ for both \SaplingAndOrchard} in
        \crossref{concretebindingsig}.}
\end{itemize}

\vspace{-1ex}
The signature scheme used in script operations is instantiated by \ECDSA on the \secpCurve.
$\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}.}

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}.}

\vspace{-1ex}
\securityrequirement{
$\JoinSplitSig$\sapling{ and\nufive{ each instantiation of} $\BindingSig{}$} must be
Strongly Unforgeable under (non-adaptive) Chosen Message Attack \nh{(SU-CMA)}, as defined for example in
\cite[Definition 6]{BDEHR2011}.\footnote{The scheme defined in that paper was attacked in \cite{LM2017},
but this has no impact on the applicability of the definition.}
This allows an adversary to obtain signatures on chosen messages, and then requires it to be
infeasible for the adversary to forge a previously unseen valid \mbox{(message, signature)}
pair without access to the \signingKey.
}

\vspace{1ex}
\begin{nnotes}
  \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
        the key derivation in \crossref{saplingkeycomponents}\nufive{ and in
        \crossref{orchardkeycomponents}}.

        The definitions of schemes with additional features in \crossref{abstractsigrerand}
        and in \crossref{abstractsigmono} also become simpler.
  \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}),
        a \defining{\oneTimeSignatureScheme} would suffice for $\JoinSplitSig$.
        This is also the reason why only security against \emph{non-adaptive}
        chosen message attack is needed. In fact the instantiation of $\JoinSplitSig$
        uses a scheme designed for security under adaptive attack even when multiple
        signatures are signed under the same key.
  \saplingonwarditem{The same remarks as above apply to $\BindingSig{}$, except that
        the key is derived from the randomness of \valueCommitments. This results
        in the same distribution as of freshly generated key pairs, for each
        \transaction containing \spendDescriptions or \outputDescriptions\nufive{ or
        \actionDescriptions}.}
  \item \nh{SU-CMA} security requires it to be infeasible for the adversary, not
        knowing the \defining{\privateKey}, to forge a distinct signature on a
        previously seen message. That is, \joinSplitSignatures\sapling{ and
        \saplingBindingSignatures}\nufive{ and \orchardBindingSignatures}
        are intended to be \defining{\sigNonmalleable} in the sense of \cite{BIP-62}.
  \item The terminology used in this specification is that we ``validate'' signatures, and
        ``verify'' \zkSNARKProofs.
\end{nnotes}


\sapling{
\vspace{-2ex}
\introsection
\lsubsubsubsection{Signature with Re-Randomizable Keys}{abstractsigrerand}

\vspace{-2ex}
A \defining{\rerandomizableSignatureScheme} $\Sig$ is a \signatureScheme that
additionally defines:

\begin{itemize}
  \item a type of \defining{\randomizers} $\SigRandom$;
  \item a \randomizer generator $\SigGenRandom \typecolon () \rightarrowR \SigRandom$;
  \item a \signingKey randomization algorithm $\SigRandomizePrivate \typecolon \SigRandom \times \SigPrivate \rightarrow \SigPrivate$;
  \item a \validatingKey randomization algorithm $\SigRandomizePublic \typecolon \SigRandom \times \SigPublic \rightarrow \SigPublic$;
  \item a distinguished ``identity'' \randomizer $\SigRandomizerId \typecolon \SigRandom$
\end{itemize}

\vspace{-1.6ex}
such that:
\vspace{0.8ex}

\begin{itemize}
  \item for any $\SigRandomizer \typecolon \SigRandom$,
        $\SigRandomizePrivate_{\SigRandomizer} \typecolon \SigPrivate \rightarrow \SigPrivate$
        is injective and easily invertible;
  \item $\SigRandomizePrivate_{\SigRandomizerId}$ is the identity function on $\SigPrivate$.
        \vspace{0.3ex}
        \introlist
  \item for any $\sk \typecolon \SigPrivate$,
        \begin{formulae}
          \item $\SigRandomizePrivate(\SigRandomizer, \sk) : \SigRandomizer \leftarrowR \SigGenRandom()$
        \end{formulae}
        \vspace{-1.5ex} is identically distributed to $\SigGenPrivate()$.
        \vspace{0.3ex}
  \item for any $\sk \typecolon \SigPrivate$ and $\SigRandomizer \typecolon \SigRandom$,
        \begin{formulae}
           \item $\SigRandomizePublic(\SigRandomizer, \SigDerivePublic(\sk)) =
                  \SigDerivePublic(\SigRandomizePrivate(\SigRandomizer, \sk))$.
        \end{formulae}
\end{itemize}

\vspace{-1.5ex}
The following security requirement for such \signatureSchemes is based on that
given in \cite[section 3]{FKMSSS2016}. \defining{Note that we require Strong Unforgeability
with \xReRandomized Keys, not Existential Unforgeability with \xReRandomized Keys
(the latter is called ``Unforgeability under \xReRandomized Keys'' in
\cite[Definition 8]{FKMSSS2016}).} Unlike the case for $\JoinSplitSig$, we require
security under adaptive chosen message attack with multiple messages signed using
a given key. (Although each \note uses a different \reRandomized key pair, the same
original key pair can be \reRandomized for multiple \notes, and also it can happen
that multiple \transactions spending the same \note are revealed to an adversary.)

\introlist
\vspace{-0.5ex}
\securityrequirement{\textbf{Strong Unforgeability with Re-randomized Keys under adaptive Chosen Message Attack (SURK-CMA)}

For any $\sk \typecolon \SigPrivate$, let
\begin{formulae}
  \item $\Oracle_{\sk} \typecolon \SigMessage \times \SigRandom \rightarrow \SigSignature$
\end{formulae}
\vspace{-1ex}
be a signing oracle with state
$Q \typecolon \powerset{\SigMessage \times \SigSignature}$ initialized to $\setof{}$
that records queried messages and corresponding signatures.

\begin{algorithm}
  \item $\Oracle_{\sk} :=$ let mutable $Q \leftarrow \setof{}$ in $\fun{(m \typecolon \SigMessage, \SigRandomizer \typecolon \SigRandom)}{}$
  \item \tab let $\sigma = \SigSign{\SigRandomizePrivate(\SigRandomizer, \sk)}(m)$
  \item \tab set $Q \leftarrow Q \union \setof{(m, \sigma)}$
  \item \tab return $\sigma \typecolon \SigSignature$.
\end{algorithm}

For random $\sk \leftarrowR \SigGenPrivate()$ and $\vk = \SigDerivePublic(\sk)$, it must be
infeasible for an adversary given $\vk$ and a new instance of $\Oracle_{\sk}$ to find
$(m', \sigma', \SigRandomizer')$ such that
$\SigValidate{\SigRandomizePublic(\SigRandomizer', \vk)}(m', \sigma') = 1$ and
$(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$.
} %securityrequirement

\begin{nnotes}
  \item The \randomizer and key arguments to $\SigRandomizePrivate$ and $\SigRandomizePublic$
        are swapped relative to \cite[section 3]{FKMSSS2016}.
        \vspace{-0.5ex}
  \item The requirement for the identity \randomizer $\SigRandomizerId$ simplifies the
        definition of \nh{SURK-CMA} by removing the need for two oracles (because the oracle for
        original keys, called $\Oracle_1$ in \cite{FKMSSS2016}, is a special case of the
        oracle for randomized keys).
        \vspace{-0.5ex}
  \item Since $\SigRandomizePrivate(\SigRandomizer, \sk) :
        \SigRandomizer \leftarrowR \SigRandom$ has an identical distribution to $\SigGenPrivate()$,
        and since $\SigDerivePublic$ is a deterministic function, the combination of a \reRandomized
        \validatingKey and signature(s) under that key do not reveal the key from which it was
        \reRandomized.
        \vspace{-0.5ex}
  \item Since $\SigRandomizePrivate_{\SigRandomizer}$ is injective and
        easily invertible, knowledge of $\SigRandomizePrivate(\SigRandomizer, \sk)$
        \emph{and} $\SigRandomizer$ implies knowledge of $\sk$.
\end{nnotes}
} %sapling


\sapling{
\introlist
\vspace{-3ex}
\lsubsubsubsection{Signature with Signing Key to Validating Key Monomorphism}{abstractsigmono}

\vspace{-2ex}
A \defining{\keyMonomorphicSignatureScheme} $\Sig$ is a \signatureScheme that
additionally defines:

\begin{itemize}
  \item an abelian group on \signingKeys, with operation
        $\grpplus\!\! \typecolon \SigPrivate \times \SigPrivate \rightarrow \SigPrivate$ and
        identity $\grpzero$;
  \item an abelian group on \validatingKeys, with operation
        $\combplus\!\! \typecolon \SigPublic \times \SigPublic \rightarrow \SigPublic$ and
        identity $\combzero$.
\end{itemize}

\vspace{-1.5ex}
such that for any $\sk_{\oneto{2}} \typecolon \SigPrivate$,
$\SigDerivePublic(\sk_1 \grpplus \sk_2) = \SigDerivePublic(\sk_1)\, \combplus \SigDerivePublic(\sk_2)$.

In other words, $\SigDerivePublic$ is a \defining{\monomorphism (that is, an injective homomorphism)} from the
\signingKey group to the \validatingKey group.

\vspace{0.5ex}
\introlist
For $\rmN \typecolon \PosInt$,
\begin{itemize}
  \item $\sgrpsum{i=1}{\rmN} \sk_i$ means $\sk_1 \grpplus \sk_2 \grpplus \cdots\, \grpplus \sk_{\rmN}$;
  \item $\scombsum{i=1}{\rmN} \vk_i$ means $\vk_1 \combplus \vk_2 \combplus \cdots\, \combplus \vk_{\rmN}$.
\end{itemize}
\vspace{-2ex}
When $\rmN = 0$ these yield the appropriate group identity, i.e. $\sgrpsum{i=1}{0} \sk_i = \grpzero$
and $\scombsum{i=1}{0} \vk_i = \combzero$.

$\grpneg \sk$ means the \signingKey such that $(\grpneg \sk) \grpplus \sk = \grpzero$,
and $\sk_1 \grpminus \sk_2$ means $\sk_1 \grpplus\, (\grpneg \sk_2)$.

$\combneg \vk$ means the \validatingKey such that $(\combneg \vk) \combplus \vk = \combzero$,
and $\vk_1 \combminus \vk_2$ means $\vk_1 \combplus\, (\combneg \vk_2)$.

\vspace{1ex}
With a change of notation from $\mu$ to $\SigDerivePublic$, $+$ to $\grpplus$, and $\mult$ to $\combplus$,
this is similar to the definition of a \quotedtermnoindex{Signature with Secret Key to Public Key Homomorphism}
in \cite[Definition 13]{DS2016}, except for an additional requirement for the homomorphism to be injective.

\introlist
\vspace{-1ex}
\securityrequirement{
For any $\sk_1 \typecolon \SigPrivate$, and an unknown $\sk_2 \leftarrowR \SigGenPrivate()$
chosen independently of $\sk_1$, the distribution of $\sk_1 \grpplus \sk_2$ is
computationally indistinguishable from that of $\SigGenPrivate()$.
(Since $\grpplus$ is an abelian group operation, this implies that for $n \typecolon \PosInt$,
$\sgrpsum{i=1}{n} \sk_i$ is computationally indistinguishable from $\SigGenPrivate()$
when at least one of $\sk_{\alln}$ is unknown.)
} %securityrequirement
} %sapling


\introlist
\vspace{-1ex}
\lsubsubsection{Commitment}{abstractcommit}

\vspace{-1ex}
\defining{
A \commitmentScheme is a function that, given a \commitmentTrapdoor generated at
random and an input, can be used to commit to the input in such a way that:

\begin{itemize}
  \item no information is revealed about it without the \trapdoor (\quotedHiding); and
  \item given the \trapdoor and input, the commitment can be verified to \quotedtermandindex{open}{open (a commitment)}
        to that input and no other (\quotedBinding)\rlap{.}
\end{itemize}
} %defining

\vspace{-1ex}
A \commitmentScheme $\CommitAlg$ defines a type of inputs $\CommitInput$,
a type of commitments $\CommitOutput$, a type of \commitmentTrapdoors
$\CommitTrapdoor$, and a \trapdoor generator $\CommitGenTrapdoor \typecolon () \rightarrowR \CommitTrapdoor$.

\vspace{1ex}
Let $\CommitAlg \typecolon \CommitTrapdoor \times \CommitInput \rightarrow \CommitOutput$
be a function satisfying the following security requirements.

\begin{securityrequirements}[leftmargin=2em]
  \item \textbf{Computational \hiding:} For all $x, x' \typecolon \CommitInput$,
        the distributions $\{\, \Commit{r}(x) \;|\; r \leftarrowR \CommitGenTrapdoor() \,\}$
        and $\{\, \Commit{r}(x') \;|\; r \leftarrowR \CommitGenTrapdoor() \,\}$ are
        computationally indistinguishable.
  \item \textbf{Computational \binding:} It is infeasible to find
        $x, x' \typecolon \CommitInput$ and
        $r, r' \typecolon \CommitTrapdoor$
        such that $x \neq x'$ and $\Commit{r}(x) = \Commit{r'}(x')$.
\end{securityrequirements}

\vspace{-1ex}
\begin{pnotes}[leftmargin=2em]
  \item $\CommitGenTrapdoor$ need not produce the uniform distribution on $\CommitTrapdoor$.
        In that case, it is incorrect to choose a \trapdoor from the latter distribution.
  \item 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.
        \sapling{(In fact, this is feasible for $\NoteCommitAlg{Sapling}$ and $\ValueCommitAlg{Sapling}$
        because \trapdoors are equivalent modulo $\ParamJ{r}$, and the range of a \trapdoor
        for those algorithms is $\binaryrange{\ScalarLength{Sapling}}$ where
        $2^{\ScalarLength{Sapling}} > \ParamJ{r}$.)}
\end{pnotes}

\vspace{1ex}
Let $\NoteCommitRandLengthSprout$, $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$,
and $\ValueLength$ be as defined in \crossref{constants}.

Define $\NoteCommitTrapdoor{Sprout} := \bitseq{\NoteCommitRandLengthSprout}$ and
$\NoteCommitOutput{Sprout} := \bitseq{\MerkleHashLength{Sprout}}$.

\introlist
\Sprout uses a \noteCommitmentScheme

\begin{tabular}{@{\hskip 1.5em}r@{\;}l}
  $\NoteCommit{Sprout}{}  $&$\typecolon\; \NoteCommitTrapdoor{Sprout} \times \PRFOutputSprout
     \times \ValueType \times \PRFOutputSprout$ \\[-1ex]
  \hphantom{$\NoteCommitAlg{Sapling}$} &\hspace{26.9em}$\rightarrow \NoteCommitOutput{Sprout}$,
\end{tabular}

instantiated in \crossref{concretesproutnotecommit}.

\sapling{
\vspace{2ex}
Let $\ScalarLength{Sapling}$ be as defined in \crossref{constants}.

Let $\SubgroupJ$, $\ellJ$, and $\ParamJ{r}$ be as defined in \crossref{jubjub}.

\introlist
Define:
\begin{formulae}
  \item $\NoteCommitTrapdoor{Sapling} := \binaryrange{\ScalarLength{Sapling}}$ and
        $\NoteCommitOutput{Sapling} := \GroupJ$;
  \item $\ValueCommitTrapdoor{Sapling} := \binaryrange{\ScalarLength{Sapling}}$ and
        $\ValueCommitOutput{Sapling} := \GroupJ$.
\end{formulae}

\introlist
\Sapling uses two additional \commitmentSchemes:

\begin{tabular}{@{\hskip 1.5em}r@{\;}l@{\;}l}
  $\NoteCommitAlg{Sapling}  $&$\typecolon\; \NoteCommitTrapdoor{Sapling} \times \ReprJ \times \ReprJ \times \ValueType \hspace{0.55em}
     $&$\rightarrow \NoteCommitOutput{Sapling}$ \\
  $\ValueCommitAlg{Sapling} $&$\typecolon\; \ValueCommitTrapdoor{Sapling} \times \ValueCommitTypeSapling $&$\rightarrow \ValueCommitOutput{Sapling}$
\end{tabular}

$\NoteCommitAlg{Sapling}$ is instantiated in \crossref{concretesaplingnotecommit}, and
$\ValueCommitAlg{Sapling}$ is instantiated in \crossref{concretevaluecommit}.

\vspace{-1ex}
\nnote{$\NoteCommitAlg{Sapling}$ and $\ValueCommitAlg{Sapling}$ always return points in the subgroup $\SubgroupJ$.
However, we declare the type of these commitment outputs to be $\GroupJ$ because they are not
directly checked to be in the subgroup when $\ValueCommitAlg{Sapling}$ outputs appear in \spendDescriptions
and \outputDescriptions, or when the $\cmuField$ field derived from a $\NoteCommitAlg{Sapling}$ appears
in an \outputDescription.}
} %sapling

\nufive{
\vspace{2ex}
Let $\ScalarLength{Orchard}$ be as defined in \crossref{constants}.

Let $\GroupP$, $\ellP$, $\ParamP{q}$, and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}.

\introlist
Define:
\begin{formulae}
  \item $\NoteCommitTrapdoor{Orchard} := \binaryrange{\ScalarLength{Orchard}}$ and
        $\NoteCommitOutput{Orchard} := \maybe{\GroupP}$;
  \item $\ValueCommitTrapdoor{Orchard} := \binaryrange{\ScalarLength{Orchard}}$ and
        $\ValueCommitOutput{Orchard} := \GroupP$.
  \item $\CommitIvkTrapdoor := \binaryrange{\ScalarLength{Orchard}}$ and
        $\CommitIvkOutput := \CommitIvkOutputType$.
\end{formulae}

\introlist
\Orchard uses three additional \commitmentSchemes:

\begin{tabular}{@{\hskip 1.5em}r@{\;}l@{\;}l}
  $\NoteCommitAlg{Orchard}  $&$\typecolon\; \NoteCommitTrapdoor{Orchard} \times \ReprP \times \ReprP \times \ValueType$ \\[-1ex]
                             &\hspace{21.2em}$\times\; \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType $&$\rightarrow \NoteCommitOutput{Orchard}$ \\
  $\ValueCommitAlg{Orchard} $&$\typecolon\; \ValueCommitTrapdoor{Orchard} \times \ValueCommitTypeOrchard $&$\rightarrow \ValueCommitOutput{Orchard}$ \\
  $\CommitIvkAlg            $&$\typecolon\; \CommitIvkTrapdoor \times \AuthSignPublicTypeOrchard \times \NullifierKeyTypeOrchard $&$\rightarrow \CommitIvkOutput$
\end{tabular}

\begin{pnotes}
  \item $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ can return $\bot$ (with insignificant probability).
  \item $\CommitIvkAlg$ can return $0$ (with insignificant probability) even though that is not a valid
        $\KA{Orchard}$ \privateKey. The use of $\CommitIvkAlg$ to obtain an \Orchard \incomingViewingKey
        in \crossref{orchardkeycomponents} explicitly accounts for the $0$ and $\bot$ cases.
        Use of $\CommitIvkAlg$ in the \actionCircuit does not require special handling of the $0$ case.
\end{pnotes}

$\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ are instantiated in \crossref{concreteorchardnotecommit}.
$\ValueCommitAlg{Orchard}$ is instantiated in \crossref{concretevaluecommit}.
} %nufive

\introsection
\lsubsubsection{Represented Group}{abstractgroup}

A \defining{\representedGroup} $\GroupG{}$ consists of:

\begin{itemize}
  \item a subgroup order parameter $\ParamG{r} \typecolon \PosInt$, which must be prime;
  \item a cofactor parameter $\ParamG{h} \typecolon \PosInt$;
  \item a group $\GroupG{}$ of order $\ParamG{h} \mult \ParamG{r}$, written additively
        with operation $+ \typecolon \GroupG{} \times \GroupG{} \rightarrow \GroupG{}$,
        and additive identity $\ZeroG{}$;
  \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 a left inverse of $\reprG{}$, i.e. for all $P \in \GroupG{}$,
        $\abstG{}\big(\reprG{}(P)\kern-0.1em\big) = P$.
\end{itemize}

\vspace{-2ex}
\pnote{Ideally, we would also have that for all $S$ not in the image of $\reprG{}$, $\abstG{}(S) = \bot$.
This may not be true in all cases, i.e.\ there can be \defining{\nonCanonicalPoint} encodings $P\Repr$ such
that $\reprG{}\big(\abstG{}(P\Repr)\kern-0.1em\big) \neq P\Repr$.}

\vspace{1ex}
Define $\SubgroupG{}$ as the order-$\ParamG{r}$ subgroup of $\GroupG{}$, which is called a
\defining{\representedSubgroup}. Note that this includes $\ZeroG{}$.
For the set of points of order $\ParamG{r}$ (which excludes $\ZeroG{}$), we write $\SubgroupGstar{}$.

Define $\SubgroupReprG := \setof{\reprG{}(P) \typecolon \ReprG{} \suchthat P \in \SubgroupG{}}$.
(This intentionally excludes \nonCanonicalPoint encodings if there are any.)

\vspace{0.5ex}
For $G \typecolon \GroupG{}$ we write $-G$ for the negation of $G$, such that
$(-G) + G = \ZeroG{}$. We write $G - H$ for $G + (-H)$.

\vspace{-1ex}
We also extend the $\vsum{}{}$ notation to addition on group elements.

\introlist
For $G \typecolon \GroupG{}$ and $k \typecolon \Int$ we write $\scalarmult{k}{G}$
for scalar multiplication on the group, i.e.

\begin{formulae}
  \item $\scalarmult{k}{G} := \begin{cases}
          \ssum{i = 1}{k} G, &\caseif k \geq 0 \\[1.5ex]
          \ssum{i = 1}{-k} (-G), &\caseotherwise.
        \end{cases}$
\end{formulae}

For $G \typecolon \GroupG{}$ and $a \typecolon \GF{\ParamG{r}}$, we may also write
$\scalarmult{a}{G}$ meaning $\scalarmult{a \bmod \ParamG{r}}{G}$ as defined above.
(This variant is not defined for fields other than $\GF{\ParamG{r}}$.)


\sapling{
\vspace{-1ex}
\introsection
\lsubsubsection{Coordinate Extractor}{abstractextractor}

\vspace{-1ex}
A \defining{\coordinateExtractor} for a \representedGroup $\GroupG{}$ is a function
$\ExtractG \typecolon \SubgroupG{} \rightarrow T$ for some type $T$.

\pnote{
Unlike the representation function $\reprG{}$, $\ExtractG$ need not have an
efficiently computable left inverse.
} %pnote
} %sapling


\sapling{
\vspace{-1ex}
\introlist
\lsubsubsection{Group Hash}{abstractgrouphash}

\vspace{-1ex}
Given a \representedSubgroup $\SubgroupG{}$, a \defining{\familyOfGroupHashesIntoTheSubgroup},
denoted $\SubgroupGHash{}$, consists of:
\begin{itemize}
  \item a type $\SubgroupGHashURSType$ of \uniformRandomStrings;
        \vspace{-1ex}
  \item a type $\SubgroupGHashInput$ of inputs;
        \vspace{-1ex}
  \item a function $\SubgroupGHash{} \typecolon \SubgroupGHashURSType \times \SubgroupGHashInput \rightarrow \SubgroupG{}$.
\end{itemize}

In \crossref{concretegrouphashjubjub}, we instantiate a family of \defining{\groupHashes} into
the \jubjubCurve defined by \crossref{jubjub}.

\vspace{-2ex}
\securityrequirement{
For a randomly selected $\URS \typecolon \SubgroupGHashURSType$,
it must be reasonable to model $\SubgroupGHash{\URS}$ (restricted to inputs for which it does
not return $\bot$) as a \randomOracle.
} %securityrequirement

\nufive{
\vspace{1ex}
In \crossref{concretegrouphashpallasandvesta}, we instantiate \groupHashes into the \Pallas
and \Vesta curves. These are not strictly speaking \familiesOfGroupHashes, because they
have a trivial URS, and so the above security definition does not apply. Nevertheless, they
can be heuristically modelled as \randomOracles.
\vspace{1ex}
} %nufive

\begin{nnotes}
  \item $\GroupJHash{}$ is used to obtain generators of the \jubjubCurve for various purposes:
        the bases $\AuthSignBase{Sapling}$ and $\AuthProveBaseSapling$ used in \Sapling key generation,
        the \xPedersenHash defined in \crossref{concretepedersenhash}, and
        the \commitmentSchemes defined in \crossref{concretewindowedcommit} and
        in \crossref{concretehomomorphiccommit}.

        The security property needed for these uses can alternatively be defined in the
        standard model as follows:

        \textbf{Discrete Logarithm Independence}:
        For a randomly selected member $\SubgroupGHash{\URS}$ of the family, it is infeasible to find
        a sequence of \emph{distinct} inputs $m_{\alln} \typecolon \typeexp{\SubgroupGHashInput}{n}$
        and a sequence of nonzero $x_{\alln} \typecolon \typeexp{\GFstar{\ParamG{r}}}{n}$
        such that $\ssum{i = 1}{n}\!\Big(\scalarmult{x_i}{\SubgroupGHash{\URS}(m_i)}\Big) = \ZeroG{}$.
  \item Under the \xDiscreteLogarithm assumption on $\SubgroupG{}$, a \randomOracle almost surely satisfies
        Discrete Logarithm Independence. Discrete Logarithm Independence implies \collisionResistance\!,
        since a collision $(m_1, m_2)$ for $\SubgroupGHash{\URS}$ trivially gives a
        discrete logarithm relation with $x_1 = 1$ and $x_2 = -1$.
  \item $\GroupJHash{}$ is used in \crossref{concretediversifyhash} to instantiate $\DiversifyHash{Sapling}$.
        We do not know how to prove the Unlinkability property defined in that section
        in the standard model, but in a model where $\GroupJHash{}$ (restricted to
        inputs for which it does not return $\bot$) is taken as a \randomOracle,
        it is implied by the \xDecisionalDiffieHellman assumption on $\SubgroupJ$\nufive{,
        and similarly for $\GroupPHash$}.
  \item $\URS$ is a \defining{\uniformRandomString}; we chose it verifiably at random
        (see \crossref{beacon}), after fixing the concrete group hash algorithm to be used.
        This mitigates the possibility that the group hash algorithm could have
        been backdoored. \nufive{For \Orchard, we considered a URS to be unnecessary,
        because we follow \cite{ID-hashtocurve} which does not use one.}
\end{nnotes}
} %sapling


\vspace{-2ex}
\introlist
\lsubsubsection{Represented Pairing}{abstractpairing}

A \defining{\representedPairing} $\GroupPair{}$ consists of:

\begin{itemize}
  \item a group order parameter $\ParamPair{r} \typecolon \PosInt$ which must be prime;
  \item two \representedSubgroups $\SubgroupPair{1, 2}$, both of order $\ParamPair{r}$;
  \item a group $\SubgroupPair{T}$ of order $\ParamPair{r}$, written multiplicatively with operation\,
        $\mult \typecolon \SubgroupPair{T} \times \SubgroupPair{T} \rightarrow \SubgroupPair{T}$
        and group identity $\ParamPair{\mathbf{1}}$;
  \item three generators $\GenPair{1, 2, T}$ of $\SubgroupPair{1, 2, T}$ respectively;
  \item a pairing function
        $\PairingPair \typecolon \SubgroupPair{1} \times \SubgroupPair{2} \rightarrow \SubgroupPair{T}$
        satisfying:
        \begin{itemize}
          \item (Bilinearity)\; for all $a, b \typecolon \GFstar{r}$,
                $P \typecolon \SubgroupPair{1}$, and $Q \typecolon \SubgroupPair{2}$,\;
                $\PairingPair\Of{\scalarmult{a}{P}, \scalarmult{b}{Q}} = \PairingPair\Of{P, Q}^{a \mult b}$;\, and
          \item (Nondegeneracy)\; there does not exist $P \typecolon \SubgroupPairstar{1}$
                such that for all $Q \typecolon \SubgroupPair{2},\;
                \PairingPair\Of{P, Q} = \OnePair$.
        \end{itemize}
\end{itemize}

\lsubsubsection{Zero-Knowledge Proving System}{abstractzk}

\defining{A \zeroKnowledgeProvingSystem is a cryptographic protocol that allows
proving a particular \statement, dependent on \primary and \auxiliaryInputs,
in zero knowledge --- that is, without revealing information about the
\auxiliaryInputs other than that implied by the \statement.} The type of
\zeroKnowledgeProvingSystem needed by \Zcash is a \defining{\ppzkSNARK} \cite{BCCGLRT2014}.

\introlist
A \ppzkSNARK instance $\ZK$ defines:

\begin{itemize}
  \item a type of \defining{\zkProvingKeys}, $\ZKProvingKey$;
  \item a type of \defining{\zkVerifyingKeys}, $\ZKVerifyingKey$;
  \item a type of \primaryInputs $\ZKPrimary$;
  \item a type of \auxiliaryInputs $\ZKAuxiliary$;
  \item a type of \defining{\zkSNARKProofs} $\ZKProof$;
  \item a type $\ZKSatisfying \subseteq \ZKPrimary \times \ZKAuxiliary$ of inputs satisfying
the \statement;
  \item a randomized key pair generation algorithm $\ZKGen \typecolon () \rightarrowR \ZKProvingKey \times \ZKVerifyingKey$;
  \item a proving algorithm $\ZKProve{} \typecolon \ZKProvingKey \times \ZKSatisfying \rightarrow \ZKProof$;
  \item a verifying algorithm $\ZKVerify{} \typecolon \ZKVerifyingKey \times \ZKPrimary \times \ZKProof \rightarrow \bit$;
\end{itemize}

\introlist
The security requirements below are supposed to hold with overwhelming
probability for $(\pk, \vk) \leftarrowR \ZKGen()$.

\vspace{1ex}
\begin{securityrequirements}
  \item \textbf{Completeness:} An honestly generated proof will convince a verifier:
for any $(x, w) \in \ZKSatisfying$, if $\ZKProve{\pk}(x, w)$ outputs $\Proof{}$,
then $\ZKVerify{\vk}(x, \Proof{}) = 1$.
  \item \textbf{Knowledge Soundness:} For any adversary $\Adversary$ able to find an
$x \typecolon \ZKPrimary$ and proof $\Proof{} \typecolon \ZKProof$ such that $\ZKVerify{\vk}(x, \Proof{}) = 1$,
there is an efficient extractor $\Extractor{\Adversary}$ such that if $\Extractor{\Adversary}(\vk, \pk)$
returns $w$, then the probability that $(x, w) \not\in \ZKSatisfying$ is insignificant.
  \item \textbf{Statistical Zero Knowledge:} An honestly generated proof is statistical
zero knowledge. That is, there is a feasible stateful simulator $\Simulator$ such that,
for all stateful distinguishers $\Distinguisher$, the following two probabilities are
not significantly different:
\vspace{0.5ex}

$\;\;\Prob{
  (x, w) \in \ZKSatisfying \\
  \Distinguisher(\Proof{}) = 1
}{
  (\pk, \vk) \leftarrowR \ZKGen() \\
  (x, w) \leftarrowR \Distinguisher(\pk, \vk) \\
  \Proof{} \leftarrowR \ZKProve{\pk}(x, w)
}
\text{\; and \;}
\Prob{
  (x, w) \in \ZKSatisfying \\
  \Distinguisher(\Proof{}) = 1
}{
  (\pk, \vk) \leftarrowR \Simulator() \\
  (x, w) \leftarrowR \Distinguisher(\pk, \vk) \\
  \Proof{} \leftarrowR \Simulator(x)
}$
\end{securityrequirements}

These definitions are derived from those in \cite[Appendix C]{BCTV2014b}, adapted to
state concrete security for a fixed circuit, rather than asymptotic security for
arbitrary circuits. ($\ZKProve{}$ corresponds to $P$, $\ZKVerify{}$ corresponds to $V$,
and $\ZKSatisfying$ corresponds to $\mathcal{R}_C$ in the notation of that appendix.)

The Knowledge Soundness definition is a way to formalize the property that it is
infeasible to find a new proof $\Proof{}$ where $\ZKVerify{\vk}(x, \Proof{}) = 1$ without
\emph{knowing} an \auxiliaryInput $w$ such that $(x, w) \in \ZKSatisfying$.
Note that Knowledge Soundness implies Soundness --- i.e.\ the property that it is
infeasible to find a new proof $\Proof{}$ where $\ZKVerify{\vk}(x, \Proof{}) = 1$ without
\emph{there existing} an \auxiliaryInput $w$ such that $(x, w) \in \ZKSatisfying$.

\begin{nnotes}
  \item The above properties do not include \defining{\proofNonmalleability} \cite{DSDCOPS2001},
        and the design of the protocol using the \zeroKnowledgeProvingSystem must take this
        into account.
  \item The terminology used in this specification is that we ``validate'' signatures, and
        ``verify'' \zkSNARKProofs.
\end{nnotes}

\sapling{
\vspace{-1ex}
\introlist
\Zcash uses \notnufive{two}\nufive{three} \provingSystems:
\begin{itemize}
  \item \BCTV (\crossref{bctv}) is used with the
        \BNPairing pairing (\crossref{bnpairing}),
        to prove and verify the \Sprout \joinSplitStatement
        (\crossref{joinsplitstatement}) before \Sapling activation.
        \vspace{-0.5ex}
  \item \Groth (\crossref{groth}) is used with the
        \BLSPairing pairing (\crossref{blspairing}),
        to prove and verify the \Sapling \spendStatement
        (\crossref{spendstatement}) and \outputStatement
        (\crossref{outputstatement}). It is also used to prove
        and verify the \joinSplitStatement after \Sapling activation.
        \vspace{-0.5ex}
  \nufiveonwarditem{\HaloTwo (\crossref{halo2}) is used with the
        \vestaCurve (\crossref{pallasandvesta}) to prove and verify the
        \Orchard \actionStatement (\crossref{actionstatement}).}
\end{itemize}

\vspace{-0.5ex}
These specializations are:
\begin{itemize}
  \item $\JoinSplit$ for the \Sprout \joinSplitStatement (with \BCTV and \BNPairing,
        or \Groth and \BLSPairing);
  \item $\Spend$ for the \Sapling \spendStatement and
        $\Output$ for the \Sapling \outputStatement\notnufive{.}\notbeforenufive{;}
  \nufiveonwarditem{$\Action$ for the \Orchard \actionStatement.}
\end{itemize}

\vspace{-0.5ex}
We omit key subscripts on $\JoinSplitProve$ and
$\JoinSplitVerify$, taking them to be either the \BCTV \provingKey
and \verifyingKey defined in \crossref{bctvparameters}, or the
\texttt{sprout-groth16.params} \Groth \provingKey and \verifyingKey
defined in \crossref{grothparameters}, according to whether the proof
appears in a \block before or after \Sapling activation.

We\notnufive{ also} omit subscripts on $\SpendProve$,
$\SpendVerify$, $\OutputProve$, and $\OutputVerify$, taking
them to be the relevant \Groth \provingKeys and
\verifyingKeys defined in \crossref{grothparameters}.

\nufive{
We also omit subscripts on $\ActionProve$ and $\ActionVerify$.
For \HaloTwo, parameters for a given circuit implementation are
generated on the fly by the \halotwo library, and do not require
parameter files.
} %nufive
} %sapling


\lsubsection{Key Components}{keycomponents}

\vspace{-1ex}
\lsubsubsection{\SproutText{} Key Components}{sproutkeycomponents}

\vspace{-0.6ex}
Let $\AuthPrivateLength$ be as defined in \crossref{constants}.

\vspace{-0.2ex}
Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concreteprfs}.

\vspace{-0.2ex}
Let $\KA{Sprout}$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}.

\vspace{0.3ex}
A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a \bitSequence
uniformly at random from $\bitseq{\AuthPrivateLength}$.

\introlist
$\AuthPublic$, $\TransmitPrivate$ and $\TransmitPublic$ are derived from
$\AuthPrivate$ as follows:

\vspace{-0.6ex}
\begin{tabular}{@{\hskip 2em}r@{\;}l}
  $\AuthPublic$ &$:= \PRFaddr{\AuthPrivate}(0)$ \\
  $\TransmitPrivate$ &$:= \KAFormatPrivate{Sprout}(\PRFaddr{\AuthPrivate}(1))$ \\
  $\TransmitPublic$ &$:= \KADerivePublic{Sprout}(\TransmitPrivate, \KABase{Sprout})$.
\end{tabular}


\sapling{
\vspace{-1.8ex}
\lsubsubsection{\SaplingText{} Key Components}{saplingkeycomponents}

\vspace{-1ex}
Let $\PRFOutputLengthExpand$, $\SpendingKeyLength$, $\InViewingKeyLength{Sapling}$,
$\OutViewingKeyLength$, and $\DiversifierLength$ be as defined in \crossref{constants}.

\vspace{-0.6ex}
Let $\SubgroupJ$, $\SubgroupJstar$, $\SubgroupReprJ$, $\reprJ$, and $\ParamJ{r}$ be as defined in
\crossref{jubjub}, and let $\FindGroupJHash$ be as defined in \crossref{concretegrouphashjubjub}.

\vspace{-0.2ex}
Let $\PRFexpand{}$ and $\PRFock{Sapling}{}$, instantiated in \crossref{concreteprfs},
be \pseudoRandomFunctions.

\vspace{-0.2ex}
Let $\KA{Sapling}$, instantiated in \crossref{concretesaplingkeyagreement},
be a \keyAgreementScheme.

\vspace{-0.2ex}
Let $\CRHivk$, instantiated in \crossref{concretecrhivk}, be a \hashFunction.

\vspace{-0.2ex}
Let $\DiversifyHash{Sapling}$, instantiated in \crossref{concretediversifyhash},
be a \hashFunction.

\vspace{-0.2ex}
Let $\SpendAuthSig{Sapling}$, instantiated in \crossref{concretespendauthsig},
be a \rerandomizableSignatureScheme.

\vspace{-0.2ex}
Let $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\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{-0.2ex}
Define $\AuthProveBaseSapling := \FindGroupJHash\Of{\ascii{Zcash\_H\_}, \ascii{}}$.

\vspace{-0.2ex}
Define $\ToScalar{Sapling}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamJ{r}}$.

\introlist
A new \Sapling \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence
uniformly at random from $\SpendingKeyType$.

\vspace{-0.2ex}
From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamJ{r}}$,
the \authProvingKey $\AuthProvePrivate \typecolon \GF{\ParamJ{r}}$, and the
\outgoingViewingKey $\OutViewingKey \typecolon \OutViewingKeyType$ are derived as follows:

\vspace{-0.6ex}
\begin{tabular}{@{\hskip 1.7em}r@{\;}l}
  $\AuthSignPrivate$ &$:= \ToScalar{Sapling}\big(\PRFexpand{\SpendingKey}([0])\kern-0.1em\big)$ \\
  $\AuthProvePrivate$ &$:= \ToScalar{Sapling}\big(\PRFexpand{\SpendingKey}([1])\kern-0.1em\big)$ \\
  $\OutViewingKey$ &$:= \truncate{(\OutViewingKeyLength/8)}\big(\PRFexpand{\SpendingKey}([2])\kern-0.1em\big)$
\end{tabular}

\vspace{-0.4ex}
If $\AuthSignPrivate = 0$, discard this key and repeat with a new $\SpendingKey$.

\introlist
\vspace{-0.2ex}
$\AuthSignPublic \typecolon \SubgroupJstar$, $\NullifierKey \typecolon \SubgroupJ$, and
the \incomingViewingKey $\InViewingKey \typecolon \InViewingKeyTypeSapling$ are then derived as:

\vspace{-0.6ex}
\begin{tabular}{@{\hskip 1.7em}r@{\;}l}
  $\AuthSignPublic$ &$:= \SpendAuthSigDerivePublic{Sapling}(\AuthSignPrivate)$ \\
  $\NullifierKey$ &$:= \scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}$ \\
  $\kern 0.26em\InViewingKey$ &$:= \CRHivk\big(\reprJ\Of{\AuthSignPublic}, \reprJ\Of{\NullifierKey}\kern-0.08em\big)$.
\end{tabular}

\vspace{-0.4ex}
If $\InViewingKey = 0$, discard this key and repeat with a new $\SpendingKey$.

\introlist
As explained in \crossref{addressesandkeys}, \Sapling allows the efficient
creation of multiple \diversifiedPaymentAddresses with the same \spendingAuthority.
A group of such addresses shares the same \fullViewingKey and \incomingViewingKey.

\vspace{-0.2ex}
To create a new \diversifiedPaymentAddress given an \incomingViewingKey
$\InViewingKey$, repeatedly pick a \defining{\diversifier} $\Diversifier$ uniformly at
random from $\DiversifierType$ until the \defining{\diversifiedBase}
$\DiversifiedTransmitBase = \DiversifyHash{Sapling}(\Diversifier)$ is not $\bot$.
Then calculate the \defining{\diversifiedTransmissionKey} $\DiversifiedTransmitPublic$:

\begin{formulae}
  \item $\DiversifiedTransmitPublic := \KADerivePublic{Sapling}(\InViewingKey, \DiversifiedTransmitBase)$.
\end{formulae}

\vspace{-1ex}
The resulting \diversifiedPaymentAddress is
$(\Diversifier \typecolon \DiversifierType, \DiversifiedTransmitPublic \typecolon \KAPublicPrimeSubgroup{Sapling})$.

\vspace{1ex}
For each \spendingKey, there is also a \defining{\defaultDiversifiedPaymentAddress}
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. 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}$
be as defined in \crossref{concretegrouphashjubjub}. Define:
\vspace{-0.5ex}
\begin{formulae}
  \item $\CheckDiversifier(\Diversifier \typecolon \DiversifierType) := \begin{cases}
          \bot,         &\caseif \DiversifyHash{Sapling}(\Diversifier) = \bot \\
          \Diversifier, &\caseotherwise
        \end{cases}$
  \item $\DefaultDiversifier(\sk \typecolon \SpendingKeyType) :=
          \first\big(\fun{i \typecolon \byte}{\CheckDiversifier(\truncate{(\DiversifierLength/8)}(\PRFexpand{\sk}([3, i])))
                                              \typecolon \maybe{\SubgroupJstar}}\big)$.
\end{formulae}

For a random \spendingKey, $\DefaultDiversifier$ returns $\bot$ with probability approximately $2^{-256}$;
if this happens, discard the key and repeat with a different $\SpendingKey$.

\introlist
\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}).
        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.
        \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
        be randomly chosen unique values used to index into a database, rather than
        directly encoding the needed data.
\end{pnotes}

\vspace{-1ex}
\begin{nnotes}
  \item Assume that $\PRFexpand{}$ is a \xPRF with output range $\PRFOutputExpand$, where
        $2^{\PRFOutputLengthExpand}$ is large compared to $\ParamJ{r}$.

        Define $f \typecolon \SpendingKeyType \times \PRFInputExpand \rightarrow \GF{\ParamJ{r}}$ by
        $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}$
        is injective; the bias introduced by reduction modulo $\ParamJ{r}$ is small
        because \crossref{constants} defines $\PRFOutputLengthExpand$ as $512$, while $\ParamJ{r}$
        has length $252$ bits. It follows that the distribution of $\AuthSignPrivate$,
        i.e.\ $\PRFexpand{\SpendingKey}([0]) : \SpendingKey \leftarrowR \SpendingKeyType$,
        is computationally indistinguishable from $\SpendAuthSigGenPrivate{Sapling}()$ defined
        in \crossref{concretespendauthsig}\rlap{.}
        \vspace{-0.5ex}
  \item The distribution of $\AuthProvePrivate$, i.e.\
        $\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)$
        is bijective, the distribution of $\reprJ\Of{\NullifierKey}$ will be computationally
        indistinguishable from uniform on $\SubgroupReprJ$ (the keyspace of $\PRFnf{Sapling}{}$).
\end{nnotes}
\vspace{-2ex}
} %sapling


\nufive{
\introsection
\lsubsubsection{\OrchardText{} Key Components}{orchardkeycomponents}

\vspace{-1ex}
Let $\PRFOutputLengthExpand$, $\SpendingKeyLength$, $\OutViewingKeyLength$, $\DiversifierLength$,
and $\DiversifierKeyLength$ be as defined in \crossref{constants}.

Let $\GroupP$, $\reprP$, $\ellP$, $\ParamP{q}$, and $\ParamP{r}$ be as defined in
\crossref{pallasandvesta}.

\vspace{-0.25ex}
Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}.

\vspace{-0.35ex}
Let $\GroupPHash$ be as defined in \crossref{concretegrouphashpallasandvesta}.

\vspace{-0.25ex}
Let $\PRFexpand{}$ and $\PRFock{Orchard}{}$ be as defined in \crossref{concreteprfs}.

\vspace{-0.5ex}
Let $\DeriveInternalFVKOrchard$ be as defined in \cite[Orchard internal key derivation]{ZIP-32}.

\vspace{-0.25ex}
Let $\PRPd{} \typecolon \DiversifierKeyType \times \DiversifierType \rightarrow \DiversifierType$
be as defined in \crossref{concreteprps}.

\vspace{-0.35ex}
Let $\KA{Orchard}$, instantiated in \crossref{concreteorchardkeyagreement},
be a \keyAgreementScheme.

\vspace{-0.35ex}
Let $\CommitIvk{}$, instantiated in \crossref{concretesinsemillacommit},
be a \commitmentScheme.

\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.

\vspace{-0.25ex}
Let $\ItoLEBSP{}$, $\ItoLEOSP{}$, and $\LEOStoIP{}$ be as defined in \crossref{endian}.

\vspace{0.5ex}
Define $\ToBase{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{q}}$.

\vspace{-1.5ex}
Define $\ToScalar{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{r}}$.

\introlist
A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a \bitSequence
uniformly at random from $\SpendingKeyType$.

From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamP{r}}$,
the \authValidatingKey $\AuthSignPublic \typecolon \AuthSignPublicTypeOrchard$,
the \nullifierDerivingKey $\NullifierKey \typecolon \NullifierKeyTypeOrchard$,
the \commitIvkRandomness $\CommitIvkRand \typecolon \CommitIvkRandType$,
the \diversifierKey $\DiversifierKey \typecolon \DiversifierKeyType$,
the $\KA{Orchard}$ \privateKey $\InViewingKey \typecolon \InViewingKeyTypeOrchard$,
the \outgoingViewingKey $\OutViewingKey \typecolon \OutViewingKeyType$, and corresponding
``internal'' keys are derived as follows:

\begin{algorithm}
  \item let mutable $\AuthSignPrivate \leftarrow \ToScalar{Orchard}\big(\PRFexpand{\SpendingKey}([6])\kern-0.1em\big)$
        \vspace{-0.4ex}
  \item let $\NullifierKey = \ToBase{Orchard}\big(\PRFexpand{\SpendingKey}([7])\kern-0.1em\big)$
        \vspace{-0.4ex}
  \item let $\CommitIvkRand = \ToScalar{Orchard}\big(\PRFexpand{\SpendingKey}([8])\kern-0.1em\big)$
        \vspace{-0.3ex}
  \item if $\AuthSignPrivate = 0$, discard this key and repeat with a new $\SpendingKey$.
        \vspace{-0.3ex}
  \item let $\AuthSignPublicPoint = \SpendAuthSigDerivePublic{Orchard}(\AuthSignPrivate)$
        \vspace{-0.3ex}
  \item if the last bit (that is, the $\tilde{y}$ bit) of $\reprP(\AuthSignPublicPoint)$ is $1$:
        \vspace{-0.4ex}
  \item \tab set $\AuthSignPrivate \leftarrow -\AuthSignPrivate$
        \vspace{0.2ex}
  \item let $\AuthSignPublic = \ExtractP(\AuthSignPublicPoint)$
        \vspace{-0.4ex}
  \item let $\InViewingKey = \CommitIvk{\CommitIvkRand}\big(\AuthSignPublic, \NullifierKey\big)$
        \vspace{-0.3ex}
  \item if $\InViewingKey \in \setof{0, \bot}$, discard this key and repeat with a new $\SpendingKey$.
        \vspace{-0.2ex}
  \item let $K = \ItoLEBSPOf{\SpendingKeyLength}{\CommitIvkRand}$
        \vspace{-0.5ex}
  \item let $R = \PRFexpand{K}\big([\hexint{82}] \bconcat \ItoLEOSPOf{256}{\AuthSignPublic} \bconcat \ItoLEOSPOf{256}{\NullifierKey}\kern-0.25em\big)$
        \vspace{-0.2ex}
  \item let $\DiversifierKey$ be the first $\DiversifierKeyLength/8$ bytes of $R$ and
        let $\OutViewingKey$ be the remaining $\OutViewingKeyLength/8$ bytes of $R$.
        \vspace{-0.4ex}
  \item let $(\Internal{\AuthSignPublic}, \Internal{\NullifierKey}, \Internal{\CommitIvkRand}) = \DeriveInternalFVKOrchard(\AuthSignPublic, \NullifierKey, \CommitIvkRand)$
        \vspace{-0.3ex}
  \item let $\Internal{\InViewingKey} = \CommitIvk{\Internal{\CommitIvkRand}}\big(\Internal{\AuthSignPublic}, \Internal{\NullifierKey}\big)$
        \vspace{-0.2ex}
  \item if $\Internal{\InViewingKey} \in \setof{0, \bot}$, discard this key and repeat with a new $\SpendingKey$.
        \vspace{-0.2ex}
  \item let $\Internal{K} = \ItoLEBSPOf{\SpendingKeyLength}{\Internal{\CommitIvkRand}}$
        \vspace{-0.5ex}
  \item let $\Internal{R} = \PRFexpand{\Internal{K}}\big([\hexint{82}] \bconcat \ItoLEOSPOf{256}{\Internal{\AuthSignPublic}} \bconcat \ItoLEOSPOf{256}{\Internal{\NullifierKey}}\kern-0.25em\big)$
        \vspace{-0.2ex}
  \item let $\Internal{\DiversifierKey}$ be the first $\DiversifierKeyLength/8$ bytes of $\Internal{R}$ and
        let $\Internal{\OutViewingKey}$ be the remaining $\OutViewingKeyLength/8$ bytes of $\Internal{R}$.
\end{algorithm}

\introlist
\pnote{$\Internal{\AuthSignPublic} = \AuthSignPublic$ and $\Internal{\NullifierKey} = \NullifierKey$.}

As explained in \crossref{addressesandkeys}, \Orchard allows the efficient
creation of multiple \diversifiedPaymentAddresses with the same \spendingAuthority.
A group of such addresses shares the same \fullViewingKey, \incomingViewingKey, and
\outgoingViewingKey.

\introlist
To create a new \diversifiedPaymentAddress given an \incomingViewingKey
$(\DiversifierKey, \InViewingKey)$, pick a \defining{\diversifierIndex} $\DiversifierIndex$
uniquely from $\DiversifierType$. Then calculate the \diversifier $\Diversifier$ and the
\defining{\diversifiedTransmissionKey} $\DiversifiedTransmitPublic$:

\begin{formulae}
  \item $\Diversifier := \PRPd{\DiversifierKey}(\DiversifierIndex)$
        \vspace{-0.5ex}
  \item $\DiversifiedTransmitBase := \DiversifyHash{Orchard}(\Diversifier)$
        \vspace{-0.5ex}
  \item $\DiversifiedTransmitPublic := \KADerivePublic{Orchard}(\InViewingKey, \DiversifiedTransmitBase)$.
\end{formulae}

\vspace{-1ex}
The resulting \diversifiedPaymentAddress is
$(\Diversifier \typecolon \DiversifierType, \DiversifiedTransmitPublic \typecolon \KAPublic{Orchard})$.

The \diversifiedPaymentAddress with \diversifierIndex $0$ is called the \defining{\defaultDiversifiedPaymentAddress}.

\vspace{1ex}
\begin{pnotes}
  \item \xDiversifierIndices \SHOULDNOT be chosen at random. \cite{ZIP-32} specifies their
        usage in the context of hierarchical deterministic wallets.
  \item Address generators \MAY encode information in the \diversifierIndex
        that can be recovered by the recipient of a payment, given the \diversifierKey.
  \item $\CommitIvkRand$ is used both as a randomizer for $\CommitIvk{}$, and as a
        key for $\PRFexpand{}$ to derive $\DiversifierKey$ and $\OutViewingKey$.
        If $\DiversifierKey$ and $\OutViewingKey$ are known to an adversary, then
        this reuse prevents proving that the use of $\CommitIvk{}$ in this context is
        perfectly \hiding. It is also not sufficient to model $\PRFexpand{}$ only as a PRF.
        In practice, we believe it would be extremely surprising if there were an
        exploitable interaction between scalar multiplication used in $\CommitIvk{}$,
        and $\BlakeTwobGeneric$ used to instantiate $\PRFexpand{}$. It is possible,
        albeit somewhat inelegantly, to model this usage by a joint assumption on \Pallas
        scalar multiplication and $\PRFexpand{}$.
\end{pnotes}

\vspace{-1ex}
\begin{nnotes}
  \item 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}.
  \item The output of $\CommitIvk{}$ is the \affineSW $x$-coordinate of a \pallasCurve point,
        which we then use as a $\KA{Orchard}$ \privateKey $\InViewingKey$ for \note encryption.
        The fact that $\InViewingKey$ is non-uniform on $\GF{\ParamP{r}}$ (since it can
        only take on roughly half of the possible values) is not expected to cause any
        security issue.
\end{nnotes}
} %nufive


\lsubsection{JoinSplit Descriptions}{joinsplitdesc}

A \joinSplitTransfer, as specified in \crossref{joinsplit}, is encoded in
\transactions as a \defining{\joinSplitDescription}.

Each \transaction includes a sequence of zero or more \joinSplitDescriptions.
When this sequence is non-empty, the \transaction also includes encodings of a
$\JoinSplitSig$ public \validatingKey and signature.

Let $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$, $\RandomSeedLength$,
$\NOld$, $\NNew$, and $\MAXMONEY$ be as defined in \crossref{constants}.

Let $\hSigCRH$ be as defined in \crossref{abstracthashes}.

Let $\NoteCommit{Sprout}{}$ be as defined in \crossref{abstractcommit}.

Let $\KA{Sprout}$ be as defined in \crossref{abstractkeyagreement}.

Let $\Sym$ be as defined in \crossref{abstractsym}.

Let $\JoinSplit$ be as defined in \crossref{abstractzk}.

\vspace{1ex}
\introlist
A \joinSplitDescription comprises $(\vpubOld, \vpubNew, \rt{Sprout}, \nfOld{\allOld},
\cmNew{\allNew}, \EphemeralPublic, \RandomSeed, \h{\allOld}, \ProofJoinSplit,
\TransmitCiphertext{\allNew})$ \\
where
\begin{itemize}
  \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
        \crossref{transactions}, for the output \treestate of either
        a previous \block, or a previous \joinSplitTransfer in this
        \transaction.
  \item $\nfOld{\allOld} \typecolon \typeexp{\PRFOutputSprout}{\NOld}$ is
        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 $\EphemeralPublic \typecolon \KAPublic{Sprout}$ is
        a key agreement \publicKey, used to derive the key for encryption
        of the \notesCiphertextSprout (\crossref{sproutinband});
  \item $\RandomSeed \typecolon \RandomSeedType$ is
        a seed that must be chosen independently at random for each
        \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}, \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
        activation)};
  \item $\TransmitCiphertext{\allNew} \typecolon \typeexp{\Ciphertext}{\NNew}$ is
        a sequence of ciphertext components for the encrypted output \notes.
\end{itemize}

\introlist
The $\ephemeralKey$ and $\encCiphertexts$ fields together form the \notesCiphertextSprout.

The value $\hSig$ is also computed from $\RandomSeed$, $\nfOld{\allOld}$, and the
$\joinSplitPubKey$ of the containing \transaction:
\begin{formulae}
  \item $\hSig := \hSigCRH(\RandomSeed, \nfOld{\allOld}, \joinSplitPubKey)$.
\end{formulae}

\vspace{-1ex}
\begin{consensusrules}
  \item Elements of a \joinSplitDescription \MUST have the types given
        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}, \vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}\big) = 1$.
  \item Either $\vpubOld$ or $\vpubNew$ \MUST be zero.
  \canopyonwarditem{$\vpubOld$ \MUST be zero.}
\end{consensusrules}


\sapling{
\vspace{-2ex}
\lsubsection{Spend Descriptions}{spenddesc}

\vspace{-1ex}
A \spendTransfer, as specified in \crossref{spendsandoutputs}, is encoded in
\transactions as a \defining{\spendDescription}.

Each \transaction includes a sequence of zero or more \defining{\spendDescriptions}.

Each \spendDescription is authorized by a signature, called the \defining{\spendAuthSignature}.

Let $\MerkleHashLength{Sapling}$ and $\PRFOutputLengthNfSapling$ be as defined in \crossref{constants}.

Let $\ZeroJ$, $\abstJ$, $\reprJ$, and $\ParamJ{h}$ be as defined in \crossref{jubjub}.

Let $\ValueCommitOutput{Sapling}$ be as defined in \crossref{abstractcommit}.

Let $\SpendAuthSig{Sapling}$ be as defined in \crossref{spendauthsig}.

Let $\Spend$ be as defined in \crossref{abstractzk}.

\vspace{1ex}
\introlist
A \spendDescription comprises $(\cv, \rt{Sapling}, \nf, \AuthSignRandomizedPublic, \ProofSpend, \spendAuthSig)$
where
\vspace{1ex}
\begin{itemize}
  \item $\cv \typecolon \ValueCommitOutput{Sapling}$ is the \valueCommitment to the value of the input \note;
  \item $\rt{Sapling} \typecolon \MerkleHash{Sapling}$ is an \anchor, as defined in
        \crossref{transactions}, for the output \treestate of a previous \block;
  \item $\nf \typecolon \PRFOutputNfSapling$ is the \nullifier for the input \note;
  \item $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Sapling}$ is a randomized \validatingKey
        that should be used to validate $\spendAuthSig$;
  \item $\ProofSpend \typecolon \SpendProof$ is a \zkSNARKProof with \primaryInput
        $(\cv, \rt{Sapling}, \nf, \AuthSignRandomizedPublic)$ for the \spendStatement defined in
        \crossref{spendstatement};
  \item $\spendAuthSig \typecolon \SpendAuthSigSignature{Sapling}$ is a \spendAuthSignature, validated
        as specified in \crossref{spendauthsig}.
\end{itemize}

\vspace{-1ex}
\begin{consensusrules}
  \item Elements of a \spendDescription \MUST be valid encodings of the types given above.
  \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$
        \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignRandomizedPublic}$ \MUSTNOT be $\ZeroJ$.
  \item The proof $\Proof{\Spend}$ \MUST be valid given a \primaryInput formed
        from the other fields except $\spendAuthSig$ ---
        i.e.\ $\SpendVerify\big(\kern-0.1em(\cv, \rt{Sapling}, \nf, \AuthSignRandomizedPublic), \Proof{\Spend}\big) = 1$.
  \item Let $\SigHash$ be the \sighashTxHash of this \transaction, not associated with an input,
        as defined in \crossref{sighash} using $\SIGHASHALL$.

        The \spendAuthSignature \MUST be a valid $\SpendAuthSig{Sapling}$ signature over $\SigHash$
        using $\AuthSignRandomizedPublic$ as the \validatingKey ---
        i.e.\ $\SpendAuthSigValidate{Sapling}{\AuthSignRandomizedPublic}(\SigHash, \spendAuthSig) = 1$.

        \nufiveonward{As specified in \crossref{concretereddsa}, the validation of the $\RedDSAReprR{}$
        component of the signature changes to prohibit \nonCanonicalPoint encodings.}
\end{consensusrules}

\vspace{-1.5ex}
\begin{nnotes}
  \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$
        \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$.
        \vspace{-0.25ex}
  \item The rule that $\cv$ and $\AuthSignRandomizedPublic$ \MUST not be \smallOrderAdjective has the effect
        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}
} %sapling


\sapling{
\vspace{-2ex}
\lsubsection{Output Descriptions}{outputdesc}

\vspace{-1ex}
An \outputTransfer, as specified in \crossref{spendsandoutputs}, is encoded in
\transactions as an \defining{\outputDescription}.

\vspace{-0.25ex}
Each \transaction includes a sequence of zero or more \outputDescriptions.
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}
\introlist
An \outputDescription comprises $(\cv, \cmU, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \ProofOutput)$
where
\begin{itemize}
  \item $\cv \typecolon \ValueCommitOutput{Sapling}$ is the \valueCommitment to the value of the output \note;
  \item $\cmU \typecolon \MerkleHash{Sapling}$ is the result of applying $\ExtractJ$ (defined
        in \crossref{concreteextractorjubjub}) to the \noteCommitment for the output \note;
  \item $\EphemeralPublic \typecolon \KAPublic{Sapling}$ is
        a key agreement \publicKey, used to derive the key for encryption
        of the \noteCiphertextSapling (\crossref{saplinginband});
  \item $\TransmitCiphertext{} \typecolon \Ciphertext$ is
        a ciphertext component for the encrypted output \note;
  \item $\OutCiphertext{} \typecolon \Ciphertext$ is a ciphertext component that allows the holder of
        the \outgoingCipherKey (which can be derived from a \fullViewingKey) to recover the recipient
        \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey
        $\EphemeralPrivate$, hence the entire \notePlaintext;
  \item $\ProofOutput \typecolon \OutputProof$ is a \zkSNARKProof with \primaryInput
        $(\cv, \cmU, \EphemeralPublic)$ for the \outputStatement defined in \crossref{outputstatement}.
\end{itemize}

\vspace{-1ex}
\begin{consensusrules}
  \item Elements of an \outputDescription \MUST be valid encodings of the types given above.
        \vspace{-0.3ex}
  \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$
        \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\EphemeralPublic}$ \MUSTNOT be $\ZeroJ$.
        \vspace{-0.3ex}
  \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed
        from the other fields except $\TransmitCiphertext{}$ and $\OutCiphertext{}$ ---
        i.e.\ $\OutputVerify\big(\kern-0.1em(\cv, \cmU, \EphemeralPublic), \Proof{\Output}\big) = 1$.
\end{consensusrules}

\vspace{-1.5ex}
\begin{nnotes}
  \item As stated in \shortcrossref{concretehomomorphiccommit}, an implementation of $\HomomorphicPedersenCommit{Sapling}{}$
        \MAY resample the \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$.
        \vspace{-0.25ex}
  \item The rule that $\cv$ and $\EphemeralPublic$ \MUST not be \smallOrderAdjective has the effect
        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} = \AuthSignRandomizedPublic$.
\end{nnotes}
} %sapling


\nufive{
\lsubsection{Action Descriptions}{actiondesc}

An \actionTransfer, as specified in \crossref{actions}, is encoded in \transactions as an
\defining{\actionDescription}.
Each version 5 \transaction includes a sequence of zero or more \defining{\actionDescriptions}.
(Version 4 \transactions cannot contain \actionDescriptions.)

\introlist
Each \actionDescription is authorized by a signature, called the \defining{\spendAuthSignature}.

\vspace{0.5ex}
Let $\MerkleHashLength{Orchard}$ be as defined in \crossref{constants}.

Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.

Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}.

Let $\ValueCommitOutput{Orchard}$ be as defined in \crossref{abstractcommit}.

Let $\SpendAuthSig{Orchard}$ be as defined in \crossref{spendauthsig}.

Let $\KA{Orchard}$ be as defined in \crossref{abstractkeyagreement}.

Let $\Sym$ be as defined in \crossref{abstractsym}.

Let $\Action$ be as defined in \crossref{abstractzk}.

\vspace{1ex}
\introsection
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
        input \note minus the value of the output \note;
        \vspace{-0.5ex}
  \item $\rt{Orchard} \typecolon \MerkleHashOrchard$ is an \anchor, as defined in \crossref{transactions},
        for the output \treestate of a previous \block;
        \vspace{-0.25ex}
  \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$;
        \vspace{-0.25ex}
  \item $\spendAuthSig \typecolon \SpendAuthSigSignature{Orchard}$ is a \spendAuthSignature,
        validated as specified in \crossref{spendauthsig};
        \vspace{-0.25ex}
  \item $\cmX \typecolon \MerkleHashOrchard$ 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
        the \outgoingCipherKey (which can be derived from a \fullViewingKey) to recover the recipient
        \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey
        $\EphemeralPrivate$, hence the entire \notePlaintext;
  \item $\enableSpends \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued}
        spends in this Action;
  \item $\enableOutputs \typecolon \bit$ is a flag that is set in order to enable \nh{non-zero-valued}
        outputs in this Action;
        \vspace{-0.25ex}
  \item $\Proof{} \typecolon \ActionProof$ is a \zkSNARKProof with \primaryInput
        $(\cv, \rt{Orchard}\kern-0.1em, \nf\kern-0.1em, \AuthSignRandomizedPublic, \cmX, \enableSpends, \enableOutputs)$
        for the \actionStatement defined in \crossref{actionstatement}.
\end{itemize}

\vspace{-1.5ex}
\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{txnencoding}), not in the $\type{ActionDescription}$ structure.
$\Proof{}$ is aggregated with other Action proofs and encoded in the $\proofsOrchard$ field of a
\transaction.}

\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$.

        The \spendAuthSignature \MUST be a valid $\SpendAuthSig{Orchard}$ signature over $\SigHash$
        using $\AuthSignRandomizedPublic$ as the \validatingKey ---
        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{}$ \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}
\begin{nnotes}
        \vspace{-0.25ex}
  \item $\cv$ and $\AuthSignRandomizedPublic$ can be the zero point $\ZeroP$. $\EphemeralPublic$ cannot
        be $\ZeroP$.
        \vspace{-0.25ex}
  \item $\nf$ and $\cmX$ are \emph{not} checked to be valid \affineSW $x$-coordinates on the \pallasCurve;
        they are only checked to encode integers in $\range{0}{\ParamP{q}-1}$.
\end{nnotes}
} %nufive


\vspace{-3ex}
\lsubsection{Sending Notes}{send}

\vspace{-1ex}
\lsubsubsection{Sending Notes (\SproutText)}{sproutsend}

\vspace{-1ex}
In order to send \Sprout \shielded value, the sender constructs a
\transaction containing one or more \joinSplitDescriptions.

\introlist
Let $\JoinSplitSig$ be as specified in \crossref{abstractsig}.

\vspace{-0.5ex}
Let $\NoteCommitAlg{Sprout}$ be as specified in \crossref{abstractcommit}.

\vspace{-0.5ex}
Let $\RandomSeedLength$ and $\NoteUniquePreRandLength$ be as specified in \crossref{constants}.

Sending a \transaction containing \joinSplitDescriptions involves first
generating a new $\JoinSplitSig$ key pair:

\begin{formulae}
  \item $\joinSplitPrivKey \leftarrowR \JoinSplitSigGenPrivate()$
  \item $\joinSplitPubKey := \JoinSplitSigDerivePublic(\joinSplitPrivKey)$.
\end{formulae}

\vspace{-1ex}
\introlist
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. 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}()$.
  \item Compute $\NoteUniqueRand_i = \PRFrho{\NoteUniquePreRand}(i, \hSig)$.
        \vspace{-0.5ex}
  \item Compute $\cm_i =
        \NoteCommit{Sprout}{\NoteCommitRand_i}(\AuthPublicSub{i}, \Value_i, \NoteUniqueRand_i)$.
        \vspace{-0.5ex}
  \item Let $\NotePlaintext{i} = (\hexint{00}, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i, \Memo_i)$.
\end{itemize}

\vspace{-1ex}
$\NotePlaintext{\allNew}$ are then encrypted to the recipient \transmissionKeys
$\TransmitPublicSub{\allNew}$, giving the \notesCiphertextSprout
$(\EphemeralPublic, \TransmitCiphertext{\allNew})$, as described in \crossref{sproutinband}.

In order to minimize information leakage, the sender \SHOULD randomize the order
of the input \notes and of the output \notes. Other considerations relating to
information leakage from the structure of \transactions are beyond the
scope of this specification.

After generating all of the \joinSplitDescriptions, the sender obtains
$\dataToBeSigned \typecolon \byteseqs$ as described in \crossref{sproutnonmalleability},
and signs it with the private \defining{\joinSplitSigningKey}:

\begin{formulae}
  \item $\joinSplitSig \leftarrowR \JoinSplitSigSign{\text{\small\joinSplitPrivKey}}(\dataToBeSigned)$
\end{formulae}

\vspace{-0.5ex}
Then the encoded \transaction including $\joinSplitSig$ is submitted to the \peerToPeerNetwork.

\canopyonwardpnote{\cite{ZIP-211} specifies that nodes and wallets \MUST disable any facilities
to send to \Sprout addresses. This \SHOULD be made clear in user interfaces and API documentation.}

The facility to send to \Sprout addresses is \notbeforecanopy{in any case} \OPTIONAL for a particular
node or wallet implementation.


\sapling{
\vspace{-1ex}
\lsubsubsection{Sending Notes (\SaplingText)}{saplingsend}

\vspace{-1ex}
In order to send \Sapling \shielded value, the sender constructs a \transaction
with one or more \outputDescriptions.

Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as specified in \crossref{abstractcommit}.

\vspace{-0.25ex}
Let $\KA{Sapling}$ be as specified in \crossref{abstractkeyagreement}.

\vspace{-0.25ex}
Let $\DiversifyHash{Sapling}$ be as specified in \crossref{abstracthashes}.

\vspace{-0.25ex}
Let $\ToScalar{Sapling}$ be as specified in \crossref{saplingkeycomponents}.

Let $\reprJ$ and $\ParamJ{r}$ be as defined in \crossref{jubjub}.

\vspace{1ex}
Let $\OutViewingKey$ be a \Sapling \outgoingViewingKey that is intended to be able to decrypt
this payment. This may be one of:
\begin{itemize}
  \item the \outgoingViewingKey for the address (or one of the addresses) from which the
        payment was sent;
        \vspace{-0.5ex}
  \item the \outgoingViewingKey for all payments associated with an \definingquotedterm{account},
        to be defined in \cite{ZIP-32};
        \vspace{-0.5ex}
  \item $\bot$, if the sender should not be able to decrypt the payment once it has
        deleted its own copy.
\end{itemize}

\vspace{-2ex}
\introlist
\pnote{Choosing $\OutViewingKey = \bot$ is useful if the sender prefers to obtain
forward secrecy of the payment information with respect to compromise of its own secrets.}

\canopy{
Let $\CanopyActivationHeight$ be as defined in \crossref{constants}.

Let $\NotePlaintextLeadByte$ be the \notePlaintextLeadByte. This \MUST be $\hexint{01}$
if for the next \block, $\BlockHeight < \CanopyActivationHeight$, or $\hexint{02}$
if $\BlockHeight \geq \CanopyActivationHeight$.
}

\intropart
For each \outputDescription, the sender selects a value $\Value \typecolon \range{0}{\MAXMONEY}$
and a destination \Sapling \shieldedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, and then
performs the following steps:

\vspace{-0.5ex}
\begin{algorithm}
  \item Check that $\DiversifiedTransmitPublic$ is of type $\KAPublicPrimeSubgroup{Sapling}$, i.e.\ it
        \MUST be a valid \ctEdwardsCurve point on the \jubjubCurve (as defined in \crossref{jubjub}), and
        $\scalarmult{\ParamJ{r}}{\DiversifiedTransmitPublic} = \ZeroJ$.
        \vspace{-0.25ex}
  \item Calculate $\DiversifiedTransmitBase = \DiversifyHash{Sapling}(\Diversifier)$
        and check that $\DiversifiedTransmitBase \neq \bot$.
        \vspace{-0.25ex}
  \item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Sapling}()$.
\canopy{
        \vspace{-0.25ex}
  \item If $\NotePlaintextLeadByte = \hexint{01}$:
} %canopy
        \vspace{-0.25ex}
  \item \canopy{\tab} Choose a uniformly random \ephemeralPrivateKey $\EphemeralPrivate \leftarrowR \KAPrivate{Sapling} \setminus \setof{0}$.
        \vspace{-0.25ex}
  \item \canopy{\tab} Choose a uniformly random \commitmentTrapdoor $\NoteCommitRand \leftarrowR \NoteCommitGenTrapdoor{}()$.
        \vspace{-0.25ex}
  \item \canopy{\tab} Set $\NoteCommitRandBytesOrSeedBytes := \ItoLEOSP{256}(\NoteCommitRand)$.
\canopy{
        \vspace{-0.25ex}
  \item else:
        \vspace{-0.25ex}
  \item \tab Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$.
        \vspace{-0.25ex}
  \item \tab Derive $\NoteCommitRand = \ToScalar{Sapling}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$.
        \vspace{-0.25ex}
  \item \tab Derive $\EphemeralPrivate = \ToScalar{Sapling}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.1em\big)$.
  \item \blank
} %canopy
        \vspace{-0.25ex}
  \item Let $\cv = \ValueCommit{Sapling}{\ValueCommitRand}(\Value)$.
        \vspace{-0.25ex}
  \item Let $\cm = \NoteCommit{Sapling}{\NoteCommitRand}(\reprJ\Of{\DiversifiedTransmitBase},
                                                         \reprJ\Of{\DiversifiedTransmitPublic},
                                                         \Value)$.
        \vspace{-0.15ex}
  \item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$.
        \vspace{-0.25ex}
  \item Encrypt $\NotePlaintext{}$ to the recipient
        \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ with
        \diversifiedBase $\DiversifiedTransmitBase$, and to the
        \outgoingViewingKey $\OutViewingKey$, giving the \noteCiphertextSapling
        $(\EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext)$.
        This procedure is described in \crossref{saplingandorchardencrypt}; it also uses
        $\cvField$ and $\cmuField$ to derive $\OutCipherKey$, and takes
        $\EphemeralPrivate$ as input.
        \vspace{-0.25ex}
  \item Generate a proof $\ProofOutput$ for the \outputStatement in \crossref{outputstatement}.
        \vspace{-0.25ex}
  \item Return $(\cv, \cm, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \ProofOutput)$.
\end{algorithm}

\vspace{-1ex}
In order to minimize information leakage, the sender \SHOULD randomize the order of
\outputDescriptions 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 \peerToPeerNetwork.
} %sapling


\nufive{
\vspace{-1ex}
\introlist
\lsubsubsection{Sending Notes (\OrchardText)}{orchardsend}

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{0.25ex}
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}.

Let $\reprP$, $\ParamP{r}$, and the \pallasCurve be as defined in \crossref{pallasandvesta}.

Let $\ExtractPbot$ be as defined in \crossref{concreteextractorpallas}.

Let $\ItoLEOSP{}$ be as defined in \crossref{endian}.

\vspace{0.5ex}
\introlist
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}.

\vspace{-0.25ex}
Let $\NotePlaintextLeadByte$ be the \notePlaintextLeadByte, which \MUST be $\hexint{02}$.

\vspace{0.5ex}
\introlist
For each \actionDescription, the sender selects a value $\Value \typecolon \range{0}{\MAXMONEY}$
and a destination \Orchard \shieldedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, and
performs the following steps:

\begin{algorithm}
        \vspace{-0.5ex}
  \item Check that $\DiversifiedTransmitPublic$ is of type $\KAPublic{Orchard}$.
  \item Calculate $\DiversifiedTransmitBase = \DiversifyHash{Orchard}(\Diversifier)$.
  \item Choose a uniformly random \commitmentTrapdoor $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Orchard}()$.
  \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$.
  \item Let $\NoteUniqueRand = \nfOld{}$ from the same \actionDescription, and let $\NoteUniqueRandBytes = \ItoLEOSPOf{256}{\NoteUniqueRand}$.
  \item Derive $\EphemeralPrivate = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([4] \bconcat \NoteUniqueRandBytes)\kern-0.1em\big)$.
  \item If $\EphemeralPrivate = 0 \pmod{\ParamP{r}}$, repeat the above steps using a different $\NoteSeedBytes$.
  \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5] \bconcat \NoteUniqueRandBytes)\kern-0.1em\big)$.
  \item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9] \bconcat \NoteUniqueRandBytes)\kern-0.09em\big)$.
  \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}.
  \item Let $\cmX = \ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRand}(\reprP\Of{\DiversifiedTransmitBase},
                                                                           \reprP\Of{\DiversifiedTransmitPublic},
                                                                           \Value, \NoteUniqueRand, \NoteNullifierRand)\kern-0.1em\big)$.
  \item If $\cmX = \bot$, repeat the above steps using a different $\NoteSeedBytes$.
  \item Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteSeedBytes, \Memo)$.
        \vspace{0.25ex}
  \item Encrypt $\NotePlaintext{}$ to the recipient
        \diversifiedTransmissionKey $\DiversifiedTransmitPublic$ with
        \diversifiedBase $\DiversifiedTransmitBase$, and to the
        \outgoingViewingKey $\OutViewingKey$, giving the \noteCiphertextOrchard
        $(\EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext)$.
        This procedure is described in \crossref{saplingandorchardencrypt}; it uses
        $\cvNet{}$ and $\cmX$ to derive $\OutCipherKey$, and takes
        $\EphemeralPrivate$ as input.
  \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{-0.5ex}
If no real \Orchard \note is being spent in the same \actionTransfer, the sender
\SHOULD create a \dummyNote to spend as described in \crossref{orcharddummynotes},
and use that \dummyNote's \nullifier as the $\NoteUniqueRand$ value.

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 \peerToPeerNetwork.

\pnote{
The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are
swapped for \Orchard relative to \Sapling. This was due to an oversight and there is no good
reason for it.
} %pnote
} %nufive


\lsubsection{Dummy Notes}{dummynotes}

\vspace{-1ex}
\lsubsubsection{Dummy Notes (\SproutText)}{sproutdummynotes}

\vspace{-1ex}
The fields in a \joinSplitDescription allow for $\NOld$ input \notes, and
$\NNew$ output \notes. In practice, we may wish to encode a \joinSplitTransfer
with fewer input or output \notes. This is achieved using \defining{\dummyNotes}.

\introlist
\vspace{0.5ex}
Let $\AuthPrivateLength$ and $\PRFOutputLengthSprout$ be as defined in \crossref{constants}.

\introlist
Let $\PRFnf{Sprout}{}$ be as defined in \crossref{abstractprfs}.

Let $\NoteCommitAlg{Sprout}$ be as defined in \crossref{abstractcommit}.

\introlist
\vspace{0.5ex}
A \dummy \Sprout input \note, with index $i$ in the \joinSplitDescription,
is constructed as follows:
\begin{itemize}
  \item Generate a new uniformly random \spendingKey $\AuthPrivateOld{i} \leftarrowR \bitseq{\AuthPrivateLength}$
        and derive its \payingKey $\AuthPublicOld{i}$.
        \vspace{-0.5ex}
  \item Set $\vOld{i} = 0$.
        \vspace{-0.5ex}
  \item Choose uniformly random $\NoteUniqueRandOld{i} \leftarrowR \PRFOutputSprout$
        and $\NoteCommitRandOld{i} \leftarrowR \NoteCommitGenTrapdoor{Sprout}()$.
  \item Compute $\nfOld{i} = \PRFnf{Sprout}{\AuthPrivateOld{i}}(\NoteUniqueRandOld{i})$.
        \vspace{-0.25ex}
  \item Let $\TreePath{i}$ be a \dummy \merklePath for the
        \auxiliaryInput to the \joinSplitStatement (this will not be checked).
        \vspace{0.25ex}
  \item When generating the \joinSplitProof\!\!, set $\EnforceMerklePath{i}$ to $0$.
\end{itemize}

\vspace{-0.5ex}
A \dummy \Sprout output \note is constructed as normal but with
zero value, and sent to a random \shieldedPaymentAddress.


\sapling{
\vspace{-1ex}
\introsection
\lsubsubsection{Dummy Notes (\SaplingText)}{saplingdummynotes}

\vspace{-1ex}
In \Sapling there is no need to use \dummyNotes simply in order to fill
otherwise unused inputs as in the case of a \joinSplitDescription; nevertheless
it may be useful for privacy to obscure the number of real \shieldedInputs from
\Sapling \notes.

\vspace{0.5ex}
Let $\SpendingKeyLength$ be as defined in \crossref{constants}.

\vspace{-0.25ex}
Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as defined in \crossref{abstractcommit}.

\vspace{-0.25ex}
Let $\DiversifyHash{Sapling}$ be as specified in \crossref{abstracthashes}.

\vspace{-0.25ex}
Let $\ToScalar{Sapling}$ be as specified in \crossref{saplingkeycomponents}.

\vspace{-0.25ex}
Let $\reprJ$ and $\ParamJ{r}$ be as defined in \crossref{jubjub}.

\vspace{-0.25ex}
Let $\PRFnf{Sapling}{}$ be as defined in \crossref{abstractprfs}.

\vspace{-0.25ex}
Let $\NoteCommitAlg{Sapling}$ be as defined in \crossref{abstractcommit}.

\introlist
\vspace{0.75ex}
A \spendDescription for a \dummy \Sapling input \note is constructed as follows:
\begin{itemize}
  \item Choose uniformly random $\SpendingKey \leftarrowR \SpendingKeyType$.
        \vspace{-0.2ex}
  \item Generate the $\AuthSignPublic$ and $\NullifierKey$ components of a \fullViewingKey
        and a \diversifiedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$
        for $\SpendingKey$, as described in \crossref{saplingkeycomponents}.
        \vspace{-0.2ex}
  \item Let $\Value = 0$ and $\NotePosition = 0$.
        \vspace{-0.2ex}
  \item Choose uniformly random $\ValueCommitRand \leftarrowR \ValueCommitGenTrapdoor{Sapling}()$.
        \vspace{-0.4ex}
  \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$.
        \vspace{-0.2ex}
  \item Derive $\NoteCommitRand = \ToScalar{Sapling}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$.
        \vspace{-0.2ex}
  \item Let $\cv = \ValueCommit{Sapling}{\ValueCommitRand}(\Value)$.
        \vspace{-0.2ex}
  \item Let $\cm = \NoteCommit{Sapling}{\NoteCommitRand}\big(\reprJ\Of{\DiversifiedTransmitBase},
                                                             \reprJ\Of{\DiversifiedTransmitPublic},
                                                             \Value\big)$.
        \vspace{-0.2ex}
  \item Let $\NoteUniqueRandRepr = \reprJ\big(\MixingPedersenHash(\cm, \NotePosition)\kern-0.1em\big)$.
  \item Let $\NullifierKeyRepr = \reprJ(\NullifierKey)$.
        \vspace{-0.2ex}
  \item Let $\nf = \PRFnf{Sapling}{\NullifierKeyRepr}(\NoteUniqueRandRepr)$.
        \vspace{-0.2ex}
  \item Construct a \dummy \merklePath $\TreePath{}$ for use in the
        \auxiliaryInput to the \spendStatement (this will not be checked, because $\Value = 0$).
\end{itemize}

As in \Sprout, a \dummy \Sapling output \note is constructed as normal but with
zero value, and sent to a random \shieldedPaymentAddress.
} %sapling


\nufive{
\introsection
\lsubsubsection{Dummy Notes (\OrchardText)}{orcharddummynotes}

As for \Sapling, it may be useful for privacy to obscure the number of real \shieldedInputs
from \Orchard \notes.

\vspace{0.5ex}
Let $\SpendingKeyLength$ be as defined in \crossref{constants}.

\vspace{-0.5ex}
Let $\ValueCommitAlg{Orchard}$ and $\NoteCommitAlg{Orchard}$ be as defined in \crossref{abstractcommit}.

\vspace{-0.5ex}
Let $\DiversifyHash{Orchard}$ be as specified in \crossref{abstracthashes}.

\vspace{-0.5ex}
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}.

\vspace{-0.25ex}
Let $\DeriveNullifierAlg$ be as defined in \crossref{rhoandnullifiers}.

\vspace{-0.25ex}
Let $\NoteCommitAlg{Orchard}$ be as defined in \crossref{abstractcommit}.

\vspace{-0.25ex}
Let $\ItoLEOSP{}$ be as defined in \crossref{endian}.

\introlist
\vspace{0.5ex}
The spend-related fields of an \actionDescription for a \dummy \Orchard input \note are
constructed as follows:
\begin{itemize}
  \item Choose uniformly random $\SpendingKey \leftarrowR \SpendingKeyType$.
  \item Generate a \fullViewingKey $(\AuthSignPublic, \NullifierKey, \CommitIvkRand)$ and a
        \diversifiedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$
        for $\SpendingKey$ as described in \crossref{orchardkeycomponents}.
  \item Let $\Value = 0$.
  \item Choose uniformly random $\NoteSeedBytes \leftarrowR \NoteSeedBytesType$.
  \item Choose uniformly random $\NoteUniqueRandPoint \leftarrowR \GroupP$.
  \item Let $\NoteUniqueRand = \ExtractP(\NoteUniqueRandPoint)$ and $\NoteUniqueRandBytes = \ItoLEOSPOf{256}{\NoteUniqueRand}$.
  \item Derive $\NoteCommitRand = \ToScalar{Orchard}\big(\PRFexpand{\NoteSeedBytes}([5] \bconcat \NoteUniqueRandBytes)\kern-0.1em\big)$.
  \item Derive $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9] \bconcat \NoteUniqueRandBytes)\kern-0.1em\big)$.
  \item Let $\cm = \NoteCommit{Orchard}{\NoteCommitRand}\big(\reprP\Of{\DiversifiedTransmitBase},
                                                             \reprP\Of{\DiversifiedTransmitPublic},
                                                             \Value, \NoteUniqueRand, \NoteNullifierRand\big)$.
  \item If $\cm = \bot$, repeat the above steps using a different $\NoteSeedBytes$.
  \item Let $\nf = \DeriveNullifier{\NullifierKey}(\NoteUniqueRand, \NoteNullifierRand, \cm)$.
  \item Construct a \dummy \merklePath $\TreePath{}$ for use in the
        \auxiliaryInput to the \actionStatement (this will not be checked, because $\Value = 0$).
\end{itemize}

As in \Sprout and \Sapling, a \dummy \Orchard output \note is constructed as normal but with
zero value, and sent to a random \shieldedPaymentAddress.

\pnote{
The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are
swapped for \Orchard relative to \Sapling. This was due to an oversight and there is no good
reason for it.
} %pnote
} %nufive


\introlist
\lsubsection{Merkle Path Validity}{merklepath}

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}.
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\sapling{ and \Sapling}\nufive{ and \Orchard}
\noteCommitmentTrees.

Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash,
which is a \bitSequence.

The \merkleLayer numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot,
has $2^h$ \merkleNodes with \merkleIndices $0$ to $2^h-1$ inclusive.

Let $\MerkleNode{h}{i}$ be the \merkleHash associated with the \merkleNode at
\merkleIndex $i$ in \merkleLayer $h$.

The \merkleNodes at \merkleLayer $\MerkleDepth{}$ are called \defining{\merkleLeafNodes}.
When a \noteCommitment is added to the tree, it occupies the \merkleLeafNode
\merkleHash $\MerkleNode{\MerkleDepth{}}{i}$ for the next available $i$.

As-yet unused \merkleLeafNodes are associated with a distinguished \merkleHash
$\Uncommitted{Sprout}$\sapling{ or $\Uncommitted{Sapling}$}\nufive{ or $\Uncommitted{Orchard}$}.
It is assumed to be infeasible to find a preimage \note $\NoteTuple{}$ such that
$\NoteCommitment{Sprout}(\NoteTuple{}) = \Uncommitted{Sprout}$.
\sapling{(No similar assumption is needed for \SaplingOrOrchard because we use a representation
for $\Uncommitted{Sapling}$ that cannot occur as an output of $\NoteCommitment{Sapling}$\nufive{,
and similarly for \Orchard}.)}

\introlist
The \merkleNodes at \merkleLayers $0$ to $\MerkleDepth{}-1$ inclusive are called
\defining{\merkleInternalNodes}, and are associated with $\MerkleCRH{}$ outputs.
\MerkleInternalNodes are computed from their children in the next \merkleLayer
as follows: for $0 \leq h < \MerkleDepth{}$ and $0 \leq i < 2^h$,

\begin{formulae}
  \item $\MerkleNode{h}{i} := \MerkleCRH{}(h, \MerkleNode{h+1}{2i}, \MerkleNode{h+1}{2i+1})$.
\end{formulae}

\introlist
A \defining{\merklePath} from \merkleLeafNode $\MerkleNode{\MerkleDepth{}}{i}$ in the
\incrementalMerkleTree is the sequence

\begin{formulae}
  \item $\listcomp{\MerkleNode{h}{\MerkleSibling(h, i)} \for
          h \from \MerkleDepth{} \downto 1}$,
\end{formulae}

where
\begin{formulae}
  \item $\MerkleSibling(h, i) := \floor{\raisebox{0.5ex}{$\frac{i}{\strut 2^{\MerkleDepth{}-h}}$}} \xor 1$
\end{formulae}

Given such a \merklePath, it is possible to verify that \merkleLeafNode
$\MerkleNode{\MerkleDepth{}}{i}$ is in a tree with a given \merkleRoot $\rt{} = \MerkleNode{0}{0}$.

\sapling{
\begin{pnotes}
  \item For \Sapling, Merkle \merkleHashes are specified to be encoded as \bitSequences, but the
        \merkleRoot $\rt{Sapling}$ is encoded for the \primaryInput of a \spendProof as an element
        of $\GF{\ParamJ{q}}$, as specified in \crossref{cctsaplingspend}. The \spendCircuit allows
        inputs to $\MerkleCRH{Sapling}$ at each \merkleNode to be \nonCanonicallyFieldElement encoded,
        as specified in \crossref{cctmerklepath}.
\nufive{
  \item For \Orchard, Merkle \merkleHashes have type $\MerkleHashOrchard$ as defined in
        \crossref{concreteextractorpallas}. Similarly to \Sapling, the \actionCircuit allows
        inputs to $\MerkleCRH{Orchard}$ at each \merkleNode to be \nonCanonicallyFieldElement
        encoded.
  \item The \actionCircuit is permitted to be implemented in such a way that the \merklePath
        validity check can pass if any \merkleHash on the path, including the \merkleRoot, is
        $0$. This can only happen if $\SinsemillaHash$ returned $\bot$ for that hash, because
        $0$ is not the \affineSW $x$-coordinate of any point on the \pallasCurve (as shown in a
        note at \crossref{concreteextractorpallas}), and $\SinsemillaHashToPoint$ cannot return
        $\ZeroP$. Allowing the validity check to pass in that case models the fact that
        incomplete addition is used to implement Sinsemilla in the circuit. As proven in
        \theoremref{thmsinsemillaex}, a $\bot$ output from $\SinsemillaHash$ yields a
        nontrivial discrete logarithm relation. Since we assume finding such a relation to be
        infeasible, we can argue that it is safe to allow an adversary to create a proof that
        passes the Merkle validity check in such a case.
} %nufive
\end{pnotes}
} %sapling


\introsection
\lsubsection{SIGHASH Transaction Hashing}{sighash}

\Bitcoin and \Zcash use signatures and/or \nh{non-interactive} proofs associated
with \transaction inputs to authorize spending. Because these signatures or proofs
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 \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 \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
ciphertext in order to create an encryption of a related plaintext, without knowing the
original plaintext. \Zcash has been designed to mitigate malleability attacks, as described
in \crossref{sproutnonmalleability}\sapling{, \crossref{bindingsig}, and \crossref{spendauthsig}}.

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$, 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.

In \Zcash, all \sighashTypes are extended to cover the \Zcash-specific
fields $\nJoinSplit$, $\vJoinSplit$, and if present $\joinSplitPubKey$. These fields
are described in \crossref{txnencoding}. 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}.

The original \defining{\sighashAlgorithm} defined by \Bitcoin suffered from some deficiencies as
described in \cite{ZIP-143}; in \Zcash these were addressed by changing this algorithm
as part of the \Overwinter upgrade.
} %overwinter

\nufive{
\Orchard and the \NUFive \networkUpgrade introduce \transaction version 5, which \MUST be
used if any \actionTransfers are present. This version also provides nonmalleable \transaction
identifiers, and \MAY be used for that reason whether or not \actionTransfers are present.
} %nufive

\preoverwinter{The \sighashAlgorithm used prior to \Overwinter activation, i.e.\ for
version 1 and 2 \transactions, will be defined in \cite{ZIP-76} (to be written).}

\overwinteronly{The \sighashAlgorithm used after \Overwinter activation and before \Sapling
activation, i.e.\ for version 3 \transactions, is defined in \cite{ZIP-143}.}

\saplingonward{The \sighashAlgorithm used after \Sapling activation, i.e.\ for
version 4 \transactions, is defined in \cite{ZIP-243}.}

\blossomonward{The \sighashAlgorithm used after \Blossom activation is the same as
for \Sapling, but using the \Blossom \consensusBranchID \hexint{2BB40E60} as defined in
\cite{ZIP-206}.}

\heartwoodonward{The \sighashAlgorithm used after \Heartwood activation is the same as
for \Sapling, but using the \Heartwood \consensusBranchID \hexint{F5B9230B} as defined in
\cite{ZIP-250}.}

\canopyonward{The \sighashAlgorithm used after \Canopy activation is the same as
for \Sapling, but using the \Canopy \consensusBranchID \hexint{E9FF75A6} as defined in
\cite{ZIP-251}.}

\nufiveonward{The \sighashAlgorithm used for version 5 \transactions introduced by the
\NUFive \networkUpgrade is defined in \cite{ZIP-244}. Version 4 \transactions continue
to use the \sighashAlgorithm defined in \cite{ZIP-243}. After \NUFive activation, both
\transaction versions use the \NUFive \consensusBranchID \hexint{F919A198} as defined in
\cite{ZIP-252}.}

\nufive{
\consensusrule{
\nufiveonward{Any \sighashType encoding used in a version 5 \transaction \MUST be the
canonical encoding of one of the defined \sighashTypes, i.e.\ one of \hexint{01},
\hexint{02}, \hexint{03}, \hexint{81}, \hexint{82}, or \hexint{83}. (Previously,
undefined bits of a \sighashType encoding were ignored.)}
} %consensusrule
} %nufive


\introsection
\lsubsection{Non-malleability (\SproutText)}{sproutnonmalleability}

Let $\dataToBeSigned$ be the hash of the \transaction{}, not associated with an input,
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
to the other \joinSplitDescriptions in the same \transaction, an ephemeral $\JoinSplitSig$
key pair is generated for each \transaction, and the $\dataToBeSigned$ is
signed with the private \signingKey of this key pair. The corresponding public
\validatingKey is included in the \transaction encoding as $\joinSplitPubKey$.

$\JoinSplitSig$ is instantiated in \crossref{concretejssig}.

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}.

Let $\PRFpk{}$ be as defined in \crossref{abstractprfs}.

For each $i \in \setofOld$, the creator of a \joinSplitDescription calculates
$\h{i} = \PRFpk{\AuthPrivateOld{i}}(i, \hSig)$.

The correctness of $\h{\allOld}$ is enforced by the \joinSplitStatement
given in \crossref{sproutnonmalleablejs}. This ensures that a holder of
all of the $\AuthPrivateOld{\allOld}$ for every \joinSplitDescription in the
\transaction has authorized the use of the private \signingKey corresponding
to $\joinSplitPubKey$ to sign this \transaction.


\introlist
\lsubsection{Balance (\SproutText)}{joinsplitbalance}

\vspace{-1ex}
In \Bitcoin, all inputs to and outputs from a \transaction are transparent.
The total value of \transparentOutputs must not exceed the total value of
\transparentInputs. The net value of \transparentInputs minus \transparentOutputs
is transferred to the miner of the \block containing the \transaction; it is added
to the \minerSubsidy in the \coinbaseTransaction of the \block.

\Zcash \Sprout extends this by adding \joinSplitTransfers.
Each \joinSplitTransfer can be seen, from the perspective of the \transparentTxValuePool,
as an input and an output simultaneously.

$\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.

As defined in \cite{ZIP-209}, the \defining{\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.

\vspace{-2ex}
\consensusrule{If the \SproutChainValuePoolBalance would become negative in the \blockChain
created as a result of accepting a \block, then all nodes \MUST reject the block as invalid.}

\vspace{1ex}
Unlike original \Zerocash \cite{BCGGMTV2014}, \Zcash does not have
a distinction between Mint and Pour operations. The addition of $\vpubOld$ to a
\joinSplitDescription subsumes the functionality of both Mint and Pour.

Also, a difference in the number of real input \notes does not by itself cause two
\joinSplitDescriptions to be distinguishable.

As stated in \crossref{joinsplitdesc}, either $\vpubOld$ or $\vpubNew$ \MUST be zero.
No generality is lost because, if a \transaction in which both $\vpubOld$ and
$\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.


\sapling{
\introsection
\vspace{-2ex}
\extralabel{bindingsig}{\lsubsection{Balance and Binding Signature (\SaplingText)}{saplingbalance}}

\vspace{-1ex}
\Sapling adds \spendTransfers and \outputTransfers to the transparent and
\joinSplitTransfers present in \Sprout.
The net value of \spendTransfers minus \outputTransfers in a \transaction is
called the \defining{\saplingBalancingValue}, measured in \zatoshi as a signed integer
$\vBalance{Sapling}$.

$\vBalance{Sapling}$ is encoded in a \transaction as the field \valueBalance{Sapling}.
For a v4 \transaction, $\vBalance{Sapling}$ is always explicitly encoded.
\nufive{
For a v5 \transaction, $\vBalance{Sapling}$ is implicitly zero if the \transaction has
no \spendDescriptions or \outputDescriptions.
} %nufive
Transaction fields are described in \crossref{txnencoding}.

A positive $\saplingBalancingValue$ takes value from the \defining{\SaplingTxValuePool}
and adds it to the \transparentTxValuePool. A negative $\saplingBalancingValue$ does the
reverse. As a result, positive $\vBalance{Sapling}$ is treated like an \emph{input} to the
\transparentTxValuePool, whereas negative $\vBalance{Sapling}$ is treated like an \emph{output}
from that pool.

As defined in \cite{ZIP-209}, the \defining{\SaplingChainValuePoolBalance} for a given
\blockChain is the negation of the sum of all $\valueBalance{Sapling}$ field values for
\transactions in the \blockChain.

\vspace{-2ex}
\consensusrule{If the \SaplingChainValuePoolBalance would become negative in the \blockChain
created as a result of accepting a \block, then all nodes \MUST reject the block as invalid.}

\vspace{1ex}
\introlist
Consistency of $\vBalance{Sapling}$ with the \valueCommitments in \spendDescriptions
and \outputDescriptions is enforced by the \defining{\saplingBindingSignature}.
This signature has a dual rôle in the \Sapling protocol:

\begin{itemize}
  \item To prove that the total value spent by \spendTransfers, minus that produced
        by \outputTransfers, is consistent with the $\vBalance{Sapling}$ field
        of the \transaction;
        \vspace{-0.5ex}
  \item To prove that the signer knew the randomness used for the Spend and Output
        \valueCommitments, in order to prevent \outputDescriptions from being
        replayed by an adversary in a different \transaction.
        (A \spendDescription already cannot be replayed due to its \spendAuthSignature.)
\end{itemize}

Instead of generating a key pair at random, we generate it as a function of the
\valueCommitments in the \spendDescriptions and \outputDescriptions of the \transaction,
and the \saplingBalancingValue.

\vspace{2ex}
Let $\SubgroupJ$, $\SubgroupJstar$, and $\ParamJ{r}$ be as defined in \crossref{jubjub}.

\introlist
\crossref{concretevaluecommit} instantiates:
\vspace{-0.5ex}
\begin{formulae}
  \item $\ValueCommitAlg{Sapling} \typecolon \ValueCommitTrapdoor{Sapling} \times \ValueCommitTypeSapling \rightarrow \ValueCommitOutput{Sapling}$;
        \vspace{-1ex}
  \item $\ValueCommitValueBase{Sapling} \typecolon \SubgroupJstar$, the value base in $\ValueCommitAlg{Sapling}$;
  \item $\ValueCommitRandBase{Sapling} \typecolon \SubgroupJstar$, the randomness base in $\ValueCommitAlg{Sapling}$.
\end{formulae}

$\BindingSig{Sapling}$, $\combplus$, and $\grpplus$ are instantiated in \crossref{concretebindingsig}.

\crossref{abstractsigmono} specifies these operations and the derived notation $\combminus$, $\scombsum{i=1}{\rmN}$,
$\grpminus$, and $\sgrpsum{i=1\vphantom{p}}{\rmN}$, which in this section are to be interpreted as
operating on the \primeOrderSubgroup of points on the \jubjubCurve and on its scalar field.

\vspace{1ex}
\introlist
Suppose that the \transaction has:
\begin{itemize}
  \item $n$ \spendDescriptions with \valueCommitments $\cvOld{\alln}$,
        committing to values $\vOld{\alln}$ with randomness $\ValueCommitRandOld{\alln}$;
  \item $m$ \outputDescriptions with \valueCommitments $\cvNew{\allm}$,
        committing to values $\vNew{\allm}$ with randomness $\ValueCommitRandNew{\allm}$;
  \item \saplingBalancingValue $\vBalance{Sapling}$.
\end{itemize}

\vspace{-1ex}
In a correctly constructed \transaction, $\vBalance{Sapling} = \ssum{i=1}{n} \vOld{i} - \ssum{j=1}{m} \vNew{j}$,
but validators cannot check this directly because the values are hidden by the commitments.

\introlist
Instead, validators calculate the \defining{\txBindingValidatingKey} as:
\begin{formulae}
% <https://twitter.com/hdevalence/status/984145085674676224> ¯\_(ツ)_/¯
  \item $\BindingPublic{Sapling} := \Bigg(\!\vcombsum{i=1}{n}\kern 0.2em \cvOld{i}\kern 0.05em\Bigg) \combminus\!
                                    \Bigg(\kern-0.05em\vcombsum{j=1}{m}\kern 0.2em \cvNew{j}\kern 0.05em\Bigg) \combminus
                                    \ValueCommit{Sapling}{0}\big(\vBalance{Sapling}\big)$.
\end{formulae}
\vspace{-1ex}
(This key is not encoded explicitly in the \transaction and must be recalculated.)

\introlist
\vspace{1ex}
The signer knows $\ValueCommitRandOld{\alln}$ and $\ValueCommitRandNew{\allm}$, and so can
calculate the corresponding \signingKey as:
\begin{formulae}
  \item $\BindingPrivate{Sapling} := \Bigg(\!\vgrpsum{i=1}{n} \ValueCommitRandOld{i}\Bigg) \grpminus\!
                                     \Bigg(\!\vgrpsum{j=1}{m} \ValueCommitRandNew{j}\Bigg)$.
\end{formulae}

\vspace{-1ex}
In order to check for implementation faults, the signer \SHOULD also check that
\begin{formulae}
  \item $\BindingPublic{Sapling} = \BindingSigDerivePublic{Sapling}(\BindingPrivate{Sapling})$.
\end{formulae}

\vspace{-1ex}
Let $\SigHash$ be the \sighashTxHash as defined in \cite{ZIP-243} for a version 4
\transaction\nufive{ or \cite{ZIP-244} for a version 5 \transaction}, not associated with
an input, using the \sighashType $\SIGHASHALL$.

A validator checks balance by validating that
$\BindingSigValidate{Sapling}{\BindingPublic{Sapling}}(\SigHash, \bindingSig{Sapling}) = 1$.

\vspace{1ex}
\introlist
We now explain why this works.

\vspace{1ex}
A \saplingBindingSignature proves knowledge of the discrete logarithm $\BindingPrivate{Sapling}$
of $\BindingPublic{Sapling}$ with respect to $\ValueCommitRandBase{Sapling}$.
That is, $\BindingPublic{Sapling} = \scalarmult{\BindingPrivate{Sapling}}{\ValueCommitRandBase{Sapling}}$.
So the value $0$ and randomness $\BindingPrivate{Sapling}$ is an opening of the \xPedersenCommitment
$\BindingPublic{Sapling} = \ValueCommit{Sapling}{\BindingPrivate{Sapling}}(0)$.
By the \binding property of the \xPedersenCommitment, it is infeasible to find another
opening of this commitment to a different value.

Similarly, the \binding property of the \valueCommitments in the \spendDescriptions and
\outputDescriptions ensures that an adversary cannot find an opening to more than one value
for any of those commitments, i.e.\ we may assume that $\vOld{\alln}$ are determined by
$\cvOld{\alln}$, and that $\vNew{\allm}$ are determined by $\cvNew{\allm}$. We may also
assume, from Knowledge Soundness of \Groth, that the Spend proofs could not have been
generated without knowing $\ValueCommitRandOld{\alln} \pmod{\ParamJ{r}}$, and the Output
proofs could not have been generated without knowing $\ValueCommitRandNew{\allm} \pmod{\ParamJ{r}}$.

\introlist
Using the fact that $\ValueCommit{Sapling}{\ValueCommitRand}(\Value) = \scalarmult{\Value}{\ValueCommitValueBase{Sapling}}\,
\combplus \scalarmult{\ValueCommitRand}{\ValueCommitRandBase{Sapling}}$, the expression for $\BindingPublic{Sapling}$
above is equivalent to:

\vspace{1ex}
\begin{tabular}{@{\hskip 2em}r@{\;}l}
  $\BindingPublic{Sapling}$ &$= \Biggscalarmult{\Bigg(\!\vgrpsum{i=1}{n} \vOld{i}\Bigg) \grpminus\!
                                                \Bigg(\!\vgrpsum{j=1}{m} \vNew{j}\Bigg) \grpminus \vBalance{Sapling}}{\ValueCommitValueBase{Sapling}}\, \combplus
                                \Biggscalarmult{\Bigg(\!\vgrpsum{i=1}{n} \ValueCommitRandOld{i}\Bigg) \grpminus\!
                                                \Bigg(\!\vgrpsum{j=1}{m} \ValueCommitRandNew{j}\Bigg)}{\ValueCommitRandBase{Sapling}}$ \\[3.5ex]
                            &$= \ValueCommit{Sapling}{\BindingPrivate{Sapling}}\Bigg(\!\vsum{i=1}{n} \vOld{i} - \vsum{j=1}{m} \vNew{j} - \vBalance{Sapling}\Bigg)$.
\end{tabular}

\introlist
Let $\vSum = \vsum{i=1}{n} \vOld{i} - \vsum{j=1}{m} \vNew{j} - \vBalance{Sapling}$.

Suppose that $\vSum = \vBad \neq 0 \pmod{\ParamJ{r}}$.
Then $\BindingPublic{Sapling} = \ValueCommit{Sapling}{\BindingPrivate{Sapling}}(\vBad)$.
If the adversary were able to find the discrete logarithm of this $\BindingPublic{Sapling}$
with respect to $\ValueCommitRandBase{Sapling}$, say ${\BindingPrivate{}}'$ (as needed to
create a valid \saplingBindingSignature), then $(\vBad, \BindingPrivate{Sapling})$ and
$(0, {\BindingPrivate{}}')$ would be distinct openings of $\BindingPublic{Sapling}$ to different
values, breaking the \binding property of the \valueCommitmentScheme.

\introlist
The above argument shows only that $\Value^* = 0 \pmod{\ParamJ{r}}$; in order to show that
$\vSum = 0$, we will also demonstrate that it does not overflow $\ValueCommitTypeSapling$.

The $\spendStatements$ (\crossref{spendstatement}) prove that all of $\vOld{\alln}$
are in $\ValueType$. Similarly the $\outputStatements$ (\crossref{outputstatement})
prove that all of $\vNew{\allm}$ are in $\ValueType$.
$\vBalance{Sapling}$ is encoded in the \transaction as a signed two's complement $64$-bit integer
in the range $\SignedValueFieldType$. $\ValueLength$ is defined as 64, so $\vSum$
is in the range $\range{-m \mult (2^{64}-1) - 2^{63} + 1}{n \mult (2^{64}-1) + 2^{63}}$.
The maximum \transaction size is $2$ MB, and the minimum contributions of a \spendDescription
and an \outputDescription to \transaction size
are\notnufive{ $384$ bytes}\nufive{ (in a v5 \transaction) $352$ bytes} and $948$ bytes
respectively, limiting $n$ to at
most\notnufive{ $\floor{\frac{2000000}{384}} = 5208$}\nufive{ $\floor{\frac{2000000}{352}} = 5681$}
and $m$ to at most $\floor{\frac{2000000}{948}} = 2109$.

This ensures that $\vSum \in
\range{-38913406623490299131842}{\notnufive{96079866507916199586728}\nufive{104805176454780817500623}}$,
a subrange of $\ValueCommitTypeSapling$.

Thus checking the \saplingBindingSignature ensures that the \spendTransfers and \outputTransfers
in the \transaction balance, without their individual values being revealed.

In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em-sum of the
\Sapling \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash
by signing $\SigHash$.

\vspace{1ex}
\pnote{
The spender \MAY reveal any strict subset of the \Sapling \valueCommitment randomnesses
to other parties that are cooperating to create the \transaction. If all of the
\valueCommitment randomnesses are revealed, that could allow replaying the
\outputDescriptions of the \transaction.
} %pnote

\nnote{
The technique of checking signatures using a \validatingKey derived from a sum of
\xPedersenCommitments is also used in the \Mimblewimble protocol \cite{Jedusor2016}.
The \privateKey $\BindingPrivate{Sapling}$ acts as a \definingquotedterm{synthetic blinding factor},
in the sense that it is synthesized from the other blinding factors (\trapdoors)
$\ValueCommitRandOld{\alln}$ and $\ValueCommitRandNew{\allm}$; this technique is
also used in \Bulletproofs \cite{Dalek-notes}.
} %nnote
} %sapling


\nufive{
\introlist
\lsubsection{Balance and Binding Signature (\OrchardText)}{orchardbalance}

\Orchard introduces \actionTransfers, each of which can optionally perform a spend,
and optionally perform an output. Similarly to \Sapling, the net value of \Orchard
spends minus outputs in a \transaction is called the \defining{\orchardBalancingValue},
measured in \zatoshi as a signed integer $\vBalance{\Orchard}$.

$\vBalance{Orchard}$ is encoded in a \transaction as the field \valueBalance{Orchard}.
If a \transaction has no \actionDescriptions, $\vBalance{Orchard}$ is implicitly zero.
Transaction fields are described in \crossref{txnencoding}.

A positive $\orchardBalancingValue$ takes value from the \defining{\OrchardTxValuePool}
and adds it to the \transparentTxValuePool. A negative $\orchardBalancingValue$ does the
reverse. As a result, positive $\vBalance{Orchard}$ is treated like an \emph{input} to the
\transparentTxValuePool, whereas negative $\vBalance{Orchard}$ is treated like an \emph{output}
from that pool.

Similarly to the \SaplingChainValuePoolBalance defined in \cite{ZIP-209}, the
\defining{\OrchardChainValuePoolBalance} for a given \blockChain is the negation of the
sum of all $\valueBalance{Orchard}$ field values for \transactions in the \blockChain.

\vspace{-1ex}
\consensusrule{If the \OrchardChainValuePoolBalance would become negative in the \blockChain
created as a result of accepting a \block, then all nodes \MUST reject the block as invalid.}

\introlist
\vspace{2ex}
Consistency of $\vBalance{Orchard}$ with the \valueCommitments in \actionDescriptions
is enforced by the \defining{\orchardBindingSignature}. The rôle of this signature in the
\Orchard protocol is to prove that the net value spent (i.e.\ the total value spent minus
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,
an \orchardBindingSignature does prove that the signer knew this commitment randomness;
this provides defence in depth and reduces the differences of \Orchard from \Sapling,
which may simplify security analysis.}

\vspace{1ex}
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{0.5ex}
Let $\GroupP$, $\GroupPstar$, and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}.

\introlist
\crossref{concretevaluecommit} instantiates:
\vspace{-0.5ex}
\begin{formulae}
  \item $\ValueCommitAlg{Orchard} \typecolon \ValueCommitTrapdoor{Orchard} \times \ValueCommitTypeOrchard \rightarrow \ValueCommitOutput{Orchard}$;
        \vspace{-1ex}
  \item $\ValueCommitValueBase{Orchard} \typecolon \GroupPstar$, the value base in $\ValueCommitAlg{Orchard}$;
  \item $\ValueCommitRandBase{Orchard} \typecolon \GroupPstar$, the randomness base in $\ValueCommitAlg{Orchard}$.
\end{formulae}

$\BindingSig{Orchard}$, $\combplus$, and $\grpplus$ are instantiated in \crossref{concretebindingsig}.

\crossref{abstractsigmono} specifies these operations and the derived notation $\combminus$, $\scombsum{i=1}{\rmN}$,
$\grpminus$, and $\sgrpsum{i=1\vphantom{p}}{\rmN}$, which in this section are to be interpreted as
operating on the \pallasCurve and its scalar field.

\vspace{1ex}
\introlist
Suppose that the \transaction has:
\begin{itemize}
  \item $n$ \actionDescriptions with \valueCommitments $\cvNet{\alln}$,
        committing to values $\vNet{\alln}$ with randomness $\ValueCommitRandNet{\alln}$;
  \item \orchardBalancingValue $\vBalance{Orchard}$.
\end{itemize}

\vspace{-1ex}
In a correctly constructed \transaction, $\vBalance{Orchard} = \ssum{i=1}{n} \vNet{i}$,
but validators cannot check this directly because the values are hidden by the commitments.

\introlist
Instead, validators calculate the \defining{\txBindingValidatingKey} as:
\begin{formulae}
  \item $\BindingPublic{Orchard} := \Bigg(\!\vcombsum{i=1}{n}\kern 0.2em \cvNet{i}\kern 0.05em\Bigg) \combminus
                                    \ValueCommit{Orchard}{0}\big(\vBalance{Orchard}\big)$.
\end{formulae}
\vspace{-1ex}
(This key is not encoded explicitly in the \transaction and must be recalculated.)

\introlist
\vspace{1ex}
The signer knows $\ValueCommitRandNet{\alln}$, and so can calculate the corresponding \signingKey as:
\begin{formulae}
  \item $\BindingPrivate{Orchard} := \vgrpsum{i=1}{n} \ValueCommitRandNet{i}$.
\end{formulae}

\vspace{-1ex}
In order to check for implementation faults, the signer \SHOULD also check that
\begin{formulae}
  \item $\BindingPublic{Orchard} = \BindingSigDerivePublic{Orchard}(\BindingPrivate{Orchard})$.
\end{formulae}

A \transaction containing \actionDescriptions is necessarily a version 5 \transaction.
Let $\SigHash$ be the \sighashTxHash for a version 5 \transaction as defined in \cite{ZIP-244}
as modified by \cite{ZIP-225}, not associated with an input, using the \sighashType $\SIGHASHALL$.

A validator checks balance by validating that
$\BindingSigValidate{Orchard}{\BindingPublic{Orchard}}(\SigHash, \bindingSig{Orchard}) = 1$.

\introlist
\vspace{1ex}
The security argument is very similar to that for \saplingBindingSignatures, but
for completeness we spell it out, since there are minor differences due to the net
value commitments, and a different bound on the net value sum $\vSum$.

\vspace{1ex}
An \orchardBindingSignature proves knowledge of the discrete logarithm $\BindingPrivate{Orchard}$
of $\BindingPublic{Orchard}$ with respect to $\ValueCommitRandBase{Orchard}$.
That is, $\BindingPublic{Orchard} = \scalarmult{\BindingPrivate{Orchard}}{\ValueCommitRandBase{Orchard}}$.
So the value $0$ and randomness $\BindingPrivate{Orchard}$ is an opening of the \xPedersenCommitment
$\BindingPublic{Orchard} = \ValueCommit{Orchard}{\BindingPrivate{Orchard}}(0)$.
By the \binding property of the \xPedersenCommitment, it is infeasible to find another
opening of this commitment to a different value.

Similarly, the \binding property of the \valueCommitments in the \actionDescriptions
ensures that an adversary cannot find an opening to more than one value
for any of those commitments, i.e.\ we may assume that $\vNet{\alln}$ are determined by
$\cvNet{\alln}$. We may also assume, from Knowledge Soundness of \HaloTwo, that the Action
proofs could not have been generated without knowing $\ValueCommitRandNet{\alln} \pmod{\ParamP{r}}$.

\introlist
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{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{\vgrpsum{i=1}{n} \ValueCommitRandNet{i}}{\ValueCommitRandBase{Orchard}}$ \\[3.5ex]
                            &$= \ValueCommit{Orchard}{\BindingPrivate{Orchard}}\Bigg(\!\vsum{i=1}{n} \vNet{i} - \vBalance{Orchard}\Bigg)$.
\end{tabular}

\introlist
Let $\vSum = \vsum{i=1}{n} \vNet{i} - \vBalance{Orchard}$.

Suppose that $\vSum = \vBad \neq 0 \pmod{\ParamJ{r}}$.
Then $\BindingPublic{Orchard} = \ValueCommit{Orchard}{\BindingPrivate{Orchard}}(\vBad)$.
If the adversary were able to find the discrete logarithm of this $\BindingPublic{Orchard}$
with respect to $\ValueCommitRandBase{Orchard}$, say ${\BindingPrivate{}}'$ (as needed to
create a valid \orchardBindingSignature), then $(\vBad, \BindingPrivate{Orchard})$ and
$(0, {\BindingPrivate{}}')$ would be distinct openings of $\BindingPublic{Orchard}$ to different
values, breaking the \binding property of the \valueCommitmentScheme.

\introlist
The above argument shows only that $\Value^* = 0 \pmod{\ParamP{r}}$; in order to show that
$\vSum = 0$, we will also demonstrate that it does not overflow $\ValueCommitTypeOrchard$.

The $\actionStatements$ (\crossref{actionstatement}) prove that all $\vNet{\alln}$
are in $\SignedValueDifferenceType$. $\vBalance{Orchard}$ is encoded in the \transaction as a
\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).

This ensures that $\vSum \in \range{-1208916596242592319864832}{1208916596242592319864833}$,
a subrange of $\ValueCommitTypeOrchard$.

Thus checking the \orchardBindingSignature ensures that the \actionTransfers in the \transaction
balance, without their individual net values being revealed.

In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em-sum of the
\Orchard \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash
by signing $\SigHash$.

\pnote{
The spender \MAY reveal any strict subset of the \Orchard \valueCommitment randomnesses to
other parties that are cooperating to create the \transaction.
} %pnote
} %nufive


\sapling{
\introsection
\lsubsection{Spend Authorization Signature (\SaplingAndOrchardText)}{spendauthsig}

$\SpendAuthSig{}$ is used in \SaplingAndOrchard to prove knowledge of the \spendingKey authorizing
spending of an input \note. It is instantiated in \crossref{concretespendauthsig}.

We use $\SpendAuthSig{Sapling}$ to refer to the \spendAuthSignatureScheme for
\Sapling, which is instantiated on the \jubjubCurve.
\nufive{We use $\SpendAuthSig{Orchard}$ to refer to the \spendAuthSignatureScheme for
\Orchard, which is instantiated on the \pallasCurve. The following discussion applies to
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 \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\nufive{ or \actionStatement} proves that
this \validatingKey is a \reRandomization 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}\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}\nufive{ or in \crossref{orchardkeycomponents}}.

\notbeforenufive{
Let $\SpendAuthSig{}$ be $\SpendAuthSig{Sapling}$\nufive{ or $\SpendAuthSig{Orchard}$ as applicable}.
} %notbeforenufive

\introlist
\vspace{1ex}
For each \spendDescription\nufive{ or \actionDescription}, the signer chooses a fresh
\defining{\spendAuthRandomizer} $\AuthSignRandomizer$:

\begin{enumerate}
  \item Choose $\AuthSignRandomizer \leftarrowR \SpendAuthSigGenRandom{\maybeSapling}()$.
  \item Let $\AuthSignRandomizedPrivate = \SpendAuthSigRandomizePrivate{\maybeSapling}(\AuthSignRandomizer, \AuthSignPrivate)$.
  \item Let $\AuthSignRandomizedPublic = \SpendAuthSigDerivePublic{\maybeSapling}(\AuthSignRandomizedPrivate)$.
  \item Generate a proof $\Proof{}$ of the \spendStatement (\crossref{spendstatement})\nufive{ or
        \actionStatement (\crossref{actionstatement})}, with $\AuthSignRandomizer$ in the
        \auxiliaryInput and $\AuthSignRandomizedPublic$ in the \primaryInput.
  \item Let $\spendAuthSig = \SpendAuthSigSign{\maybeSapling}{\AuthSignRandomizedPrivate}(\SigHash)$.
\end{enumerate}

The resulting $\spendAuthSig$ and $\Proof{}$ are included in the \spendDescription\nufive{, or
in the \vSpendAuthSigs{Sapling} or \vSpendAuthSigs{Orchard} field of a version 5 \transaction}.

\vspace{1ex}
\pnote{
If the spender is computationally or memory-limited, step 4 (and only step 4) \MAY be delegated
to a different party that is capable of performing the \zkSNARKProof. In this case privacy will be
lost to that party since it needs $\AuthSignPublic$ and the \authProvingKey $\AuthProvePrivate$;
this allows also deriving the $\NullifierKey$ component of the \fullViewingKey. \nufive{(In
\Orchard, that party needs the $\NullifierKey$ directly to make the \zkSNARKProof.)} Together
$\AuthSignPublic$ and $\NullifierKey$ are sufficient to recognize spent \notes and to recognize
and decrypt incoming \notes. However, the other party will not obtain \spendingAuthority for other
\transactions, since it is not able to create a \spendAuthSignature by itself.
} %pnote
} %sapling


\intropart
\extralabel{commitmentsandnullifiers}{\lsubsection{Computing \NoteUniqueRandText{} values and Nullifiers}{rhoandnullifiers}}

\vspace{1ex}
In \Sprout\nufive{ and \Orchard}, each \note has a $\NoteUniqueRand$ component, defined as
part of the \note.

\sapling{
\vspace{1ex}
\introlist
In \Sapling, each \positionedNote (as defined in \crossref{notecommitmentconcept}) has an associated
$\NoteUniqueRand$ value, which is computed from its \noteCommitment $\cm$ and \notePosition
$\NotePosition$ as follows:

\begin{formulae}
  \item $\NoteUniqueRand := \MixingPedersenHash(\cm, \NotePosition)$.
\end{formulae}

\vspace{-1ex}
$\MixingPedersenHash$ is defined in \crossref{concretemixinghash}.
} %sapling

\vspace{2ex}
\introlist
Let $\PRFnf{Sprout}{}$\sapling{ and $\PRFnf{Sapling}{}$}\nufive{ and $\PRFnf{Orchard}{}$}
be as instantiated in \crossref{concreteprfs}.

\vspace{1ex}
For a \Sprout \note, the \nullifier (see \crossref{nullifierconcept}) is derived as
$\PRFnf{Sprout}{\AuthPrivate}(\NoteUniqueRand)$, where $\AuthPrivate$ is the \spendingKey
associated with the \note.

\vspace{1ex}
\sapling{
For a \Sapling \note, the \nullifier is derived as
$\PRFnf{Sapling}{\NullifierKeyRepr}(\NoteUniqueRandRepr)$, where $\NullifierKeyRepr$
is a representation of the \nullifierDerivingKey associated with the \note and
$\NoteUniqueRandRepr = \reprJ(\NoteUniqueRand)$.
} %sapling

\vspace{1ex}
\nufive{
\introlist
The derivation of \nullifiers for \Orchard \notes is a little more complicated.

Let $\GroupP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.

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}}\,$.

\introlist
To avoid repetition, we define a function $\DeriveNullifierAlg \typecolon
\NullifierKeyTypeOrchard \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \GroupP \rightarrow \NullifierTypeOrchard$
as follows:

\begin{formulae}
  \item $\DeriveNullifier{\NullifierKey}(\NoteUniqueRand, \NoteNullifierRand, \cm) =
           \ExtractP\big(\bigscalarmult{(\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) +
                                         \NoteNullifierRand) \bmod \ParamP{q}}{\NullifierBaseOrchard} + \cm\big)$.
\end{formulae}
\vspace{-0.5ex}
where $\NullifierKey$ is the \nullifierDerivingKey associated with the \note;
$\NoteUniqueRand$ and $\NoteNullifierRand$ are part of the \note; and $\cm$ is
the \noteCommitment.

\pnote{The addition of $\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand)$ and $\NoteNullifierRand$
is intentionally done modulo $\ParamP{q}$, even though the scalar multiplication is on the \pallasCurve
which has scalar field $\GF{\ParamP{r}}$.}
} %nufive

\securityrequirement{
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
        the \note\sapling{, and possibly its position}, in a way that can be
        checked in the corresponding statement that controls spends (i.e.\ the
        \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.)
  \item Given a set of \nullifiers of \emph{a priori} unknown \notes,
        they must not be linkable to those \notes with probability greater
        than expected by chance, even to an adversary with the corresponding
        \incomingViewingKeys (but not \fullViewingKeys), and even if the
        adversary may have created the \notes.
\end{itemize}
} %securityrequirement

\pagebreak
\lsubsection{Zk-SNARK Statements}{snarkstatements}

\vspace{-1ex}
\lsubsubsection{JoinSplit Statement (\SproutText)}{joinsplitstatement}

\vspace{-2ex}
Let $\MerkleHashLength{Sprout}$, $\PRFOutputLengthSprout$, $\MerkleDepth{Sprout}$, $\ValueLength$,
$\AuthPrivateLength$, $\NoteUniquePreRandLength$, $\hSigLength$, $\NOld$, $\NNew$ be as defined in \crossref{constants}.

\vspace{-1ex}
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
let $\NoteType{Sprout}$ and $\NoteCommitment{Sprout}$ be as defined in \crossref{notes}.

A valid instance of a \defining{\joinSplitStatement}, $\ProofJoinSplit$, assures that given a \primaryInput:

\vspace{-1ex}
\begin{formulae}
  \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\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}$,
\end{formulae}
\vspace{-1.5ex}
the prover knows an \auxiliaryInput:
\vspace{-0.5ex}
\begin{formulae}
  \item $\oparen\TreePath{\allOld} \typecolon \typeexp{\typeexp{\MerkleHash{Sprout}}{\MerkleDepth{Sprout}}}{\NOld},\\
         \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},\vspace{0.5ex}\\
         \hparen\NoteUniquePreRand \typecolon \bitseq{\NoteUniquePreRandLength},\vspace{-0.5ex}\\
         \hparen\EnforceMerklePath{\allOld} \typecolon \bitseq{\NOld}\cparen$,
\end{formulae}
\vspace{-2ex}
where:
\vspace{-0.5ex}
\begin{formulae}
  \item for each $i \in \setofOld$: $\nOld{i} = (\AuthPublicOld{i},
\vOld{i}, \NoteUniqueRandOld{i}, \NoteCommitRandOld{i})$;
  \item for each $i \in \setofNew$: $\nNew{i} = (\AuthPublicNew{i},
\vNew{i}, \NoteUniqueRandNew{i}, \NoteCommitRandNew{i})$
\end{formulae}
\vspace{-1ex}
such that the following conditions hold:

\snarkcondition{Merkle path validity}{sproutmerklepathvalidity}
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}.}

\snarkcondition{Merkle path enforcement}{sproutmerklepathenforcement}
for each $i \in \setofOld$, if $\vOld{i} \neq 0$ then $\EnforceMerklePath{i} = 1$.

\vspace{-0.5ex}
\snarkcondition{Balance}{sproutbalance}
$\vpubOld + \ssum{i=1}{\NOld} \vOld{i} = \vpubNew + \ssum{i=1}{\NNew} \vNew{i} \in \ValueType$.

\vspace{0.5ex}
\snarkcondition{Nullifier integrity}{sproutnullifierintegrity}
for each $i \in \setofOld$:
$\nfOld{i} = \PRFnf{Sprout}{\AuthPrivateOld{i}}(\NoteUniqueRandOld{i})$.

\snarkcondition{Spend authority}{sproutspendauthority}
for each $i \in \setofOld$:
$\AuthPublicOld{i} = \PRFaddr{\AuthPrivateOld{i}}(0)$.

\snarkcondition{Non-malleability}{sproutnonmalleablejs}
for each $i \in \setofOld$:
$\h{i} = \PRFpk{\AuthPrivateOld{i}}(i, \hSig)$.

\snarkcondition{Uniqueness of $\NoteUniqueRandNew{i}$}{sproutuniquerho}
for each $i \in \setofNew$:
$\NoteUniqueRandNew{i} = \PRFrho{\NoteUniquePreRand}(i, \hSig)$.

\snarkcondition{Note commitment integrity}{sproutcommitmentintegrity}
for each $i \in \setofNew$: $\cmNew{i} = \NoteCommitment{Sprout}(\nNew{i})$.

\vspace{1ex}
For details of the form and encoding of proofs, see \crossref{bctv}.


\sapling{
\lsubsubsection{Spend Statement (\SaplingText)}{spendstatement}

\vspace{-1ex}
Let $\MerkleHashLength{Sapling}$, $\PRFOutputLengthNfSapling$, $\ScalarLength{Sapling}$, and $\MerkleDepth{Sapling}$
be as defined in \crossref{constants}.

\vspace{-0.5ex}
Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as specified in \crossref{abstractcommit}.

\vspace{-0.5ex}
Let $\SpendAuthSig{Sapling}$ be as defined in \crossref{concretespendauthsig}.

\vspace{-0.5ex}
Let $\GroupJ$, $\SubgroupJ$, $\reprJ$, $\ParamJ{q}$, $\ParamJ{r}$, and $\ParamJ{h}$ be as defined in \crossref{jubjub}.

\vspace{-0.5ex}
Let $\ExtractJ \typecolon \SubgroupJ \rightarrow \MerkleHash{Sapling}$ be as defined in \crossref{concreteextractorjubjub}.

\vspace{-0.5ex}
Let $\AuthProveBaseSapling$ be as defined in \crossref{saplingkeycomponents}.

\intropart
\vspace{0.5ex}
A valid instance of a \defining{\spendStatement}, $\ProofSpend$, assures that given a \primaryInput:

\vspace{-1ex}
\begin{formulae}
  \item $\oparen\rt{Sapling} \typecolon \MerkleHash{Sapling},\\
         \hparen\cvOld{} \typecolon \ValueCommitOutput{Sapling},\\
         \hparen\nfOld{} \typecolon \PRFOutputNfSapling,\\
         \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Sapling}\cparen$,
\end{formulae}

\vspace{-2ex}
\introlist
the prover knows an \auxiliaryInput:

\vspace{-1ex}
\begin{formulae}
  \item $\oparen\TreePath{} \typecolon \typeexp{\MerkleHash{Sapling}}{\MerkleDepth{Sapling}},\vspace{-0.4ex}\\
         \hparen\NotePosition \typecolon \NotePositionType{Sapling},\vspace{0.4ex}\\
         \hparen\DiversifiedTransmitBase \typecolon \GroupJ,\\
         \hparen\DiversifiedTransmitPublic \typecolon \GroupJ,\vspace{0.6ex}\\
         \hparen\vOld{} \typecolon \ValueType,\\
         \hparen\ValueCommitRandOld{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
         \hparen\cmOld{} \typecolon \GroupJ,\\
         \hparen\NoteCommitRandOld{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
         \hparen\AuthSignRandomizer \typecolon \binaryrange{\ScalarLength{Sapling}},\\
         \hparen\AuthSignPublic \typecolon \SpendAuthSigPublic{Sapling},\\
         \hparen\AuthProvePrivate \typecolon \binaryrange{\ScalarLength{Sapling}}\cparen$
\end{formulae}
\vspace{-1.5ex}
such that the following conditions hold:

\vspace{0.5ex}
\snarkcondition{Note commitment integrity}{spendnotecommitmentintegrity}
$\cmOld{} = \NoteCommit{Sapling}{\NoteCommitRandOld{}}(\reprJ\Of{\DiversifiedTransmitBase},
                                                       \reprJ\Of{\DiversifiedTransmitPublic},
                                                       \vOld{})$.

\snarkcondition{Merkle path validity}{spendmerklepathvalidity}
Either $\vOld{} = 0$; or $(\TreePath{}, \NotePosition)$ is a valid \merklePath of depth $\MerkleDepth{Sapling}$,
as defined in \crossref{merklepath}, from $\cmU = \ExtractJ(\cmOld{})$ to the \anchor $\rt{Sapling}$.

\snarkcondition{Value commitment integrity}{spendvaluecommitmentintegrity}
$\cvOld{} = \ValueCommit{Sapling}{\ValueCommitRandOld{}}(\vOld{})$.

\snarkcondition{Small order checks}{spendnonsmall}
$\DiversifiedTransmitBase$ and $\AuthSignPublic$
are not of \smallOrder, i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$
and $\scalarmult{\ParamJ{h}}{\AuthSignPublic} \neq \ZeroJ$.

\snarkcondition{Nullifier integrity}{spendnullifierintegrity}
$\nfOld{} = \PRFnf{Sapling}{\NullifierKeyRepr}(\NoteUniqueRandRepr)$ where
\vspace{-1ex}
\begin{formulae}
  \item $\NullifierKeyRepr = \reprJ\big(\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}\big)$
        \vspace{-1ex}
  \item $\NoteUniqueRandRepr = \reprJ\big(\MixingPedersenHash(\cmOld{}, \NotePosition)\kern-0.12em\big)$.
\end{formulae}

\vspace{-1ex}
\snarkcondition{Spend authority}{spendauthority}
$\AuthSignRandomizedPublic = \SpendAuthSigRandomizePublic{Sapling}(\AuthSignRandomizer, \AuthSignPublic)$.

\vspace{0.5ex}
\snarkcondition{Diversified address integrity}{spendaddressintegrity}
$\DiversifiedTransmitPublic = \scalarmult{\InViewingKey}{\DiversifiedTransmitBase}$ where
\vspace{-1ex}
\begin{formulae}
  \item $\InViewingKey = \CRHivk(\AuthSignPublicRepr, \NullifierKeyRepr)$
        \vspace{-1ex}
  \item $\AuthSignPublicRepr = \reprJ\Of{\AuthSignPublic}$\,.
\end{formulae}

For details of the form and encoding of \spendStatement proofs, see \crossref{groth}.

\begin{pnotes}
        \vspace{-0.5ex}
  \item \xPrimary and \auxiliaryInputs \MUST be constrained to have the types specified. In particular,
        see \crossref{ccteddecompressvalidate}, for required validity checks on compressed
        representations of \jubjubCurve points. \\[0.5ex]
        The $\ValueCommitOutput{Sapling}$ and $\SpendAuthSigPublic{Sapling}$ types also represent points,
        i.e.\ $\GroupJ$.
        \vspace{-0.5ex}
  \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its
        input \bitSequence is a canonical encoding (in $\range{0}{\ParamJ{q}-1}$) of the integer
        from the previous \merkleLayer.
        \vspace{-0.5ex}
  \item It is \emph{not} checked in the \spendStatement that $\AuthSignRandomizedPublic$ is not of
        \smallOrder. However, this \emph{is} checked outside the \spendStatement, as specified in
        \crossref{spenddesc}.
        \vspace{-0.5ex}
  \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$.
        \vspace{-0.5ex}
  \item $\SpendAuthSigRandomizePublic{Sapling}(\AuthSignRandomizer, \AuthSignPublic) = \AuthSignPublic + \scalarmult{\AuthSignRandomizer}{\AuthSignBase{Sapling}}$. \\[0.5ex]
        ($\AuthSignBase{Sapling}$ is as defined in \crossref{concretespendauthsig}.)
\end{pnotes}
} %sapling


\sapling{
\vspace{-2ex}
\introsection
\lsubsubsection{Output Statement (\SaplingText)}{outputstatement}

\vspace{-1ex}
Let $\MerkleHashLength{Sapling}$ and $\ScalarLength{Sapling}$ be
as defined in \crossref{constants}.

Let $\ValueCommitAlg{Sapling}$ and $\NoteCommitAlg{Sapling}$ be as specified in \crossref{abstractcommit}.

Let $\GroupJ$, $\reprJ$, and $\ParamJ{h}$ be as defined in \crossref{jubjub}.

\vspace{-0.5ex}
Let $\ExtractJ \typecolon \SubgroupJ \rightarrow \MerkleHash{Sapling}$ be as defined in \crossref{concreteextractorjubjub}.

\vspace{1ex}
A valid instance of an \defining{\outputStatement}, $\ProofOutput$, assures that given a \primaryInput:

\begin{formulae}
  \item $\oparen\cvNew{} \typecolon \ValueCommitOutput{Sapling},\\
         \hparen\cmU \typecolon \MerkleHash{Sapling},\\
         \hparen\EphemeralPublic \typecolon \GroupJ\cparen$,
\end{formulae}

\vspace{-1ex}
\introlist
the prover knows an \auxiliaryInput:

\begin{formulae}
  \item $(\DiversifiedTransmitBase \typecolon \GroupJ,\\[0.5ex]
   \hparen\DiversifiedTransmitPublicRepr \typecolon \ReprJ,\\
   \hparen\vNew{} \typecolon \ValueType,\\
   \hparen\ValueCommitRandNew{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
   \hparen\NoteCommitRandNew{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
   \hparen\EphemeralPrivate \typecolon \binaryrange{\ScalarLength{Sapling}})$
\end{formulae}
\vspace{-1ex}
such that the following conditions hold:

\vspace{1ex}
\snarkcondition{Note commitment integrity}{outputnotecommitmentintegrity}
$\cmU = \ExtractJ\big(\NoteCommit{Sapling}{\NoteCommitRandNew{}}(\DiversifiedTransmitBaseRepr,
                                                                 \DiversifiedTransmitPublicRepr,
                                                                 \vNew{})\kern-0.12em\big)$,
where $\DiversifiedTransmitBaseRepr = \reprJ\Of{\DiversifiedTransmitBase}$\,.

\vspace{-1ex}
\snarkcondition{Value commitment integrity}{outputvaluecommitmentintegrity}
$\cvNew{} = \ValueCommit{Sapling}{\ValueCommitRandNew{}}(\vNew{})$.

\snarkcondition{Small order check}{outputnonsmall}
$\DiversifiedTransmitBase$ is not of \smallOrder,
i.e.\ $\scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} \neq \ZeroJ$.

\vspace{0.5ex}
\snarkcondition{Ephemeral public key integrity}{outputepkintegrity}
$\EphemeralPublic = \scalarmult{\EphemeralPrivate}{\DiversifiedTransmitBase}$.

\vspace{2ex}
For details of the form and encoding of \outputStatement proofs, see \crossref{groth}.

\begin{pnotes}
        \vspace{-0.5ex}
  \item \xPrimary and \auxiliaryInputs \MUST be constrained to have the types specified. In particular,
        see \crossref{ccteddecompressvalidate}, for required validity checks on compressed
        representations of \jubjubCurve points.
        The $\ValueCommitOutput{Sapling}$ type also represents points, i.e. $\GroupJ$.
        \vspace{-0.5ex}
  \item The validity of $\DiversifiedTransmitPublicRepr$ is \emph{not} checked in this circuit (which is the reason
        why it is typed as a \bitSequence rather than as a point).
        \vspace{-0.5ex}
  \item It is \emph{not} checked that $\ValueCommitRandOld{} < \ParamJ{r}$ or that $\NoteCommitRandOld{} < \ParamJ{r}$.
\end{pnotes}
} %sapling


\nufive{
\vspace{-3ex}
\lsubsubsection{Action Statement (\OrchardText)}{actionstatement}

\vspace{-1ex}
Let $\MerkleHashLength{Orchard}$, $\ScalarLength{Orchard}$, and $\MerkleDepth{Orchard}$ be as defined in \crossref{constants}.

\vspace{-0.5ex}
Let $\ValueCommitAlg{Orchard}$, $\NoteCommitAlg{Orchard}$, and $\CommitIvkAlg$ be as specified in \crossref{abstractcommit}.

\vspace{-0.5ex}
Let $\SpendAuthSig{Orchard}$ be as defined in \crossref{concretespendauthsig}.

\vspace{-0.25ex}
Let $\GroupP$, $\GroupPstar$, $\reprP$, $\ParamP{q}$, and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}.

\vspace{-0.25ex}
Let $\Selectx$, $\Selecty$, $\ExtractP$, and $\ExtractPbot$ be as defined in \crossref{concreteextractorpallas}.

\vspace{-0.25ex}
Let $\DeriveNullifierAlg$ be as defined in \crossref{rhoandnullifiers}.

\intropart
\vspace{0.5ex}
A valid instance of an \defining{\actionStatement}, $\Proof{}$, assures that given a \primaryInput:

\vspace{-1ex}
\begin{formulae}
  \item $\oparen\rt{Orchard} \typecolon \MerkleHashOrchard,\\
         \hparen\cvNet{} \typecolon \ValueCommitOutput{Orchard},\\
         \hparen\nfOld{} \typecolon \range{0}{\ParamP{q}-1},\\
         \hparen\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Orchard},\\
         \hparen\cmX \typecolon \MerkleHashOrchard,\vspace{0.2ex}\\
         \hparen\enableSpends \typecolon \bit,\vspace{0.4ex}\\
         \hparen\enableOutputs \typecolon \bit\cparen$,
\end{formulae}

\vspace{-2ex}
\introlist
the prover knows an \auxiliaryInput:

\vspace{-1ex}
\begin{formulae}
  \item $\oparen\TreePath{} \typecolon \typeexp{\MerkleHashOrchard}{\MerkleDepth{Orchard}},\vspace{-0.6ex}\\
         \hparen\NotePosition \typecolon \NotePositionType{Orchard},\vspace{0.4ex}\\
         \hparen\DiversifiedTransmitBaseOld \typecolon \GroupPstar,\\
         \hparen\DiversifiedTransmitPublicOld \typecolon \GroupPstar,\vspace{0.6ex}\\
         \hparen\vOld{} \typecolon \ValueType,\\
         \hparen\NoteUniqueRandOld{} \typecolon \NoteUniqueRandTypeOrchard,\\
         \hparen\NoteNullifierRandOld \typecolon \NoteNullifierRandType,\vspace{-0.2ex}\\
         \hparen\NoteCommitRandOld{} \typecolon \binaryrange{\ScalarLength{Orchard}},\\
         \hparen\cmOld{} \typecolon \GroupP,\vspace{-0.6ex}\\
         \hparen\AuthSignRandomizer \typecolon \binaryrange{\ScalarLength{Orchard}},\vspace{0.2ex}\\
         \hparen\AuthSignPublicPoint \typecolon \GroupPstar,\\
         \hparen\NullifierKey \typecolon \NullifierKeyTypeOrchard,\\
         \hparen\CommitIvkRand \typecolon \CommitIvkTrapdoor,\\
         \hparen\DiversifiedTransmitBaseNew \typecolon \GroupPstar,\\
         \hparen\DiversifiedTransmitPublicNew \typecolon \GroupPstar,\vspace{0.2ex}\\
         \hparen\vNew{} \typecolon \ValueType,\vspace{0.2ex}\\
         \hparen\NoteNullifierRandNew \typecolon \NoteNullifierRandType,\vspace{-0.2ex}\\
         \hparen\NoteCommitRandNew{} \typecolon \binaryrange{\ScalarLength{Orchard}},\\
         \hparen\ValueCommitRand{} \typecolon \binaryrange{\ScalarLength{Orchard}}\cparen$
\end{formulae}
\vspace{-2ex}
such that the following conditions hold:

\introlist
\snarkcondition{Old note commitment integrity}{actionoldnotecommitmentintegrity}
$\NoteCommit{Orchard}{\NoteCommitRandOld{}}(\reprP(\DiversifiedTransmitBaseOld),
                                            \reprP(\DiversifiedTransmitPublicOld),
                                            \vOld{},
                                            \NoteUniqueRandOld{},
                                            \NoteNullifierRandOld) \in \setof{\cmOld{}, \bot}$.

\vspace{-0.5ex}
\snarkcondition{Merkle path validity}{actionmerklepathvalidity}
Either $\vOld{} = 0$; or $(\TreePath{}, \NotePosition)$ is a valid \merklePath of depth $\MerkleDepth{Orchard}$,
as defined in \crossref{merklepath}, from $\cmOld{}$ to the \anchor $\rt{Orchard}$.

\snarkcondition{Value commitment integrity}{actionvaluecommitmentintegrity}
$\cvNet{} = \ValueCommit{Orchard}{\ValueCommitRand}(\vOld{} - \vNew{})$.

\vspace{-0.5ex}
\snarkcondition{Nullifier integrity}{actionnullifierintegrity}
$\nfOld{} = \DeriveNullifier{\NullifierKey}(\NoteUniqueRandOld{}, \NoteNullifierRandOld, \cmOld{})$.

\snarkcondition{Spend authority}{actionspendauthority}
$\AuthSignRandomizedPublic = \SpendAuthSigRandomizePublic{Orchard}(\AuthSignRandomizer, \AuthSignPublicPoint)$.

\snarkcondition{Diversified address integrity}{actionaddressintegrity}
$\InViewingKey = \bot$ or $\DiversifiedTransmitPublicOld = \scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$ where
$\InViewingKey = \CommitIvk{\CommitIvkRand}\big(\ExtractP(\AuthSignPublicPoint), \NullifierKey\big)$.

\snarkcondition{New note commitment integrity}{actionnewnotecommitmentintegrity}
$\ExtractPbot\big(\NoteCommit{Orchard}{\NoteCommitRandNew{}}(\reprP(\DiversifiedTransmitBaseNew),
                                                             \reprP(\DiversifiedTransmitPublicNew),
                                                             \vNew{}\!,
                                                             \NoteUniqueRandNew{}\!,
                                                             \NoteNullifierRandNew)\kern-0.1em\big) \in \setof{\cmX, \bot}$,
where $\NoteUniqueRandNew{} = \nfOld{} \pmod{\ParamP{q}}$.

\vspace{-0.5ex}
\snarkcondition{Enable spend flag}{actionenablespend}
$\vOld{} = 0$ or $\enableSpends = 1$.

\snarkcondition{Enable output flag}{actionenableoutput}
$\vNew{} = 0$ or $\enableOutputs = 1$.

\vspace{2ex}
For details of the form and encoding of \actionStatement proofs, see \crossref{halo2}.

\begin{pnotes}
  \item The \primaryInputs are encoded as the following sequence of type $\typeexp{\GF{\ParamP{q}}}{9}$: \\
        $\big[\,\rt{Orchard} \pmod{\ParamP{q}}, \Selectx\Of{\cvNet{}}, \Selecty\Of{\cvNet{}},
                \nfOld{} \pmod{\ParamP{q}}, \Selectx\Of{\AuthSignRandomizedPublic}, \Selecty\Of{\AuthSignRandomizedPublic},
                \cmX \!\pmod{\ParamP{q}}, \enableSpends \pmod{\ParamP{q}}, \\
         \hphantom{\big[\,} \enableOutputs \pmod{\ParamP{q}} \,\big]$. \\[1ex]
        (Recall from \crossref{notation} that ``$\!\!\pmod{\ParamP{q}}$'' interprets an integer as an $\GF{\ParamP{q}}$
        element.)
  \item \xPrimary and \auxiliaryInputs \MUST be constrained to have the types specified.
        In particular, $\DiversifiedTransmitBaseOld$, $\DiversifiedTransmitPublicOld$,
        $\DiversifiedTransmitBaseNew$, $\DiversifiedTransmitPublicNew$, and $\AuthSignPublicPoint$ cannot be $\ZeroP$.
        The $\ValueCommitOutput{Orchard}$ and $\SpendAuthSigPublic{Orchard}$ types represent
        \pallasCurve points, i.e.\ $\GroupP$.
  \item The scalar multiplication used in $\ValueCommitAlg{Orchard}$ must operate correctly on the
        range $\SignedValueDifferenceType$, which is different to the range $\SignedValueFieldType$
        of $\vBalance{Orchard}$.
  \item In the Merkle path validity check, each \merkleLayer does \emph{not} check that its
        input \bitSequence is a canonical encoding (in $\MerkleHashOrchard$) of the integer
        from the previous \merkleLayer.
  \item As specified in \crossref{merklepath}, the validity check is permitted to be implemented in
        such a way that it can pass if any $\MerkleCRH{Orchard}$ hash on the \merklePath outputs $0$.
        This allows nondeterministic, incomplete addition to be used in the circuit for $\SinsemillaHash$.
  \item It is \emph{not} checked that $\ValueCommitRand{} < \ParamP{r}$ or that $\NoteCommitRandOld{} < \ParamP{r}$
        or that $\NoteCommitRandNew{} < \ParamP{r}$.
  \item $\SpendAuthSigRandomizePublic{Orchard}(\AuthSignRandomizer, \AuthSignPublicPoint) =
           \AuthSignPublicPoint + \scalarmult{\AuthSignRandomizer}{\AuthSignBase{Orchard}}$.

        ($\AuthSignBase{Orchard}$ is as defined in \crossref{concretespendauthsig}.)
  \item The validity of $\DiversifiedTransmitBaseRepr$ and $\DiversifiedTransmitPublicRepr$ are
        \emph{not} checked in this circuit. Also, $\rt{Orchard}$ and $\cmX$ are \emph{not} checked
        to be \Pallas \affineSW $x$-coordinates or $0$.
  \item When a value given as a field element in the \actionCircuit is used as a scalar for scalar
        multiplication, it involves witnessing the scalar as a sequence of bits or window indices,
        typically for a total of $255$ bits (except in the case of multiplying by the value
        difference $\vOld{} - \vNew{}$). This raises the possibility that the witnessed $255$-bit
        representation may match the original field element modulo $\ParamP{q}$, but \emph{not}
        modulo $\ParamP{r}$. Unless it can be proven to result in an equivalent statement, the
        decomposition of each scalar value \MUST be canonical. \\[1ex]
        The cases in which not checking canonicity results in an equivalent statement are those
        where the statement only requires to prove knowledge of the scalar, without using it
        elsewhere --- i.e.\ the multiplications by $\NoteCommitRandOld{}$ or $\NoteCommitRandNew{}$
        in $\NoteCommitAlg{Orchard}$, by $\ValueCommitRand$ in $\ValueCommitAlg{Orchard}$, by
        $\CommitIvkRand$ in $\CommitIvkAlg$, and by $\AuthSignRandomizer$ in
        $\SpendAuthSigRandomizePublic{Orchard}$. In particular, the representation of
        $(\PRFnf{Orchard}{\NullifierKey}(\NoteUniqueRand) + \NoteNullifierRand) \bmod \ParamP{q}$
        that is used for the scalar multiplication in $\DeriveNullifierAlg$ \MUST be checked to be
        canonical in order to avoid a potential \doubleSpend vulnerability, and similarly for the
        representation of $\InViewingKey$ in $\scalarmult{\InViewingKey}{\DiversifiedTransmitBaseOld}$.
\end{pnotes}

\vspace{-1ex}
\begin{nnotes}
  \item The procedure in \crossref{orchardkeycomponents} will always produce a \spendAuthAddressKey that
        effectively has the compressed $y$-coordinate, $\tilde{y}$, set to $0$. The \actionStatement, on the
        other hand, allows the prover to witness $\smash{\AuthSignPublicPoint}$ with $\tilde{y}$ set to $0$ or $1$.
        This is harmless because if the prover and signer(s) of the \spendAuthSignature collectively
        know $\AuthSignRandomizedPrivate$ and $\AuthSignRandomizer$, we can conclude that they
        collectively know $\AuthSignPrivate$ up to sign, which is sufficient for spend authorization.
        \vspace{-0.25ex}
        \introlist
  \item There is intentionally no equivalent to the \snarkref{Ephemeral public key integrity}{outputepkintegrity}
        check from the \Sapling \outputStatement. It is unnecessary for the sender of an \Orchard \note
        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}. These checks are
        required after the end of the ZIP 212 grace period, which precedes \NUFive activation.\vspace{-0.25ex}
  \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 relation. If the \xDiscreteLogarithmProblem is hard on the
        \pallasCurve, then finding such a case is infeasible.
\end{nnotes}
} %nufive


\vspace{-2.5ex}
\lsubsection{In-band secret distribution (\SproutText)}{sproutinband}

\vspace{-1ex}
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$. A \memo (\crossref{noteptconcept})
is also transmitted.

To transmit these secrets securely to a recipient
\emph{without} requiring an \outOfBand 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 and \memo.

\introlist
A single \ephemeralPublicKey is shared between encryptions of the $\NNew$
\shieldedOutputs in a \joinSplitDescription. All of the resulting ciphertexts
are combined to form a \notesCiphertextSprout.

For both encryption and decryption,

\vspace{-0.75ex}
\begin{itemize}
  \item let $\Sym$ be the scheme instantiated in \crossref{concretesym};
        \vspace{-0.5ex}
  \item let $\KDF{Sprout}$ be the \keyDerivationFunction instantiated in \crossref{concretesproutkdf};
        \vspace{-0.5ex}
  \item let $\KA{Sprout}$ be the \keyAgreementScheme instantiated in \crossref{concretesproutkeyagreement};
        \vspace{-0.5ex}
  \item let $\hSig$ be the value computed for this \joinSplitDescription in \crossref{joinsplitdesc}.
\end{itemize}


\vspace{-3ex}
\lsubsubsection{Encryption (\SproutText)}{sproutencrypt}

\vspace{-1ex}
Let $\KA{Sprout}$ be the \keyAgreementScheme instantiated in \crossref{concretesproutkeyagreement}.

\vspace{-0.75ex}
Let $\TransmitPublicSub{\allNew}$ be the \transmissionKeys
for the intended recipient addresses of each new \note.

\vspace{-0.5ex}
Let $\NotePlaintext{\allNew}$ be \Sprout \notePlaintexts defined in \crossref{noteptconcept}.

\introlist
\vspace{0.5ex}
Then to encrypt:

\vspace{-1.25ex}
\begin{itemize}
  \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})$.
    \end{itemize}
\end{itemize}

\vspace{-3ex}
The resulting \defining{\notesCiphertextSprout} is $(\EphemeralPublic, \TransmitCiphertext{\allNew})$.

\introlist
\pnote{
It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note
with a random (and undecryptable) dummy ciphertext, relying instead on \outOfBand
transmission of the \note to the recipient. In this case the ephemeral key \MUST
still be generated as a random \publicKey (rather than a random \bitSequence) to ensure
indistinguishability from other \joinSplitDescriptions. This mode of operation raises
further security considerations, for example of how to validate a \Sprout{}
\note received \outOfBand, which are not addressed in this document.
}

\lsubsubsection{Decryption (\SproutText)}{sproutdecrypt}

\vspace{-1ex}
Let $\InViewingKey = (\AuthPublic, \TransmitPrivate)$ be the recipient's \incomingViewingKey,
and let $\TransmitPublic$ be the corresponding \transmissionKey derived from
$\TransmitPrivate$ as specified in \crossref{sproutkeycomponents}.

Let $\cm_{\allNew}$ be the \noteCommitments of each output coin.

\introlist
\vspace{0.5ex}
Then for each $i \in \setofNew$, the recipient will attempt to decrypt that ciphertext
component $(\EphemeralPublic, \TransmitCiphertext{i})$ as follows:

\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)$
        \vspace{-0.5ex}
  \item return $\DecryptNoteSprout(\TransmitKey{i}, \TransmitCiphertext{i}, \cm_i, \AuthPublic).$
\end{formulae}

\introlist
$\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.6ex}
  \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}$
        \vspace{-0.5ex}
  \item let $\NoteTuple{i} = (\AuthPublic, \Value_i, \NoteUniqueRand_i, \NoteCommitRand_i)$
        \vspace{-0.5ex}
  \item if $\NotePlaintextLeadByte_i \neq \hexint{00}$ or $\NoteCommitment{Sprout}(\NoteTuple{i}) \neq \cm_i$, return $\bot$
        \vspace{-0.2ex}
  \item return $(\NoteTuple{i}, \Memo_i)$.
\end{formulae}

\introlist
\vspace{-1ex}
\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}

See \crossref{inbandrationale} for further discussion of the security and
engineering rationale behind this encryption scheme.


\sapling{
\introsection
\extralabel{saplinginband}{\lsubsection{In-band secret distribution (\SaplingAndOrchardText)}{saplingandorchardinband}}

\vspace{-1ex}
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 \outOfBand communication channel, the \diversifiedTransmissionKey
$\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's
possession of the associated $\KA{Sapling}$\nufive{ or $\KA{Orchard}$}
\privateKey $\InViewingKey$ is used to reconstruct the original \note and \memo.

Unlike in \Sprout, each \SaplingOrOrchard \shieldedOutput is encrypted by a fresh \ephemeralPublicKey.

\vspace{0.5ex}
For both encryption and decryption,
\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}$}
        defined in \crossref{notecommitmentconcept};
        \vspace{-0.25ex}
  \item let $\ToScalar{}$ be $\ToScalar{Sapling}$ defined in \crossref{saplingkeycomponents}\nufive{ or
        $\ToScalar{Orchard}$ defined in \crossref{orchardkeycomponents}};
        \vspace{-0.25ex}
  \item $\LEBStoOSP{}$, $\LEOStoIP{}$, $\ItoLEBSP{}$, and $\ItoLEOSP{}$ are defined in \crossref{endian}.
\end{itemize}
} %sapling


\sapling{
\vspace{-2ex}
\extralabel{saplingencrypt}{\lsubsubsection{Encryption (\SaplingAndOrchardText)}{saplingandorchardencrypt}}

\vspace{-1ex}
Let $\DiversifiedTransmitPublic \typecolon \KAPublicPrimeSubgroup{}$ be the
\diversifiedTransmissionKey for the intended recipient address of a new \SaplingOrOrchard \note,
and let $\DiversifiedTransmitBase \typecolon \KAPublicPrimeSubgroup{}$ be the corresponding
\diversifiedBase computed as $\DiversifyHash{}(\Diversifier)$.

Since \Sapling \note encryption is used only in the context of \crossref{saplingsend}\nufive{, and similarly
\Orchard \note encryption is used only in the context of \crossref{orchardsend}}, we may assume that
$\DiversifiedTransmitBase$ has already been calculated and is not $\bot$. Also, the \ephemeralPrivateKey
$\EphemeralPrivate$ has been chosen.

\introlist
Let $\OutViewingKey \typecolon \maybe{\OutViewingKeyType}$ be as described in \shortcrossref{saplingsend}\nufive{ or
\shortcrossref{orchardsend}}, i.e.\ the \outgoingViewingKey of the \shieldedPaymentAddress from which the \note is being
spent, or an \outgoingViewingKey associated with a \cite{ZIP-32} account, or $\bot$.

Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$
be the \SaplingOrOrchard \notePlaintext.\notnufive{

} $\NotePlaintext{}$ is encoded as defined in \crossref{noteptencoding}.

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}
Then to encrypt:
\begin{algorithm}
  \item let $\TransmitPlaintext{}$ be the \rawEncoding of $\NotePlaintext{}$
  \item let $\EphemeralPublic = \KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)$
  \item let $\ephemeralKey = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\EphemeralPublic}\kern 0.03em}$
        \vspace{-0.25ex}
  \item let $\DHSecret{} = \KAAgree{}(\EphemeralPrivate, \DiversifiedTransmitPublic)$
  \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$
  \item let $\TransmitCiphertext{} = \SymEncrypt{\TransmitKey{}}(\TransmitPlaintext{})$
  \item if $\OutViewingKey = \bot$:
  \item \tab choose random $\OutCipherKey \leftarrowR \Keyspace$ and $\OutPlaintext \leftarrowR \byteseq{(\ellG{} + 256)/8}$
  \item else:
  \item \tab let $\cvField = \LEBStoOSP{\ellG{}}\big(\reprG{}(\cv)\kern-0.12em\big)$
        \vspace{-0.25ex}
  \item \tab let $\cmstarField = \LEBStoOSP{256}\big(\ExtractG(\cm)\kern-0.12em\big)$
        \vspace{-0.25ex}
  \item \tab let $\OutCipherKey = \PRFock{}{\OutViewingKey}(\cvField, \cmstarField, \ephemeralKey)$
        \vspace{0.25ex}
  \item \tab let $\OutPlaintext = \LEBStoOSPOf{\ellG{} + 256}{\reprG{}(\DiversifiedTransmitPublic) \,\bconcat\, \ItoLEBSPOf{256}{\EphemeralPrivate}\kern-0.12em}$
  \item \vspace{-2ex}
  \item let $\OutCiphertext = \SymEncrypt{\OutCipherKey}(\OutPlaintext)$
\end{algorithm}

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 \outOfBand
transmission of the \note to the recipient. In this case the ephemeral key \MUST
still be generated as a random \publicKey (rather than a random \bitSequence) to ensure
indistinguishability from other \outputDescriptions. This mode of operation raises
further security considerations, for example of how to validate a \SaplingOrOrchard \note
received \outOfBand, which are not addressed in this document.
} %pnote
} %sapling


\sapling{
\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 $\KA{Sapling}$\nufive{ or $\KA{Orchard}$}
\privateKey, as specified in \crossref{saplingkeycomponents}\nufive{ or in \crossref{orchardkeycomponents}}.

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 \affineCtEdwards
$u$-coordinate\nufive{ or \affineSW $x$-coordinate} of the \noteCommitment, i.e.\ $\ExtractG(\cm)$.)

\canopy{
Let the constants $\CanopyActivationHeight$ and $\ZIPTwoOneTwoGracePeriod$ be as defined in \crossref{constants}.

Let $\BlockHeight$ be the \blockHeight of the \block containing this \transaction.
} %canopy

\introsection
The recipient will attempt to decrypt the $\ephemeralKey$ and $\TransmitCiphertext{}$
components of the \noteCiphertext:
\begin{algorithm}
        \vspace{-0.5ex}
  \item let $\EphemeralPublic = \abstG{}\Of{\ephemeralKey}\,$. if $\EphemeralPublic = \bot$, return $\bot$
        \vspace{-0.3ex}
  \item let $\DHSecret{} = \KAAgree{}(\InViewingKey, \EphemeralPublic)$
  \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$
        \vspace{-0.2ex}
  \item let $\TransmitPlaintext{} = \SymDecrypt{\TransmitKey{}}(\TransmitCiphertext{})$. if $\TransmitPlaintext{} = \bot$, return $\bot$
        \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$}
  \canopyonwarditem{for \Sapling, let $\NoteCommitRandPre = [4]$ and $\EphemeralPrivatePre = [5]$}
\nufive{
  \item for \Orchard, let $\NoteUniqueRandBytes = \ItoLEOSP{256}\big(\nfOld{}$ from the same \actionDescription$\kern-0.2em\big)\kern-0.08em$, $\NoteCommitRandPre = [5] \bconcat \NoteUniqueRandBytes$,
        and $\EphemeralPrivatePre = [4] \bconcat \NoteUniqueRandBytes$
} %nufive
  \canopyonwarditem{let $\NoteCommitRandBytes = \begin{cases}
                      \NoteSeedBytes,&\caseif \NotePlaintextLeadByte = \hexint{01} \\
                      \ToScalar{}\big(\PRFexpand{\NoteSeedBytes}(\NoteCommitRandPre)\kern-0.1em\big),&\caseotherwise
                    \end{cases}$}
  \item let $\NoteCommitRand = \LEOStoIPOf{256}{\NoteCommitRandBytes}$
        and $\DiversifiedTransmitBase = \DiversifyHash{}(\Diversifier)$.
        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}(\EphemeralPrivatePre)\kern-0.1em\big)$
        \vspace{-0.2ex}
  \item \tab if $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big) \neq \ephemeralKey$,
        return $\bot$
  \item \blank
} %canopy
  \item let $\DiversifiedTransmitPublic = \KADerivePublic{}(\InViewingKey, \DiversifiedTransmitBase)$
        \vspace{-0.25ex}
  \item \notbeforenufive{for \Sapling,} let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand)$
        \vspace{-0.25ex}
\nufive{
  \item for \Orchard, let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$
        where $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9] \bconcat \NoteUniqueRandBytes)\kern-0.1em\big)$
        \vspace{-0.2ex}
} %nufive
  \item let $\cmstar' = \NoteCommitment{}\Of{\NoteTuple{}}\,$. \nufive{if (for \Orchard) $\cmstar' = \bot$, return $\bot$}
        \vspace{-0.2ex}
  \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}
  \item $\DiversifiedTransmitBase$ has already been computed when applying $\NoteCommitment{}$, and need
        not be computed again.
        \vspace{-0.6ex}
  \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.}
        \vspace{-0.6ex}
  \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 per \crossref{rhoandnullifiers}.
        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 in \shortcrossref{rhoandnullifiers} is not in the \nullifierSet for
        that \blockChain.
        \vspace{-0.6ex}
  \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.6ex}
  \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, and private.
        \vspace{-0.6ex}
  \nufiveonwarditem{It is a consensus rule (in \crossref{actiondesc}) that each \actionDescription
        field \MUST be a valid encoding of its declared type, which in the case of $\ephemeralKey$ is
        $\KAPublic{Orchard}$ (i.e.\ $\GroupPstar$), and therefore $\EphemeralPublic$ cannot be $\ZeroP$.}
        \vspace{-0.6ex}
  \nufiveonwarditem{The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are
        swapped for \Orchard relative to \Sapling. This was due to an oversight and there is no good reason for it.}
\end{pnotes}
} %sapling

\sapling{
\vspace{-3ex}
\extralabel{saplingdecryptovk}{\lsubsubsection{Decryption using a Full Viewing Key (\SaplingAndOrchardText)}{decryptovk}}

\vspace{-1ex}
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.)

\canopy{
Let the constants $\CanopyActivationHeight$ and $\ZIPTwoOneTwoGracePeriod$ be as defined in \crossref{constants}.

\vspace{-0.4ex}
Let $\BlockHeight$ be the \blockHeight of the \block containing this \transaction.
} %canopy

\vspace{-0.5ex}
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.

\nufive{
\vspace{-0.5ex}
For an \Orchard \noteCiphertextOrchard, let $\cvField$ and $\cmstarField$ be the $\cvField$ and $\cmxField$
fields of the \actionDescription.
} %nufive

\vspace{0.5ex}
The \outgoingViewingKey holder will attempt to decrypt the \noteCiphertext as follows:

\introlist
\vspace{-0.5ex}
\begin{algorithm}
  \item let $\OutCipherKey = \PRFock{}{\OutViewingKey}(\cvField, \cmstarField, \ephemeralKey)$
        \vspace{-0.2ex}
  \item let $\OutPlaintext = \SymDecrypt{\OutCipherKey}(\OutCiphertext)\,$. if $\OutPlaintext = \bot$, return $\bot$
        \vspace{-0.2ex}
  \item extract $(\DiversifiedTransmitPublicRepr \typecolon \ReprG{},
        \EphemeralPrivateBytes \typecolon \EphemeralPrivateBytesType)$ from $\OutPlaintext$
  \item let $\EphemeralPrivate = \LEOStoIPOf{256}{\EphemeralPrivateBytes}$
        and $\DiversifiedTransmitPublic = \abstG{}\Of{\DiversifiedTransmitPublicRepr}$
        \vspace{-0.2ex}
  \item if $\EphemeralPrivate \geq \ParamG{r}$ or $\DiversifiedTransmitPublic = \bot$, return $\bot$
  \nufiveonwarditem{if $\reprP\big(\DiversifiedTransmitPublic\big) \neq \DiversifiedTransmitPublicRepr$, return $\bot$}
        \vspace{-0.2ex}
  \item let $\DHSecret{} = \KAAgree{}(\EphemeralPrivate, \DiversifiedTransmitPublic)$
        \vspace{-0.2ex}
  \item let $\TransmitKey{} = \KDF{}(\DHSecret{}, \ephemeralKey)$
        \vspace{-0.2ex}
  \item let $\TransmitPlaintext{} = \SymDecrypt{\TransmitKey{}}(\TransmitCiphertext{})$. if $\TransmitPlaintext{} = \bot$, return $\bot$
        \vspace{-0.4ex}
  \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$}
  \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$}
  \canopyonwarditem{for \Sapling, let $\NoteCommitRandPre = [4]$ and $\EphemeralPrivatePre = [5]$}
\nufive{
  \item for \Orchard, let $\NoteUniqueRandBytes = \ItoLEOSP{256}\big(\nfOld{}$ from the same \actionDescription$\kern-0.2em\big)\kern-0.08em$, $\NoteCommitRandPre = [5] \bconcat \NoteUniqueRandBytes$,
        and $\EphemeralPrivatePre = [4] \bconcat \NoteUniqueRandBytes$
} %nufive
  \canopyonwarditem{if $\NotePlaintextLeadByte \neq \hexint{01}$ and $\ToScalar{}\big(\PRFexpand{\NoteSeedBytes}(\EphemeralPrivatePre)\kern-0.1em\big) \neq \EphemeralPrivate$, return $\bot$}
        \vspace{-0.2ex}
  \canopyonwarditem{let $\NoteCommitRandBytes = \begin{cases}
                      \NoteSeedBytes,&\caseif \NotePlaintextLeadByte = \hexint{01} \\
                      \ToScalar{}\big(\PRFexpand{\NoteSeedBytes}(\NoteCommitRandPre)\kern-0.1em\big),&\caseotherwise
                    \end{cases}$}
  \item let $\NoteCommitRand = \LEOStoIPOf{256}{\NoteCommitRandBytes}$
        and $\DiversifiedTransmitBase = \DiversifyHash{}(\Diversifier)$
        \vspace{-0.2ex}
  \item if $\NoteCommitRand \geq \ParamG{r}$ or\notbeforenufive{ (for \Sapling)} $\DiversifiedTransmitBase = \bot$ or $\DiversifiedTransmitPublic \not\in \SubgroupJstar$ (see note below), return $\bot$
  \item \notbeforenufive{for \Sapling,} let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand)$
        \vspace{-0.2ex}
\nufive{
  \item for \Orchard, let $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$
        where $\NoteNullifierRand = \ToBase{Orchard}\big(\PRFexpand{\NoteSeedBytes}([9] \bconcat \NoteUniqueRandBytes)\kern-0.1em\big)$
        \vspace{-0.2ex}
} %nufive
  \item let $\cmstar' = \NoteCommitment{}\Of{\NoteTuple{}}\,$. \nufive{if (for \Orchard) $\cmstar' = \bot$, return $\bot$}
  \item if $\ItoLEOSP{256}\big(\ExtractG{}(\cmstar')\kern-0.1em\big) \neq \cmstarField$, return $\bot$
        \vspace{-0.5ex}
  \item if $\reprG{}\big(\KADerivePublic{}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big) \neq \ephemeralKey$,
        return $\bot$
  \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 set of \primeOrderAdjective points
        \smash{$\SubgroupJstar$ (i.e.\ ``if ... $\DiversifiedTransmitPublic \not\in \SubgroupJstar$}, return $\bot$'').
        That did not match the implementation in \zcashd. In fact the history is a little more
        complicated. The current specification matches the implementation in \librustzcash as of
        \cite{librustzcash-109}, which has been used in \zcashd since \zcashdref{v2.1.2}. However, there
        was another implementation of \Sapling note decryption used in \zcashd for consensus checks,
        specifically the check that a \shielded coinbase output decrypts successfully with the zero
        $\OutViewingKey$. This was corrected to enforce the same restriction on the decrypted
        $\DiversifiedTransmitPublic$ in \zcashdref{v5.5.0}, originally set to activate in a soft fork
        at \blockHeight 2121200 on both \Mainnet and \Testnet \cite{zcashd-6459}. (On \Testnet this
        height was in the past as of the \textsf{zcashd v5.5.0} release, and so the change would have
        been immediately enforced on upgrade.) Since the soft fork was observed to be retrospectively
        valid after that height, the implementation was simplified in \cite{zcashd-6725} to use the
        \librustzcash implementation in all cases, which reflects the specification above. \zebra always
        used the \librustzcash implementation.
        \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
        $\reprG{}\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$\rlap{.}\nufive{\; For
        consistency this is also what is specified for \Orchard.}\vspace{-0.6ex}
  \item For \Sapling \outgoingCiphertexts, $\DiversifiedTransmitPublicRepr$ could also be \nonCanonicalPoint.
        After \NUFive activation, the above algorithm explicitly returns $\bot$ if
        $\reprP\big(\DiversifiedTransmitPublic\big) \neq \DiversifiedTransmitPublicRepr$. However,
        this is technically redundant with the later check that returns $\bot$ if
        $\DiversifiedTransmitPublic \not\in \smash{\SubgroupJstar}$, because only \smallOrderAdjective \jubjubCurve
        points have \nonCanonicalPoint encodings. This check is enforced retrospectively for consensus
        by current \zcashd and \zebra versions, and for wallet rescanning by current \zcashd.
        Versions of \zcashd prior to \cite{zcashd-6725} could however
        have accepted \notes for which the \outgoingCiphertext contains either a canonical or
        a \nonCanonicalPoint encoding of $\ZeroJ$ for $\DiversifiedTransmitPublic$.
        \vspace{-0.5ex}
  \nufiveonwarditem{For \Orchard \outgoingCiphertexts, it is not possible for
        $\DiversifiedTransmitPublicRepr$ to be \nonCanonicalPoint.}
        \vspace{-0.5ex}
  \nufiveonwarditem{The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ are
        swapped for \Orchard relative to \Sapling. This was due to an oversight and there is no good reason for it.}
  \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.
\end{pnotes}

\vspace{-3ex}
\nnote{Implementors should pay close attention to similarities and differences between this procedure
and \crossref{decryptivk}\notcanopy{.}\canopy{, especially:\!\!
\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.3ex}
  \item in this procedure, $\DiversifiedTransmitPublic$ is obtained from $\OutPlaintext$
        rather than being derived as $\KADerivePublic{Sapling}(\InViewingKey, \DiversifiedTransmitBase)$;
        \vspace{-0.3ex}
  \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$\notnufive{.}\notbeforenufive{;}
  \nufiveonwarditem{\vspace{-0.2ex} for the same reason as in \shortcrossref{decryptivk}, $\EphemeralPublic$ cannot be $\ZeroP$.}
\end{itemize}
} %canopy
} %nnote
} %sapling


\needspace{30ex}
\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}.

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}.

\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.6ex}
  \item let mutable $\ReceivedSet \typecolon \powerset{\NoteType{Sprout} \times \MemoType} \leftarrow \setof{}$
        \vspace{-0.6ex}
  \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{0.4ex}
  \item for each \transaction $\tx$:
        \vspace{-0.3ex}
  \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.6ex}
  \item \tab \tab \tab Attempt to decrypt the \notesCiphertextSprout component
                       $(\EphemeralPublic, \TransmitCiphertext{i})$ using $\InViewingKey$ with the
                       \vspace{-1ex}
  \item \tab \tab \tab algorithm in \crossref{sproutdecrypt}. If this succeeds with $(\NoteTuple{}, \Memo)$:
  \item \tab \tab \tab \tab Add $(\NoteTuple{}, \Memo)$ to $\ReceivedSet$.
        \vspace{-0.3ex}
  \item \tab \tab \tab \tab Calculate the \nullifier $\nf$ of $\NoteTuple{}$ using $\AuthPrivate$
                            as in \crossref{rhoandnullifiers}.\vspace{-0.3ex}
  \item \tab \tab \tab \tab Add the mapping $\nf \rightarrow \NoteTuple{}$ to $\NullifierMap$.
  \item \vspace{-3.5ex}
  \item \tab \tab let $\nf_{\allOld}$ be the \nullifiers of the \joinSplitDescription
        \vspace{-0.3ex}
  \item \tab \tab for $i$ in $\allOld$: if $\nf_i$ is present in $\NullifierMap$, add $\NullifierMap(\nf_i)$ to $\SpentSet$
  \item \blank
  \item return $(\ReceivedSet, \SpentSet)$.
\end{algorithm}


\sapling{
\vspace{-2.5ex}
\extralabel{saplingscan}{\lsubsection{Block Chain Scanning (\SaplingAndOrchardText)}{scan}}

\vspace{-1ex}
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
(\crossref{saplingkeycomponents}\nufive{ or \crossref{orchardkeycomponents}}).

\vspace{0.5ex}
Let $\PRFOutputLengthNfSapling$ be as defined in \crossref{constants}.

\vspace{-0.5ex}
Let $\NoteType{}$ be $\NoteType{Sapling}$\nufive{ or $\NoteType{Orchard}$} as defined in \crossref{notes}.

\vspace{-0.5ex}
Let $\KA{}$ be\notbeforenufive{ either} $\KA{Sapling}$ as defined in \shortcrossref{concretesaplingkeyagreement}\nufive{, or
$\KA{Orchard}$ as defined in \shortcrossref{concreteorchardkeyagreement}}.

\vspace{-0.5ex}
Let $\NullifierType$ be $\PRFOutputNfSapling$\notbeforenufive{ for \Sapling}\nufive{, or $\NullifierTypeOrchard$ for \Orchard}.

\introsection
\vspace{0.5ex}
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}
        \vspace{-0.3ex}
  \item let mutable $\ReceivedSet \typecolon \powerset{\NoteType{} \times \MemoType} \leftarrow \setof{}$
        \vspace{-0.3ex}
  \item let mutable $\SpentSet \typecolon \powerset{\NoteType{}} \leftarrow \setof{}$
        \vspace{-0.3ex}
  \item let mutable $\NullifierMap \typecolon (\NullifierType \rightarrow \NoteType{}) \leftarrow$ the empty mapping
        \vspace{0.4ex}
  \item for each \transaction $\tx$:
        \vspace{-0.3ex}
  \item \tab for each \outputDescription\nufive{ or \actionDescription} in $\tx$:
        \vspace{-0.3ex}
  \item \tab \tab Attempt to decrypt the \noteCiphertextSapling components
                  $\EphemeralPublic$ and $\TransmitCiphertext{}$ using $\InViewingKey$ with the algorithm\vspace{-0.8ex}%
  \item \tab \tab \crossref{decryptivk}.
                  \vspace{-0.6ex}
  \item \tab \tab If this succeeds with $(\NoteTuple{}, \Memo)$:
        \vspace{-0.3ex}
  \item \tab \tab \tab Add $(\NoteTuple{}, \Memo)$ to $\ReceivedSet$.
        \vspace{-0.3ex}
  \item \tab \tab \tab Calculate the \nullifier $\nf$ of $\NoteTuple{}$ using $\NullifierKey$ as in \crossref{rhoandnullifiers}.
                       \vspace{-0.8ex}
  \item \tab \tab \tab (This also requires $\NotePosition$ from the \outputDescription\notbeforenufive{ for \Sapling \notes}.)
        \vspace{-0.3ex}
  \item \tab \tab \tab Add the mapping $\nf \rightarrow \NoteTuple{}$ to $\NullifierMap$.
  \item \blank
  \item \tab for each \nullifier $\nf$ of a \spendDescription\nufive{ or \actionDescription} in $\tx$:
        \vspace{-0.3ex}
  \item \tab \tab if $\nf$ is present in $\NullifierMap$, add $\NullifierMap(\nf)$ to $\SpentSet$
  \item \blank
  \item return $(\ReceivedSet, \SpentSet)$.
\end{algorithm}

\begin{nnotes}
  \item The above algorithm does not use the $\OutViewingKey$ key component, or the $\OutCiphertext$
        \noteCiphertextSapling component. When scanning the whole \blockChain, these are indeed not necessary.
        The advantage of supporting decryption using $\OutViewingKey$ as described in \crossref{decryptovk},
        is that it allows recovering information about the \notePlaintexts sent in a \transaction from that
        \transaction alone.
  \item When scanning only part of a \blockChain, it may be useful to augment the above algorithm with
        decryption of $\OutCiphertext$ components for each \transaction, in order to obtain information
        about \notes that were spent in the scanned period but received outside it.
  \item The above algorithm does not detect \notes that were sent ``\outOfBand'' or with incorrect
        \noteCiphertextsSapling. It is possible to detect whether such \notes were spent only if their \nullifiers
        are known.
\end{nnotes}
} %sapling


\intropart
\vspace{-2ex}
\lsection{Concrete Protocol}{concreteprotocol}

\lsubsection{Integers, Bit Sequences, and Endianness}{endian}

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}.

\introlist
The following functions convert between sequences of bits, sequences of bytes,
and integers:

\begin{itemize}
  \item $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$,
        such that $\ItoLEBSPOf{\ell}{x}$ is the sequence of $\ell$ bits representing $x$ in
        little-endian order;
  \item $\ItoLEOSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$,
        such that $\ItoLEBSPOf{\ell}{x}$ is the sequence of $\ceiling{\ell/8}$ bytes representing $x$ in
        little-endian order;
  \item $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$
        such that $\ItoBEBSPOf{\ell}{x}$ is the sequence of $\ell$ bits representing $x$ in
        big-endian order.
  \item $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \binaryrange{\ell}$
        such that $\LEBStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the
        \bitSequence $S$ of length $\ell$.
  \item $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$
        such that $\LEOStoIPOf{\ell}{S}$ is the integer represented in little-endian order by the
        \byteSequence $S$ of length $\ell/8$.
\notbeforenufive{
  \item $\BEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$
        such that $\BEOStoIPOf{\ell}{S}$ is the integer represented in big-endian order by the
        \byteSequence $S$ of length $\ell/8$.
} %notbeforenufive
  \item $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$
        defined as follows: pad the input on the right with $8 \mult \ceiling{\ell/8} - \ell$ zero bits
        so that its length is a multiple of 8 bits. Then convert each group of 8 bits to a byte
        value with the \emph{least} significant bit first, and concatenate the resulting bytes
        in the same order as the groups.
  \item $\LEOStoBSP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\sceiling{\ell/8}} \rightarrow \bitseq{\ell}$
        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}


\vspace{-2ex}
\extralabel{boxnotation}{\lsubsection{Bit layout diagrams}{bitlayout}}

We sometimes use bit layout diagrams, in which 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, or for the output of $\LEBStoOSP{\ell}$).

The entire diagram represents the sequence of \emph{bytes} formed by first
concatenating these \bitSequences, 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,
\bitSequence/\byteSequence conversions are always specified explicitly.)} Where bit fields
are used, the text will clarify their position in each case.


\introsection
\lsubsection{Constants}{constants}

Define:

\begin{formulae}[itemsep=0.2ex]
  \item $\MerkleDepth{Sprout} \typecolon \Nat := 29$
\sapling{
  \item $\MerkleDepth{Sapling} \typecolon \Nat := 32$
} %sapling
\nufive{
  \item $\MerkleDepth{Orchard} \typecolon \Nat := 32$
} %nufive
  \item $\MerkleHashLength{Sprout} \typecolon \Nat := 256$
\sapling{
  \item $\MerkleHashLength{Sapling} \typecolon \Nat := 255$
} %sapling
\nufive{
  \item $\MerkleHashLength{Orchard} \typecolon \Nat := 255$
} %nufive
  \item $\NOld \typecolon \Nat := 2$
  \item $\NNew \typecolon \Nat := 2$
  \item $\ValueLength \typecolon \Nat := 64$
  \item $\hSigLength \typecolon \Nat := 256$
  \item $\PRFOutputLengthSprout \typecolon \Nat := 256$
\sapling{
  \item $\PRFOutputLengthExpand \typecolon \Nat := 512$
  \item $\PRFOutputLengthNfSapling \typecolon \Nat := 256$
} %sapling
  \item $\NoteCommitRandLengthSprout \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$
\nufive{
  \item $\DiversifierKeyLength \typecolon \Nat := 256$
} %nufive
  \item $\InViewingKeyLength{Sapling} \typecolon \Nat := 251$
  \item $\OutViewingKeyLength \typecolon \Nat := 256$
  \item $\ScalarLength{Sapling} \typecolon \Nat := 252$
} %sapling
\nufive{
  \item $\ScalarLength{Orchard} \typecolon \Nat := 255$
  \item $\BaseLength{Orchard} \typecolon \Nat := 255$
} %nufive
  \item $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}} := \zeros{\MerkleHashLength{Sprout}}$
\sapling{
        \vspace{-0.25ex}
  \item $\Uncommitted{Sapling} \typecolon \bitseq{\MerkleHashLength{Sapling}} := \ItoLEBSPOf{\MerkleHashLength{Sapling}}{1}$
} %sapling
\nufive{
        \vspace{-1ex}
  \item $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard := 2$
} %nufive
        \vspace{0.25ex}
  \item $\MAXMONEY \typecolon \Nat := 2.1 \smult 10^{15}$ (\zatoshi)
\blossom{
  \item $\BlossomActivationHeight \typecolon \Nat := \begin{cases}
          653600,&\squash\text{for \Mainnet} \\
          584000,&\squash\text{for \Testnet}
        \end{cases}$
} %blossom
\canopy{
  \item $\CanopyActivationHeight \typecolon \Nat := \begin{cases}
          1046400,&\squash\text{for \Mainnet} \\
          1028500,&\squash\text{for \Testnet}
        \end{cases}$
  \item $\ZIPTwoOneTwoGracePeriod \typecolon \Nat := 32256$
} %canopy
\nufive{
  \item $\NUFiveActivationHeight \typecolon \Nat := \begin{cases}
          1687104,&\squash\text{for \Mainnet} \\
          1842420,&\squash\text{for \Testnet}
        \end{cases}$
} %nufive
  \item $\SlowStartInterval \typecolon \Nat := 20000$
  \item $\PreBlossomHalvingInterval \typecolon \Nat := 840000$
  \item $\MaxBlockSubsidy \typecolon \Nat := 1.25 \smult 10^9$ (\zatoshi)
  \item $\NumFounderAddresses \typecolon \Nat := 48$
  \item $\FoundersFraction \typecolon \Rat := \frac{1}{5}$
  \item $\PoWLimit \typecolon \Nat := \begin{cases}
          2^{243} - 1,&\squash\text{for \Mainnet} \\
          2^{251} - 1,&\squash\text{for \Testnet}
        \end{cases}$
  \item $\PoWAveragingWindow \typecolon \Nat := 17$
  \item $\PoWMedianBlockSpan \typecolon \Nat := 11$
  \item $\PoWMaxAdjustDown \typecolon \Rat := \frac{32}{100}$
  \item $\PoWMaxAdjustUp \typecolon \Rat := \frac{16}{100}$
  \item $\PoWDampingFactor \typecolon \Nat := 4$
  \item $\PreBlossomPoWTargetSpacing \typecolon \Nat := 150$ (seconds).
\blossom{
  \item $\PostBlossomPoWTargetSpacing \typecolon \Nat := 75$ (seconds).
} %blossom
\end{formulae}


\introsection
\lsubsection{Concrete Cryptographic Schemes}{concreteschemes}

\lsubsubsection{Hash Functions}{concretehashes}

\extralabel{concretesha256}{\lsubsubsubsection{\shaHashText{}, \shadHashText{}, \shaCompressText{}, and \bigShaHashText{} Hash Functions}{concretesha}}

\vspace{-1ex}
SHA-256 and SHA-512 are defined by \cite{NIST2015}.

\Zcash uses the full \defining{\shaHash} \hashFunction to instantiate $\NoteCommitment{Sprout}$.

\begin{formulae}
  \item $\SHAFull \typecolon \byteseqs \rightarrow \byteseq{32}$
\end{formulae}

\cite{NIST2015} strictly speaking only specifies the application of SHA-256 to
messages that are \bitSequences, producing outputs (``message digests'') that
are also \bitSequences. In practice, SHA-256 is universally implemented with a
byte-sequence interface for messages and outputs, such that the
\emph{most significant} bit of each byte corresponds to the first bit of the
associated \bitSequence. (In the NIST specification ``first'' is conflated with
``leftmost''.)

\introlist
\defining{\shadHash}, defined as a double application of \shaHash, is used to hash \blockHeaders:

\begin{formulae}
  \item $\SHAFulld \typecolon \byteseqs \rightarrow \byteseq{32}$
\end{formulae}

\Zcash also uses the SHA-256 compression function, \defining{\shaCompress}. This operates
on a single $512$-bit block and \emph{excludes} the padding step specified
in \cite[section 5.1]{NIST2015}.

That is, the input to $\SHACompress$ is what
\cite[section 5.2]{NIST2015} refers to as ``the message and its padding''.
The Initial Hash Value is the same as for full \shaHash.

\introlist
\shaCompress is used to instantiate several \pseudoRandomFunctions and
$\MerkleCRH{Sprout}$.

\begin{formulae}
  \item $\SHACompress \typecolon \bitseq{512} \rightarrow \bitseq{256}$
\end{formulae}

\vspace{-1.5ex}
The ordering of bits within words in the interface to $\SHACompress$ is
consistent with \cite[section 3.1]{NIST2015}, i.e.\ big-endian.

\vspace{1ex}
\EdSpecific uses \defining{\bigShaHash}:

\begin{formulae}
  \item $\BigSHAFull \typecolon \byteseqs \rightarrow \byteseq{64}$
\end{formulae}

\vspace{-2ex}
The comment above concerning bit vs byte-sequence interfaces also applies to \bigShaHash.


\vspace{-1ex}
\lsubsubsubsection{BLAKE2 Hash Functions}{concreteblake2}

\vspace{-1ex}
BLAKE2 is defined by \cite{ANWW2013}.
\sapling{\Zcash uses both the $\BlakeTwobGeneric$ and $\BlakeTwosGeneric$
variants.}

$\BlakeTwobOf{\ell}{p, x}$ refers to unkeyed $\BlakeTwob{\ell}$
in sequential mode, with an output digest length of $\ell/8$ bytes,
$16$-byte personalization string $p$, and input $x$.

\introlist
$\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}\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}$.}

\begin{formulae}
  \item $\BlakeTwob{\ell} \typecolon \byteseq{16} \times \byteseqs \rightarrow \byteseq{\ell/8}$
\end{formulae}

\vspace{-1.5ex}
\pnote{
$\BlakeTwob{\ell}$ is not the same as $\BlakeTwob{512}$ truncated to
$\ell$ bits, because the digest length is encoded in the parameter
block.
}

\sapling{
\vspace{1ex}
$\BlakeTwosOf{\ell}{p, x}$ refers to unkeyed $\BlakeTwos{\ell}$
in sequential mode, with an output digest length of $\ell/8$ bytes,
$8$-byte personalization string $p$, and input $x$.

$\BlakeTwosGeneric$ is used to instantiate $\PRFnf{Sapling}{}$, $\CRHivk$,
and $\GroupJHash{}$.

\begin{formulae}
  \item $\BlakeTwos{\ell} \typecolon \byteseq{8} \times \byteseqs \rightarrow \byteseq{\ell/8}$
\end{formulae}
} %sapling


\vspace{-2.5ex}
\introsection
\lsubsubsubsection{Merkle Tree Hash Function}{merklecrh}

\newsavebox{\merklebox}
\begin{lrbox}{\merklebox}
\begin{bytefield}[bitwidth=0.04em]{512}
    \sbitbox{256}{$256$-bit $\leftRepr$} &
    \sbitbox{256}{$256$-bit $\rightRepr$}
\end{bytefield}
\end{lrbox}

\vspace{-2ex}
$\MerkleCRH{Sprout}$\sapling{ and $\MerkleCRH{Sapling}$}\nufive{ and $\MerkleCRH{Orchard}$} are used
to hash \incrementalMerkleTree \merkleHashes for \Sprout\sapling{ and \Sapling}\nufive{ and \Orchard}
respectively.

\vspace{-2ex}
\lsubsubsubsubsection{$\MerkleCRH{Sprout}$ Hash Function}{sproutmerklecrh}

\vspace{-2ex}
$\MerkleCRH{Sprout} \typecolon \MerkleLayer{Sprout} \times \MerkleHash{Sprout} \times \MerkleHash{Sprout}
\rightarrow \MerkleHash{Sprout}$ is defined as follows:

\begin{formulae}
  \item $\MerkleCRH{Sprout}(\layerInput, \leftRepr, \rightRepr) := \SHACompressBox{\merklebox}$.
\end{formulae}

\vspace{-1ex}
$\SHACompress$ is defined in \crossref{concretesha256}.

\vspace{-2ex}
\securityrequirement{
\shaCompress must be \collisionResistant, and it must be infeasible to find a preimage $x$
such that $\SHACompress(x) = \zeros{256}$.
}

\vspace{-0.5ex}
\begin{pnotes}
  \item The $\layerInput$ argument does not affect the output.
  \item \shaCompress is not the same as the \shaHash function, which hashes arbitrary-length
        \byteSequences.
\end{pnotes}

\sapling{
\vspace{-2ex}
\lsubsubsubsubsection{$\MerkleCRH{Sapling}$ Hash Function}{saplingmerklecrh}

\vspace{-1ex}
Let $\PedersenHash$ be as specified in \crossref{concretepedersenhash}.

$\MerkleCRH{Sapling} \typecolon \MerkleLayer{Sapling} \times \MerkleHash{Sapling} \times \MerkleHash{Sapling}
\rightarrow \MerkleHash{Sapling}$ is defined as follows:

\begin{formulae}
  \item $\MerkleCRH{Sapling}(\layerInput, \leftRepr, \rightRepr) :=
           \PedersenHash(\ascii{Zcash\_PH},\, \layerRepr \bconcat \leftRepr \bconcat \rightRepr)$
  \item where $\layerRepr = \ItoLEBSP{6}\big(\MerkleDepth{Sapling} - 1 - \layerInput\big)$.
\end{formulae}

\vspace{-2.5ex}
\securityrequirement{$\PedersenHash$ must be \collisionResistant\!.}

\introlist
\pnote{The prefix $\layerRepr$ provides domain separation between inputs at different layers of the
\noteCommitmentTree. $\NoteCommitAlg{Sapling}$, like $\PedersenHash$, is defined in terms of $\PedersenHashToPoint$,
but using a prefix that cannot collide with a layer prefix, as noted in \crossref{concretewindowedcommit}.}
} %sapling


\nufive{
\vspace{-2ex}
\lsubsubsubsubsection{$\MerkleCRH{Orchard}$ Hash Function}{orchardmerklecrh}

\vspace{-2ex}
Let $\SinsemillaHash$ be as specified in \crossref{concretesinsemillahash}.

$\MerkleCRH{Orchard} \typecolon \MerkleLayer{Orchard} \times \MerkleHashOrchard \times \MerkleHashOrchard
\rightarrow \MerkleHashOrchard$ is defined as follows:

\begin{formulae}
  \item $\MerkleCRH{Orchard}(\layerInput, \leftInput, \rightInput) := \begin{cases}
           0,     &\caseif \hash = \bot \\
           \hash, &\caseotherwise
        \end{cases}$
  \item \begin{tabular}{@{}l@{\;}r@{\;}l}
          where &$\hash$      &$= \SinsemillaHash(\ascii{z.cash:Orchard-MerkleCRH},\, \layerRepr \bconcat \leftRepr \bconcat \rightRepr)$ \\
                &$\layerRepr$ &$= \ItoLEBSP{10}\big(\MerkleDepth{Orchard} - 1 - \layerInput\big)$ \\
                &$\leftRepr$  &$= \ItoLEBSP{\MerkleHashLength{Orchard}}\big(\leftInput\big)$ \\
                &$\rightRepr$ &$= \ItoLEBSP{\MerkleHashLength{Orchard}}\big(\rightInput\big)$.
        \end{tabular}
\end{formulae}

\begin{securityrequirements}
  \item $\SinsemillaHash$ must be \collisionResistant.
  \item It must be infeasible to find a input of length $10 + 2 \mult \MerkleHashLength{Orchard}$
        bits to $\SinsemillaHash$ that yields output $\bot$.
\end{securityrequirements}

\pnote{The prefix $\layerRepr$ provides domain separation between inputs at different layers of the
\noteCommitmentTree.}
} %nufive


\lsubsubsubsection{\hSigText{} Hash Function}{hsigcrh}

\newsavebox{\hsigbox}
\begin{lrbox}{\hsigbox}
\begin{bytefield}[bitwidth=0.04em]{1024}
    \sbitbox{256}{$256$-bit $\RandomSeed$} &
    \sbitbox{256}{\hfill $256$-bit $\nfOld{\mathrm{1}}$\hfill...\;} &
    \sbitbox{256}{$256$-bit $\nfOld{\NOld}$} &
    \sbitbox{300}{$256$-bit $\joinSplitPubKey$}
\end{bytefield}
\end{lrbox}

\vspace{-2ex}
$\hSigCRH$ is used to compute the value $\hSig$ in \crossref{joinsplitdesc}.

\begin{formulae}
  \item $\hSigCRH(\RandomSeed, \nfOld{\allOld}, \joinSplitPubKey) := \BlakeTwobOf{256}{\ascii{ZcashComputehSig},\; \hSigInput}$
\end{formulae}

\vspace{-2ex}
where
\begin{formulae}
  \item $\hSigInput := \Justthebox{\hsigbox}$.
\end{formulae}

\vspace{-1ex}
$\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}.

\securityrequirement{
$\BlakeTwobOf{256}{\ascii{ZcashComputehSig}, x}$ must be \collisionResistant on $x$.
}


\newsavebox{\crhivkbox}
\begin{lrbox}{\crhivkbox}
\setsapling
\begin{bytefield}[bitwidth=0.05em]{512}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\AuthSignPublicRepr}$} &
    \sbitbox{256}{$\LEBStoOSPOf{256}{\NullifierKeyRepr}$}
\end{bytefield}
\end{lrbox}

\sapling{
\introlist
\lsubsubsubsection{\CRHivkText{} Hash Function}{concretecrhivk}

\vspace{-2ex}
$\CRHivk$ is used to derive the \incomingViewingKey $\InViewingKey$
for a \Sapling \shieldedPaymentAddress.
For its use when generating an address see \crossref{saplingkeycomponents},
and for its use in the \spendStatement see \crossref{spendstatement}.

\introlist
It is defined as follows:

\begin{formulae}
  \item $\CRHivk(\AuthSignPublicRepr, \NullifierKeyRepr) :=
           \LEOStoIPOf{256}{\BlakeTwosOf{256}{\ascii{Zcashivk},\; \crhInput}} \bmod 2^{\InViewingKeyLength{Sapling}}$
\end{formulae}

\vspace{-2ex}
where
\begin{formulae}
  \item $\crhInput := \Justthebox{\crhivkbox}$
\end{formulae}

\vspace{1ex}
$\BlakeTwosOf{256}{p, x}$ is defined in \crossref{concreteblake2}.

\vspace{-1ex}
\securityrequirement{
$\LEOStoIPOf{256}{\BlakeTwosOf{256}{\ascii{Zcashivk}, x}} \bmod 2^{\InViewingKeyLength{Sapling}}$
must be \collisionResistant on a $64$-byte input $x$. Note that this
does not follow from \collisionResistance of $\BlakeTwos{256}$
(and the best possible concrete security is that of a $251$-bit hash
rather than a $256$-bit hash), but it is a reasonable assumption
given the design, structure, and cryptanalysis to date of $\BlakeTwosGeneric$.
}

\vspace{-1ex}
\nnote{
$\BlakeTwosGeneric$ has a variable output digest length feature, but it
does not support arbitrary bit lengths, otherwise it would have been
used rather than external truncation. However, the protocol-specific
personalization string together with truncation achieve essentially
the same effect as using that feature.
} %nnote
} %sapling


\sapling{
\introlist
\lsubsubsubsection{\DiversifyHashText{Sapling}\notbeforenufive{ and \DiversifyHashText{Orchard}} Hash Function\notbeforenufive{s}}{concretediversifyhash}

$\DiversifyHash{Sapling} \typecolon \DiversifierType \rightarrow \maybe{\SubgroupJstar}$
is used to derive a \diversifiedBase in \crossref{saplingkeycomponents}.

Let $\GroupJHash{}$ and $U$ be as defined in \crossref{concretegrouphashjubjub}.

\introlist
Define

\vspace{-1ex}
\begin{formulae}
  \item $\DiversifyHash{Sapling}(\Diversifier) :=
           \GroupJHash{\NotUpMySleeve}\Of{\ascii{Zcash\_gd}, \LEBStoOSPOf{\DiversifierLength}{\Diversifier}\kern-0.1em}$.
\end{formulae}

\nufive{
$\DiversifyHash{Orchard} \typecolon \DiversifierType \rightarrow \GroupPstar$
is used to derive a \diversifiedBase in \crossref{orchardkeycomponents}.

Let $\GroupPHash{}$ be as defined in \crossref{concretegrouphashpallasandvesta}.

\introlist
Define

\vspace{-1ex}
\begin{formulae}
  \item $\DiversifyHash{Orchard}(\Diversifier) := \begin{cases}
                                                    \GroupPHash(\ascii{z.cash:Orchard-gd}, \ascii{}),
                                                       &\caseif P = \ZeroP \\
                                                    P, &\caseotherwise
                                                  \end{cases}$
\end{formulae}
\vspace{-2ex}
where $P = \GroupPHash\Of{\ascii{z.cash:Orchard-gd}, \LEBStoOSPOf{\DiversifierLength}{\Diversifier}\kern-0.1em}$.

\vspace{1ex}
The following security property and notes apply to both \Sapling and \Orchard.
} %nufive

\vspace{-2ex}
\securityrequirement{
\textbf{Unlinkability:} Given two randomly selected
\shieldedPaymentAddresses from different spend authorities, and a third \shieldedPaymentAddress
which could be derived from either of those authorities, such that the three
addresses use different \diversifiers, it is not possible to tell which authority
the third address was derived from.
} %securityrequirement

\begin{nnotes}
  \item Suppose that $\GroupJHash{}$ (restricted to inputs for which it does not
        return $\bot$) is modelled as a \randomOracle from \diversifiers to points
        of order $\ParamJ{r}$ on the \jubjubCurve. In this model, Unlinkability
        of $\DiversifyHash{Sapling}$ holds under the \xDecisionalDiffieHellman assumption on the
        \primeOrderSubgroup of points on the \jubjubCurve.

        To prove this, consider the ElGamal encryption scheme \cite{ElGamal1985}
        on this \primeOrderSubgroup, restricted to encrypting plaintexts encoded
        as the group identity $\ZeroJ$. (ElGamal was originally defined for $\GFstar{p}$
        but works in any \primeOrderGroup.) ElGamal \publicKeys then have the same form
        as \diversifiedPaymentAddresses. If we make the assumption above on $\GroupJHash{}$,
        then generating a new \diversifiedPaymentAddress from a given address $\pk$,
        gives the same distribution of
        $(\DiversifiedTransmitBase', \DiversifiedTransmitPublic')$ pairs as the
        distribution of ElGamal ciphertexts obtained by encrypting $\ZeroJ$ under $\pk$.
        \todo{check whether this is justified.}
        Then, the definition of \keyPrivacy (\nh{IK-CPA} as defined in \cite[Definition 1]{BBDP2001})
        for ElGamal corresponds to the definition of Unlinkability for $\DiversifyHash{Sapling}$.
        (\nh{IK-CCA} corresponds to the potentially stronger requirement that $\DiversifyHash{Sapling}$
        remains Unlinkable when given Diffie--Hellman key agreement oracles for each
        of the candidate \diversifiedPaymentAddresses.)
        So if ElGamal is \keyPrivate, then $\DiversifyHash{Sapling}$ is Unlinkable under the
        same conditions.
        \cite[Appendix A]{BBDP2001} gives a security proof for \keyPrivacy
        (both \nh{IK-CPA} and \nh{IK-CCA}) of ElGamal under the \xDecisionalDiffieHellman
        assumption on the relevant group. (In fact the proof needed is the
        ``small modification'' described in the last paragraph in which the generator
        is chosen at random for each key.)

  \item It is assumed (also for the security of other uses of
        the group hash, such as Pedersen hashes and commitments) that the discrete
        logarithm of the output group element with respect to any other generator
        is unknown. This assumption is justified if the group hash acts as a
        \randomOracle.
        Essentially, \diversifiers act as handles to unknown random numbers.
        (The group hash inputs used with different personalizations are in different
        ``namespaces''.)

  \item Informally, the random self-reducibility property of DDH implies that an
        adversary would gain no advantage from being able to query an oracle for
        additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs with
        the same \spendingAuthority as an existing \shieldedPaymentAddress, since they
        could also create such pairs on their own. This justifies only considering
        two \shieldedPaymentAddresses in the security definition.

        \todo{FIXME This is not correct, because additional pairs don't quite
        follow the same distribution as an address with a valid diversifier.
        The security definition may need to be more complex to model this properly.}

  \item An $88$-bit diversifier cannot be considered cryptographically unguessable
        at a $128$-bit security level; also, randomly chosen diversifiers are likely
        to suffer birthday collisions when the number of choices approaches $2^{44}$.

        If most users are choosing diversifiers randomly (as recommended in
        \crossref{saplingkeycomponents}), then the fact that they
        may accidentally choose diversifiers that collide (and therefore reveal
        the fact that they are not derived from the same \incomingViewingKey)
        does not appreciably reduce the anonymity set.

        In \cite{ZIP-32}\nufive{ and \crossref{orchardkeycomponents}} an $88$-bit
        \defining{\pseudoRandomPermutation}, keyed differently for each node of the
        derivation tree, is used to select new \diversifiers. This resolves the
        potential problem, provided that the input to the \pseudoRandomPermutation
        does not repeat for a given node.

  \item If the holder of an \incomingViewingKey permits an adversary to ask for a new
        address for that \incomingViewingKey with a given \diversifier, then it can
        trivially break Unlinkability for the other \diversifiedPaymentAddresses
        associated with the \incomingViewingKey (this does not compromise other
        privacy properties). Implementations \SHOULD avoid providing such a
        ``chosen \diversifier'' oracle.
\end{nnotes}
} %sapling


\sapling{
\introlist
\lsubsubsubsection{Pedersen Hash Function}{concretepedersenhash}

$\PedersenHash$ is an algebraic \hashFunction with \collisionResistance
(for fixed input length) derived from assumed hardness of the
\xDiscreteLogarithmProblem on the \jubjubCurve.
It is based on the work of David Chaum, Ivan Damgård, Jeroen van de Graaf,
Jurgen Bos, George Purdy, Eugène van Heijst and Birgit Pfitzmann in
\cite{CDvdG1987}, \cite{BCP1988} and \cite{CvHP1991},
and of Mihir Bellare, Oded Goldreich, and Shafi Goldwasser in \cite{BGG1995},
with optimizations for efficient instantiation in \zkSNARKCircuits
by Sean Bowe and \nh{Daira-Emma} Hopwood.

$\PedersenHash$ is used in the definitions of \xPedersenCommitments
(\crossref{concretewindowedcommit}), and of the \defining{\xPedersenHash} for the
\Sapling \incrementalMerkleTree (\crossref{saplingmerklecrh}).

Let $\GroupJ$, $\SubgroupJ$, $\ZeroJ$, $\ParamJ{q}$, $\ParamJ{r}$, $\ParamJ{a}$, and $\ParamJ{d}$ be as defined in \crossref{jubjub}.

Let $\ExtractJ \typecolon \SubgroupJ \rightarrow \MerkleHash{Sapling}$ be as defined in \crossref{concreteextractorjubjub}.

\vspace{-1ex}
Let $\FindGroupJHash$ be as defined in \crossref{concretegrouphashjubjub}.

Let $\Uncommitted{Sapling}$ be as defined in \crossref{constants}.

Let $c$ be the largest integer such that $4 \mult \hfrac{2^{4 \mult c}-1}{15} \leq \hfrac{\ParamJ{r}-1}{2}$,
i.e.\ $c := 63$.

\newsavebox{\gencountbox}
\begin{lrbox}{\gencountbox}
\begin{bytefield}[bitwidth=0.28em]{32}
    \sbitbox{32}{$32$-bit $i-1$}
\end{bytefield}
\end{lrbox}

\introlist
\vspace{2ex}
Define $\PedersenGen \typecolon \byteseq{8} \times \Nat \rightarrow \SubgroupJstar$ by:

\begin{formulae}
  \item $\PedersenGen(D, i) := \FindGroupJHash\Of{D, \Justthebox{\gencountbox}}$.
\end{formulae}

\newcommand{\sj}[1]{s^{\kern 0.02em j}_{#1}}

\introsection
Define $\PedersenHashToPoint(D \typecolon \byteseq{8}, M \typecolon \bitseq{\PosInt}) \rightarrow \SubgroupJ$ as follows:

\begin{algorithm}
  \item Pad $M$ to a multiple of $3$ bits by appending zero bits, giving $M'$.
  \item Let $n = \ceiling{\hfrac{\length(M')}{3 \mult c}}$.
  \item Split $M'$ into $n$ \defining{\segments} $M_\barerange{1}{n}$
        so that $M' = \concatbits(M_\barerange{1}{n})$, and
        each of $M_\barerange{1}{n-1}$ is of length $3 \smult c$ bits.
        ($M_n$ may be shorter.)
  \item Return $\ssum{i=1}{n} \scalarmult{\PedersenEncode{M_i}}{\PedersenGen(D, i)} \typecolon \SubgroupJ$.
\end{algorithm}

\vspace{-1ex}
where
$\PedersenEncode{\paramdot} \typecolon \bitseq{3 \mult \range{1}{c}} \rightarrow
   \bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$ is defined as:

\begin{algorithm}
  \item Let $k_i = \length(M_i)/3$.
  \item Split $M_i$ into $3$-bit \defining{\chunks} $m_\barerange{1}{k_i}$
        so that $M_i = \concatbits(m_\barerange{1}{k_i})$.
  \item Write each $m_j$ as $[\sj{0}, \sj{1}, \sj{2}]$, and let
        $\enc(m_j) = (1 - 2 \smult \sj{2}) \mult (1 + \sj{0} + 2 \smult \sj{1}) \typecolon \Int$.
  \item Let $\PedersenEncode{M_i} = \ssum{j=1}{k_i} \enc(m_j) \mult 2^{4 \mult (j-1)}$.
\end{algorithm}

\introlist
\vspace{-1ex}
Finally, define $\PedersenHash \typecolon \byteseq{8} \times \bitseq{\PosInt} \rightarrow \MerkleHash{Sapling}$ by:

\begin{formulae}
  \item $\PedersenHash(D, M) := \ExtractJ\big(\PedersenHashToPoint\Of{D, M}\kern-0.1em\big)$.
\end{formulae}

See \crossref{cctpedersenhash} for rationale and efficient circuit implementation
of these functions.

\securityrequirement{
$\PedersenHash$ and $\PedersenHashToPoint$ 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.
}

\vspace{-1ex}
\nnote{
These \hashFunctions are \emph{not} \collisionResistant for variable-length inputs.
}

\introlist
\theoremlabel{thmpedersenencodeinjective}
\begin{theorem}[The encoding function $\PedersenEncode{\paramdot}$ is injective]\end{theorem}

\begin{proof}
We first check that the range of
$\vsum{j=1}{k_i} \enc(m_j) \mult 2^{4 \mult (j-1)}$ is a subset of
the allowable range $\bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$.
The range of this expression is a subset of
$\rangenozero{-\PedersenRangeOffset}{\PedersenRangeOffset}$ where
$\PedersenRangeOffset = 4 \mult \vsum{i=1}{c} 2^{4 \mult (i-1)} = 4 \mult \hfrac{2^{4 \mult c} - 1}{15}$.

\introlist
When $c = 63$, we have

\begin{tabular}{@{\hskip 2em}r@{\;}l}
  $4 \mult \hfrac{2^{4 \mult c} - 1}{15}$ &$= \hexint{444444444444444444444444444444444444444444444444444444444444444}$ \\
                                          & \\[-2ex]
  $\hfrac{\ParamJ{r}-1}{2}$               &$= \hexint{73EDA753299D7D483339D80809A1D8053341049E6640841684B872F6B7B965B}$
\end{tabular}

so the required condition is met. This implies that there is no ``wrap around''
and so $\ssum{j=1}{k_i} \enc(m_j) \mult 2^{4 \mult (j-1)}$ may be treated as an
integer expression.

$\enc$ is injective. In order to prove that $\PedersenEncode{\paramdot}$ is injective,
consider $\PedersenEncodeNonneg{\paramdot} \typecolon \bitseq{3 \mult \range{1}{c}} \rightarrow
\range{0}{2 \smult \PedersenRangeOffset}$ such that
$\PedersenEncodeNonneg{M_i} = \PedersenEncode{M_i} + \PedersenRangeOffset$.
With $k_i$ and $m_j$ defined as above, we have
$\PedersenEncodeNonneg{M_i} = \ssum{j=1}{k_i} \enc'(m_j) \mult 2^{4 \mult (j-1)}$
where $\enc'(m_j) = \enc(m_j) + 4$ is in $\range{0}{8}$ and $\enc'$ is injective.
Express this sum in hexadecimal; then each $m_j$ affects only one hex digit, and
it is easy to see that $\PedersenEncodeNonneg{\paramdot}$ is injective.
Therefore so is $\PedersenEncode{\paramdot}$.
\end{proof}

Since the security proof from \cite[Appendix A]{BGG1995}
depends only on the encoding being injective and its range not including
zero, the proof can be adapted straightforwardly to show that $\PedersenHashToPoint$
is \collisionResistant under the same assumptions and security bounds.
Because $\ExtractJ$ is injective, it follows that $\PedersenHash$ is equally
\collisionResistant\!.
} %sapling


\sapling{
\lsubsubsubsection{Mixing Pedersen Hash Function}{concretemixinghash}

\vspace{-1ex}
A mixing \xPedersenHash is used to compute $\NoteUniqueRand$ from
$\cm$ and $\NotePosition$ in \crossref{rhoandnullifiers}. It takes as
input a \xPedersenCommitment $P$, and hashes it with another input $x$.

Define $\NotePositionBaseSapling := \FindGroupJHash\Of{\ascii{Zcash\_J\_}, \ascii{}}$.

\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{-3ex}
\securityrequirement{
The function
\begin{formulae}
  \item $\fun{(r, M, x) \typecolon \range{0}{\ParamJ{r}-1} \times \bitseq{\PosInt} \times
           \range{0}{\ParamJ{r}-1}}{\MixingPedersenHash(\WindowedPedersenCommit{r}(M), x) \typecolon \GroupJ}$
\end{formulae}
\vspace{-1ex}
must be \collisionResistant on $(r, M, x)$.
}

\vspace{2ex}
See \crossref{cctmixinghash} for efficient circuit implementation of this function.
} %sapling


\nufive{
\introlist
\vspace{-1ex}
\lsubsubsubsection{Sinsemilla Hash Function}{concretesinsemillahash}

\vspace{-2ex}
\defining{$\SinsemillaHash$} is an algebraic \hashFunction with
\collisionResistance (for fixed input length) derived from assumed hardness
of the \xDiscreteLogarithmProblem. It is designed by Sean Bowe and \nh{Daira-Emma} Hopwood.
The motivation for introducing a new discrete-logarithm-based hash function (rather than
using $\PedersenHash$) is to make efficient use of the lookups available in recent
proof systems including \HaloTwo.

$\SinsemillaHash$ is used in the definition of $\SinsemillaCommitAlg$
(\crossref{concretesinsemillacommit}), and for the \Orchard \incrementalMerkleTree
(\crossref{orchardmerklecrh}).

Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, $\ParamP{r}$, and $\ParamP{b}$ be as defined in
\crossref{pallasandvesta}.

\vspace{-0.25ex}
Let $\ExtractPbot \typecolon \maybe{\GroupP} \rightarrow \maybe{\MerkleHashOrchard}$ 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{0.5ex}
Let $k := 10$.

\vspace{-0.25ex}
Let $c$ be the largest integer such that $2^c \leq \hfrac{\ParamP{r}-1}{2}$,
i.e.\ $c := 253$.

\introlist
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)$ \\[-0.25ex]
  $\SinsemillaGenBase(j)$ &$:= \GroupPHash\!\big(\ascii{z.cash:SinsemillaS}, \ItoLEOSP{32}(j)\kern-0.1em\big)$.
\end{tabular}

\vspace{1ex}
\introlist
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]
  $(x, y)$ &$\incompleteadd$ &$(x', y')$ &$= \begin{cases}
                                               \bot,              &\caseif x = x' \\
                                               (x, y) + (x', y'), &\caseotherwise\text{.}
                                             \end{cases}$
\end{tabular}

\introlist
\vspace{1ex}
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 $n \mult k$ bits by appending zero bits, giving $\Mpadded$.
        \vspace{-0.25ex}
  \item split $\Mpadded$ into $n$ \defining{\pieces} $\Mpieces_{\barerange{1}{n}}$,
        each of length $k$ bits, so that $\Mpadded = \concatbits(\Mpieces_{\barerange{1}{n}})$.
  \item return $\listcomp{\LEBStoIP{k}(\Mpieces_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(m_i)\kern-0.1em\big) \incompleteadd \Acc$
  \item \blank
  \item return $\Acc$.
\end{algorithm}

\introlist
\vspace{-1ex}
Finally, define $\SinsemillaHash \typecolon \byteseqs \times \bitseq{\range{0}{k \mult c}} \rightarrow \maybe{\MerkleHashOrchard}$ by:

\begin{formulae}
  \item $\SinsemillaHash(D, M) := \ExtractPbot\big(\SinsemillaHashToPoint\Of{D, M}\kern-0.1em\big)$.
\end{formulae}

\vspace{-1ex}
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$. 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

\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}

\vspace{-3.5ex}
\lsubsubsubsubsection{Security argument}{sinsemillasecurity}

\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 \xDiscreteLogarithmProblem in $\mathbb{P}$.

\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 $\chi(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 \chi(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 $\chi(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') \neq \bot$ efficiently yields a nontrivial
discrete logarithm relation, and similarly for $\SinsemillaHash(D, M) = \SinsemillaHash(D, M') \neq \bot$.
\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 whenever $\SinsemillaHashToPoint(D, M) \neq \bot$,
\vspace{0.25ex}
\begin{formulae}
  \item $\SinsemillaHashToPoint(D, M) = \scalarmult{2^n}{\SinsemillaGenInit(D)} + \ssum{j=0}{2^k - 1} \scalarmult{\chi(m)_{j+1}}{\SinsemillaGenBase(j)}$,\, where $m = \pad_n(M)$.
\end{formulae}
\vspace{-0.25ex}
(The $j+1$ is just because sequence indices are $1$-based.)

\introlist
This is a Pedersen vector hash of the $\chi(m)$ elements, with a fixed offset $\scalarmult{2^n}{\SinsemillaGenInit(D)}$.
The fixed offset does not affect \collisionResistance in this context. (See below for why
it cannot be eliminated for $\SinsemillaHash$, or when using incomplete addition.)
\theoremref{thmsinsemillaex} will prove that a $\bot$ output from $\SinsemillaHashToPoint$
yields a nontrivial discrete log relation. It follows that the \collisionResistance of
$\SinsemillaHashToPoint$ can be tightly reduced, via the proof in \cite[Appendix A]{BGG1995},
to the \xDiscreteLogarithmProblem 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.

\vspace{0.5ex}
Now we consider $\SinsemillaHash$. We want to prove that, for given $D$, if we can find two distinct
messages $M$ and $M'$ such that $\ExtractPbot\smash{\big(\SinsemillaHashToPoint(D, M)\kern-0.1em\big)} =
\ExtractPbot\smash{\big(\SinsemillaHashToPoint(D, M')\kern-0.1em\big)} \neq \bot$ then we can efficiently
extract a discrete logarithm.

The inputs to $\ExtractPbot$ are not $\bot$, therefore they are in $\GroupP$.
$\ExtractPbot$ maps $P, Q \in \GroupP$ to the same output if and only if $P = \pm Q$.
So either $\SinsemillaHashToPoint(D, M) = \SinsemillaHashToPoint(D, M')$ (in which case use the
original Pedersen hash proof) or $\SinsemillaHashToPoint(D, M) = -\SinsemillaHashToPoint(D, M')$.
In the latter case, let $m = \pad_n(M)$ and $m' = \pad_n(M')$, then we have

\vspace{0.5ex}
\begin{tabular}{@{\hskip 1.5em}r@{\;}l}
$    \scalarmult{2^n}{\SinsemillaGenInit(D)} + \ssum{j=0}{{2^k}-1} \scalarmult{\chi(m)_{j+1}}{\SinsemillaGenBase(j)} = $&$ -\kern-0.1em\Big(\scalarmult{2^n}{\SinsemillaGenInit(D)} + \ssum{j'=0}{{2^k}-1} \scalarmult{\chi(m')_{j'+1}}{\SinsemillaGenBase(j')}\kern-0.15em\Big)$ \\
$\scalarmult{2^{n+1}}{\SinsemillaGenInit(D)} + \ssum{j=0}{{2^k}-1} \scalarmult{\chi(m)_{j+1} + \chi(m')_{j+1}}{\SinsemillaGenBase(j)} = $&$ 0$
\end{tabular}

\vspace{1ex}
Because $2^{n+1} \leq \ParamP{r}-1$, the coefficients $\!\!\pmod{\ParamP{r}}$ are not all zero, and therefore
this is a nontrivial discrete logarithm relation between independent bases.
\end{proof}

\begin{nnotes}
  \item \cite[Lemma 3]{JT2020} proves a tight reduction from finding a nontrivial discrete logarithm
        relation in a \primeOrderGroup to solving the \xDiscreteLogarithmProblem in that group.
  \item 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{rhoandnullifiers} against Faerie Gold attacks, as described in
        \crossref{faeriegold}.
        \vspace{-0.25ex}
  \item Assuming that $\GroupGHash$ acts as a \randomOracle, it can also be proven that $\SinsemillaHashToPoint$
        and $\SinsemillaHash$ are \collisionResistant across different personalization inputs (regardless of input length).
\end{nnotes}

\introsection
\theoremlabel{thmsinsemillaex}
\begin{theorem}[A $\bot$ output from $\SinsemillaHashToPoint$ yields a nontrivial discrete log relation]\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)$
        \vspace{-0.25ex}
  \item for $i$ from $1$ up to $n$:
        \vspace{-1ex}
  \item \tab let $\Acc_i \leftarrow \big(\Acc_{i-1} \incompleteadd \SinsemillaGenBase(m_i)\kern-0.1em\big) \incompleteadd \Acc_{i-1}$
  \item \vspace{-4.5ex}
  \item return $\Acc_n$.
\end{formulae}

\vspace{-0.5ex}
We have an exceptional case if and only if $\Acc_{i-1} = \pm\, \SinsemillaGenBase(m_i)$ or $\Acc_{i-1} + \SinsemillaGenBase(m_i) = \pm\, \Acc_{i-1}$.
(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.)

\vspace{0.5ex}
If $\Acc_{i-1} + \SinsemillaGenBase(m_i) = \Acc_{i-1}$, then we have $\SinsemillaGenBase(m_i) = \ZeroP$
contrary to assumption. So exceptional cases occur only if $\scalarmult{\alpha}{\Acc_{i-1}} + \SinsemillaGenBase(m_i) = \ZeroP$
for some $i \in \range{1}{n}$, and $\alpha = -1$ (for the case $\Acc_{i-1} = \SinsemillaGenBase(m_i)$) or $\alpha = 1$ (for
$\Acc_{i-1} = -\SinsemillaGenBase(m_i)$) or $\alpha = 2$ (for $\Acc_{i-1} + \SinsemillaGenBase(m_i) = -\Acc_{i-1}$).

\vspace{-0.5ex}
$\Acc_i$ has a representation $\scalarmult{2^i}{\SinsemillaGenInit(D)} + \ssum{j=0}{2^k - 1} \,\scalarmult{X_{i,j+1}}{\SinsemillaGenBase(j)}$
for some $X_i \typecolon \typeexp{\binaryrange{i}}{2^j}$.
So given $m$ that results in an exceptional case, the nontrivial discrete logarithm relation
$\scalarmult{\alpha \mult 2^i}{\SinsemillaGenInit(D)} + \Big(\ssum{j=0}{\smash{2^k - 1}} \,\scalarmult{\alpha \mult X_{i,j+1}}{\SinsemillaGenBase(j)}\kern-0.15em\Big) + \SinsemillaGenBase(m_i) = \ZeroP$
is easily computable from $m$. The coefficients in this representation do not overflow since
$X_{i,j+1} < 2^i$ for all $i \in \range{1}{n}$ and $j \in \binaryrange{k}$; and
$|\alpha \mult 2^i| \leq \ParamP{r}-1$ for all $i \in \range{1}{n}$ and $\alpha \in \setof{-1, 1, 2}$.\;
\end{proof}

\vspace{-0.5ex}
Similarly, a $\bot$ output from $\SinsemillaHash$ yields a nontrivial discrete logarithm relation,
because $\ExtractPbot$ only returns $\bot$ when its input is $\bot$.

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


\nufive{
\introlist
\lsubsubsubsection{\PoseidonHashText{} Function}{poseidonhash}

\vspace{-1ex}
$\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. For verifying the parameters used in Zcash, we
recommend the fork \cite{Poseidon-Zc1.1} which avoids use of the obsolete PyCrypto library.}}

The \nh{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 $56$.

We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise addition in
$\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 use the \nh{``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
$\PoseidonHash \typecolon \GF{\ParamP{q}} \times \GF{\ParamP{q}} \rightarrow \GF{\ParamP{q}}$
is specified as:

\begin{formulae}
  \item $\PoseidonHash(x, y) = f([x, y, 2^{65}])_1$ (using $1$-based indexing).
\end{formulae}

\vspace{-1ex}
The MDS matrix and round constants are generated by \texttt{generate\_parameters\_grain.sage} in
Version 1.1 of the reference implementation. The number of full and partial rounds are as calculated
by \texttt{calc\_round\_numbers.py} in that implementation, for a $128$-bit security level
``with margin''.

\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}. 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
        suitable for implementing FFT may be more vulnerable to integral attacks.''
        $\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, previous cryptanalysis of $\Poseidon$ has focussed mainly on the case
        of \nh{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}}$.

        On the other hand, the number of rounds chosen includes a significant security margin,
        even taking into account these considerations. For small $t$, such as $t = 3$ as used
        here, the results of \cite{KR2020} are positive for security since they indicate that
        the number of active \nh{S-boxes} through the middle rounds is larger than originally
        estimated by the $\Poseidon$ designers (and the number of rounds is based on this
        original conservative estimate).

        Also note that the use of $\Poseidon$ in \Orchard is very conservative. First, the
        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 $\NoteUniqueRand$ comes
        from a previous \nullifier which is effectively a random \affineSW $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 $\NoteUniqueRand$, this nullifier
        construction would still be secure under a \xDecisionalDiffieHellman assumption
        on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from
        an ideal PRF.
  \item The constant $2^{65}$ comes from \cite[section 4.2]{GKRRS2019}:
        ``\nh{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
        $2$ field elements, and the output length is $1$ field element.
\end{nnotes}
} %nufive


\introlist
\lsubsubsubsection{Equihash Generator}{equihashgen}

$\EquihashGen{n, k}$ is a specialized \hashFunction that maps an input
and an index to an output of length $n$ bits. It is used in \crossref{equihash}.

\newsavebox{\powtagbox}
\begin{lrbox}{\powtagbox}
\begin{bytefield}[bitwidth=0.16em]{128}
    \sbitbox{64}{64-bit $\ascii{ZcashPoW}$} &
    \sbitbox{32}{32-bit $n$} &
    \sbitbox{32}{32-bit $k$}
\end{bytefield}
\end{lrbox}

\newsavebox{\powcountbox}
\begin{lrbox}{\powcountbox}
\begin{bytefield}[bitwidth=0.16em]{32}
    \sbitbox{32}{32-bit $g$}
\end{bytefield}
\end{lrbox}

Let $\powtag := \Justthebox{\powtagbox}$.

Let $\powcount(g) := \Justthebox{\powcountbox}$.

\vspace{2ex}
\introlist
% Blech. Dijkstra was right \cite{EWD-831}.
Let $\EquihashGen{n, k}(S, i) := T_\barerange{h+1}{h+n}$, where
\begin{formulae}
  \item $m = \floor{\frac{512}{n}}$;
  \item $h = (i-1 \bmod m) \mult n$;
  \item $T = \BlakeTwobOf{(\mathnormal{n \mult m})}{\powtag,\, S \bconcat \powcount(\floor{\frac{i-1}{m}})}$.
\end{formulae}

Indices of bits in $T$ are 1-based.

$\BlakeTwobOf{\ell}{p, x}$ is defined in \crossref{concreteblake2}.

\securityrequirement{
$\BlakeTwobOf{\ell}{\powtag, x}$ must generate output that is sufficiently
unpredictable to avoid short-cuts to the \Equihash solution process.
It would suffice to model it as a \randomOracle.
}

\pnote{
When $\EquihashGen{}$ is evaluated for sequential indices, as
in the \Equihash solving process (\crossref{equihash}),
the number of calls to $\BlakeTwobGeneric$ can be reduced by a factor of
$\floor{\frac{512}{n}}$ in the best case (which is a factor of 2 for
$n = 200$).
}


\introsection
\lsubsubsection{Pseudo Random Functions}{concreteprfs}

Let \shaCompress be as given in \crossref{concretesha256}.

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}
\begin{bytefield}[bitwidth=0.06em]{512}
    \sbitbox{18}{$1$} &
    \sbitbox{18}{$1$} &
    \sbitbox{18}{$0$} &
    \sbitbox{18}{$0$} &
    \sbitbox{224}{$252$-bit $x$} &
    \sbitbox{56}{$8$-bit $t$} &
    \sbitbox{200}{$\zeros{248}$}
\end{bytefield}
\end{lrbox}

\newsavebox{\nfbox}
\begin{lrbox}{\nfbox}
\begin{bytefield}[bitwidth=0.06em]{512}
    \sbitbox{18}{$1$} &
    \sbitbox{18}{$1$} &
    \sbitbox{18}{$1$} &
    \sbitbox{18}{$0$} &
    \sbitbox{224}{$252$-bit $\AuthPrivate$} &
    \sbitbox{256}{$256$-bit $\NoteUniqueRand$}
\end{bytefield}
\end{lrbox}

\newsavebox{\pkbox}
\begin{lrbox}{\pkbox}
\begin{bytefield}[bitwidth=0.06em]{512}
    \sbitbox{18}{$0$} &
    \sbitbox{18}{\iminusone} &
    \sbitbox{18}{$0$} &
    \sbitbox{18}{$0$} &
    \sbitbox{224}{$252$-bit $\AuthPrivate$} &
    \sbitbox{256}{$256$-bit $\hSig$}
\end{bytefield}
\end{lrbox}

\newsavebox{\rhobox}
\begin{lrbox}{\rhobox}
\begin{bytefield}[bitwidth=0.06em]{512}
    \sbitbox{18}{$0$} &
    \sbitbox{18}{\iminusone} &
    \sbitbox{18}{$1$} &
    \sbitbox{18}{$0$} &
    \sbitbox{224}{$252$-bit $\NoteUniquePreRand$} &
    \sbitbox{256}{$256$-bit $\hSig$}
\end{bytefield}
\end{lrbox}

\vspace{-3ex}
\begin{equation*}
\begin{aligned}
\PRFaddr{x}(t)                                &:= \SHACompressBox{\addrbox} \\
\PRFnf{Sprout}{\AuthPrivate}(\NoteUniqueRand) &:= \SHACompressBox{\nfbox} \\
\PRFpk{\AuthPrivate}(i, \hSig)                &:= \SHACompressBox{\pkbox} \\
\PRFrho{\NoteUniquePreRand}(i, \hSig)         &:= \SHACompressBox{\rhobox}
\end{aligned}
\end{equation*}

\vspace{1ex}
\begin{securityrequirements}
  \item \shaCompress must be \collisionResistant\!.
  \item \shaCompress must be a \xPRF when keyed by the bits
        corresponding to $x$, $\AuthPrivate$ or $\NoteUniquePreRand$
        in the above diagrams, with input in the remaining bits.
\end{securityrequirements}

\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
are independent. As well as the inputs shown here, bits $\mathtt{1011}$
in this position are used to distinguish uses of the full \shaHash hash
function; see \crossref{concretesproutnotecommit}.

(The specific bit patterns chosen here were motivated by the possibility of future
extensions that might have increased $\NOld$ and/or $\NNew$ to 3, or added an
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}
\begin{lrbox}{\saplingockbox}
\setsapling
\begin{bytefield}[bitwidth=0.038em]{512}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\OutViewingKey}$} &
    \sbitbox{256}{$32$-byte $\cvField$}
    \sbitbox{256}{$32$-byte $\cmuField$} &
    \sbitbox{264}{$32$-byte $\ephemeralKey$}
\end{bytefield}
\end{lrbox}

\newsavebox{\nfsaplingbox}
\begin{lrbox}{\nfsaplingbox}
\setsapling
\begin{bytefield}[bitwidth=0.038em]{512}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\NullifierKeyRepr}$} &
    \sbitbox{256}{$\LEBStoOSPOf{256}{\NoteUniqueRandRepr}$}
\end{bytefield}
\end{lrbox}

\sapling{
\introlist
\vspace{2ex}
$\PRFexpand{}$ is used in \crossref{saplingkeycomponents} to derive the
\authSigningKey $\AuthSignPrivate$ and the \authProvingKey $\AuthProvePrivate$.

It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in
\crossref{concreteblake2}:

\begin{formulae}
  \item $\PRFexpand{\SpendingKey}(t) := \BlakeTwobOf{512}{\ascii{Zcash\_ExpandSeed}, \LEBStoOSPOf{256}{\SpendingKey} \bconcat t}$
\end{formulae}

\vspace{-3ex}
\securityrequirement{
$\BlakeTwobOf{512}{\ascii{Zcash\_ExpandSeed}, \LEBStoOSPOf{256}{\SpendingKey} \bconcat t}$ must be a \xPRF for output range
$\PRFOutputExpand$ when keyed by the bits corresponding to $\SpendingKey$, with input in the bits
corresponding to $t$.
} %securityrequirement


\introlist
\vspace{2ex}
$\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
\crossref{concreteblake2}:

\begin{formulae}
  \item $\PRFock{Sapling}{\OutViewingKey}(\cvField, \cmuField, \ephemeralKey) := \BlakeTwobOf{256}{\ascii{Zcash\_Derive\_ock}, \ockInput}$
  \item where $\ockInput = \Justthebox{\saplingockbox}$.
\end{formulae}

\vspace{-2ex}
\securityrequirement{
$\BlakeTwobOf{512}{\ascii{Zcash\_Derive\_ock}, \ockInput}$ must be a
PRF for output range $\Keyspace$ (defined in \crossref{concretesym}) when keyed by the bits corresponding
to $\OutViewingKey$, with input in the bits corresponding to $\cvField$, $\cmuField$, and $\ephemeralKey$.
} %securityrequirement

\vspace{2ex}
\introlist
$\PRFnf{Sapling}{}$ is used to derive the \nullifier for a \Sapling \note.
It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \crossref{concreteblake2}:

\begin{formulae}
  \item $\PRFnf{Sapling}{\NullifierKeyRepr}(\NoteUniqueRandRepr) := \BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$.
\end{formulae}

\vspace{-2ex}
\securityrequirement{
The function $\BlakeTwosOf{256}{\ascii{Zcash\_nf}, \Justthebox{\nfsaplingbox}}$ must be a
\collisionResistant \xPRF for output range $\byteseq{32}$ when keyed by the bits
corresponding to $\NullifierKeyRepr$, with input in the bits corresponding to
$\NoteUniqueRandRepr$. Note that
{$\NullifierKeyRepr$}{$\typecolon$}{$\SubgroupReprJ$} % {$...$} hack needed for reasonable spacing
is a representation of a point in the $\ParamJ{r}$-order subgroup of the \jubjubCurve,
and therefore is not uniformly distributed on $\ReprJ$.
$\SubgroupReprJ$ is defined in \crossref{jubjub}.
}
} %sapling


\newsavebox{\orchardockbox}
\begin{lrbox}{\orchardockbox}
\setnufive
\begin{bytefield}[bitwidth=0.038em]{512}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\OutViewingKey}$} &
    \sbitbox{256}{$32$-byte $\cvField$}
    \sbitbox{256}{$32$-byte $\cmxField$} &
    \sbitbox{264}{$32$-byte $\ephemeralKey$}
\end{bytefield}
\end{lrbox}

\nufive{
\introlist
\vspace{2ex}
$\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
\crossref{concreteblake2}:

\begin{formulae}
  \item $\PRFock{Orchard}{\OutViewingKey}(\cvField, \cmxField, \ephemeralKey) := \BlakeTwobOf{256}{\ascii{Zcash\_Orchardock}, \ockInput}$
  \item where $\ockInput = \Justthebox{\orchardockbox}$.
\end{formulae}

\vspace{-2ex}
\securityrequirement{
$\BlakeTwobOf{512}{\ascii{Zcash\_Orchardock}, \ockInput}$ must be a
PRF for output range $\Keyspace$ (defined in \crossref{concretesym}) when keyed by the bits corresponding
to $\OutViewingKey$, with input in the bits corresponding to $\cvField$, $\cmxField$, and $\ephemeralKey$.
} %securityrequirement

\vspace{2ex}
\introlist
Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}.

$\PRFnf{Orchard}{} \typecolon \NullifierKeyTypeOrchard \times \NoteUniqueRandTypeOrchard \rightarrow \PRFOutputNfOrchard$ is used as
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) := \PoseidonHash(\NullifierKey, \NoteUniqueRand)$.
\end{formulae}

\vspace{-2ex}
\securityrequirement{
$\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

\begin{nnotes}
  \item This construction of a PRF from a sponge is described in \cite[section 3.12]{BDPA2011}.
        It is called ``outer-keyed sponge'' in \cite{ADMA2015}, or ``black-box keying'' in \cite{GPT2015}.
        The results of these papers do not directly apply because the key is smaller than the rate.
        However, the result of \cite{GG2015} provides evidence for the security of this construction
        (even if it technically considers a situation in which the distinguishing adversary cannot
        evaluate the full permutation).
  \item See \crossref{poseidonhash} for further security discussion of how \Orchard uses $\Poseidon$.
\end{nnotes}
} %nufive


\introsection
\vspace{-1ex}
\lsubsubsection{Symmetric Encryption}{concretesym}

\vspace{-1ex}
Let $\Keyspace := \bitseq{256}$, $\Plaintext := \byteseqs$, and $\Ciphertext := \byteseqs$.

Let the \symmetricEncryptionScheme $\SymEncrypt{\Key}(\Ptext)$ be authenticated encryption using
$\SymSpecific$ \cite{RFC-7539} encryption of plaintext $\Ptext \in \Plaintext$,
with empty ``associated data", all-zero nonce $\zeros{96}$, and $256$-bit key
$\Key \in \Keyspace$.

Similarly, let $\SymDecrypt{\Key}(\Ctext)$ be $\SymSpecific$
decryption of ciphertext $\Ctext \in \Ciphertext$, with empty
``associated data", all-zero nonce $\zeros{96}$, and $256$-bit key
$\Key \in \Keyspace$. The result is either the plaintext \byteSequence,
or $\bot$ indicating failure to decrypt.

\pnote{
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$.
} %pnote

\nufive{
\lsubsubsection{Pseudo Random Permutations}{concreteprps}

Let $\DiversifierKeyLength$ and $\DiversifierLength$ be as defined in \crossref{constants}.

$\PRPd{} \typecolon \DiversifierKeyType \times \DiversifierType \rightarrow \DiversifierType$
is a \pseudoRandomPermutation specified in \crossref{abstractprps}. In this specification,
it is used to generate \diversifiers for \Orchard \shieldedPaymentAddresses in
\crossref{orchardkeycomponents}. (\cite{ZIP-32} uses an identical construction to
generate \diversifiers for \Sapling \shieldedPaymentAddresses.)

Let $\FFOneAES{K}(\mathit{tweak}, x)$ be the $\FFOne$ format-preserving
encryption algorithm \cite{NIST2016} using $\AES$ with a $256$-bit key $K$, and
parameters $\mathit{radix} = 2, \mathit{minlen} = 88, \mathit{maxlen} = 88$.
It will be used only with the empty string $\ascii{}$ as the $\mathit{tweak}$.
$x$ is a sequence of $88$ bits, as is the output.

Define $\PRPd{K}(\Diversifier) := \FFOneAES{K}(\ascii{}, \Diversifier)$.

\securityrequirement{$\FFOneAESAlg$ with tweak fixed to $\ascii{}$ must be a secure
\pseudoRandomPermutation.}

\vspace{-1ex}
\nnote{
\cite{DKLS2020} describes attacks against $\FFOne$ that are practical for some
parameterizations. However, for an $88$-bit domain, and $10$ rounds as specified in
\cite{NIST2016}, even the distinguishing attack is no better than a brute force
search for the $256$-bit key. Specifically we have $r = 5$ (half the number of rounds)
and $n = 44$ (half the domain size in bits), so according to \cite[section 4.2]{DKLS2020}
the data complexity is $2^{2n((r-1)-\frac{1}{2})-n} = 2^{264}$, and the time complexity
is $2^{2n((r-1)-\frac{1}{2})} = 2^{308}$.
} %nnote
} %nufive

\lsubsubsection{Key Agreement And Derivation}{concretekaandkdf}

\lsubsubsubsection{\SproutText{} Key Agreement}{concretesproutkeyagreement}

$\KA{Sprout}$ is a \keyAgreementScheme as specified in \crossref{abstractkeyagreement}.

It is instantiated as $\KASproutCurve$ key agreement, described in \cite{Bernstein2006},
as follows.

Let $\KAPublic{Sprout}$ and $\KASharedSecret{Sprout}$ be the type of $\KASproutCurve$ \publicKeys
(i.e.\ $\byteseq{32}$), and let $\KAPrivate{Sprout}$ be the type of $\KASproutCurve$
secret keys.

Let $\KASproutCurveMultiply(\bytes{n}, \bytes{q})$ be the result of point
multiplication of the $\KASproutCurve$ \publicKey represented by the byte
sequence $\bytes{q}$ by the $\KASproutCurve$ secret key represented by the
\byteSequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}.

Let $\KABase{Sprout} := \KASproutCurveBase$ be the public \byteSequence representing
the $\KASproutCurve$ base point.

Let $\KASproutCurveClamp(\bytes{x})$ take a 32-byte sequence $\bytes{x}$ as input
and return a \byteSequence representing a $\KASproutCurve$ \privateKey, with
bits ``clamped'' as described in \cite[section 3]{Bernstein2006}:
``clear bits $0, 1, 2$ of the first byte, clear bit $7$ of the last byte,
and set bit $6$ of the last byte.'' Here the bits of a byte are numbered
such that bit $b$ has numeric weight $2^b$.

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}
\begin{bytefield}[bitwidth=0.16em]{128}
    \sbitbox{64}{$64$-bit $\ascii{ZcashKDF}$} &
    \sbitbox{32}{$8$-bit $i\!-\!1$} &
    \sbitbox{56}{$\zeros{56}$}
\end{bytefield}
\end{lrbox}

\newsavebox{\kdfinputbox}
\begin{lrbox}{\kdfinputbox}
\begin{bytefield}[bitwidth=0.04em]{1024}
    \sbitbox{256}{$256$-bit $\hSig$} &
    \sbitbox{256}{$256$-bit $\DHSecret{i}$} &
    \sbitbox{256}{$256$-bit $\EphemeralPublic$} &
    \sbitbox{256}{$256$-bit $\TransmitPublicNew{i}$}
\end{bytefield}
\end{lrbox}

$\KDF{Sprout}$ is a \keyDerivationFunction as specified in \crossref{abstractkdf}.

It is instantiated using $\BlakeTwob{256}$ as follows:

\begin{formulae}
  \item $\KDF{Sprout}(i, \hSig, \DHSecret{i}, \EphemeralPublic, \TransmitPublicNew{i}) :=
\BlakeTwobOf{256}{\kdftag, \kdfinput}$
\end{formulae}
\introlist
where:
\begin{formulae}
  \item $\kdftag := \Justthebox{\kdftagbox}$
  \item $\kdfinput := \Justthebox{\kdfinputbox}$.
\end{formulae}

$\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}.


\sapling{
\lsubsubsubsection{\SaplingText{} Key Agreement}{concretesaplingkeyagreement}

$\KA{Sapling}$ is a \keyAgreementScheme as specified in \crossref{abstractkeyagreement}.

It is instantiated as Diffie--Hellman with cofactor multiplication on \Jubjub
as follows:

Let $\GroupJ$, $\SubgroupJ$, $\SubgroupJstar$, and the cofactor $\ParamJ{h}$ be as defined in \crossref{jubjub}.

Define $\KAPublic{Sapling} := \GroupJ$.

Define $\KAPublicPrimeSubgroup{Sapling} := \SubgroupJ$.

Define $\KASharedSecret{Sapling} := \SubgroupJ$.

Define $\KAPrivate{Sapling} := \GF{\ParamJ{r}}$.

Define $\KADerivePublic{Sapling}(\sk, B) := \scalarmult{\sk}{B}$.

Define $\KAAgree{Sapling}(\sk, P) := \scalarmult{\ParamJ{h} \mult \sk}{P}$.
} %sapling


\newsavebox{\kdfsaplinginputbox}
\begin{lrbox}{\kdfsaplinginputbox}
\setsapling
\begin{bytefield}[bitwidth=0.07em]{544}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\DHSecret{}}\kern 0.02em}$} &
    \sbitbox{256}{$\ephemeralKey$}
\end{bytefield}
\end{lrbox}

\introsection
\sapling{
\lsubsubsubsection{\SaplingText{} Key Derivation}{concretesaplingkdf}

\vspace{-1ex}
$\KDF{Sapling}$ is a \keyDerivationFunction as specified in \crossref{abstractkdf}.

It is instantiated using $\BlakeTwob{256}$ as follows:

\vspace{-0.5ex}
\begin{formulae}
  \item $\KDF{Sapling}(\DHSecret{}, \ephemeralKey) :=
           \BlakeTwobOf{256}{\ascii{Zcash\_SaplingKDF}, \kdfinput}$.
\end{formulae}
\vspace{-2.5ex}
where:
\begin{formulae}
  \item $\kdfinput := \Justthebox{\kdfsaplinginputbox}$.
\end{formulae}

$\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}.
} %sapling


\nufive{
\lsubsubsubsection{\OrchardText{} Key Agreement}{concreteorchardkeyagreement}

$\KA{Orchard}$ is a \keyAgreementScheme as specified in \crossref{abstractkeyagreement}.

It is instantiated as Diffie--Hellman on \Pallas as follows:

Let $\GroupP$ be as defined in \crossref{pallasandvesta}.

Define $\KAPublic{Orchard} := \GroupPstar$.

Define $\KASharedSecret{Orchard} := \GroupPstar$.

Define $\KAPrivate{Orchard} := \GFstar{\ParamP{r}}$.

Define $\KADerivePublic{Orchard}(\sk, B) := \scalarmult{\sk}{B}$.

Define $\KAAgree{Orchard}(\sk, P) := \scalarmult{\sk}{P}$.
} %nufive


\newsavebox{\kdforchardinputbox}
\begin{lrbox}{\kdforchardinputbox}
\setnufive
\begin{bytefield}[bitwidth=0.07em]{544}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\reprP\Of{\DHSecret{}}\kern 0.02em}$} &
    \sbitbox{256}{$\ephemeralKey$}
\end{bytefield}
\end{lrbox}

\nufive{
\lsubsubsubsection{\OrchardText{} Key Derivation}{concreteorchardkdf}

\vspace{-1ex}
$\KDF{Orchard}$ is a \keyDerivationFunction as specified in \crossref{abstractkdf}.

It is instantiated using $\BlakeTwob{256}$ as follows:

\vspace{-0.5ex}
\begin{formulae}
  \item $\KDF{Orchard}(\DHSecret{}, \ephemeralKey) :=
           \BlakeTwobOf{256}{\ascii{Zcash\_OrchardKDF}, \kdfinput}$.
\end{formulae}
\vspace{-2.5ex}
where:
\begin{formulae}
  \item $\kdfinput := \Justthebox{\kdforchardinputbox}$.
\end{formulae}

$\BlakeTwobOf{256}{p, x}$ is defined in \crossref{concreteblake2}.
} %nufive


\introsection
\extralabel{concretejssig}{\lsubsubsection{\EdSpecificText}{concreteed25519}}

\EdSpecific is a \signatureScheme as specified in \crossref{abstractsig}.
It is used to instantiate $\JoinSplitSig$ as described in \crossref{sproutnonmalleability}.

Let $\PreCanopyExcludedPointEncodings \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},$ \\
$\hexarray{01,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},$ \\
$\hexarray{26,e8,95,8f,c2,b2,27,b0,45,c3,f4,89,f2,ef,98,f0,d5,df,ac,05,d3,c6,33,39,b1,38,02,88,6d,53,fc,05},$ \\
$\hexarray{c7,17,6a,70,3d,4d,d8,4f,ba,3c,0b,76,0d,10,67,0f,2a,20,53,fa,2c,39,cc,c6,4e,c7,fd,77,92,ac,03,7a},$ \\
$\hexarray{13,e8,95,8f,c2,b2,27,b0,45,c3,f4,89,f2,ef,98,f0,d5,df,ac,05,d3,c6,33,39,b1,38,02,88,6d,53,fc,85},$ \\
$\hexarray{b4,17,6a,70,3d,4d,d8,4f,ba,3c,0b,76,0d,10,67,0f,2a,20,53,fa,2c,39,cc,c6,4e,c7,fd,77,92,ac,03,fa},$ \\
$\hexarray{ec,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,7f},$ \\
$\hexarray{ed,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,7f},$ \\
$\hexarray{ee,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,7f},$ \\
$\hexarray{d9,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff},$ \\
$\hexarray{da,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff}$
\end{tabular}
} \\
$\}$.

Let $p = 2^{255} - 19$.

\vspace{-0.25ex}
Let $a = -1$.

\vspace{-0.25ex}
Let $d = -121665/121666 \pmod{p}$.

Let $\ell = 2^{252} + 27742317777372353535851937790883648493$ (the order of the \EdSpecific
curve's \primeOrderSubgroup).

Let $\EdDSABase$ be the base point given in \cite{BDLSY2012}.

Define the notation $\optsqrt{\,\paramdot\,}$ as in \crossref{notation}.

Define $\ItoLEOSP{}$, $\LEOStoBSP{}$, and $\LEBStoIP{}$ as in \crossref{endian}.

Define $\reprBytesEdSpecific \typecolon \GroupEdSpecific \rightarrow \ReprEdSpecificBytes$ such
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}.}

\introlist
Define $\abstBytesEdSpecific \typecolon \ReprEdSpecificBytes \rightarrow \maybe{\GroupEdSpecific}$ such that
$\abstBytesEdSpecific\Of{\bytes{P}}$ is computed as follows:
\begin{formulae}
  \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.
        \vspace{-0.25ex}
  \item let $y \typecolon \GF{p} = \LEBStoIPOf{255}{y\Repr} \pmod{p}$.
        \vspace{-0.25ex}
  \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}$.)
        \vspace{-0.25ex}
  \item if $x = \bot$, return $\bot$.
        \vspace{-0.25ex}
  \item if $x \bmod 2 = \tilde{x}$ then return $(x, y)$ else return $(p - x, y)$.
\end{formulae}

\pnote{This definition of point decoding differs from that of \cite[section 5.1.3, as corrected by the errata]{RFC-8032}.
In the latter there is an additional step ``\texttt{If x = 0, and x\_0 = 1, decoding fails.}'',
which rejects the encodings $\{$ \\
\scalebox{0.615}[0.7]{
\begin{tabular}{@{\hspace{1.5em}}l@{}}
$\hexarray{01,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,80},$ \\
$\hexarray{ee,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff},$ \\
$\hexarray{ec,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff}$
\end{tabular}
} \\
$\}$. \\
In this specification, the first two of these are accepted as encodings of $(0, 1)$, and the third is
accepted as an encoding of $(0, -1)$.}

\vspace{2ex}
\EdSpecific is defined as in \cite{BDLSY2012}, using \bigShaHash as the internal \hashFunction,
with the additional requirements below. A valid \EdSpecific \validatingKey is defined as a sequence of
$32$ bytes encoding a point on the \EdSpecific curve.

\introlist
The requirements on a signature $(\EdDSAReprR{}, \EdDSAReprS{})$ with \validatingKey $\EdDSAReprA{}$ on
a message $M$ are:
\begin{itemize}
  \item $\EdDSAReprS{}$ \MUST represent an integer less than $\ell$.
  \item $\EdDSAReprR{}$ and $\EdDSAReprA{}$ \MUST be encodings of points $\EdDSASigR{}$ and $\EdDSASigA{}$ respectively
        on the \EdSpecific curve;
  \precanopyitem{$\EdDSAReprR{}$ \MUSTNOT be in $\PreCanopyExcludedPointEncodings$;}
  \precanopyitem{The validation equation \MUST be equivalent to $\scalarmult{\EdDSASigS{}}{B} = \EdDSASigR{} + \scalarmult{\EdDSASigc{}}{\EdDSASigA{}}$.}
  \canopyonwarditem{The validation equation \MUST be equivalent to
        $\scalarmult{8}{\scalarmult{\EdDSASigS{}}{B}} = \scalarmult{8}{\EdDSASigR{}} + \scalarmult{8}{\scalarmult{\EdDSASigc{}}{\EdDSASigA{}}}$ for
        single-signature validation.}
\end{itemize}
\vspace{-2ex}
where $\EdDSASigc{}$ is computed as the integer corresponding to $\BigSHAFull(\EdDSAReprR{} \bconcat \EdDSAReprA{} \bconcat M)$
as specified in \cite{BDLSY2012}.

If these requirements are not met or the validation equation does not hold, then the signature is
considered invalid.

\vspace{1ex}
\introlist
The encoding of an \EdSpecific signature is:

\newsavebox{\sigbox}
\begin{lrbox}{\sigbox}
\begin{bytefield}[bitwidth=0.075em]{512}
    \sbitbox{256}{$256$-bit $\EdDSAReprR{}$} &
    \sbitbox{256}{$256$-bit $\EdDSAReprS{}$}
\end{bytefield}
\end{lrbox}

\begin{formulae}
  \item $\Justthebox{\sigbox}$
\end{formulae}

\vspace{-1ex}
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\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 \PreCanopyExcludedPointEncodings$.
  \canopyonwarditem{Appendix \crossref{ed25519batchvalidate} describes an optimization that \MAY be used to speed up
validation of batches of \EdSpecific signatures.}
\end{pnotes}

\vspace{-2.5ex}
\nnote{The exclusion\canopy{, before \Canopy activation,} of $\PreCanopyExcludedPointEncodings$
from $\EdDSAReprR{}$ is due to a quirk of version 1.0.15 of the
libsodium library \cite{libsodium} which was initially used to implement \EdSpecific
signature validation in \zcashd.
(The \texttt{ED25519\_COMPAT} compile-time option was not set.) The intent was to
exclude points of order less than $\ell$; however, not all such points were covered.}

\canopyonwardnnote{Because the post-\Canopy rules for \EdSpecific signatures are a relaxation
of the pre-\Canopy rules, a \fullValidator implementation that checkpoints on the \Canopy
\activationBlock \MAY validate using the post-\Canopy rules for the whole chain (and \zcashd
does so since \zcashdref{v4.2.0}). We retain the pre-\Canopy rules in the specification in order
to accurately document the history of consensus changes.}


\sapling{
\extralabel{concreteredjubjub}{\lsubsubsection{\RedDSAText{}\notnufive{ and \RedJubjubText{}}\notbeforenufive{, \RedJubjubText{}, and \RedPallasText{}}}{concretereddsa}}

$\RedDSA$ is a Schnorr-based \signatureScheme, optionally supporting key \reRandomization
as described in \crossref{abstractsigrerand}. It also supports a
Secret Key to Public Key Monomorphism as described in \crossref{abstractsigmono}.
It is based on a scheme from \cite[section 3]{FKMSSS2016}, with some ideas from
EdDSA \cite{BJLSY2015}.

$\RedJubjub$ is a specialization of $\RedDSA$ to the \jubjubCurve (\crossref{jubjub}),
using the $\BlakeTwob{512}$ hash function.

The \spendAuthSignatureScheme $\SpendAuthSig{Sapling}$ is instantiated by $\RedJubjub$, using
parameters defined in \crossref{concretespendauthsig}.

The \bindingSignatureScheme $\BindingSig{Sapling}$ is instantiated by $\RedJubjub$ without
key \reRandomization, using parameters defined in \crossref{concretebindingsig}.

\nufive{
$\RedPallas$ is a specialization of $\RedDSA$ to the \pallasCurve defined in \crossref{pallasandvesta},
using the $\BlakeTwob{512}$ hash function.

The \spendAuthSignatureScheme $\SpendAuthSig{Orchard}$ is instantiated by $\RedPallas$, using
parameters defined in \crossref{concretespendauthsig}.

The \bindingSignatureScheme $\BindingSig{Orchard}$ is instantiated by $\RedPallas$ without
key \reRandomization, using parameters defined in \crossref{concretebindingsig}.
} %nufive

Let $\ItoLEBSP{}$, $\ItoLEOSP{}$, $\LEOStoIP{}$, and $\LEBStoOSP{}$ be as defined in \crossref{endian}.

\introlist
\vspace{1ex}
We first describe the scheme $\RedDSA$ over a general \representedGroup.
Its parameters are:
\begin{itemize}
  \item a \representedGroup $\GroupG{}$, which also defines
        a subgroup $\SubgroupG{}$ of order $\ParamG{r}$, a cofactor $\ParamG{h}$,
        a group operation $+$, an additive identity $\ZeroG{}$,
        a bit-length $\ellG{}$, a representation function $\reprG{}$,
        and an abstraction function $\abstG{}$, as specified in
        \crossref{abstractgroup};
  \item $\GenG{}$, a generator of $\SubgroupG{}$;
  \item a bit-length $\RedDSAHashLength \typecolon \Nat$ such that
        $2^{\RedDSAHashLength-128} \geq \ParamG{r}$ and $\RedDSAHashLength \bmod 8 = 0$;
  \item a cryptographic \hashFunction $\RedDSAHash \typecolon \byteseqs \rightarrow \byteseq{\RedDSAHashLength/8}$.
\end{itemize}

\introlist
Its associated types are defined as follows:
\begin{formulae}
  \item $\RedDSAMessage := \byteseqs$
  \item $\RedDSASignature := \smash{\byteseq{\ceiling{\smash{\ellG{}}/8}\, +\, \ceiling{\bitlength(\ParamG{r})/8}}}$
  \item $\RedDSAPublic := \GroupG{}$
  \item $\RedDSAPrivate := \GF{\ParamG{r}}$.
  \item $\RedDSARandom := \GF{\ParamG{r}}$.
\end{formulae}

\vspace{-1ex}
\introlist
Define $\RedDSAHashToScalar \typecolon \byteseqs \rightarrow \GF{\ParamG{r}}$ by:
\begin{formulae}
  \item $\RedDSAHashToScalar(B) = \LEOStoIP{\RedDSAHashLength}\big(\RedDSAHash(B)\kern-0.16em\big) \!\pmod{\ParamG{r}}$
\end{formulae}

\introlist
Define $\RedDSAGenPrivate \typecolon () \rightarrowR \RedDSAPrivate$ as:
\begin{formulae}
  \item Return $\sk \leftarrowR \GF{\ParamG{r}}$.
\end{formulae}

\introlist
Define $\RedDSADerivePublic \typecolon \RedDSAPrivate \rightarrow \RedDSAPublic$ by:
\begin{formulae}
  \item $\RedDSADerivePublic(\sk) := \scalarmult{\sk}{\GenG{}}$.
\end{formulae}

\introlist
Define $\RedDSAGenRandom \typecolon () \rightarrowR \RedDSARandom$ as:
\begin{formulae}
  \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$.
  \item Return $\RedDSAHashToScalar(T)$.
\end{formulae}

Define $\RedDSARandomizerId := 0 \pmod{\ParamG{r}}$.
\vspace{1ex}

\introlist
Define $\RedDSARandomizePrivate \typecolon \RedDSARandom \times \RedDSAPrivate \rightarrow \RedDSAPrivate$ by:
\begin{formulae}
  \item $\RedDSARandomizePrivate(\RedDSARandomizer, \sk) := \sk + \RedDSARandomizer \pmod{\ParamG{r}}$.
\end{formulae}

\introlist
Define $\RedDSARandomizePublic \typecolon \RedDSARandom \times \RedDSAPublic \rightarrow \RedDSAPublic$ as:
\begin{formulae}
  \item $\RedDSARandomizePublic(\RedDSARandomizer, \vk) := \vk + \scalarmult{\RedDSARandomizer}{\GenG{}}$.
\end{formulae}

\introlist
Define $\RedDSASign{} \typecolon (\sk \typecolon \RedDSAPrivate) \times (M \typecolon \RedDSAMessage) \rightarrowR \RedDSASignature$ as:
\begin{algorithm}
  \item Choose a \byteSequence $T$ uniformly at random on $\byteseq{(\RedDSAHashLength+128)/8}$.
  \item Let $\vkBytes{} = \LEBStoOSPOf{\ellG{}}{\reprG{}\Of{\RedDSADerivePublic(\sk)}\kern 0.05em}$.
        \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.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{}$.
\end{algorithm}

\introlist
Define $\RedDSAValidate{} \typecolon (\vk \typecolon \RedDSAPublic) \times (M \typecolon \RedDSAMessage) \times
        (\sigma \typecolon \RedDSASignature) \rightarrow \bit$ as:
\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{-1ex}
  \item Let $\RedDSASigc{} = \RedDSAHashToScalar(\RedDSAReprR{} \bconcat \vkBytes{} \bconcat M)$.
  \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
        as key randomization. They are also used in \cite{ZIP-32} when deriving child extended keys,
        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).
\end{nnotes}

\introlist
The two abelian groups specified in \crossref{abstractsigmono} are instantiated for $\RedDSA$
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}

\introlist
As required, $\RedDSADerivePublic$ is a group monomorphism, since it is injective and:

\begin{tabular}{@{\hskip 1.5em}r@{\;}l}
  $\RedDSADerivePublic(\sk_1 \grpplus \sk_2)$
    &$= \scalarmult{\sk_1 + \sk_2 \pmod{\ParamG{r}}}{\GenG{}}$ \\
    &$= \scalarmult{\sk_1}{\GenG{}} + \scalarmult{\sk_2}{\GenG{}}$ \;(since $\GenG{}$ has order $\ParamG{r}$)\\
    &$= \RedDSADerivePublic(\sk_1)\, \combplus \RedDSADerivePublic(\sk_2)$.
\end{tabular}

\vspace{0.5ex}
A $\RedDSA$ \validatingKey $\vk$ can be encoded as a \bitSequence $\reprG{}\Of{\vk}$\, of
length $\ellG{}$ bits (or as a corresponding \byteSequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$).

\vspace{0.5ex}
\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}

\nufive{
\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

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}$}.
} %sapling


\sapling{
\introsection
\vspace{-1ex}
\lsubsubsubsection{Spend Authorization Signature (\SaplingAndOrchardText)}{concretespendauthsig}

\vspace{-1ex}
Let $\RedJubjub$ be as defined in \crossref{concretereddsa}.

Define $\AuthSignBase{Sapling} := \FindGroupJHash\Of{\ascii{Zcash\_G\_}, \ascii{}}$.

The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Sapling}$ is instantiated as $\RedJubjub$
with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Sapling}$.

\nufive{
Let $\RedPallas$ be as defined in \crossref{concretereddsa}.

Define $\AuthSignBase{Orchard} := \GroupPHash\Of{\ascii{z.cash:Orchard}, \ascii{G}}$.

The \defining{\spendAuthSignatureScheme} $\SpendAuthSig{Orchard}$ is instantiated as $\RedPallas$
with key \reRandomization and with generator $\GenG{} = \AuthSignBase{Orchard}$.
} %nufive

\vspace{0.5ex}
See \crossref{spendauthsig} for details on the use of this \signatureScheme.

\vspace{-2ex}
\securityrequirement{
\nufive{Each instantiation of} $\SpendAuthSig{}$ must be a \nh{SURK-CMA-secure} \rerandomizableSignatureScheme
as defined in \crossref{abstractsigrerand}.
} %securityrequirement
} %sapling


\sapling{
\vspace{-1ex}
\lsubsubsubsection{Binding Signature (\SaplingAndOrchardText)}{concretebindingsig}

\vspace{-1ex}
Let $\RedJubjub$\nufive{ and $\RedPallas$} be as defined in \crossref{concreteredjubjub}.

The \Sapling{} \defining{\bindingSignatureScheme}, $\BindingSig{Sapling}$, is instantiated as $\RedJubjub$
without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in
\crossref{concretevaluecommit}. See \crossref{saplingbalance} for details on the use of this \signatureScheme.

\nufive{
The \Orchard{} \defining{\bindingSignatureScheme}, $\BindingSig{Orchard}$, is instantiated as $\RedPallas$
without key \reRandomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in
\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 \nh{SUF-CMA-secure} \keyMonomorphicSignatureScheme
as defined in \crossref{abstractsigmono}. A signature must prove knowledge of the discrete logarithm of
the \validatingKey with respect to the base $\ValueCommitRandBase{Sapling}$\nufive{ or
$\ValueCommitRandBase{Orchard}$}.
} %securityrequirement
} %sapling


\introlist
\lsubsubsection{Commitment schemes}{concretecommit}

\vspace{-1ex}
\lsubsubsubsection{\SproutText{} Note Commitments}{concretesproutnotecommit}

\newsavebox{\cmbox}
\begin{lrbox}{\cmbox}
\begin{bytefield}[bitwidth=0.027em]{840}
    \sbitbox{28}{$1$} &
    \sbitbox{28}{$0$} &
    \sbitbox{28}{$1$} &
    \sbitbox{28}{$1$} &
    \sbitbox{28}{$0$} &
    \sbitbox{28}{$0$} &
    \sbitbox{28}{$0$} &
    \sbitbox{28}{$0$} &
    \sbitbox{256}{$256$-bit $\AuthPublic$} &
    \sbitbox{140}{$64$-bit $\Value$} &
    \sbitbox{256}{$256$-bit $\NoteUniqueRand$} &
    \sbitbox{256}{$256$-bit $\NoteCommitRand$}
\end{bytefield}
\end{lrbox}

\vspace{-1ex}
The \noteCommitmentScheme $\NoteCommit{Sprout}{}$ specified in \crossref{abstractcommit} is
instantiated using \shaHash as follows:

\begin{formulae}[leftmargin=1em]
  \item $\NoteCommit{Sprout}{\NoteCommitRand}(\AuthPublic, \Value, \NoteUniqueRand) := \SHAFullBox{\cmbox}$
  \item $\NoteCommitGenTrapdoor{Sprout}()$ generates the uniform distribution on $\NoteCommitTrapdoor{Sprout}$.
\end{formulae}

\vspace{-1ex}
\pnote{The leading byte of the \shaHash input is $\hexint{B0}$.}

\begin{securityrequirements}
  \item \shaCompress must be \collisionResistant\!.
  \item \shaCompress must be a \xPRF when keyed by the bits corresponding
        to the position of $\NoteCommitRand$ in the second block of \shaHash
        input, with input to the \xPRF in the remaining bits of the block and
        the chaining variable.
\end{securityrequirements}


\sapling{
\vspace{-2ex}
\introsection
\extralabel{concretesaplingnotecommit}{\lsubsubsubsection{Windowed Pedersen commitments}{concretewindowedcommit}}

\crossref{concretepedersenhash} defines a \xPedersenHash construction.
We construct \definingquotedterm{windowed} \defining{\xPedersenCommitments} by reusing that construction,
and adding a randomized point on the \jubjubCurve (see \crossref{jubjub}):

\begin{formulae}
  \item $\WindowedPedersenCommit{r}(s) :=
           \PedersenHashToPoint\Of{\ascii{Zcash\_PH}, s}\, + \scalarmult{r}{\FindGroupJHash\Of{\ascii{Zcash\_PH}, \ascii{r}}}$
\end{formulae}

See \crossref{cctwindowedcommit} for rationale and efficient circuit implementation
of this function.

The \noteCommitmentScheme $\NoteCommitAlg{Sapling}$ specified in \crossref{abstractcommit} is
instantiated as follows using $\WindowedPedersenCommitAlg$:

\begin{formulae}
  \item $\NoteCommit{Sapling}{\NoteCommitRand}(\DiversifiedTransmitBaseRepr, \DiversifiedTransmitPublicRepr, \Value) :=
           \WindowedPedersenCommit{\NoteCommitRand}\left(\ones{6} \bconcat \ItoLEBSPOf{64}{\Value} \bconcat
             \DiversifiedTransmitBaseRepr \bconcat \DiversifiedTransmitPublicRepr\right)$
  \item $\NoteCommitGenTrapdoor{Sapling}()$ generates the uniform distribution on $\GF{\ParamJ{r}}$.
\end{formulae}

\vspace{-1ex}
\begin{securityrequirements}
  \item $\WindowedPedersenCommitAlg$, and hence $\NoteCommitAlg{Sapling}$, must be
        computationally \binding and at least computationally \hiding \commitmentSchemes.
\end{securityrequirements}

\vspace{-1ex}
(They are in fact unconditionally \hiding \commitmentSchemes.)

\vspace{1ex}
\begin{pnotes}
  \item $\MerkleCRH{Sapling}$ is also defined in terms of $\PedersenHashToPoint$
        (see \crossref{saplingmerklecrh}). The prefix $\ones{6}$ distinguishes the use of
        $\WindowedPedersenCommitAlg$ in
        $\NoteCommitAlg{Sapling}$ from the layer prefix used in $\MerkleCRH{Sapling}$.
        That layer prefix is a $6$-bit \littleEndian encoding of an integer
        in the range $\range{0}{\MerkleDepth{Sapling}-1}$; because $\MerkleDepth{Sapling} < 64$,
        it cannot collide with $\ones{6}$.
  \item The arguments to $\NoteCommitAlg{Sapling}$ are in a different order to their encodings
        in $\WindowedPedersenCommit{}$. There is no particularly good reason for this.
\end{pnotes}

\introlist
\vspace{-2ex}
\theoremlabel{thmuncommittedsapling}
\begin{theorem}[$\Uncommitted{Sapling}$ is not in the range of $\,\NoteCommitAlg{Sapling}$]\end{theorem}

\begin{proof}
$\Uncommitted{Sapling}$ is defined as $\ItoLEBSPOf{\MerkleHashLength{Sapling}}{1}$.
By injectivity of $\ItoLEBSP{\MerkleHashLength{Sapling}}$ and definitions of
$\ExtractJ$, $\WindowedPedersenCommitAlg$, and $\NoteCommitAlg{Sapling}$,
$\ItoLEBSPOf{\MerkleHashLength{Sapling}}{1}$ can be in the range of $\NoteCommitAlg{Sapling}$
only if there exist $\NoteCommitRand \typecolon \NoteCommitTrapdoor{Sapling}$,
$D \typecolon \smash{\byteseq{8}}$, and $M \typecolon \smash{\bitseq{\PosInt}}$
such that $\Selectu\Of{\WindowedPedersenCommit{\NoteCommitRand}(D, M)}$ $= 1$.
The latter can only be the \affineCtEdwards $u$-coordinate of a point in $\strut\GroupJ$.
We show that there are no points in $\GroupJ$ with \affineCtEdwards $u$-coordinate $1$.
Suppose for a contradiction that $(u, \varv) \in \GroupJ$ for $u = 1$ and some
$\varv \typecolon \GF{\ParamS{r}}$. By writing the curve equation as
$\varv^2 = (1 - \ParamJ{a} \smult u^2) / (1 - \ParamJ{d} \smult u^2)$, and noting that
$1 - \ParamJ{d} \smult u^2 \neq 0$ because $\ParamJ{d}$ is nonsquare,
we have $\varv^2 = (1 - \ParamJ{a}) / (1 - \ParamJ{d})$.
The right-hand-side is a nonsquare in $\GF{\ParamS{r}}$ (for the \jubjubCurve parameters),
so there are no solutions for $\varv$ (contradiction).
\end{proof}
} %sapling


\sapling{
\extralabel{concretevaluecommit}{\lsubsubsubsection{Homomorphic Pedersen commitments (\SaplingAndOrchardText)}{concretehomomorphiccommit}}

\vspace{-1ex}
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{ and \crossref{orchardbalance}}.

Useful background is given in \crossref{spendsandoutputs}\nufive{ and \crossref{actions}}.

\introlist
\defining{In order to support this property, we also define \homomorphicPedersenCommitments for \Sapling:}

\begin{formulae}
  \item $\HomomorphicPedersenCommit{Sapling}{\ValueCommitRand}(D, \Value) :=
           \scalarmult{\Value}{\FindGroupJHash\Of{D, \ascii{v}}} + \scalarmult{\ValueCommitRand}{\FindGroupJHash\Of{D, \ascii{r}}}$
  \item $\ValueCommitGenTrapdoor{Sapling}()$ generates the uniform distribution on $\GF{\ParamJ{r}}$.
\end{formulae}

\vspace{-1ex}
See \crossref{ccthomomorphiccommit} for rationale and efficient circuit implementation
of this function.

\nufive{
\vspace{0.5ex}
\introlist
We also define \homomorphicPedersenCommitments for \Orchard:

\begin{formulae}
  \item $\HomomorphicPedersenCommit{Orchard}{\ValueCommitRand}(D, \Value) :=
           \scalarmult{\Value}{\GroupPHash\Of{D, \ascii{v}}} + \scalarmult{\ValueCommitRand}{\GroupPHash\Of{D, \ascii{r}}}$
  \item $\ValueCommitGenTrapdoor{Orchard}()$ generates the uniform distribution on $\GF{\ParamP{r}}$.
\end{formulae}
} %nufive

\introlist
Define:

\begin{tabular}{@{\hskip 1.5em}r@{\;}l}
             $\ValueCommitValueBase{Sapling}$ &$:= \FindGroupJHash\Of{\ascii{Zcash\_cv}, \ascii{v}}$ \\
             $\ValueCommitRandBase{Sapling}$  &$:= \FindGroupJHash\Of{\ascii{Zcash\_cv}, \ascii{r}}$ \notbeforenufive{\\
  \setnufive $\ValueCommitValueBase{Orchard}$ &$:= \setnufive \GroupPHash\Of{\ascii{z.cash:Orchard-cv}, \ascii{v}}$ \\
  \setnufive $\ValueCommitRandBase{Orchard}$  &$:= \setnufive \GroupPHash\Of{\ascii{z.cash:Orchard-cv}, \ascii{r}}$
} %notbeforenufive
\end{tabular}

\introlist
The \commitmentScheme $\ValueCommitAlg{Sapling}$ specified in \crossref{abstractcommit} is
instantiated as follows using $\HomomorphicPedersenCommitAlg{Sapling}$ on the \jubjubCurve:
\begin{formulae}
  \item $\ValueCommitAlg{\ValueCommitRand}(\Value) :=
           \HomomorphicPedersenCommit{Sapling}{\ValueCommitRand}(\ascii{Zcash\_cv}, \Value)$.
\end{formulae}
\vspace{-1ex}
which is equivalent to:
\begin{formulae}
  \item $\ValueCommit{Sapling}{\ValueCommitRand}(\Value) := \scalarmult{\Value}{\ValueCommitValueBase{Sapling}}
                                                          + \scalarmult{\ValueCommitRand}{\ValueCommitRandBase{Sapling}}$.
\end{formulae}

\nufive{
\introlist
The \commitmentScheme $\ValueCommitAlg{Orchard}$ specified in \crossref{abstractcommit} is
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)$.
\end{formulae}
\vspace{-1ex}
which is equivalent to:
\begin{formulae}
  \item $\ValueCommit{Orchard}{\ValueCommitRand}(\Value) := \scalarmult{\Value}{\ValueCommitValueBase{Orchard}}
                                                          + \scalarmult{\ValueCommitRand}{\ValueCommitRandBase{Orchard}}$.
\end{formulae}
} %nufive

\begin{securityrequirements}
  \item $\HomomorphicPedersenCommitAlg{Sapling}$\nufive{ and $\HomomorphicPedersenCommitAlg{Orchard}$}
        must be\notnufive{ a} computationally \binding and at least computationally \hiding
        \notnufive{\commitmentScheme}\notbeforenufive{\commitmentSchemes}, for a given personalization input $D$.
  \item $\ValueCommitAlg{Sapling}$\nufive{ and $\ValueCommitAlg{Orchard}$} must be\notnufive{ a} computationally
        \binding and at least computationally \hiding \notnufive{\commitmentScheme}\notbeforenufive{\commitmentSchemes}.
\end{securityrequirements}

(They are in fact unconditionally \hiding \commitmentSchemes.)

\vspace{-1ex}
\nnote{The output of $\HomomorphicPedersenCommit{Sapling}{}$ may (with negligible probability for a randomly
chosen \commitmentTrapdoor) be the zero point of the curve, $\ZeroJ$. This would be rejected by consensus if it appeared as
the $\cv$ field of a \spendDescription (\crossref{spenddesc}) or \outputDescription (\crossref{outputdesc}).
An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the \commitmentTrapdoor
until the resulting commitment is not $\ZeroJ$.}
} %sapling


\nufive{
\introsection
\extralabel{concreteorchardnotecommit}{\lsubsubsubsection{Sinsemilla commitments}{concretesinsemillacommit}}

\vspace{-1ex}
Let $\BaseLength{Orchard}$ be as defined in \crossref{constants}.

\vspace{-0.25ex}
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$ be as defined in \crossref{concretesinsemillahash}.

\vspace{1ex}
We construct \defining{\xSinsemillaCommitments} by reusing the \xSinsemillaHash construction,
and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta}):

\begin{formulae}
  \item $\SinsemillaCommit{r}(D, M) := \begin{cases}
           M' + \scalarmult{r}{\GroupPHash\Of{D \bconcat \ascii{-r}, \ascii{}}}\,,&\caseif M' \neq \bot \\
           \bot,&\caseotherwise
        \end{cases}$ \\
        where $M' = \SinsemillaHashToPoint(D \bconcat \ascii{-M}, M)$.
  \item $\SinsemillaShortCommit{r}(D, M) :=
           \ExtractPbot\big(\SinsemillaCommit{r}(D, M)\kern-0.1em\big)$.
\end{formulae}

\vspace{-1ex}
See \cite[section 3.7.1.2]{Zcash-Orchard} for rationale and efficient circuit
implementation of this function.

\vspace{1ex}
The probability of $\SinsemillaHashToPoint$ returning $\bot$ is insignificant
(and would yield a nontrivial discrete logarithm relation).
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$.

Provided that $\SinsemillaHashToPoint$ does not return $\bot$, $\SinsemillaCommitAlg$ is
perfectly \hiding because the output distribution is perfectly indistinguishable from a
random point in $\GroupP$, given that $r$ is a uniformly random scalar on $[0, q)$.
It follows that $\SinsemillaShortCommitAlg$ is also perfectly \hiding under the same
condition, since \hiding cannot be affected by applying any fixed function to the
\emph{output} of $\SinsemillaCommitAlg$.

\vspace{0.5ex}
The \noteCommitmentScheme $\NoteCommitAlg{Orchard}$ specified in \crossref{abstractcommit} is
instantiated as follows using $\SinsemillaCommitAlg$:

\begin{formulae}
  \item $\NoteCommit{Orchard}{\NoteCommitRand}(\DiversifiedTransmitBaseRepr, \DiversifiedTransmitPublicRepr, \Value,
                                               \NoteUniqueRand, \NoteNullifierRand) :=$
  \item \tab $\SinsemillaCommit{\NoteCommitRand}\!\big(\ascii{z.cash:Orchard-NoteCommit},$
        \vspace{-1ex}
  \item \hspace{10.55em} $\DiversifiedTransmitBaseRepr \bconcat
                          \DiversifiedTransmitPublicRepr \bconcat
                          \ItoLEBSPOf{64}{\Value} \bconcat
                          \ItoLEBSPOf{\BaseLength{Orchard}}{\NoteUniqueRand} \bconcat
                          \ItoLEBSPOf{\BaseLength{Orchard}}{\NoteNullifierRand}\kern-0.25em\big)$
  \item $\NoteCommitGenTrapdoor{Orchard}()$ generates the uniform distribution on $\GF{\ParamP{r}}$.
\end{formulae}

\vspace{-2ex}
\pnote{The arguments to $\NoteCommitAlg{Orchard}$ are the same order as their encodings in
the input to $\SinsemillaCommit{}$; this is different to $\NoteCommitAlg{Sapling}$.}

\vspace{1ex}
The \commitmentScheme $\CommitIvkAlg$ specified in \crossref{abstractcommit} is
instantiated as follows using $\SinsemillaShortCommitAlg$:

\begin{formulae}
  \item $\CommitIvk{\CommitIvkRand}(\AuthSignPublic, \NullifierKey) :=
           \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)$
  \item $\CommitIvkGenTrapdoor()$ generates the uniform distribution on $\GF{\ParamP{r}}$.
\end{formulae}

\begin{securityrequirements}
  \item $\SinsemillaCommitAlg$ and $\SinsemillaShortCommitAlg$, and hence
        $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$, must be computationally \binding
        and at least computationally \hiding \commitmentSchemes. They are in fact unconditionally
        \hiding \commitmentSchemes provided that no $\bot$ output is observed.
\end{securityrequirements}

\vspace{-2ex}
\introlist
\theoremlabel{thmuncommittedorchard}
\begin{theorem}[$\Uncommitted{Orchard}$ is not in the range of $\,\NoteCommitAlg{Orchard}$]\end{theorem}

\begin{proof}
$\Uncommitted{Orchard}$ is defined as $2$. By the definitions of $\ExtractPbot$,
$\SinsemillaShortCommitAlg$, and $\NoteCommitAlg{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
$\ExtractPbot\big(\SinsemillaCommit{\NoteCommitRand}(D, M)\kern-0.1em\big) = 2$.
$\ExtractPbot\big(\SinsemillaCommit{\NoteCommitRand}(D, M)\kern-0.1em\big)$ can
only be $\bot$ or $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$
is not square in $\GF{\ParamP{q}}$.
\end{proof}

\begin{nnotes}
  \item Although the given theorem is correct for the definition of
        $\NoteCommitAlg{Orchard}$ in this specification, the implementation in the
        \actionCircuit constrains the result to an unspecified set of values when an
        input results in an exceptional case for any incomplete addition. If this
        occurs then it yields a nontrivial discrete logarithm relation for the
        \pallasCurve, as proven in \theoremref{thmsinsemillaex}. We can therefore
        assume that it is infeasible to find such inputs with nonnegligible probability.
  \item There are also no points in $\GroupP$ with \affineSW $x$-coordinate
        $0 \pmod{\ParamP{q}}$, as shown in a note at \crossref{concreteextractorpallas}.
        We do not choose $\Uncommitted{Orchard} = 0$ because $\MerkleCRH{Orchard}$
        returns $0$ in exceptional cases. Although the \merkleHashes of \merkleLeafNodes
        are separated from the \merkleHashes at other \merkleLayers by the $\layerInput$
        input to $\MerkleCRH{Orchard}$, it would arguably be confusing to rely on that.
\end{nnotes}
} %nufive


\introsection
\lsubsubsection{Represented Groups and Pairings}{concretepairing}

\lsubsubsubsection{\BNPairingText}{bnpairing}

The \representedPairing{} \defining{\BNPairing} is defined in this section.

Let $\ParamG{q} := 21888242871839275222246405745257275088696311157297823662689037894645226208583$.

Let $\ParamG{r} := 21888242871839275222246405745257275088548364400416034343698204186575808495617$.

Let $\ParamG{b} := 3$.

(\hairspace $\ParamG{q}$ and $\ParamG{r}$ are prime.)

Let $\SubgroupG{1}$ be the group (of order $\ParamG{r}$) of rational points on a
Barreto--Naehrig (\cite{BN2005}) curve $\CurveG{1}$ over $\GF{\ParamG{q}}$ with equation $y^2 = x^3 + \ParamG{b}$.
This curve has embedding degree 12 with respect to $\ParamG{r}$.

Let $\SubgroupG{2}$ be the subgroup of order $\ParamG{r}$ in the sextic twist $\CurveG{2}$ of
$\CurveG{1}$ over $\GF{\ParamGexp{q}{2}}$ with equation $y^2 = x^3 + \frac{\ParamG{b}}{\xi}$,
where $\xi \typecolon \GF{\ParamGexp{q}{2}}$.

We represent elements of $\GF{\ParamGexp{q}{2}}$ as polynomials
$a_1 \mult t + a_0 \typecolon \GF{\ParamG{q}}[t]$, modulo the irreducible polynomial
$t^2 + 1$; in this representation, $\xi$ is given by $t + 9$.

Let $\SubgroupG{T}$ be the subgroup of $\ParamGexp{r}{\mathrm{th}}$ roots of unity in
$\GFstar{\ParamGexp{q}{12}}$, with multiplicative identity $\OneG$.

\vspace{-1ex}
Let $\PairingG$ be the optimal ate pairing (see \cite{Vercauter2009} and \cite[section 2]{AKLGL2010}) of type
$\SubgroupG{1} \times \SubgroupG{2} \rightarrow \SubgroupG{T}$.

For $i \typecolon \range{1}{2}$, let $\ZeroG{i}$ be the point at infinity
(which is the additive identity) in $\SubgroupG{i}$, and let
$\SubgroupGstar{i} := \SubgroupG{i} \setminus \setof{\ZeroG{i}}$.

Let $\GenG{1} \typecolon \SubgroupGstar{1} := (1, 2)$.

\vspace{-1ex}
\begin{tabular}{@{}l@{}r@{}l@{}}
Let $\GenG{2} \typecolon \SubgroupGstar{2} :=\;$
% are these the right way round?
&$(11559732032986387107991004021392285783925812861821192530917403151452391805634$ & $\,\mult\, t\;+$ \\
&$ 10857046999023057135944570762232829481370756359578518086990519993285655852781$ & $,             $ \\
&$  4082367875863433681332203403145435568316851327593401208105741076214120093531$ & $\,\mult\, t\;+$ \\
&$  8495653923123431417604973247489272438418190587263600148770280649306958101930$ & $).            $
\end{tabular}

$\GenG{1}$ and $\GenG{2}$ are generators of $\SubgroupG{1}$ and $\SubgroupG{2}$ respectively.

\newsavebox{\gonebox}
\begin{lrbox}{\gonebox}
\begin{bytefield}[bitwidth=0.045em]{264}
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$1$} &
    \sbitbox{80}{$1$-bit $\tilde{y}$} &
    \sbitbox{256}{$256$-bit $\ItoBEBSP{256}(x)$}
\end{bytefield}
\end{lrbox}

\newsavebox{\gtwobox}
\begin{lrbox}{\gtwobox}
\begin{bytefield}[bitwidth=0.045em]{520}
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$1$} &
    \sbitbox{20}{$0$} &
    \sbitbox{20}{$1$} &
    \sbitbox{80}{$1$-bit $\tilde{y}$} &
    \sbitbox{512}{$512$-bit $\ItoBEBSP{512}(x)$}
\end{bytefield}
\end{lrbox}

\introlist
Define $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow
\bitseq{\ell}$ as in \crossref{endian}.

\introlist
\vspace{2ex}
For a point $P \typecolon \SubgroupGstar{1} = (\xP, \yP)$:
\vspace{1ex}

\begin{itemize}
  \item The field elements $\xP$ and $\yP \typecolon \GF{q}$ are represented as
        integers $x$ and $y \typecolon \range{0}{q\!-\!1}$.
  \item Let $\tilde{y} = y \bmod 2$.
  \item $P$ is encoded as $\Justthebox{\gonebox}$.
\end{itemize}

\introlist
\vspace{1ex}
For a point $P \typecolon \SubgroupGstar{2} = (\xP, \yP)$:

\vspace{1ex}
\begin{itemize}
  \item Define $\FEtoIP \typecolon \GF{\ParamG{q}}[t] / (t^2 + 1) \rightarrow
          \range{0}{\ParamGexp{q}{2}\!-\!1}$ such that
        $\FEtoIP(a_{w,1} \mult t + a_{w,0}) = a_{w,1} \mult q + a_{w,0}$.
  \item Let $x = \FEtoIP(\xP)$, $y = \FEtoIP(\yP)$, and $y' = \FEtoIP(-\yP)$.
  \item Let $\tilde{y} = \begin{cases}
          1, &\caseif y > y' \\
          0, &\caseotherwise.
        \end{cases}$
  \item $P$ is encoded as $\Justthebox{\gtwobox}$.
\end{itemize}

\begin{nnotes}
  \item Only the $\ParamG{r}$-order subgroups $\SubgroupG{2, T}$ are used in the
        protocol, not their containing groups $\GroupG{2, T}$. Points in
        $\SubgroupGstar{2}$ are \emph{always} checked to be of order $\ParamG{r}$ when
        decoding from external representation. (The group of rational points $\GroupG{1}$
        on $\CurveG{1}/\GF{\ParamG{q}}$ is of order $\ParamG{r}$ so no subgroup checks are
        needed in that case, and elements of $\SubgroupG{T}$ are never represented externally.)
        The $\subgroupr$ superscripts on $\SubgroupG{1, 2, T}$ are used for consistency with
        notation elsewhere in this specification.
  \item The points at infinity $\ZeroG{1, 2}$ never occur in proofs and
        have no defined encodings in this protocol.
  \item A rational point $P \neq \ZeroG{2}$ on the curve $\CurveG{2}$ can be
        verified to be of order $\ParamG{r}$, and therefore in $\SubgroupGstar{2}$,
        by checking that $\ParamG{r} \mult P = \ZeroG{2}$.
  \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding
        of most other integers in this protocol.
        The encodings for $\SubgroupGstar{1, 2}$ are consistent with the
        definition of $\ECtoOSP{}$ for compressed curve points in
        \cite[section 5.5.6.2]{IEEE2004}. The LSB compressed form
        (i.e.\ $\ECtoOSPXL$) is used for points in $\SubgroupGstar{1}$,
        and the SORT compressed form (i.e.\ $\ECtoOSPXS$) for points in
        $\SubgroupGstar{2}$.
  \item Testing $y > y'$ for the compression of $\SubgroupGstar{2}$ points is equivalent
        to testing whether $(a_{y,1}, a_{y,0}) > (a_{-y,1}, a_{-y,0})$ in lexicographic order.
  \item Algorithms for decompressing points from the above encodings are
        given in \cite[Appendix A.12.8]{IEEE2000} for $\SubgroupGstar{1}$, and
        \cite[Appendix A.12.11]{IEEE2004} for $\SubgroupGstar{2}$.
\end{nnotes}

\vspace{2ex}
When computing square roots in $\GF{\ParamG{q}}$ or $\GF{\ParamGexp{q}{2}}$ in
order to decompress a point encoding, the implementation \MUSTNOT assume that
the square root exists, or that the encoding represents a point on the curve.


\newsavebox{\sonebox}
\begin{lrbox}{\sonebox}
\setsapling
\begin{bytefield}[bitwidth=0.045em]{384}
    \sbitbox{20}{$1$} &
    \sbitbox{20}{$0$} &
    \sbitbox{80}{$1$-bit $\tilde{y}$} &
    \sbitbox{381}{$381$-bit $\ItoBEBSP{381}(x)$}
\end{bytefield}
\end{lrbox}

\newsavebox{\stwobox}
\begin{lrbox}{\stwobox}
\setsapling
\begin{bytefield}[bitwidth=0.045em]{768}
    \sbitbox{20}{$1$} &
    \sbitbox{20}{$0$} &
    \sbitbox{80}{$1$-bit $\tilde{y}$} &
    \sbitbox{381}{$381$-bit $\ItoBEBSP{381}(x_1)$} &
    \sbitbox{384}{$384$-bit $\ItoBEBSP{384}(x_2)$}
\end{bytefield}
\end{lrbox}

\sapling{
\intropart
\lsubsubsubsection{\BLSPairingText}{blspairing}

The \representedPairing{} \defining{\BLSPairing} is defined in this section. Parameters are taken from
\cite{Bowe2017}.

\introlist
Let $\ParamS{q} :=\;$\scalebox{0.805}[1]{$4002409555221667393417789825735904156556882819939007885332058136124031650490837864442687629129015664037894272559787$.}

Let $\ParamS{r} := 52435875175126190479447740508185965837690552500527637822603658699938581184513$.

Let $\ParamS{u} := -15132376222941642752$.

Let $\ParamS{b} := 4$.

(\hairspace $\ParamS{q}$ and $\ParamS{r}$ are prime.)

Let $\SubgroupS{1}$ be the subgroup of order $\ParamS{r}$ of the group of rational points
on a Barreto--Lynn--Scott (\cite{BLS2002}) curve $\CurveS{1}$ over $\GF{\ParamS{q}}$ with
equation $y^2 = x^3 + \ParamS{b}$. This curve has embedding degree 12 with respect to $\ParamS{r}$.

Let $\SubgroupS{2}$ be the subgroup of order $\ParamS{r}$ in the sextic twist $\CurveS{2}$ of
$\CurveS{1}$ over $\GF{\ParamSexp{q}{2}}$ with equation $y^2 = x^3 + 4(i + 1)$, where
$i \typecolon \GF{\ParamSexp{q}{2}}$.

We represent elements of $\GF{\ParamSexp{q}{2}}$ as polynomials
$a_1 \mult t + a_0 \typecolon \GF{\ParamS{q}}[t]$, modulo the irreducible polynomial
$t^2 + 1$; in this representation, $i$ is given by $t$.

Let $\SubgroupS{T}$ be the subgroup of $\ParamSexp{r}{\mathrm{th}}$ roots of unity in
$\GFstar{\ParamSexp{q}{12}}$, with multiplicative identity $\OneS$.

\vspace{-1ex}
Let $\PairingS$ be the optimal ate pairing of type
$\SubgroupS{1} \times \SubgroupS{2} \rightarrow \SubgroupS{T}$.

For $i \typecolon \range{1}{2}$, let $\ZeroS{i}$ be the point at infinity in $\SubgroupS{i}$,
and let $\SubgroupSstar{i} := \SubgroupS{i} \setminus \setof{\ZeroS{i}}$.

\introlist
Let $\GenS{1} \typecolon \SubgroupSstar{1} :=$
\vspace{-1ex}

\begin{tabular}{@{\hspace{1em}}r@{}l@{}}
$($\scalebox{0.82}[1]{$3685416753713387016781088315183077757961620795782546409894578378688607592378376318836054947676345821548104185464507$} & $,             $ \\
   \scalebox{0.82}[1]{$1339506544944476473020471379941921221584933875938349620426543736416511423956333506472724655353366534992391756441569$} & $)$.
\end{tabular}

Let $\GenS{2} \typecolon \SubgroupSstar{2} :=$
\vspace{-1ex}

\begin{tabular}{@{\hspace{1em}}r@{}l@{}}
$($\scalebox{0.82}[1]{$3059144344244213709971259814753781636986470325476647558659373206291635324768958432433509563104347017837885763365758$} & $\,\mult\, t\;+$ \\
   \scalebox{0.82}[1]{$ 352701069587466618187139116011060144890029952792775240219908644239793785735715026873347600343865175952761926303160$} & $,             $ \\
   \scalebox{0.82}[1]{$ 927553665492332455747201965776037880757740193453592970025027978793976877002675564980949289727957565575433344219582$} & $\,\mult\, t\;+$ \\
   \scalebox{0.82}[1]{$1985150602287291935568054521177171638300868978215655730859378665066344726373823718423869104263333984641494340347905$} & $).            $
\end{tabular}

$\GenS{1}$ and $\GenS{2}$ are generators of $\SubgroupS{1}$ and $\SubgroupS{2}$ respectively.

Define $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow
\bitseq{\ell}$ as in \crossref{endian}.

\introlist
For a point $P \typecolon \SubgroupSstar{1} = (\xP, \yP)$:

\begin{itemize}
  \item The field elements $\xP$ and $\yP \typecolon \GF{\ParamS{q}}$ are represented as
        integers $x$ and $y \typecolon \range{0}{\ParamS{q}\!-\!1}$.
  \item Let $\tilde{y} = \begin{cases}
          1, &\caseif y > \ParamS{q}-y \\
          0, &\caseotherwise.
        \end{cases}$
  \item $P$ is encoded as $\Justthebox{\sonebox}$.
\end{itemize}

\introlist
For a point $P \typecolon \SubgroupSstar{2} = (\xP, \yP)$:

\begin{itemize}
  \item Define $\FEtoIPP \typecolon \GF{\ParamS{q}}[t] / (t^2 + 1) \rightarrow
                  \typeexp{\range{0}{\ParamS{q}\!-\!1}}{2}$ such that
        $\FEtoIPP(a_{w,1} \mult t + a_{w,0}) = [a_{w,1}, a_{w,0}]$.
  \item Let $x = \FEtoIPP(\xP)$, $y = \FEtoIPP(\yP)$, and $y' = \FEtoIPP(-\yP)$.
  \item Let $\tilde{y} = \begin{cases}
          1, &\caseif y > y' \text{ lexicographically} \\
          0, &\caseotherwise.
        \end{cases}$
  \item $P$ is encoded as $\Justthebox{\stwobox}$.
\end{itemize}

\begin{nnotes}
  \item Only the $\ParamS{r}$-order subgroups $\SubgroupS{1, 2, T}$ are used in the
        protocol, not their containing groups $\GroupS{1, 2, T}$. Points in
        $\SubgroupSstar{1, 2}$ are \emph{always} checked to be of order $\ParamS{r}$ when
        decoding from external representation. (Elements of $\SubgroupS{T}$ are
        never represented externally.)
        The $\subgroupr$ superscripts on $\SubgroupS{1, 2, T}$ are used for consistency with
        notation elsewhere in this specification.
  \item The points at infinity $\ZeroS{1, 2}$ never occur in proofs and
        have no defined encodings in this protocol.
  \item In contrast to the corresponding \BNPairing curve, $\CurveS{1}$ over $\GF{\ParamS{q}}$
        is \emph{not} a \primeOrderCurve.
  \item A rational point $P \neq \ZeroS{i}$ on the curve $\CurveS{i}$ for $i \in \setof{1, 2}$
        can be verified to be of order $\ParamS{r}$, and therefore in $\SubgroupSstar{i}$,
        by checking that $\ParamS{r} \mult P = \ZeroS{i}$.
  \item The use of \bigEndian order by $\ItoBEBSP{}$ is different from the encoding
        of most other integers in this protocol.
  \item The encodings for $\SubgroupSstar{1, 2}$ are specific to \Zcash.
  \item Algorithms for decompressing points from the encodings of
        $\SubgroupSstar{1, 2}$ are defined analogously to those for
        $\SubgroupGstar{1, 2}$ in \crossref{bnpairing}, taking into account that
        the SORT compressed form (not the LSB compressed form) is used
        for $\SubgroupSstar{1}$.
\end{nnotes}

When computing square roots in $\GF{\ParamS{q}}$ or $\GF{\ParamSexp{q}{2}}$
in order to decompress a point encoding, the implementation \MUSTNOT assume
that the square root exists, or that the encoding represents a point on the
curve.
}

\sapling{
\lsubsubsubsection{\JubjubText}{jubjub}

\vspace{-2ex}
\hfill\begin{minipage}{0.52\linewidth}
\small
\begin{poetry}
  \item \emph{``You boil it in sawdust: you salt it in glue:}
  \item \tab\emph{You condense it with locusts and tape:}
  \item \emph{\hphantom{``}Still keeping one principal object in view---}
  \item \tab\emph{To preserve its symmetrical shape.''}
        \vspace{0.5ex}
  \item \hfill--- Lewis Carroll, ``The Hunting of the Snark'' \cite{Carroll1876}\!\!
\end{poetry}
\end{minipage}
\vspace{2ex}

\Sapling uses an elliptic curve, \defining{\Jubjub}, designed to be efficiently implementable in
\zkSNARKCircuits. The \representedGroup $\GroupJ$ of points on this curve is defined in this
section.

A \defining{\completeTwistedEdwardsEllipticCurve}, as defined in \cite[section 4.3.4]{BL2017},
is an elliptic curve $E$ over a non-binary field $\GF{q}$, parameterized by distinct
$a, d \typecolon \GF{q} \setminus \setof{0}$ such that $a$ is square and $d$ is nonsquare,
with equation $E : a \smult u^2 + \varv^2 = 1 + d \smult u^2 \smult \varv^2$.
We use the abbreviation ``\xCtEdwards'' to refer to \completeTwistedEdwardsEllipticCurves
and coordinates.

Let $\ParamJ{q} := \ParamS{r}$, as defined in \crossref{blspairing}.

Let $\ParamJ{r} := 6554484396890773809930967563523245729705921265872317281365359162392183254199$.

(\hairspace $\ParamJ{q}$ and $\ParamJ{r}$ are prime.)

Let $\ParamJ{h} := 8$.

Let $\ParamJ{a} := -1$.

Let $\ParamJ{d} := -10240/10241 \pmod{\ParamJ{q}}$.

Let $\GroupJ$ be the group of points $(u, \varv)$ on a \ctEdwardsCurve $\CurveJ$ over $\GF{\ParamJ{q}}$
with equation $\ParamJ{a} \smult u^2 + \varv^2 = 1 + \ParamJ{d} \smult u^2 \smult \varv^2$.
The zero point with coordinates $(0, 1)$ is denoted $\ZeroJ$.
$\GroupJ$ has order $\ParamJ{h} \smult \ParamJ{r}$.

Let $\ellJ := 256$.

Define the notation $\optsqrt{\,\paramdot\,}$ as in \crossref{notation}.

\introlist
Define $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$
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\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}
Define $\abstJ \typecolon \ReprJ \rightarrow \maybe{\GroupJ}$ such that
$\abstJ\Of{P\Repr}$ is computed as follows:
\begin{formulae}
  \item let ${\varv\Repr} \typecolon \bitseq{255}$ be the first $255$ bits of $P\Repr$ and let $\tilde{u} \typecolon \bit$ be the last bit.
  \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}}$.)
  \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}

\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$.
This differs from the specification above:
\begin{itemize}
  \item Previously, $\abstJ\Of{\ItoLEBSP{256}\big(2^{255} + 1\big)\!}$ and $\abstJ\Of{\ItoLEBSP{256}\big(2^{255} + \ParamJ{q} - 1\big)\!}$ were defined as $\bot$.
  \item In the current specification, $\abstJ\Of{\ItoLEBSP{256}\big(2^{255} + 1\big)\!} = \abstJ\big(\ItoLEBSPOf{256}{1}\kern-0.27em\big) = (0, 1) = \ZeroJ$,
        and also $\abstJ\Of{\ItoLEBSP{256}\big(2^{255} + \ParamJ{q} - 1\big)\!} = \abstJ\big(\ItoLEBSPOf{256}{\ParamJ{q} - 1}\kern-0.27em\big) = (0, -1)$.
\end{itemize}
}

Define $\SubgroupJ$ as the order-$\ParamJ{r}$ subgroup of $\GroupJ$. Note that this includes $\ZeroJ$.
For the set of points of order $\ParamJ{r}$ (which excludes $\ZeroJ$), we write $\SubgroupJstar$.

Define $\SubgroupReprJ := \bigsetof{\reprJ(P) \typecolon \ReprJ \suchthat P \in \SubgroupJ}$.

\begin{nnotes}
  \item The \defining{\ctEdwardsCompressedEncoding} used here is
        consistent with that used in EdDSA \cite{BJLSY2015} for \validatingKeys and
        the $\EdDSASigR{}$ element of a signature.
  \item \cite[``Encoding and parsing curve points'']{BJLSY2015} gives algorithms
        for decompressing points from the encoding of $\GroupJ$.
  \item \cite[``Encoding and parsing integers'']{BJLSY2015} describes several possibilities
        for parsing of integers; the specification of $\abstJ$ above requires ``strict''
        parsing.
\end{nnotes}

When computing square roots in $\GF{\ParamJ{q}}$ in order to decompress a point encoding,
the implementation \MUSTNOT assume that the square root exists, or that the encoding
represents a point on the curve.

Note that algorithms elsewhere in this specification that use \Jubjub may impose
other conditions on points, for example that they have order at least $\ParamJ{r}$.
}


\sapling{
\lsubsubsubsection{Coordinate Extractor for \JubjubText}{concreteextractorjubjub}

\vspace{-2ex}
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) := \ItoLEBSP{\MerkleHashLength{Sapling}}\big(\Selectu\Of{P}\kern-0.1em\big)$.
\end{formulae}

\vspace{-2ex}
\facts{The point $(0, 1) = \ZeroJ$, and the point $(0, -1)$ has order $2$ in $\GroupJ$.
$\SubgroupJ$ is of odd-prime order.}

% <https://github.com/zcash/zcash/issues/2234#issuecomment-333360977>
\vspace{-2ex}
\introlist
\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$.
(If $\varv = 0$ then $a \mult u^2 = 1$, and so applying the doubling formula
gives $\scalarmult{2}{P} = (0, -1)$, then $\scalarmult{4}{P} = (0, 1) = \ZeroJ$;
contradiction since then $P$ would not be of odd-prime order.)
Therefore, $-\varv \neq \varv$.
Now suppose $(u, -\varv) = Q$ is a point in $\SubgroupJ$. Then by applying the
doubling formula we have $\scalarmult{2}{Q} = -\scalarmult{2}{P}$.
But also $\scalarmult{2}{(-P)} = -\scalarmult{2}{P}$. Therefore either
$Q = -P$ (then $\Selectv\Of{Q} = \Selectv\Of{-P}$\,; contradiction since
$-\varv \neq \varv$), or doubling is not injective on $\SubgroupJ$ (contradiction
since $\SubgroupJ$ is of odd order \cite{KvE2013}).
\end{proof}

\vspace{-3ex}
\introlist
\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
potentially exceptional case $1 - d \smult u^2 = 0$ does not occur for a
\ctEdwardsCurve, we see that for a given $u$ there can be at
most two possible solutions for $\varv$, and that if there are two solutions
they can be written as $\varv$ and $-\varv$. In that case by the Lemma, at
most one of $(u, \varv)$ and $(u, -\varv)$ is in $\SubgroupJ$. Therefore,
$\Selectu$ is injective on points in $\SubgroupJ$.
\end{proof}

\vspace{-1ex}
Since $\ItoLEBSP{\MerkleHashLength{Sapling}}$ is injective, it follows that
$\ExtractJ$ is injective on $\SubgroupJ$.
}


\sapling{
\introlist
\vspace{-1ex}
\lsubsubsubsection{Group Hash into \JubjubText}{concretegrouphashjubjub}

\vspace{-1ex}
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}.

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.

\introlist
The hash $\GroupJHash{\URS}(D, M) \typecolon \maybe{\SubgroupJstar}$ is calculated as follows:

\begin{algorithm}
  \item let $\HashOutput = \BlakeTwos{256}(D,\, \URS \bconcat\, M)$
  \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$.
\end{algorithm}

\vspace{-1ex}
\begin{pnotes}
\vspace{-0.5ex}
  \item The use of $\GroupJHash{\URS}$ for $\DiversifyHash{Sapling}$ and to generate independent bases
        needs a \randomOracle (for inputs on which $\vphantom{^J}\smash{\GroupJHash{\URS}}$ does not return $\bot$);
        here we show that it is sufficient to employ a simpler \randomOracle instantiated by
        $\vphantom{a^b}\BlakeTwos{256}$ in the security analysis.

        $\exclusivefun{\HashOutput \typecolon \byteseq{32}}
          {\abstJ\big(\LEOStoBSP{256}(\HashOutput)\kern-0.12em\big) \typecolon \GroupJ}{\setof{\bot,\, \ZeroJ,\, (0, -1)}}$
        is injective, and both it and its inverse are efficiently computable.

        $\exclusivefun{P \typecolon \GroupJ}
          {\scalarmult{\ParamJ{h}}{P} \typecolon \SubgroupJstar}{\setof{\ZeroJ}}$
        is exactly $\ParamJ{h}$-to-$1$, and both it and its inverse relation are efficiently computable.

        It follows that when $\fun{\big(D \typecolon \byteseq{8}, M \typecolon \byteseqs\big)}
          {\BlakeTwosOf{256}{D,\, \URS \bconcat\, M}\! \typecolon \byteseq{32}}$
        is modelled as a \randomOracle, $\exclusivefun{\big(D \typecolon \byteseq{8}, M \typecolon \byteseqs\big)}
          {\smash{\GroupJHash{\URS}}\big(D, M\big) \typecolon \SubgroupJstar}{\setof{\bot}}$ also acts as a \randomOracle.
  \item The $\BlakeTwos{256}$ chaining variable after processing $\URS$ may be precomputed.
\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.

Define $\FindGroupJHash\big(D, M\big) :=
\first(\fun{i \typecolon \byte}{\GroupJHash{\URS}\Of{D, M \bconcat\, [i]} \typecolon \maybe{\SubgroupJstar}})$.

\pnote{For random input, $\FindGroupJHash$ returns $\bot$ with probability approximately $2^{-256}$.
In the \Zcash protocol, most uses of $\FindGroupJHash$ are for constants and do not
return $\bot$; the only use that could potentially return $\bot$ is in the
computation of a \defaultDiversifiedPaymentAddress in \crossref{saplingkeycomponents}.
} %pnote
} %sapling


\nufive{
\lsubsubsubsection{\PallasAndVestaText}{pallasandvesta}

\vspace{-1ex}
\Orchard uses two elliptic curves, \defining{\Pallas} and \defining{\Vesta}, that form a cycle:
the base field of each is the scalar field of the other. In \Orchard, we use \Vesta for the proof
system (playing a similar rôle to \BLSPairing in \Sapling), and \Pallas for the application circuit
(similar to \Jubjub in \Sapling). Both curves are designed to be efficiently implementable in
\zkSNARKCircuits, although we only use \Pallas in that way for \Orchard.

The \representedGroups $\GroupP$ and $\GroupV$ of points on \Pallas and \Vesta respectively
are defined in this section.

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}
Let &$\ParamP{q}$ &$:= \hexint{40000000000000000000000000000000224698fc094cf91b992d30ed00000001}$. \\[0.25ex]
Let &$\ParamV{q}$ &$:= \hexint{40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001}$.
\end{tabular}

\vspace{-0.5ex}
(\hairspace $\ParamP{q}$ and $\ParamV{q}$ are prime.)

Let $\ParamP{r} := \ParamV{q}$ and $\ParamV{r} := \ParamP{q}$.

Let $\ParamP{b} = \ParamV{b} := 5$.

\vspace{0.5ex}
Let $\GroupP$ be the group of points $(x, y)$ with zero point $\ZeroP$, on a \swCurve $\CurveP$ over
$\GF{\ParamP{q}}$ with equation $y^2 = x^3 + \ParamP{b}$. $\GroupP$ has order $\ParamP{r}$.

Let $\GroupV$ be the group of points $(x, y)$ with zero point $\ZeroV$, on a \swCurve $\CurveV$ over
$\GF{\ParamV{q}}$ with equation $y^2 = x^3 + \ParamV{b}$. $\GroupV$ has order $\ParamV{r}$.

For the set of points on \Pallas of order $\ParamP{r}$ (which excludes $\ZeroP$), we write $\GroupPstar$.

For the set of points on \Vesta of order $\ParamV{r}$ (which excludes $\ZeroV$), we write $\GroupVstar$.

Let $\ellP = \ellV := 256$.

Define the notation $\optsqrt{\,\paramdot\,}$ as in \crossref{notation}.

\introlist
Define $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\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}
\begin{tabular}{@{\hskip 1.5em}r@{\;}l}
  $\reprG{}\big(\ZeroG{}\big)$ &$= \ItoLEBSP{256}(0)$ \\
  $\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}
\introlist
Define $\abstG{} \typecolon \ReprG{} \rightarrow \maybe{\GroupG{}}$ such that
$\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.
  \item if $\LEBStoIPOf{255}{x\Repr} \geq \ParamG{q}$ then return $\bot$, otherwise
        let $x \typecolon \GF{\ParamG{q}} = \LEBStoIPOf{255}{x\Repr} \pmod{\ParamG{q}}$.
  \item let $y = \optsqrt{x^3 + \ParamG{b}}$.
  \item if $x = 0$ and $\tilde{y} = 0$, return $\ZeroG{}$.
  \item if $y = \bot$, return $\bot$.
  \item if $y \bmod 2 = \tilde{y}$ then return $(x, y)$ else return $(x, \ParamG{q} - y)$.
\end{formulae}

\begin{pnotes}
  \item There is no solution to $0 = x^3 + 5$ in either $\GF{\ParamP{q}}$ or $\GF{\ParamV{q}}$, and
        so $y$ cannot be zero. Therefore there is only one valid representation of each point on
        \Pallas and of each \strut{}point on \Vesta; in particular $\abstP\Of{\mathsf{nc}} = \bot$ and
        $\abstV\Of{\mathsf{nc}} = \bot$ for $\mathsf{nc} = \ItoLEBSP{256}\big(2^{255}\big)$.
        This differs from the corresponding case of $\abstJ\Of{\mathsf{nc}}$ for \Jubjub, for example.
  \item When computing square roots in $\GF{\ParamP{q}}$ or $\GF{\ParamV{q}}$ in order to decompress
        a point encoding, the implementation \MUSTNOT assume that the square root exists, or that the
        encoding represents a point on the curve.
\end{pnotes}

\vspace{-2ex}
\lsubsubsubsection{Coordinate Extractor for \PallasText}{concreteextractorpallas}

\vspace{-1ex}
Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, and $\ParamP{b}$ be as defined in \crossref{pallasandvesta}.

Define $\Selectx \typecolon \GroupP \rightarrow \GF{\ParamP{q}}$ and $\Selecty \typecolon \GroupP \rightarrow \GF{\ParamP{q}}$ such that:

\vspace{-1ex}
\begin{formulae}
  \item $\Selectx\big(\ZeroP\big) = 0$
        \vspace{-0.25ex}
  \item $\Selectx\big((x, y)\big) = x$
        \vspace{-0.25ex}
  \item $\Selecty\big(\ZeroP\big) = 0$
        \vspace{-0.25ex}
  \item $\Selecty\big((x, y)\big) = y$.
\end{formulae}

\introlist
\vspace{1ex}
Define $\ExtractP \typecolon \GroupP \rightarrow \range{0}{\ParamP{q}-1}$ such that

\vspace{-1ex}
\begin{formulae}
  \item $\ExtractP(P) = \Selectx(P) \bmod \ParamP{q}$.
\end{formulae}

\vspace{-1ex}
We also define $\ExtractPbot \typecolon \maybe{\GroupP} \rightarrow \maybe{\range{0}{\ParamP{q}-1}}$ such that

\vspace{-1ex}
\begin{formulae}
  \item $\ExtractPbot\big(\bot\big) = \bot$
  \item $\ExtractPbot\big(P \typecolon \GroupP\big) = \ExtractP(P)$.
\end{formulae}

\vspace{-2ex}
\pnote{There is no solution to $y^2 = 0^3 + 5$ in $\GF{\ParamP{q}}$, and so $\ExtractP(P)$
can only be $0$ when $P = \ZeroP$.}
} %nufive

\nufive{
\lsubsubsubsection{Group Hash into \PallasAndVestaText}{concretegrouphashpallasandvesta}

\vspace{-1ex}
\Orchard uses the ``simplified SWU'' algorithm for \randomOracleAdjective hashing to elliptic curves
with $j$-invariant $0$, consistent with \cite[section 6.6.3]{ID-hashtocurve}, based on a
method by Riad Wahby and Dan Boneh \cite{WB2019}.
It is adapted from work of Eric Brier, \nh{Jean-Sébastien} Coron, Thomas Icart, David Madore,
Hugues Randriam, and Mehdi Tibouchi in \cite{BCIMRT2010}; Andrew Shallue and Christiaan van~de~Woestijne
in \cite{SvdW2006}; and Maciej Ulas in \cite{Ulas2007}.

Let $\GroupP$ and $\GroupV$ be the represented groups of points on the \pallasCurve and the
\vestaCurve respectively, as defined in \crossref{pallasandvesta}. Let $\GroupG{}$ be either
$\GroupP$ or $\GroupV$ according to the desired target curve.

Also define $\ZeroG{}$, $\GroupGstar{}$, $\ParamG{q}$, and $\abstG{}$
by replacing $\GroupG{}$ with $\GroupP$ or $\GroupV$, using definitions from
\crossref{pallasandvesta}.
Let $\curveNameG$ be $\ascii{pallas}$ when $\GroupG{} = \GroupP$, or $\ascii{vesta}$ when
$\GroupG{} = \GroupV$.

The algorithm makes use of a curve $\CurveIsoP$, called \IsoPallas, that is isogenous\footnote{\nufive{For
a brief introduction to isogenies between elliptic curves, see \cite{Cook2019}. For deeper mathematical
background, see the notes for lectures 4, 5, and 6 at \cite{Sutherland2021}.}} to $\CurveP$; or
$\CurveIsoV$, called \IsoVesta, that is isogenous to $\CurveV$.

Let $\ParamIsoP{a} := \hexint{18354a2eb0ea8c9c49be2d7258370742b74134581a27a59f92bb4b0b657a014b}$.

\vspace{-0.5ex}
Let $\ParamIsoV{a} := \hexint{267f9b2ee592271a81639c4d96f787739673928c7d01b212c515ad7242eaa6b1}$.

\vspace{-0.25ex}
Let $\ParamIsoP{b} = \ParamIsoV{b} := 1265$.

Let $\GroupIsoP$ be the group of points $(x, y)$ with zero point $\ZeroIsoP$, on a \swCurve $\CurveIsoP$
over $\GF{\ParamP{q}}$ with equation $y^2 = x^3 + \ParamIsoP{a} \mult x + \ParamIsoP{b}$.
Since $\CurveIsoP$ is isogenous to $\CurveP$, it has the same order $\ParamIsoP{r} = \ParamP{r} = \ParamV{q}$.

Let $\GroupIsoV$ be the group of points $(x, y)$ with zero point $\ZeroIsoV$, on a \swCurve $\CurveIsoV$
over $\GF{\ParamV{q}}$ with equation $y^2 = x^3 + \ParamIsoV{a} \mult x + \ParamIsoV{b}$.
Since $\CurveIsoV$ is isogenous to $\CurveV$, it has the same order $\ParamIsoV{r} = \ParamV{r} = \ParamP{q}$.

\introsection
Let $\IsoConstP{} \typecolon \typeexp{\GF{\ParamP{q}}}{13} := [$
\vspace{-1ex}
\begin{compactitemize}
  \item[] $\hexint{0e38e38e38e38e38e38e38e38e38e38e4081775473d8375b775f6034aaaaaaab},$
  \item[] $\hexint{3509afd51872d88e267c7ffa51cf412a0f93b82ee4b994958cf863b02814fb76},$
  \item[] $\hexint{17329b9ec525375398c7d7ac3d98fd13380af066cfeb6d690eb64faef37ea4f7},$
  \item[] $\hexint{1c71c71c71c71c71c71c71c71c71c71c8102eea8e7b06eb6eebec06955555580},$
  \item[] $\hexint{1d572e7ddc099cff5a607fcce0494a799c434ac1c96b6980c47f2ab668bcd71f},$
  \item[] $\hexint{325669becaecd5d11d13bf2a7f22b105b4abf9fb9a1fc81c2aa3af1eae5b6604},$
  \item[] $\hexint{1a12f684bda12f684bda12f684bda12f7642b01ad461bad25ad985b5e38e38e4},$
  \item[] $\hexint{1a84d7ea8c396c47133e3ffd28e7a09507c9dc17725cca4ac67c31d8140a7dbb},$
  \item[] $\hexint{3fb98ff0d2ddcadd303216cce1db9ff11765e924f745937802e2be87d225b234},$
  \item[] $\hexint{025ed097b425ed097b425ed097b425ed0ac03e8e134eb3e493e53ab371c71c4f},$
  \item[] $\hexint{0c02c5bcca0e6b7f0790bfb3506defb65941a3a4a97aa1b35a28279b1d1b42ae},$
  \item[] $\hexint{17033d3c60c68173573b3d7f7d681310d976bbfabbc5661d4d90ab820b12320a},$
  \item[] $\hexint{40000000000000000000000000000000224698fc094cf91b992d30ecfffffde5}$
\end{compactitemize}
\vspace{1ex}
$]$.

\introsection
Let $\IsoConstV{} \typecolon \typeexp{\GF{\ParamV{q}}}{13} := [$
\vspace{-1ex}
\begin{compactitemize}
  \item[] $\hexint{38e38e38e38e38e38e38e38e38e38e390205dd51cfa0961a43cd42c800000001},$
  \item[] $\hexint{1d935247b4473d17acecf10f5f7c09a2216b8861ec72bd5d8b95c6aaf703bcc5},$
  \item[] $\hexint{18760c7f7a9ad20ded7ee4a9cdf78f8fd59d03d23b39cb11aeac67bbeb586a3d},$
  \item[] $\hexint{31c71c71c71c71c71c71c71c71c71c71e1c521a795ac8356fb539a6f0000002b},$
  \item[] $\hexint{0a2de485568125d51454798a5b5c56b2a3ad678129b604d3b7284f7eaf21a2e9},$
  \item[] $\hexint{14735171ee5427780c621de8b91c242a30cd6d53df49d235f169c187d2533465},$
  \item[] $\hexint{12f684bda12f684bda12f684bda12f685601f4709a8adcb36bef1642aaaaaaab},$
  \item[] $\hexint{2ec9a923da239e8bd6767887afbe04d121d910aefb03b31d8bee58e5fb81de63},$
  \item[] $\hexint{19b0d87e16e2578866d1466e9de10e6497a3ca5c24e9ea634986913ab4443034},$
  \item[] $\hexint{1ed097b425ed097b425ed097b425ed098bc32d36fb21a6a38f64842c55555533},$
  \item[] $\hexint{2f44d6c801c1b8bf9e7eb64f890a820c06a767bfc35b5bac58dfecce86b2745e},$
  \item[] $\hexint{3d59f455cafc7668252659ba2b546c7e926847fb9ddd76a1d43d449776f99d2f},$
  \item[] $\hexint{40000000000000000000000000000000224698fc0994a8dd8c46eb20fffffde5}$
\end{compactitemize}
\vspace{1ex}
$]$.

\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}}
                                             {x^2 + \IsoConstG{5} \mult x + \IsoConstG{6}},
                                       \hfrac{\big(\IsoConstG{7} \mult x^3 + \IsoConstG{8} \mult x^2 + \IsoConstG{9} \mult x + \IsoConstG{10}\big) \mult y}
                                             {x^3 + \IsoConstG{11} \mult x^2 + \IsoConstG{12} \mult x + \IsoConstG{13}}\right)$.
\end{tabular}

\vspace{2ex}
Let $\BlakeTwob{512} \typecolon \byteseq{16} \times \byteseqs \rightarrow \byteseq{\ell/8}$ be as defined in \crossref{concreteblake2}.

Define the notation $\optsqrt{\,\paramdot\,}$ as in \crossref{notation}.

\vspace{-0.25ex}
Let $\BEOStoIP{}$ be as defined in \crossref{endian}.

\vspace{0.5ex}
\introlist
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{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)$
  \item return $[\,\BEOStoIPOf{512}{b_1}\! \pmod{\ParamG{q}},\, \BEOStoIPOf{512}{b_2}\! \pmod{\ParamG{q}}\,]$.
\end{algorithm}

\begin{nnotes}
  \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
        \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 $\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.
  \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}.
  \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.
  \item The conversion from bytes to field elements uses \bigEndian order, again in order
        to follow the Internet Draft\rlap{.}
  \item A minor optimization is to cache the state of the $\BlakeTwob{512}$ instance
        used to compute $b_0$ after processing $\zerobytes{128}$, 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}} \times \bit$ as follows:

\begin{formulae}
  \item $\sqrtratioG(\num, \xdiv) = \begin{cases}
                                      \,\big(\,\optsqrt{\num / \xdiv}, &\!\!\!\!1\big), \text{ if } \num / \xdiv\text{ is square in }\GF{\ParamG{q}} \\
                                      \,\big(\,\optsqrt{\ParamG{\lambda} \mult \num / \xdiv}, &\!\!\!\!0\big), \text{ otherwise.}
                                    \end{cases}$
\end{formulae}
\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 \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.)

Precompute $\ParamIsoG{\theta} := \optsqrt{\ParamIsoG{Z} / \ParamG{\lambda}}$, which is not $\bot$.\footnote{\nufive{Both
$\ParamIsoG{Z}$ and $\ParamG{\lambda}$ are nonsquare, and so their ratio is square in $\GF{\ParamG{q}}$. An arbitrary
square root may be chosen.}}

By definition we have that $\CurveG{}$ is the \swCurve with equation $y^2 = x^3 + \ParamG{b}$, and
$\CurveIsoG$ is the \swCurve with equation $y^2 = x^3 + \ParamIsoG{a} \mult x + \ParamIsoG{b}$.

\introsection
Define $\maptocurvesimpleswuIsoG(u \typecolon \GF{\ParamG{q}}) \rightarrow \GroupIsoG$ as follows:
\vspace{-0.5ex}
\begin{algorithm}
  \item let $\mathsf{Zuu} = \ParamIsoG{Z} \mult u^2$
  \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}$
  \item let $\mathsf{y} = (u \bmod 2 = y \bmod 2) \bchoose \mathsf{y}' : -\mathsf{y}'$
  \item return the $\CurveIsoG$ point with \affineSW coordinates $\left(\mathsf{x}_\num / \mathsf{x}_\xdiv,\, \mathsf{y}\right)$.
\end{algorithm}

Let $\GroupGHashInput := \byteseqs \times \byteseqs$.
The first input element acts as a domain separator to distinguish uses of the
\groupHash for different purposes; the second input element is the message.

This \hashToCurve algorithm does not have a URS, i.e.\ $\GroupGHashURSType := ()$.

\introlist
The hash $\GroupGHash(D \typecolon \byteseqs, M \typecolon \byteseqs) \typecolon \GroupG{}$
is calculated as follows:

\begin{algorithm}
  \item let $\DST = D \bconcat \ascii{-} \bconcat \curveNameG \bconcat \ascii{\_XMD:BLAKE2b\_SSWU\_RO\_}$
  \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
        to the Internet Draft, the definition here takes precedence.
  \item It is not necessary to use the $\clearcofactor$ function specified in the
        Internet Draft, because \Pallas and \Vesta (and therefore \IsoPallas and \IsoVesta)
        are \primeOrderCurves.
  \item The above description incorporates optimizations from \cite{WB2019} that avoid
        inversions and unnecessary square tests in the computation of $\maptocurvesimpleswuIsoG$.
        In order to fully avoid inversions, the output of $\maptocurvesimpleswuIsoG$ can be
        expressed in Jacobian coordinates, as can the input and output of $\IsoMapG$.
        It is outside the scope of this document to describe Jacobian coordinates, but
        for example, the $\CurveIsoG$ point with \affineSW coordinates
        $\big(\mathsf{x}_\num / \mathsf{x}_\xdiv, \mathsf{y}\big)$, has Jacobian coordinates
        $\big(\mathsf{x}_\num \mult \mathsf{x}_\xdiv : \mathsf{y} \mult \mathsf{x}_\xdiv^3 : \mathsf{x}_\xdiv\big)$.
\end{nnotes}

\vspace{-2ex}
\pnote{
The uses of $\GroupPHash$ for $\DiversifyHash{Orchard}$, and of both $\GroupPHash$ and
$\GroupVHash$ to generate independent bases, need a \randomOracle. The $\hashtocurve$ algorithm
in \cite{ID-hashtocurve} is designed to be indifferentiable from a \randomOracle (in the
framework of \cite{MRH2003}), given that $\XMDBlakeTwob$ satisfies the requirements of
\cite[section 5.5.4]{ID-hashtocurve}. The security of the Brier et al.\ construction on
which this algorithm is based is analysed in \cite{FFSTV2013} and \cite{KT2015}, with a
verified proof in \cite{BGHOZ2013}.
} %pnote
} %nufive


\lsubsubsection{Zero-Knowledge Proving Systems}{concretezk}

\vspace{-0.5ex}
\lsubsubsubsection{\BCTVText}{bctv}

\vspace{-1.5ex}
\sapling{Before \Sapling activation,}
\Zcash uses \zkSNARKs generated by a fork of \libsnark \cite{Zcash-libsnark}
with the \defining{\BCTV} \provingSystem described in \cite{BCTV2014a}, which is a modification of
the systems in \cite{PHGR2013} and \cite{BCGTV2013}.

A \BCTV proof comprises
$(\Proof{A}  \typecolon \SubgroupGstar{1},\,
  \Proof{A}' \typecolon \SubgroupGstar{1},\,
  \Proof{B}  \typecolon \SubgroupGstar{2},\,
  \Proof{B}' \typecolon \SubgroupGstar{1},\,
  \Proof{C}  \typecolon \SubgroupGstar{1},\,
  \Proof{C}' \typecolon \SubgroupGstar{1},\,
  \Proof{K}  \typecolon \SubgroupGstar{1},\,
  \Proof{H}  \typecolon \SubgroupGstar{1})$.
It is computed as described in \cite[Appendix B]{BCTV2014a}, using the pairing parameters
specified in \crossref{bnpairing}.

\pnote{
Many details of the \provingSystem are beyond the scope of this protocol document.
For example, the \quadraticConstraintProgram verifying the \joinSplitStatement, or
its translation to a \defining{\quadraticArithmeticProgram} \cite[section 2.3]{BCTV2014a},
are not specified in this document. In 2015, Bryan Parno found a bug in this
translation, which is corrected by the \libsnark implementation\footnote{Confusingly,
the bug found by Bryan Parno was fixed in \libsnark in 2015, but that fix was
incompletely described in the May 2015 update \cite[Theorem 2.4]{BCTV2014a-old}.
It is described completely in \cite[Theorem 2.4]{BCTV2014a} and in
\cite{Gabizon2019}.} \cite{WCBTV2015} \cite{Parno2015} \cite[Remark 2.5]{BCTV2014a}.
In practice it will be necessary to use the specific proving and verifying keys
that were generated for the \Zcash production \blockChain, given in
\crossref{bctvparameters}, together with a \provingSystem implementation that is
interoperable with the \Zcash fork of \defining{\libsnark}, to ensure compatibility.
}

\vuln{
\BCTV is subject to a security vulnerability, separate from \cite{Parno2015},
that could allow violation of Knowledge Soundness (and Soundness) \cite{CVE-2019-7167}
\cite{SWB2019} \cite{Gabizon2019}. The consequence for \Zcash is that balance violation
could have occurred before activation of the \Sapling \networkUpgrade, although there
is no evidence of this having happened. Use of the vulnerability to produce false proofs
is believed to have been fully mitigated by activation of \Sapling. The use of \BCTV
in \Zcash is now limited to verifying proofs that were made prior to the \Sapling
\networkUpgrade.

Due to this issue, new forks of \Zcash \MUSTNOT use \BCTV, and any other users of
the \Zcash protocol \SHOULD discontinue use of \BCTV as soon as possible.

The vulnerability does not affect the Zero Knowledge property of the scheme (as
described in any version of \cite{BCTV2014a} or as implemented in any version of
\libsnark that has been used in \Zcash), even under subversion of the parameter
generation \cite[Theorem 4.10]{BGG2017}.
}

\saplingonward{An implementation of \Zcash that checkpoints on a \block after \Sapling
\MAY choose to skip verification of \BCTV proofs. Note that in \crossref{blockchain},
there is a requirement that a \fullValidator that potentially risks \Mainnet funds
or displays \Mainnet \transaction information to a user \MUST do so only for a
\blockChain that includes the \activationBlock of the most recent \settled
\networkUpgrade, with its known \blockHash as specified in \crossref{networks}.
Since the most recent \settled \networkUpgrade is after the \Sapling \networkUpgrade,
this mitigates the potential risks due to skipping \BCTV proof verification.}

\introlist
\vspace{-1ex}
\lsubsubsubsubsection{Encoding of \BCTVText{} Proofs}{bctvencoding}

\newsavebox{\bctvbox}
\begin{lrbox}{\bctvbox}
\begin{bytefield}[bitwidth=0.021em]{2368}
    \sbitbox{264}{264-bit $\Proof{A}$} &
    \sbitbox{264}{264-bit $\Proof{A}'$} &
    \sbitbox{520}{520-bit $\Proof{B}$} &
    \sbitbox{264}{264-bit $\Proof{B}'$} &
    \sbitbox{264}{264-bit $\Proof{C}$} &
    \sbitbox{264}{264-bit $\Proof{C}'$} &
    \sbitbox{264}{264-bit $\Proof{K}$} &
    \sbitbox{264}{264-bit $\Proof{H}$}
\end{bytefield}
\end{lrbox}

\vspace{-1ex}
A \BCTV proof is encoded by concatenating the encodings of its elements;
for the \BNPairing pairing this is:

\begin{formulae}[leftmargin=0.2em]
  \item $\Justthebox{\bctvbox}$
\end{formulae}

\vspace{-0.5ex}
The resulting proof size is $296$ bytes.

\vspace{0.5ex}
In addition to the steps to verify a proof given in \cite[Appendix B]{BCTV2014a}, the
verifier \MUST check, for the encoding of each element, that:

\begin{itemize}
        \vspace{-0.5ex}
  \item the lead byte is of the required form;
        \vspace{-0.5ex}
  \item the remaining bytes encode a \bigEndian representation of an integer in
        $\range{0}{\ParamS{q}\!-\!1}$ or (for $\Proof{B}$)
        $\range{0}{\ParamSexp{q}{2}\!-\!1}$;
        \vspace{-0.5ex}
  \item the encoding represents a point in $\SubgroupGstar{1}$ or (for
        $\Proof{B}$) $\SubgroupGstar{2}$, including checking that it is of order
        $\ParamG{r}$ in the latter case.
\end{itemize}


\newsavebox{\grothbox}
\begin{lrbox}{\grothbox}
\setsapling
\begin{bytefield}[bitwidth=0.021em]{1536}
    \sbitbox{384}{384-bit $\Proof{A}$} &
    \sbitbox{768}{768-bit $\Proof{B}$} &
    \sbitbox{384}{384-bit $\Proof{C}$}
\end{bytefield}
\end{lrbox}

\sapling{
\vspace{-2ex}
\lsubsubsubsection{\GrothText}{groth}

\vspace{-1ex}
After \Sapling activation, \Zcash uses \zkSNARKs with the \defining{\Groth} \provingSystem described in
\cite{BGM2017}, which is a modification of the system in \cite{Groth2016}. An independent
security proof of this system and its setup is given in \cite{Maller2018}.

\Groth \zkSNARKProofs are used in \transactionVersion 4 and later (\crossref{txnencoding}),
both in \Sprout \joinSplitDescriptions and in \Sapling \spendDescriptions and \outputDescriptions.
They are generated by the \defining{\bellman} library \cite{Bowe-bellman}.

A \Groth proof comprises
$(\Proof{A} \typecolon \SubgroupSstar{1},\,
  \Proof{B} \typecolon \SubgroupSstar{2},\,
  \Proof{C} \typecolon \SubgroupSstar{1})$.
It is computed as described in \cite[section 3.2]{Groth2016}, using the pairing parameters
specified in \crossref{blspairing}. The proof elements are in a different order to
the presentation in \cite{Groth2016}.

\pnote{
The \quadraticConstraintPrograms verifying the \spendStatement and
\outputStatement are described in Appendix \crossref{circuitdesign}. However, many
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 (see \crossref{grothparameters}),
and a \provingSystem implementation that is interoperable with the \bellman
library used by \Zcash, to ensure compatibility.
}

\introlist
\lsubsubsubsubsection{Encoding of \GrothText{} Proofs}{grothencoding}

\vspace{-1ex}
A \Groth proof is encoded by concatenating the encodings of its elements;
for the \BLSPairing pairing this is:

\begin{formulae}
  \item $\Justthebox{\grothbox}$
\end{formulae}

The resulting proof size is $192$ bytes.

\vspace{0.5ex}
\introlist
In addition to the steps to verify a proof given in \cite{Groth2016}, the
verifier \MUST check, for the encoding of each element, that:

\begin{itemize}
        \vspace{-0.5ex}
  \item the leading bitfield is of the required form;
        \vspace{-0.5ex}
  \item the remaining bits encode a \bigEndian representation of an integer
        in $\range{0}{\ParamS{q}\!-\!1}$ or (in the case of $\Proof{B}$) two integers in
        that range;
        \vspace{-0.5ex}
  \item the encoding represents a point in $\SubgroupSstar{1}$ or (in the case of $\Proof{B}$)
        $\SubgroupSstar{2}$, including checking that it is of order $\ParamS{r}$
        in each case.
\end{itemize}
} %sapling


\nufive{
\vspace{-2ex}
\lsubsubsubsection{\HaloTwoText}{halo2}

\vspace{-1ex}
For \Orchard \actionDescriptions in version 5 \transactions, \Zcash uses \zkSNARKs with the
\defining{\HaloTwo} \provingSystem described in \cite{Zcash-halo2}.

\introlist
\lsubsubsubsubsection{Encoding of \HaloTwoText{} Proofs}{halo2encoding}

\vspace{-1ex}
\HaloTwo proofs are defined as \byteSequences, and so the encoding is the proof itself.
} %nufive


\vspace{1ex}
\extralabel{notept}{\lsubsection{Encodings of Note Plaintexts and Memo Fields}{noteptencoding}}

As explained in \crossref{noteptconcept}, transmitted \notes are stored on
the \blockChain in encrypted form. The components and usage of \notePlaintexts,
and which keys they are encrypted to, are defined in that section.

\vspace{1ex}
\introlist
The encoding of a \Sprout \notePlaintext consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.029em]{1672}
    \sbitbox{220}{$8$-bit $\NotePlaintextLeadByte$} &
    \sbitbox{180}{$64$-bit $\Value$} &
    \sbitbox{256}{$256$-bit $\NoteUniqueRand$} &
    \sbitbox{256}{$256$-bit $\NoteCommitRand$} &
    \sbitbox{800}{$\Memo$ ($\MemoByteLength$ bytes)}
\end{bytefield}
\end{equation*}

\begin{itemize}
    \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 $32$ bytes specifying $\NoteCommitRand$.
    \item $\MemoByteLength$ bytes specifying $\Memo$.
\end{itemize}

\sapling{
\introlist
The encoding of a \SaplingOrOrchard \notePlaintext consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.029em]{1672}
    \sbitbox{220}{$8$-bit $\NotePlaintextLeadByte$}
    \sbitbox{240}{$88$-bit $\Diversifier$}
    \sbitbox{180}{$64$-bit $\Value$}
    \sbitbox{256}{$256$-bit $\NoteCommitRandBytesOrSeedBytes$}
    \sbitbox{800}{$\Memo$ ($\MemoByteLength$ bytes)}
\end{bytefield}
\end{equation*}

\begin{itemize}
    \item A byte, $\hexint{01}$\canopy{ or $\hexint{02}$} as specified in \crossref{noteptconcept},
          indicating this version of the encoding of a \SaplingOrOrchard \notePlaintext.
    \item $11$ bytes specifying $\Diversifier$.
    \item $8$ bytes specifying $\Value$.
    \item $32$ bytes specifying $\NoteCommitRandBytesOrSeedBytes$.
    \item $\MemoByteLength$ bytes specifying $\Memo$.
\end{itemize}
} %sapling


\lsubsection{Encodings of Addresses and Keys}{addressandkeyencoding}

This section describes how \Zcash encodes \shieldedPaymentAddresses, \incomingViewingKeys,
and \spendingKeys.

Addresses and keys can be encoded as a \byteSequence; this is called
the \defining{\rawEncoding}. For \Sprout \shieldedPaymentAddresses, this
\byteSequence can then be further encoded using \BaseFiftyEightCheck. The \BaseFiftyEightCheck
layer is the same as for upstream \Bitcoin addresses \cite{Bitcoin-Base58}.

\sapling{
\vspace{1ex}
For \Sapling-specific key and address formats, \Bech \cite{ZIP-173} is used
instead of \BaseFiftyEightCheck.

\vspace{-3ex}
\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.}

\nufive{
\vspace{1ex}
\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.

\xUnifiedPaymentAddresses and \Orchard \spendingKeys are 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 \paymentAddress is the \Bech form converted to uppercase, using the
Alphanumeric mode \cite[sections 7.3.4 and 7.4.4]{ISO2015}.
\nufive{Similarly, the \RECOMMENDED format for a unified \paymentAddress is the \Bechm
form converted to uppercase, using the Alphanumeric mode.}
} %sapling


\introsection
\lsubsubsection{Transparent Encodings}{transparentencodings}

\lsubsubsubsection{Transparent Addresses}{transparentaddrencoding}

\defining{\xTransparentAddresses} are either P2SH (Pay to Script Hash) addresses \cite{BIP-13}
or P2PKH (Pay to Public Key Hash) addresses \cite{Bitcoin-P2PKH}.

\introlist
The \rawEncoding of a P2SH address consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.1em]{176}
    \sbitbox{80}{$8$-bit $\PtoSHAddressLeadByte$}
    \sbitbox{80}{$8$-bit $\PtoSHAddressSecondByte$}
    \sbitbox{160}{$160$-bit script hash}
\end{bytefield}
\end{equation*}

\begin{itemize}
  \item Two bytes $[\PtoSHAddressLeadByte, \PtoSHAddressSecondByte]$,
        indicating this version of the \rawEncoding of a P2SH address
        on \Mainnet. (Addresses on \Testnet use
        $[\PtoSHAddressTestnetLeadByte, \PtoSHAddressTestnetSecondByte]$
        instead.)
  \item $20$ bytes specifying a script hash \cite{Bitcoin-P2SH}.
\end{itemize}

\introlist
The \rawEncoding of a P2PKH address consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.1em]{176}
    \sbitbox{80}{$8$-bit $\PtoPKHAddressLeadByte$}
    \sbitbox{80}{$8$-bit $\PtoPKHAddressSecondByte$}
    \sbitbox{160}{$160$-bit \validatingKey hash}
\end{bytefield}
\end{equation*}

\begin{itemize}
  \item Two bytes $[\PtoPKHAddressLeadByte, \PtoPKHAddressSecondByte]$,
        indicating this version of the \rawEncoding of a P2PKH address
        on \Mainnet. (Addresses on \Testnet use
        $[\PtoPKHAddressTestnetLeadByte, \PtoPKHAddressTestnetSecondByte]$
        instead.)
  \item $20$ bytes specifying a \validatingKey hash, which is a RIPEMD-160
        hash \cite{RIPEMD160} of a SHA-256 hash \cite{NIST2015}
        of a compressed \ECDSA key encoding.
\end{itemize}

\vspace{-2ex}
\begin{pnotes}
  \item In \Bitcoin a single byte is used for the version field identifying
        the address type. In \Zcash two bytes are used. For addresses on
        \Mainnet, this and the encoded length cause the first
        two characters of the \BaseFiftyEightCheck encoding to be fixed as \ascii{t3}
        for P2SH addresses, and as \ascii{t1} for P2PKH addresses. (This does
        \emph{not} imply that a \transparent \Zcash address can be parsed
        identically to a \Bitcoin address just by removing the \ascii{t}.)
  \item \Zcash does not yet support Hierarchical Deterministic Wallet
        addresses \cite{BIP-32}.
\end{pnotes}


\lsubsubsubsection{Transparent Private Keys}{transparentkeyencoding}

These are encoded in the same way as in \Bitcoin \cite{Bitcoin-Base58},
for both \Mainnet and \Testnet.


\lsubsubsection{\SproutText{} Encodings}{sproutencodings}

\lsubsubsubsection{\SproutText{} Payment Addresses}{sproutpaymentaddrencoding}

Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}.

A \Sprout{} \defining{\shieldedPaymentAddress} consists of $\AuthPublic \typecolon \PRFOutputSprout$
and $\TransmitPublic \typecolon \KAPublic{Sprout}$.

$\AuthPublic$ is a \shaCompress output.
$\TransmitPublic$ is a $\KAPublic{Sprout}$ key, for use with the encryption scheme defined in
\crossref{sproutinband}. These components are derived from a \spendingKey as described in
\crossref{sproutkeycomponents}.

\introlist
The \rawEncoding of a \Sprout \shieldedPaymentAddress consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{520}
    \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}
  \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 $32$ bytes specifying $\TransmitPublic$, using the
        normal encoding of a $\KASproutCurve$ \publicKey \cite{Bernstein2006}.
\end{itemize}

\pnote{
For addresses on \Mainnet, the lead bytes and encoded length
cause the first two characters of the \BaseFiftyEightCheck encoding to be fixed as
\ascii{zc}. For \Testnet, the first two characters are fixed as
\ascii{zt}.
} %pnote


\lsubsubsubsection{\SproutText{} Incoming Viewing Keys}{sproutinviewingkeyencoding}

Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}.

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
\crossref{sproutinband}. These components are derived from a \spendingKey as described in
\crossref{sproutkeycomponents}.

\introlist
The \rawEncoding of a \Sprout \incomingViewingKey consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.062em]{536}
    \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*}

\vspace{-1ex}
\begin{itemize}
  \item Three bytes $[\InViewingKeyLeadByte, \InViewingKeySecondByte, \InViewingKeyThirdByte]$,
        indicating this version of the \rawEncoding of a \Zcash \incomingViewingKey
        on \Mainnet. (Addresses on \Testnet use
        $[\InViewingKeyTestnetLeadByte, \InViewingKeyTestnetSecondByte, \InViewingKeyTestnetThirdByte]$
        instead.)
  \item $32$ bytes specifying $\AuthPublic$.
  \item $32$ bytes specifying $\TransmitPrivate$, using the normal encoding
        of a $\KASproutCurve$ \privateKey \cite{Bernstein2006}.
\end{itemize}

$\TransmitPrivate$ \MUST be ``clamped'' using $\KAFormatPrivate{Sprout}$ as specified
in \crossref{sproutkeycomponents}. That is, a decoded \incomingViewingKey \MUST be
considered invalid if $\TransmitPrivate \neq \KAFormatPrivate{Sprout}(\TransmitPrivate)$.

$\KAFormatPrivate{Sprout}$ is defined in \crossref{concretesproutkeyagreement}.

\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}.}


\lsubsubsubsection{\SproutText{} Spending Keys}{sproutspendingkeyencoding}

A \Sprout{} \defining{\spendingKey} consists of $\AuthPrivate$, which is a sequence of
$252$ bits (see \crossref{sproutkeycomponents}).

\introlist
The \rawEncoding of a \Sprout \spendingKey consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{264}
    \sbitbox{80}{$8$-bit $\SpendingKeyLeadByte$} &
    \sbitbox{80}{$8$-bit $\SpendingKeySecondByte$} &
    \sbitbox{32}{$\zeros{4}$} &
    \sbitbox{252}{$252$-bit $\AuthPrivate$}
\end{bytefield}
\end{equation*}

\begin{itemize}
  \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: $4$ zero padding bits and $252$ bits specifying $\AuthPrivate$.
\end{itemize}

The zero padding occupies the most significant $4$ bits of the third byte.

\begin{pnotes}
  \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.
  \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
        are fixed as \ascii{ST}.
\end{pnotes}


\sapling{
\lsubsubsection{\SaplingText{} Encodings}{saplingencodings}

\lsubsubsubsection{\SaplingText{} Payment Addresses}{saplingpaymentaddrencoding}

Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}.

Let $\DiversifierLength$ be as defined in \crossref{constants}.

Let $\SubgroupJ$, $\abstJ$, and $\reprJ$ be as defined in \crossref{jubjub}.

Let $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$
be as defined in \crossref{endian}.

A \Sapling{} \defining{\shieldedPaymentAddress} consists of $\Diversifier \typecolon \DiversifierType$
and $\DiversifiedTransmitPublic \typecolon \KAPublicPrimeSubgroup{Sapling}$.

$\DiversifiedTransmitPublic$ is an encoding of a $\KA{Sapling}$ \publicKey of type
$\KAPublicPrimeSubgroup{Sapling}$, for use with the encryption scheme defined in
\crossref{saplinginband}. $\Diversifier$~is a \diversifier.
These components are derived as described in \crossref{saplingkeycomponents}.

\introlist
The \rawEncoding of a \Sapling \shieldedPaymentAddress consists of:
\vspace{1ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{344}
    \sbitbox{120}{$\LEBStoOSPOf{88}{\Diversifier}$}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\DiversifiedTransmitPublic}\kern 0.05em}$}
\end{bytefield}
\end{equation*}

\begin{itemize}
  \item $11$ bytes specifying $\Diversifier$.
  \item $32$ bytes specifying the \ctEdwardsCompressedEncoding of
        $\DiversifiedTransmitPublic$ (see \crossref{jubjub}).
\end{itemize}

When decoding the representation of $\DiversifiedTransmitPublic$, the address \MUST be
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 \primeOrderSubgroup $\SubgroupJ$, or
if it is a \nonCanonicalPoint encoding as defined in \crossref{abstractgroup}. This \MAY be
enforced in advance of activation of \NUFive.}

\vspace{1ex}
For addresses on \Mainnet, the \defining{\humanReadablePart} (as defined in \cite{ZIP-173}) is \ascii{zs}.
For addresses on \Testnet, the \humanReadablePart is \ascii{ztestsapling}.
} %sapling


\sapling{
\vspace{-1ex}
\lsubsubsubsection{\SaplingText{} Incoming Viewing Keys}{saplinginviewingkeyencoding}

\vspace{-2ex}
Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}.

Let $\InViewingKeyLength{Sapling}$ be as defined in \crossref{constants}.

A \Sapling{} \defining{\incomingViewingKey} consists of $\InViewingKey \typecolon \InViewingKeyTypeSapling$.

$\InViewingKey$ is a $\KAPrivate{Sapling}$ key (restricted to $\InViewingKeyLength{Sapling}$ bits),
derived as described in \crossref{saplingkeycomponents}.
It is used with the encryption scheme defined in \crossref{saplinginband}.

\introlist
The \rawEncoding of a \Sapling \incomingViewingKey consists of:
\vspace{0.5ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{256}
    \sbitbox{256}{$256$-bit $\InViewingKey$}
\end{bytefield}
\end{equation*}

\vspace{-1.5ex}
\begin{itemize}
  \item $32$ bytes (\littleEndian) specifying $\InViewingKey$, padded with zeros in the most
        significant bits.
\end{itemize}

\vspace{-1ex}
$\InViewingKey$ \MUST be in the range $\InViewingKeyTypeSapling$ as specified
in \crossref{saplingkeycomponents}. That is, a decoded \incomingViewingKey \MUST be
considered invalid if $\InViewingKey$ is not in this range.

For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zivks}.
For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zivktestsapling}.
} %sapling


\sapling{
\vspace{-1ex}
\lsubsubsubsection{\SaplingText{} Full Viewing Keys}{saplingfullviewingkeyencoding}

\vspace{-2ex}
Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}.

A \Sapling{} \defining{\fullViewingKey} consists of $\AuthSignPublic \typecolon \SubgroupJstar$,
$\NullifierKey \typecolon \SubgroupJ$, and $\OutViewingKey \typecolon \byteseq{\OutViewingKeyLength/8}$.

$\AuthSignPublic$ and $\NullifierKey$ are points on the \jubjubCurve
(see \crossref{jubjub}). They are derived as described in \crossref{saplingkeycomponents}.

\introlist
The \rawEncoding of a \Sapling \fullViewingKey consists of:
\vspace{0.5ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.05em]{512}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignPublic}\kern 0.05em}$}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\NullifierKey}\kern 0.05em}$}
    \sbitbox{256}{$32$-byte $\OutViewingKey$}
\end{bytefield}
\end{equation*}

\vspace{-1.5ex}
\begin{itemize}
  \item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\AuthSignPublic$
        (see \crossref{jubjub}).
  \item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\NullifierKey$.
  \item $32$ bytes specifying the \outgoingViewingKey $\OutViewingKey$.
\end{itemize}

\vspace{-1ex}
When decoding this representation, the key \MUST be considered invalid if $\abstJ$ returns $\bot$
for either $\AuthSignPublic$ or $\NullifierKey$, or if $\AuthSignPublic \notin \SubgroupJstar$,
or if $\NullifierKey \notin \SubgroupJ$.

For \fullViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}.
For \fullViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}.
} %sapling


\sapling{
\vspace{-1ex}
\lsubsubsubsection{\SaplingText{} Spending Keys}{saplingspendingkeyencoding}

\vspace{-2ex}
A \Sapling{} \defining{\spendingKey} consists of $\SpendingKey \typecolon \SpendingKeyType$
(see \crossref{saplingkeycomponents}).

\introlist
The \rawEncoding of a \Sapling \spendingKey consists of:
\vspace{0.5ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{256}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\SpendingKey}$}
\end{bytefield}
\end{equation*}

\vspace{-1.5ex}
\begin{itemize}
    \item $32$ bytes specifying $\SpendingKey$.
\end{itemize}

\vspace{-1ex}
For \spendingKeys on \Mainnet, the \humanReadablePart is \ascii{secret-spending-key-main}.
For \spendingKeys on \Testnet, the \humanReadablePart is \ascii{secret-spending-key-test}.
} %sapling


\nufive{
\vspace{-1ex}
\lsubsubsection{Unified and \OrchardText{} Encodings}{orchardencodings}

\vspace{-1ex}
\extralabel{unifiedpaymentaddrencoding}{\lsubsubsubsection{Unified Payment Addresses and Viewing Keys}{unifiedencodings}}

\vspace{-1ex}
Rather than defining a \Bech string encoding of \Orchard \shieldedPaymentAddresses, we instead define,
in \cite{ZIP-316}, a \defining{\unifiedPaymentAddress} format that is able to encode a set of \paymentAddresses
of different types. This enables the consumer of an address to choose the best address type it supports,
providing a better user experience as new formats are added in the future.

Similarly, \defining{\unifiedIncomingViewingKeys and \unifiedFullViewingKeys} are defined to encode sets of
\incomingViewingKeys and \fullViewingKeys respectively.

Since \cite{ZIP-316} includes a full specification of encoding, decoding, and other processing of
\unifiedPaymentAddresses, \unifiedIncomingViewingKeys, and \unifiedFullViewingKeys, we give only a
summary here.

\introlist
A \unifiedPaymentAddress includes zero or one address of each type in the following Priority List:

\begin{itemize}
  \item typecode $\hexint{03}$ -- \crossref{orchardpaymentaddrencoding};
  \item typecode $\hexint{02}$ -- \crossref{saplingpaymentaddrencoding};
  \item typecode $\hexint{01}$ -- \transparent P2SH address, \emph{or} typecode $\hexint{00}$ -- \transparent P2PKH address.
\end{itemize}

\vspace{-2ex}
with the restrictions that there \MUST be at least one \shieldedPaymentAddress (typecodes $\geq \hexint{02})$,
and that both P2SH and P2PKH cannot be present.

When sending a payment, the consumer of a \unifiedPaymentAddress \MUST use the most preferred address
type that it supports from the set, i.e.\ the first in the above list. See \cite{ZIP-316} for additional
requirements, and for discussion of \unifiedIncomingViewingKeys and \unifiedFullViewingKeys.

Note that there is intentionally no typecode defined for a \Sprout \shieldedPaymentAddress
(or \Sprout viewing keys).
Since it is no longer possible (since activation of \cite{ZIP-211} in the \Canopy \networkUpgrade)
to send funds into the \Sprout \chainValuePool, this would not be generally useful.

The format uses \Bechm \cite{BIP-350} (ignoring any length restrictions) for the checksum
algorithm and string encoding. This is chosen over \Bech in order for the checksum to better
handle variable-length inputs.

A ``jumbling'' algorithm is used in order to mitigate address replacement attacks given that
a user might only check part of the address. See \cite{ZIP-316} for full details.
} %nufive


\nufive{
\vspace{-1ex}
\lsubsubsubsection{\OrchardText{} Raw Payment Addresses}{orchardpaymentaddrencoding}

\vspace{-2ex}
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.

An \Orchard{} \defining{\shieldedPaymentAddress} consists of $\Diversifier \typecolon \DiversifierType$
and $\DiversifiedTransmitPublic \typecolon \KAPublic{Orchard}$.

$\DiversifiedTransmitPublic$ is an encoding of a $\KA{Orchard}$ \publicKey of type
$\KAPublic{Orchard}$, for use with the encryption scheme defined in \crossref{saplingandorchardinband}.
$\Diversifier$~is a sequence of $11$ bytes. These components are derived as described in
\crossref{orchardkeycomponents}.

\introlist
\vspace{0.5ex}
The \rawEncoding of an \Orchard \shieldedPaymentAddress consists of:
\vspace{0.5ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{344}
    \sbitbox{120}{$\LEBStoOSPOf{88}{\Diversifier}$}
    \sbitbox{256}{$\LEBStoOSP{256}\big(\reprP\Of{\DiversifiedTransmitPublic}\kern-0.1em\big)$}
\end{bytefield}
\end{equation*}

\vspace{-1.5ex}
\begin{itemize}
  \item $11$ bytes specifying $\Diversifier$.
  \item $32$ bytes specifying the \swCompressedEncoding of
        $\DiversifiedTransmitPublic$ (see \crossref{pallasandvesta}\rlap{).}
\end{itemize}

\vspace{-1ex}
When decoding the representation of $\DiversifiedTransmitPublic$, the address \MUST be
considered invalid if $\abstP$ returns $\bot$ or $\ZeroP$.

There is no \BechOptm encoding defined for an individual \Orchard \shieldedPaymentAddress;
instead use a \unifiedPaymentAddress as defined in \cite{ZIP-316}.
} %nufive


\nufive{
\vspace{-1ex}
\lsubsubsubsection{\OrchardText{} Raw Incoming Viewing Keys}{orchardinviewingkeyencoding}

\vspace{-2.5ex}
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.

\vspace{-0.5ex}
An \Orchard{} \defining{\incomingViewingKey} consists of a \diversifierKey $\DiversifierKey$,
and a $\KAPrivate{Orchard}$ key $\InViewingKey$ restricted to the range $\InViewingKeyTypeOrchard$.
It is derived as described in \crossref{orchardkeycomponents}, and is used with the
encryption scheme defined in \crossref{saplingandorchardinband}.

Let $\ItoLEOSP{}$ be as defined in \crossref{endian}.

\introlist
\vspace{0.5ex}
The \rawEncoding of an \Orchard \incomingViewingKey consists of:
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{256}
    \sbitbox{256}{$\DiversifierKey$}
    \sbitbox{256}{$\ItoLEOSPOf{256}{\InViewingKey}$}
\end{bytefield}
\end{equation*}

\vspace{-2.5ex}
\begin{itemize}
  \item $32$ bytes specifying $\DiversifierKey$.
  \item $32$ bytes (\littleEndian) specifying $\InViewingKey$.
\end{itemize}

\vspace{-1.5ex}
$\InViewingKey$ \MUST be in the range $\InViewingKeyTypeOrchard$ as specified
in \crossref{orchardkeycomponents}. That is, a decoded \incomingViewingKey \MUST be
considered invalid if $\InViewingKey$ is not in this range.

There is no \BechOptm encoding defined for an individual \Orchard \incomingViewingKey;
instead use a \unifiedIncomingViewingKey as defined in \cite{ZIP-316}.
} %nufive


\nufive{
\vspace{-1ex}
\lsubsubsubsection{\OrchardText{} Raw Full Viewing Keys}{orchardfullviewingkeyencoding}

\vspace{-2.5ex}
Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}.

\vspace{-0.5ex}
Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}.

An \Orchard{} \defining{\fullViewingKey} consists of $\AuthSignPublic \typecolon \AuthSignPublicTypeOrchard$,
$\NullifierKey \typecolon \NullifierKeyTypeOrchard$, and $\CommitIvkRand \typecolon \GF{\ParamP{r}}$.

$\AuthSignPublic$ is the \authValidatingKey, a result of applying $\ExtractP$ to a
point on the \pallasCurve (see \crossref{pallasandvesta}). $\NullifierKey$ is the
\nullifierDerivingKey, a field element in $\NullifierKeyTypeOrchard$.
$\CommitIvkRand$ is the \commitIvkRandomness, a field element in $\CommitIvkRandType$.
They are derived as described in \crossref{orchardkeycomponents}.

Let $\ItoLEOSP{}$ be as defined in \crossref{endian}.

\introlist
\vspace{0.5ex}
The \rawEncoding of an \Orchard \fullViewingKey consists of:
\begin{equation*}
\begin{bytefield}[bitwidth=0.05em]{512}
    \sbitbox{256}{$\ItoLEOSPOf{256}{\AuthSignPublic}$}
    \sbitbox{256}{$\ItoLEOSPOf{256}{\NullifierKey}$}
    \sbitbox{256}{$\ItoLEOSPOf{256}{\CommitIvkRand}$}
\end{bytefield}
\end{equation*}

\vspace{-2.5ex}
\begin{itemize}
  \item $32$ bytes (\littleEndian) specifying $\AuthSignPublic$.
  \item $32$ bytes (\littleEndian) specifying $\NullifierKey$.
  \item $32$ bytes (\littleEndian) specifying $\CommitIvkRand$.
\end{itemize}

\introlist
\vspace{-1.5ex}
When decoding this representation, the key \MUST be considered invalid if $\AuthSignPublic$,
$\NullifierKey$, or $\CommitIvkRand$ are not canonically encoded elements of their respective
fields, or if $\AuthSignPublic$ is not a valid \Pallas $x$-coordinate, or if either the
external or internal \incomingViewingKeys derived as specified in \crossref{orchardkeycomponents}
are $0$ or $\bot$.

There is no \BechOptm encoding defined for an individual \Orchard \fullViewingKey;
instead use a \unifiedFullViewingKey as defined in \cite{ZIP-316}.
} %nufive


\nufive{
\vspace{-1ex}
\lsubsubsubsection{\OrchardText{} Spending Keys}{orchardspendingkeyencoding}

\vspace{-2ex}
An \Orchard{} \defining{\spendingKey} consists of $\SpendingKey \typecolon \SpendingKeyType$
(see \crossref{orchardkeycomponents}).

\introlist
The \rawEncoding of an \Orchard \spendingKey consists of:
\vspace{0.5ex}
\begin{equation*}
\begin{bytefield}[bitwidth=0.07em]{256}
    \sbitbox{256}{$\LEBStoOSPOf{256}{\SpendingKey}$}
\end{bytefield}
\end{equation*}

\vspace{-1.5ex}
\begin{itemize}
    \item $32$ bytes specifying $\SpendingKey$.
\end{itemize}

\vspace{-1ex}
\Orchard \spendingKeys are encoded using \Bechm (not \Bech).

For \spendingKeys on \Mainnet, the \humanReadablePart is \ascii{secret-orchard-sk-main}.
For \spendingKeys on \Testnet, the \humanReadablePart is \ascii{secret-orchard-sk-test}.
} %nufive


\introlist
\vspace{-1ex}
\lsubsection{\BCTVText{} zk-SNARK Parameters}{bctvparameters}

\vspace{-1ex}
The \shaHash hashes of the \provingKey and \verifyingKey for the \Sprout \joinSplitCircuit,
encoded in \libsnark format, are:

\vspace{-1ex}
\begin{lines}
  \item[] \texttt{8bc20a7f013b2b58970cddd2e7ea028975c88ae7ceb9259a5344a16bc2c0eef7  sprout-proving.key}
  \item[] \texttt{4bd498dae0aacfd8e98dc306338d017d9c08dd0918ead18172bd0aec2fc5df82  sprout-verifying.key}
\end{lines}

\vspace{-0.5ex}
These parameters were obtained by a \multiPartyComputation described in
\cite{BGG-mpc} and \cite{BGG2017}. \sapling{They are used only before \Sapling
activation.} Due to the security vulnerability described in \crossref{bctv}, it is
not recommended to use these parameters in new protocols, and it is recommended to
stop using them in protocols other than \Zcash where they are currently used.


\sapling{
\introsection
\lsubsection{\GrothText{} zk-SNARK Parameters}{grothparameters}

\bellman \cite{Bowe-bellman} encodes the \provingKey and \verifyingKey for a
\zkSNARKCircuit in a single parameters file. The $\BlakeTwob{512}$ hashes of this file
for the \Sapling \spendCircuit and \outputCircuit, and for the implementation of
the \Sprout \joinSplitCircuit used after \Sapling activation, are respectively:

\vspace{-1ex}
\begin{lines}
  \item[] \texttt{8270785a1a0d0bc77196f000ee6d221c9c9894f55307bd9357c3f0105d31ca63} \\
          \texttt{991ab91324160d8f53e2bbd3c2633a6eb8bdf5205d822e7f3f73edac51b2b70c  sapling-spend.params}
  \item[] \texttt{657e3d38dbb5cb5e7dd2970e8b03d69b4787dd907285b5a7f0790dcc8072f60b} \\
          \texttt{f593b32cc2d1c030e00ff5ae64bf84c5c3beb84ddc841d48264b4a171744d028  sapling-output.params}
  \item[] \texttt{e9b238411bd6c0ec4791e9d04245ec350c9c5744f5610dfcce4365d5ca49dfef} \\
          \texttt{d5054e371842b3f88fa1b9d7e8e075249b3ebabd167fa8b0f3161292d36c180a  sprout-groth16.params}
\end{lines}

These parameters were obtained by a \multiPartyComputation described in \cite{BGM2017}.
} %sapling


\sapling{
\introsection
\lsubsection{Randomness Beacon}{beacon}

Let $\URS := \ascii{096b36a5804bfacef1691e173c366a47ff5ba84a44f26ddd7e8d9f79d5b42df0}$.

This value is used in the definition of $\GroupJHash{}$ in \crossref{concretegrouphashjubjub},
and in the \multiPartyComputation to obtain the \Sapling parameters given in
\crossref{grothparameters}.

\introlist
It is derived as described in \cite{Bowe2018}:

\begin{itemize}
  \item Take the hash of the \Bitcoin \block at height $514200$ in \rpcByteOrder,
        i.e.\ the \bigEndian $32$-byte representation of $\hexint{00000000000000000034b33e842ac1c50456abe5fa92b60f6b3dfc5d247f7b58}$.
  \item Apply \shaHash $2^{42}$ times.
  \item Convert to a \xUSASCII lowercase hexadecimal string.
\end{itemize}

\vspace{-2ex}
\pnote{$\URS$ is a $64$-byte \xUSASCII string, i.e.\ the first byte is \hexint{30}, not \hexint{09}.}
} %sapling


\intropart
\lsection{Network Upgrades}{networkupgrades}

\Zcash launched with a protocol revision that we call \defining{\Sprout}.

\overwinter{A first upgrade, called \defining{\Overwinter}, activated on \Mainnet on 26~June, 2018
at \blockHeight $347500$ \cite{Swihart2018}. Its specifications are
described in this document, \cite{ZIP-201}, \cite{ZIP-202}, \cite{ZIP-203}, and \cite{ZIP-143}.}

\sapling{A second upgrade, called \defining{\Sapling}, activated on \Mainnet on 28~October, 2018
at \blockHeight $419200$ \cite{Hamdon2018}. Its specifications are
described in this document, \cite{ZIP-205}, and \cite{ZIP-243}.}

\blossom{A third upgrade, called \defining{\Blossom}, activated on \Mainnet on 11~December, 2019
at \blockHeight $653600$ \cite{Zcash-Blossom}. Its specifications are
described in this document, \cite{ZIP-206}, and \cite{ZIP-208}.}

\heartwood{A fourth upgrade, called \defining{\Heartwood}, activated on \Mainnet on 16~July, 2020
at \blockHeight $903000$ \cite{Zcash-Heartwd}. Its specifications are
described in this document, \cite{ZIP-250}, \cite{ZIP-213}, and \cite{ZIP-221}.}

\canopy{A fifth upgrade, called \defining{\Canopy}, activated on \Mainnet on 18~November, 2020
at \blockHeight $1046400$ (coinciding with the first \blockSubsidy \halving)
\cite{Zcash-Canopy}. Its specifications are described in this document,
\cite{ZIP-251}, \cite{ZIP-207}, \cite{ZIP-211}, \cite{ZIP-212}, \cite{ZIP-214}, and \cite{ZIP-215}.}

\nufive{A sixth upgrade, called \defining{\NUFive}, activated on \Mainnet on 31~May, 2022
at \blockHeight $1687104$ \cite{Zcash-Nu5}. Its specifications are described in this document,
\cite{ZIP-252}, \cite{ZIP-216}, \cite{ZIP-221}, \cite{ZIP-224}, \cite{ZIP-225}, \cite{ZIP-239},
\cite{ZIP-244}, and \cite{ZIP-316}, with updates to \cite{ZIP-32}, \cite{ZIP-203}, \cite{ZIP-209},
\cite{ZIP-212}, \cite{ZIP-213}, and \cite{ZIP-221}.
Additional information and rationale is given in \cite{Zcash-Orchard} and \cite{Zcash-halo2}.}

\introlist
\vspace{1ex}
This section summarizes the strategy for upgrading from \Sprout to subsequent versions
of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, and \NUFive),
and for future upgrades.

\defining{The \networkUpgrade mechanism is described in \cite{ZIP-200}.}

Each \networkUpgrade is introduced as a
\definingquotedterm{bilateral consensus rule change}. In this kind of upgrade,

\begin{itemize}
  \item there is an \defining{\activationHeight} at which the \consensusRuleChange
        takes effect;
  \item \blocks and \transactions that are valid according to
        the post-upgrade rules are not valid before the upgrade
        \blockHeight;
  \item \blocks and \transactions that are valid according to
        the pre-upgrade rules are no longer valid at or after the
        \activationHeight.
\end{itemize}

Full support for each \networkUpgrade is indicated by a minimum version
of the \peerToPeerProtocol. At the planned \activationHeight,
nodes that support a given upgrade will disconnect from (and will not
reconnect to) nodes with a protocol version lower than this
minimum. \overwinter{See \cite{ZIP-201} for how this applies to the \Overwinter
upgrade, for example.}

This ensures that upgrade-supporting nodes transition cleanly
from the old protocol to the new protocol. Nodes that do not
support the upgrade will find themselves on a network that uses
the old protocol and is fully partitioned from the upgrade-supporting
network. This allows us to specify arbitrary protocol changes that
take effect at a given \blockHeight.

Note, however, that a
\blockChainReorganization across the upgrade \activationHeight is possible.
In the case of such a reorganization, \blocks at a height
before the \activationHeight will still be created and
validated according to the pre-upgrade rules, and
upgrade-supporting nodes \MUST allow for this.

%\todo{how upgrade-dependent rules are described in this specification.}


\intropart
\lsection{Consensus Changes from \BitcoinText}{consensusfrombitcoin}

\vspace{-1.5ex}
\extralabel{txnencodingandconsensus}{\lsubsection{Transaction Encoding and Consensus}{txnencoding}}

\vspace{-0.5ex}
The \Zcash{} \defining{\transaction} format up to and including \transactionVersion $4$ is as follows
(this should be read in the context of consensus rules later in the section):

\begin{center}
\scalebox{0.8}{
\renewcommand{\arraystretch}{1.3}
\hbadness=10000
\begin{tabularx}{1.21\textwidth}{|c|c|l|p{10em}|L|}
\hline
\!\!Version$\footnotestar$\!\!\! & \heading{Bytes} & \heading{Name} & \heading{Data Type} & \heading{Description} \\
\hhline{|=====|}

$\barerange{1}{4}$ & $4$ & $\headerField$ & \type{uint32} & Contains: \begin{compactitemize}
                                                    \item $\fOverwintered$ flag (bit $31$)
                                                    \item $\versionField$ (bits $\barerange{30}{0}$) --
                                                          \transactionVersion.
                                                  \end{compactitemize} \\ \hline

\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 \transparentInputs.\! \\ \hline

$\barerange{1}{4}$ & \Varies & $\txIn$ & $\txIn$ & \xTransparent inputs, encoded as in \Bitcoin.\! \\ \hline

$\barerange{1}{4}$ & \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparentOutputs.\! \\ \hline

$\barerange{1}{4}$ & \Varies & $\txOut$ & $\txOut$ & \xTransparent outputs, encoded as in \Bitcoin.\! \\ \hline

$\barerange{1}{4}$ & $4$ & $\lockTime$ & \type{uint32} & Unix-epoch UTC time or \blockHeight, encoded as in \Bitcoin.\! \\ \hline

\setoverwinter $\barerange{3}{4}$ &\setoverwinter $4$ &\setoverwinter $\nExpiryHeight$ &\overwintertype{uint32} &\setoverwinter
A \blockHeight after which the \transaction will expire, or $0$ to disable expiry.
\smash{\cite{ZIP-203}} \\ \hline

\setsapling $4$ &\setsapling $8$ &\setsapling $\valueBalance{Sapling}\!$ &\saplingtype{int64} &\setsapling
The net value of \Sapling{} spends minus outputs.\! \\ \hline

\setsapling $4$ &\setsapling \Varies &\setsapling $\nSpendsSapling$ &\saplingtype{compactSize} &\setsapling
The number of \spendDescriptions in $\vSpendsSapling$.\! \\ \hline

\setsapling $4$ &\setsapling \Longunderstack{$384 \mult$ \\$\!\nSpendsSapling\!$} &\setsapling $\vSpendsSapling$ &\saplingtype{SpendDescriptionV4} \saplingtype{[$\nSpendsSapling$]} &\setsapling
A sequence of \spendDescriptions{}, encoded per \crossref{spendencodingandconsensus}.\! \\ \hline

\setsapling $4$ &\setsapling \Varies &\setsapling $\nOutputsSapling\!$ &\saplingtype{compactSize} &\setsapling
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

$\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 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

$\barerange{2}{4}\;\dagger$ & $32$ & $\joinSplitPubKey\!$ & \type{byte[32]} &
An encoding of a $\JoinSplitSig$ public \validatingKey.\! \\ \hline

$\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

\setsapling $4\;\ddagger$ &\setsapling $64$ &\setsapling $\bindingSig{Sapling}$ &\saplingtype{byte[64]} &\setsapling
A \saplingBindingSignature on the \sighashTxHash, validated as specified in \crossref{concretebindingsig}.\! \\ \hline

\end{tabularx}
\renewcommand{\arraystretch}{\defaultarraystretch}
} %scalebox
\end{center}

\vspace{-1.5ex}
\begin{tabularx}{\textwidth}{@{}l@{\hskip 1em}X@{}}
$\footnotestar$ & Version constraints apply to the $\effectiveVersion$, which is equal to
$\minimum(2, \versionField)$ when $\fOverwintered = 0$ and to $\versionField$ otherwise.
\nufive{If $\effectiveVersion \geq 5$ once $\headerField$ has been parsed, the remainder of the
\transaction encoding \MUST be parsed according to the v5 format described in the next table.}
The consensus rules later in this section specify constraints on $\nVersionGroupId$
depending on $\effectiveVersion$. \\

$\dagger$ & The \joinSplitPubKey{} and \joinSplitSig{} fields are present if and only if
$\effectiveVersion \geq 2$ and $\nJoinSplit > 0$. \\

\setsapling $\ddagger$ & \textcolor{\saplingcolor}{\bindingSig{Sapling} is present if and only if
$\effectiveVersion = 4$ and $\nSpendsSapling + \nOutputsSapling > 0$.}
\end{tabularx}

\sapling{
Note that the \valueBalance{Sapling} field is always present for these \transactionVersions.

\vspace{-1ex}
\begin{flushleft}
Several \Sapling fields have been renamed from previous versions of this specification:
$\valueBalance{} \rightarrow \valueBalance{Sapling}$;
$\nShieldedSpend \rightarrow \nSpendsSapling$; $\vShieldedSpend \rightarrow \vSpendsSapling$;
$\nShieldedOutput \rightarrow \nOutputsSapling$; $\vShieldedOutput \rightarrow \vOutputsSapling$;
$\bindingSig{} \rightarrow \bindingSig{Sapling}$.
\end{flushleft}
} %sapling

\nufive{
\introlist
The \Zcash{} \defining{\transaction} format for \transactionVersion 5 is as follows
(this should be read in the context of consensus rules later in the section):
\vspace{-1.2ex}
\begin{center}
\scalebox{0.76}{
\renewcommand{\arraystretch}{1.28}
\hbadness=10000
\begin{tabularx}{1.27\textwidth}{|c|c|l|p{11.1em}|L|}
\hline
\!\!Note\!\! & \heading{Bytes} & \heading{Name} & \heading{Data Type} & \heading{Description} \\
\hhline{|=====|}

& $4$ & $\headerField$ & \type{uint32} & Contains: \begin{compactitemize}
                                                    \item $\fOverwintered$ flag (bit $31$, always set)
                                                    \item $\versionField$ (bits $\barerange{30}{0}$) --
                                                          \transactionVersion.\!
                                                  \end{compactitemize} \\ \hline

& $4$ & $\nVersionGroupId\!$ & \type{uint32} & Version group ID (nonzero).\! \\ \hline

& $4$ & $\nConsensusBranchId\!$ & \type{uint32} & \xConsensusBranchID. \\ \hline

& $4$ & $\lockTime$ & \type{uint32} & Unix-epoch UTC time or \blockHeight, encoded as in \Bitcoin\rlap{.} \\ \hline

& $4$ & $\nExpiryHeight$ & \type{uint32} &
A \blockHeight after which the \transaction will expire, or $0$ to disable expiry.
\smash{\cite{ZIP-203}}\! \\
\hhline{|=====|}

& \Varies & $\txInCount$ & \type{compactSize} & Number of \transparentInputs.\! \\ \hline

& \Varies & $\txIn$ & $\txIn$ & \xTransparent inputs, encoded as in \Bitcoin.\! \\ \hline

& \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparentOutputs.\! \\ \hline

& \Varies & $\txOut$ & $\txOut$ & \xTransparent outputs, encoded as in \Bitcoin.\! \\
\hhline{|=====|}

& \Varies & $\nSpendsSapling$ & \type{compactSize} &
The number of \spendDescriptions in $\vSpendsSapling$.\! \\ \hline

& \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{$756 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputsSapling\!$ & \type{OutputDescriptionV5} \type{[$\nOutputsSapling$]} &
A sequence of \outputDescriptions{}, encoded per \crossref{outputencodingandconsensus}.\! \\ \hline

$\dagger$ & $8$ & $\valueBalance{Sapling}\!$ & \type{int64} &
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

& \Longunderstack{$192 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendProofsSapling$ & \type{byte[192]} \type{[$\nSpendsSapling$]} &
Encodings of the \zkSNARKProofs for each \Sapling \spendDescription.\! \\ \hline

& \Longunderstack{$64 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendAuthSigs{Sapling}$ & \type{byte[64]} \type{[$\nSpendsSapling$]} &
Authorizing signatures for each \Sapling \spendDescription.\! \\ \hline

& \Longunderstack{$192 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputProofsSapling$ & \type{byte[192]} \type{[$\nOutputsSapling$]} &
Encodings of the \zkSNARKProofs for each \Sapling \outputDescription.\! \\ \hline

$\dagger$ & $64$ & $\bindingSig{Sapling}$ & \type{byte[64]} &
A \saplingBindingSignature on the \sighashTxHash, validated per \crossref{concretebindingsig}.\! \\
\hhline{|=====|}

& \Varies &\setnufive $\nActionsOrchard\!$ & \type{compactSize} &
The number of \actionDescriptions in $\vActionsOrchard$.\! \\ \hline

& \Longunderstack{$820 \mult$ \\$\!\nActionsOrchard\!$} & $\vActionsOrchard$ & \type{ActionDescription} \type{[$\nActionsOrchard$]} &
A sequence of \actionDescriptions{}, encoded per \crossref{actionencodingandconsensus}.\! \\ \hline

$\mathsection$ & $1$ & $\flagsOrchard$ & \type{byte} &
Contains: \begin{compactitemize}
  \item $\enableSpendsOrchard$ flag (bit $0$)
  \item $\enableOutputsOrchard$ flag (bit $1$)
  \item Reserved, zeros (bits $\barerange{2}{7}$).\!
\end{compactitemize} \\ \hline

$\mathsection$ & $8$ & $\valueBalance{Orchard}\!$ & \type{int64} &
The net value of \Orchard spends minus outputs.\! \\ \hline

$\mathsection$ & $32$ & $\anchorField{Orchard}$ & \type{byte[32]} &
A \merkleRoot of the \Orchard \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Orchard}\big)$.\! \\ \hline

$\mathsection$ & \Varies & $\sizeProofsOrchard$ & \type{compactSize} &
The length of the aggregated \zkSNARKProof $\ProofAction$. Value is $2720 + 2272 \cdot \nActionsOrchard$.\! \\ \hline

$\mathsection$ & \!$\sizeProofsOrchard$\! & $\proofsOrchard$ & \type{byte[$\sizeProofsOrchard$]}\!\! &
The aggregated \zkSNARKProof $\ProofAction$ (see \crossref{halo2}).\! \\ \hline

& \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]} &
An \orchardBindingSignature on the \sighashTxHash, validated per \crossref{concretebindingsig}.\! \\ \hline

\end{tabularx}
\renewcommand{\arraystretch}{\defaultarraystretch}
} %scalebox

\vspace{-0.5ex}
\scalebox{0.86}{
\begin{tabularx}{1.15\textwidth}{@{\!\!}l@{\hskip 1em}X@{}}
$\dagger$ & The fields \valueBalance{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.8ex]

$\ddagger$ & The field \anchorField{Sapling} is present if and only if $\nSpendsSapling > 0$. \\[-0.5ex]

$\mathsection$ & The fields \flagsOrchard, \valueBalance{Orchard}, \anchorField{Orchard},
\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}
\vspace{-1.5ex}
\scalebox{0.86}{
\raggedright\!\!\Transactionversion 5 does not support \joinSplitTransfers.
Several fields are reordered and/or renamed relative to prior versions.}} %scalebox %nufive

\lsubsubsection{Transaction Identifiers}{txnidentifiers}

The \transactionID of a \sapling{version 4} or earlier \transaction is the \shadHash hash
of the \transaction encoding in the \notbeforenufive{pre-v5} format described above.

\nufive{
The \transactionID of a version 5 \transaction is as defined in \cite{ZIP-244}. A v5
\transaction also has a \wtxid (used for example in the \peerToPeerProtocol) as defined
in \cite{ZIP-239}.
} %nufive

\lsubsubsection{Transaction Consensus Rules}{txnconsensus}

\begin{consensusrules}
  \item The \defining{\transactionVersionNumber} \MUST be greater than or equal to $1$.
  \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
        be $\hexint{03C48270}$.}
  \saplingprenufiveitem{The \transactionVersionNumber{} \MUST be $4$, and the \versionGroupID{}
        \MUST be $\hexint{892F2085}$.}
  \nufiveonwarditem{The \transactionVersionNumber \MUST be $4$ or $5$.
        If the \transactionVersionNumber{} is $4$ then the \versionGroupID \MUST be $\hexint{892F2085}$.
        If the \transactionVersionNumber{} is $5$ then the \versionGroupID \MUST be $\hexint{26A7270A}$.}
  \nufiveonwarditem{If $\effectiveVersion \geq 5$, the \nConsensusBranchId{} field \MUST match the
        \consensusBranchID used for \sighashTxHashes, as specified in \cite{ZIP-244}.}
  \presaplingitem{The encoded size of the \transaction \MUST be less than or equal to
        $100000$ bytes.}
  \nufiveonwarditem{\nSpendsSapling, \nOutputsSapling, and \nActionsOrchard{} \MUST all be less
        than $2^{16}$.}
  \presaplingitem{If $\effectiveVersion = 1$ or $\nJoinSplit = 0$, then both \txInCount{} and \txOutCount{} \MUST be nonzero.\!}
  \saplingonwarditem{If $\effectiveVersion < 5$, then at least one of \txInCount, \nSpendsSapling, and \nJoinSplit{} \MUST be nonzero.}
  \saplingonwarditem{If $\effectiveVersion < 5$, then at least one of \txOutCount, \nOutputsSapling, and \nJoinSplit{} \MUST be nonzero.}
  \nufiveonwarditem{If $\effectiveVersion \geq 5$ then this condition \MUST hold: $\txInCount > 0$ or \mbox{$\nSpendsSapling > 0$} or
        $(\nActionsOrchard > 0$ and $\enableSpendsOrchard = 1)$.}
  \nufiveonwarditem{If $\effectiveVersion \geq 5$ then this condition \MUST hold: $\txOutCount > 0$ or \mbox{$\nOutputsSapling > 0$} or
        $(\nActionsOrchard > 0$ and $\enableOutputsOrchard = 1)$.}
  \nufiveonwarditem{If $\effectiveVersion \geq 5$ and $\nActionsOrchard > 0$, then at least one of
        $\enableSpendsOrchard$ and $\enableOutputsOrchard$ \MUST be $1$.}
  \item A \transaction with one or more \transparentInputs from \coinbaseTransactions \MUST have no
        \transparentOutputs (i.e.\ \txOutCount{} \MUST be $0$). Inputs from
        \coinbaseTransactions include \foundersReward outputs\canopy{ and \fundingStream outputs}.
  \item If $\effectiveVersion \geq 2$ and $\nJoinSplit > 0$, then:
        \begin{itemize}
          \item \joinSplitPubKey{} \MUST be a valid encoding (see \crossref{concretejssig}) of
                an \EdSpecific \validatingKey.
          \item \joinSplitSig{} \MUST represent a valid signature under \joinSplitPubKey{} of
                $\dataToBeSigned$, as defined in \crossref{sproutnonmalleability}.
        \end{itemize}
        \vspace{-1ex}
        \introlist
  \saplingonwarditem{If $\effectiveVersion \geq 4$ and $\nSpendsSapling + \nOutputsSapling > 0$,
        then:
        \begin{itemize}
          \item let $\BindingPublic{Sapling}$ and $\SigHash$ be as defined in \crossref{saplingbalance};
          \item \bindingSig{Sapling} \MUST represent a valid signature under the \txBindingValidatingKey
                $\BindingPublic{Sapling}$ of $\SigHash$ ---
                i.e.\ $\BindingSigValidate{Sapling}{\BindingPublic{Sapling}}(\SigHash, \bindingSig{Sapling}) = 1$.
                \nufiveonward{As specified in \crossref{concretereddsa}, the validation of the $\RedDSAReprR{}$
                component of the signature changes to prohibit \nonCanonicalPoint encodings.}
        \end{itemize}}
        \vspace{-1ex}
  \saplingonwarditem{If $\effectiveVersion = 4$ and there are no \spendDescriptions or \outputDescriptions,
        then $\valueBalance{Sapling}$ \MUST be $0$.}
  \nufiveonwarditem{If $\effectiveVersion \geq 5$ and $\nActionsOrchard > 0$,
        then:
        \begin{itemize}
          \item let $\BindingPublic{Orchard}$ and $\SigHash$ be as defined in \crossref{orchardbalance};
          \item \bindingSig{Orchard} \MUST represent a valid signature under the \txBindingValidatingKey
                $\BindingPublic{Orchard}$ of $\SigHash$ ---
                i.e.\ $\BindingSigValidate{Orchard}{\BindingPublic{Orchard}}(\SigHash, \bindingSig{Orchard}) = 1$.
                As specified in \crossref{concretereddsa}, validation of the $\RedDSAReprR{}$ component
                of the signature prohibits \nonCanonicalPoint encodings.
        \end{itemize}}
        \vspace{-1ex}
  \item The total value in \zatoshi of \transparentOutputs from a \coinbaseTransaction\heartwood{, minus
        $\vBalance{Sapling}$,}\nufive{ minus $\vBalance{Orchard}$,} \MUSTNOT be greater than the value in
        \zatoshi of \blockSubsidy plus the \transactionFees paid by \transactions in this \block.
  \item A \coinbaseTransaction \MUSTNOT have any \joinSplitDescriptions.
  \item \sapling{A \coinbaseTransaction \MUSTNOT have any \spendDescriptions.}
  \preheartwooditem{\sapling{A \coinbaseTransaction \MUSTNOT have any \outputDescriptions.}}
  \nufiveonwarditem{In a version 5 \coinbaseTransaction, the \enableSpendsOrchard{} flag \MUST be $0$.}
  \nufiveonwarditem{In a version 5 \transaction, the reserved bits $\barerange{2}{7}$ of the
        \flagsOrchard{} field \MUST be zero.}
  \item A \coinbaseTransaction for a \block at \blockHeight greater than $0$ \MUST have a script that,
        as its first item, encodes the \blockHeight $\BlockHeight$ as follows. For $\BlockHeight$ in
        the range $\range{1}{16}$, the encoding is a single byte of value $\hexint{50} + \BlockHeight$.
        Otherwise, let $\heightBytes$ be the signed \littleEndian representation of $\BlockHeight$,
        using the minimum nonzero number of bytes such that the most significant byte is $< \hexint{80}$.
        The length of $\heightBytes$ \MUST be in the range $\range{1}{5}$. Then the encoding is the
        length of $\heightBytes$ encoded as one byte, followed by $\heightBytes$ itself. This matches
        the encoding used by \Bitcoin in the implementation of \cite{BIP-34} (but the description here
        is to be considered normative).
  \item A \coinbaseTransaction script \MUST have length in $\range{2}{100}$ bytes.
  \item A \transparentInput in a non-coinbase \transaction \MUSTNOT have a null \prevout.
  \item Every non-null \prevout \MUST point to a unique \utxo in either a preceding \block, or a
        \emph{previous} \transaction in the same \block.
  \item %\consensuslink{bad-txns-premature-spend-of-coinbase}
        A \transaction \MUSTNOT spend a \transparentOutput of a \coinbaseTransaction
        from a \block less than 100 \blocks prior to the spend. Note that \transparentOutputs of
        \coinbaseTransactions include \foundersReward outputs \canopy{and \transparent \fundingStream outputs}.
  \item A \transaction \MUSTNOT spend an output of the \genesisBlock \coinbaseTransaction. (There is one
        such zero-valued output, on each of \Testnet and \Mainnet.)
  \overwinterprenufiveitem{\nExpiryHeight{} \MUST be less than or equal to $499999999$.}
  \nufiveonwarditem{\nExpiryHeight{} \MUST be less than or equal to $499999999$ for non-coinbase \transactions.}
  \overwinteronwarditem{If a \transaction is not a \coinbaseTransaction and its \nExpiryHeight{} field
        is nonzero, then it \MUSTNOT be mined at a \blockHeight greater than its \nExpiryHeight.}
  \nufiveonwarditem{The \nExpiryHeight{} field of a \coinbaseTransaction \MUST be equal to its \blockHeight.}
  \saplingonwarditem{\valueBalance{Sapling} \MUST be in the range $\range{-\MAXMONEY}{\MAXMONEY}$.}
  \nufiveonwarditem{\valueBalance{Orchard} \MUST be in the range $\range{-\MAXMONEY}{\MAXMONEY}$ for version
        5 \transactions.}
  \heartwoodonwarditem{All \SaplingAndOrchard outputs in \coinbaseTransactions \MUST decrypt to a
        \notePlaintext, i.e.\ the procedure in \crossref{decryptovk} does not return $\bot$, using
        a sequence of $32$ zero bytes as the \outgoingViewingKey. (This implies that\canopy{ before
        \Canopy activation,} \Sapling outputs of a \coinbaseTransaction \MUST have \notePlaintextLeadByte
        equal to $\hexint{01}$.)}
  \canopyonwarditem{Any \SaplingOrOrchard output of a \coinbaseTransaction decrypted to a \notePlaintext according
        to the preceding rule \MUST have \notePlaintextLeadByte equal to $\hexint{02}$. (This applies even
        during the ``grace period'' specified in \cite{ZIP-212}.)}
  \item \todo{Other rules inherited from \Bitcoin.}
\end{consensusrules}

The types specified in \crossref{txnencoding} are part of the consensus rules.

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}
  \item Previous versions of this specification defined what is now the \headerField{} field
        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.
  \item The semantics of \transactions with \versionNumber 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 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
        \transactionVersionNumber are consensus rules.}
  \item The \transactionVersionNumber{} \hexint{7FFFFFFF}, and the \versionGroupID{} \hexint{FFFFFFFF},
        are reserved for use in experimental extensions to \transaction format or semantics on private
        testnets. They \MUSTNOT be used on the \Zcash \Mainnet or \Testnet.
  \item Note that a future upgrade might use \emph{any} \transactionVersionNumber\overwinter{ or
        \versionGroupID}.
        It is likely that an upgrade that changes the \transactionVersionNumber\overwinter{ or
        \versionGroupID} will also change the \transaction format, and software that parses
        \transactions \SHOULD take this into account.
  \overwinteronwarditem{The purpose of \defining{\versionGroupID} is to allow unambiguous parsing of
        \quotedtermnoindex{loose} \transactions, independent of the context of a \blockChain.
        Code that parses \transactions is likely to be reused between \defining{\consensusBranches}
        as defined in \cite{ZIP-200}, and in that case the \fOverwintered{} and \versionField{}
        fields alone may be insufficient to determine the format to be used for parsing.}
  \item A \transactionVersionNumber of $2$ does not have the same meaning as in
        \Bitcoin, where it is associated with support for \ScriptOP{CHECKSEQUENCEVERIFY}
        as specified in \cite{BIP-68}. \Zcash was forked from \BitcoinCore v0.11.2
        and does not currently support BIP 68.
  \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
        with \cite{ZIP-213} \shieldedOutputs.}}
\heartwood{
  \item Prior to the \Heartwood \networkUpgrade, it was not possible for \coinbaseTransactions
        to have \shielded outputs, and therefore the ``coinbase maturity'' rule and the requirement
        to spend coinbase outputs only in \transactions with no \transparentOutputs, applied to
        \emph{all} coinbase outputs.
} %heartwood
  \canopyonwarditem{The rule that \Sapling outputs in \coinbaseTransactions \MUST decrypt to a \notePlaintext
        with lead byte $\hexint{02}$, also applies to \fundingStream outputs that specify \Sapling
        \shieldedPaymentAddresses, if there are any.}
  \nufiveonwarditem{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 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
        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-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.
        These \note spending and creation consensus rules are specified as part of the \Orchard
        \actionStatement (\crossref{actionstatement}).}
  \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. The negative case can only occur for \transactions with
        \cite{ZIP-213} \shieldedOutputs.}
  \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
        the security argument for balance preservation.}
  \nufiveonwarditem{The rule that from \NUFive activation, the \nExpiryHeight{} field of a \coinbaseTransaction
        MUST be equal to the \blockHeight, is needed to maintain the property that all \transactions have
        unique \transactionIDs. All non-coinbase \transactions necessarily have some effecting data that
        is unique across all \transactions in a \validBlockChain: either a \txIn{} referring to a previous
        unique \txOut, or a \spendDescription or \actionDescription referring to a unique \nullifier.
        However, \coinbaseTransactions do not necessarily have any such unique \emph{effecting} data; the
        \blockHeight encoded in the coinbase script is unique in a \validBlockChain, but for v5 \transactions,
        it is not included in the \transactionID hash specified by \cite{ZIP-244}. Requiring \nExpiryHeight{}
        to be set to the \blockHeight ensures that the effecting data that contributes to the \transactionID
        is unique, even for v5 \coinbaseTransactions. In order to avoid the \blockHeight being limited to
        $499999999$, we also remove that bound on \nExpiryHeight{} for \coinbaseTransactions. For consistency,
        these changes apply to \emph{all}\! \coinbaseTransactions, not just v5 \coinbaseTransactions.}
\end{pnotes}

\introlist
The changes relative to \Bitcoin version 1 \transactions as described in \cite{Bitcoin-Format} are:

\begin{itemize}
  \item \Transactionversion 0 is not supported.
  \item A version 1 \transaction is equivalent to a version 2 \transaction with
        $\nJoinSplit = 0$.
  \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, these fields have been added: $\nConsensusBranchId$,
        $\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 \transparentInputs, provided
        at least one of $\nJoinSplit$\sapling{, $\nSpendsSapling$,\notnufive{ and}
        $\nOutputsSapling$}\nufive{, and $\nActionsOrchard$} are nonzero.
  \item A consensus rule limiting \transaction size has been added. In \Bitcoin there is
        a corresponding standard rule but no consensus rule.
\end{itemize}

\introsection
\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:

\begin{center}
\hbadness=2200
\begin{tabularx}{0.92\textwidth}{|c|l|l|L|}
\hline
Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
\hhline{|=|=|=|=|}

$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

$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$ & $\commitmentsField$ & \type{byte[32][$\NNew$]} &
A sequence of \noteCommitments for the output \notes $\cmNew{\allNew}$. \\ \hline

$32$ & $\ephemeralKey$ & \type{byte[32]} &
A $\KASproutCurve$ \publicKey $\EphemeralPublic$. \\ \hline

$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

$296\;\dagger$ & $\zkproof$ & \type{byte[296]} &
An encoding of the \zkSNARKProof $\ProofJoinSplit$ (see \crossref{bctv}). \\ \hline

\setsapling $192\;\ddagger$ &\setsapling $\zkproof$ &\setsapling \type{byte[192]} &\setsapling
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

\end{tabularx}
\end{center}

$\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}.

Consensus rules applying to a \joinSplitDescription are given in \crossref{joinsplitdesc}.


\sapling{
\extralabel{spendencoding}{\lsubsection{Spend Description Encoding and Consensus}{spendencodingandconsensus}}

Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.

\vspace{-0.5ex}
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{SpendDescriptionV4}\nufive{ or \type{SpendDescriptionV5}} type:

\vspace{-2.5ex}
\begin{center}
\hbadness=2000
\begin{tabularx}{0.92\textwidth}{|c|l|l|L|}
\hline
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}\kern 0.05em}$. \\ \hline

$32\nufive{\;\dagger}$ & $\anchorField{}$ & \type{byte[32]} &
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

$32$ & $\rkField$ & \type{byte[32]} &
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

$64\nufive{\;\dagger}$ & $\spendAuthSigField$ & \type{byte[64]} &
A signature authorizing this Spend. \\ \hline

\end{tabularx}
\end{center}

\vspace{-1.5ex}
\nufive{$\dagger$ The $\anchorField{}$, $\zkproof$, and $\spendAuthSigField$ fields are only present in a
\spendDescription if the \transactionVersion is $4$. For v5 \transactions, all \spendDescriptions share
the same \anchor, which is encoded once as the $\anchorField{Sapling}$ field of the \transaction as
described in \crossref{txnencoding}. The $\zkproof$ and $\spendAuthSigField$ fields have been moved into
$\vSpendProofsSapling$ and $\vSpendAuthSigs{Sapling}$ respectively for v5.}

\vspace{-2ex}
\consensusrule{$\LEOStoIPOf{256}{\anchorField{Sapling}}$\nufive{, if present,} \MUST be less than $\ParamJ{q}$.}

\vspace{-0.5ex}
Other consensus rules applying to a \spendDescription are given in \crossref{spenddesc}.

\introsection
\vspace{-2ex}
\extralabel{outputencoding}{\lsubsection{Output Description Encoding and Consensus}{outputencodingandconsensus}}

\vspace{-1ex}
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{OutputDescriptionV4}\nufive{ or \type{OutputDescriptionV5}} type:

\vspace{-2.5ex}
\begin{center}
\hbadness=2000
\begin{tabularx}{0.92\textwidth}{|c|l|l|L|}
\hline
Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
\hhline{|=|=|=|=|}

$32$ & $\cvField$ & \type{byte[32]} & A \valueCommitment to the value of the output \note,
$\LEBStoOSPOf{256}{\reprJ\Of{\cv}\kern 0.05em}$. \\ \hline

$32$ & $\cmuField$ & \type{byte[32]} & The $u$-coordinate of the \noteCommitment for the output \note,
$\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}\kern 0.05em}$. \\ \hline

$580$ & $\encCiphertext$ & \type{byte[580]} & A ciphertext component for the
encrypted output \note, $\TransmitCiphertext{}$. \\ \hline

$80$ & $\outCiphertext$ & \type{byte[80]} & A ciphertext component that allows the holder of
the \outgoingCipherKey to recover the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$
and \ephemeralPrivateKey $\EphemeralPrivate$, hence the entire \notePlaintext. \\ \hline

$192\nufive{\;\dagger}$ & $\zkproof$ & \type{byte[192]} & An encoding of the \zkSNARKProof
$\ProofOutput$ (see \crossref{groth}). \\ \hline

\end{tabularx}
\end{center}

\vspace{-1.5ex}
\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.}

\introlist
The $\ephemeralKey$, $\encCiphertext$, and $\outCiphertext$ fields together form the
\noteCiphertextSapling, which is computed as described in \crossref{saplinginband}.

\vspace{-1ex}
\consensusrule{$\LEOStoIPOf{256}{\cmuField}$ \MUST be less than $\ParamJ{q}$.}

Other consensus rules applying to an \outputDescription are given in \crossref{outputdesc}.
} %sapling


\nufive{
\introsection
\lsubsection{Action Description Encoding and Consensus}{actionencodingandconsensus}

Let $\LEBStoOSP{}{}$ be as defined in \crossref{endian}.

\vspace{-0.5ex}
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:

\vspace{-1.5ex}
\begin{center}
\hbadness=2000
\begin{tabularx}{0.92\textwidth}{|c|l|l|L|}
\hline
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, $\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 $\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,
$\LEBStoOSPOf{256}{\cmX}$ where $\cmX = \ExtractP(\cm)$. \\ \hline

$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
encrypted output \note, $\TransmitCiphertext{}$. \\ \hline

$80$ & $\outCiphertext$ & \type{byte[80]} & A ciphertext component that allows the holder of
the \outgoingCipherKey (which can be derived from a \fullViewingKey) to recover the recipient
\diversifiedTransmissionKey $\DiversifiedTransmitPublic$ and the \ephemeralPrivateKey
$\EphemeralPrivate$, hence the entire \notePlaintext. \\ \hline

\end{tabularx}
\end{center}

The $\ephemeralKey$, $\encCiphertext$, and $\outCiphertext$ fields together form the
\noteCiphertextOrchard, which is computed as described in \crossref{saplinginband}.

\vspace{-1ex}
\consensusrule{$\LEOStoIPOf{256}{\cmxField}$ \MUST be less than $\ParamP{q}$.}

Other consensus rules applying to an \actionDescription are given in \crossref{actiondesc}.
} %nufive


\introsection
\lsubsection{Block Header Encoding and Consensus}{blockheader}

The \Zcash{} \defining{\blockHeader} format is as follows (this should be read in the context
of consensus rules later in the section):

\begin{center}
\hbadness=5000
\begin{tabularx}{0.965\textwidth}{|c|l|p{8em}|L|}
\hline
Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\
\hhline{|=|=|=|=|}

$4$ & $\nVersion$ & \type{int32} & \defining{The \blockVersionNumber indicates which set of
\block validation rules to follow.} The current and only defined \blockVersionNumber
for \Zcash is $4$. \\ \hline

$32$ & $\hashPrevBlock$ & \type{byte[32]} & A \shadHash hash in internal byte order of the
previous \block's \header. This ensures no previous \block can be changed without also
changing this \block's \header. \\ \hline

$32$ & $\hashMerkleRoot$ & \type{byte[32]} & A \shadHash hash in internal byte order. The
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$}
\notbeforenufive{/}\\ \nufive{$\hashBlockCommitments$}} &
\type{byte[32]} &
{\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.\\}
\heartwoodandcanopy{The $\hashChainHistoryRoot$ of this \block \cite{ZIP-221}.\\}
\nufiveonward{The $\hashBlockCommitments$ of this \block \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

$4$ & $\nBitsField$ & \type{uint32} & An encoded version of the \targetThreshold this \block's
\header hash must be less than or equal to, in the same nBits format used by \Bitcoin.
\cite{Bitcoin-nBits} \\ \hline

$32$ & $\nNonce$ & \type{byte[32]} & An arbitrary field that miners can change to modify the
\header hash in order to produce a hash less than or equal to the \targetThreshold. \\ \hline

$3$ & $\solutionSize$ & \type{compactSize} & The size of an \Equihash solution in bytes (always $1344$). \\ \hline

$1344$ & $\solution$ & \type{byte[1344]} & The \Equihash solution. \\ \hline

\end{tabularx}
\end{center}

\vspace{2ex}
A \block consists of a \blockHeader and a sequence of \transactions. How transactions
are encoded in a \block is part of the Zcash \peerToPeerProtocol but not part of
the consensus protocol.

\vspace{1ex}
Let $\ThresholdBits$ be as defined in \crossref{diffadjustment}, and let $\PoWMedianBlockSpan$
be the constant defined in \crossref{constants}.

\defining{Define the \medianTimePast of a \block to be the median (as defined in \crossref{diffadjustment})
of the $\nTimeField$ fields of the \emph{preceding} $\PoWMedianBlockSpan$ \blocks (or all
preceding \blocks if there are fewer than $\PoWMedianBlockSpan$). The \medianTimePast of a
\genesisBlock is not defined.}

\vspace{2ex}
\begin{consensusrules}
  \item The \blockVersionNumber \MUST be greater than or equal to $4$.
  \item For a \block at \blockHeight $\BlockHeight$, $\nBitsField$ \MUST be equal to
        $\ThresholdBits(\BlockHeight)$.
  \item The \block \MUST pass the difficulty filter defined in \crossref{difficulty}.
  \item $\solution$ \MUST represent a \validEquihashSolution as defined in \crossref{equihash}.
  \item For each \block other than the \genesisBlock, $\nTimeField$ \MUST be strictly greater
        than the \medianTimePast of that \block.
  \item For each \block at \blockHeight $2$ or greater on \Mainnet, or \blockHeight
        $653606$ or greater on \Testnet, $\nTimeField$ \MUST be less than or equal to
        the \medianTimePast of that \block plus $90 \mult 60$ seconds.
  \item The size of a \block \MUST be less than or equal to $2000000$ bytes.
\notheartwood{
  \saplingonwarditem{$\hashFinalSaplingRoot$ \MUST be $\LEBStoOSPOf{256}{\rt{Sapling}}$ where
        $\rt{Sapling}$ is the \merkleRoot of the \Sapling \noteCommitmentTree for the final
        \Sapling \treestate of this \block.}
}
\notbeforeheartwood{
  \saplingandblossomitem{$\hashLightClientRoot$ \MUST be $\LEBStoOSP{256}\big(\rt{Sapling}\big)$ where
        $\rt{Sapling}$ is the \merkleRoot of the \Sapling \noteCommitmentTree for the final
        \Sapling \treestate of this \block.}
  \heartwoodandcanopyitem{$\hashLightClientRoot$ \MUST be set to the $\hashChainHistoryRoot$
        for this \block, as specified in \cite{ZIP-221}.}
  \nufiveonwarditem{$\hashBlockCommitments$ \MUST be set to the value of $\hashBlockCommitments$
        for this \block, as specified in \cite{ZIP-244}.}
}
  \item A \block \MUST have at least one \transaction.
  \item The first \transaction in a \block \MUST be a \coinbaseTransaction, and subsequent
        \transactions \MUSTNOT be \coinbaseTransactions.
  \item \todo{Other rules inherited from \Bitcoin.}
\end{consensusrules}

In addition, a \fullValidator \MUSTNOT accept \blocks with $\nTimeField$ more than two hours
in the future according to its clock. This is not strictly a consensus rule because it is
nondeterministic, and clock time varies between nodes. Also note that a \block that is
rejected by this rule at a given point in time may later be accepted.

\begin{pnotes}
        \vspace{-0.5ex}
  \item The semantics of blocks with \blockVersionNumber{} not equal to $4$
        is not currently defined. Miners \MUSTNOT create such \blocks.
        \vspace{-0.5ex}
  \item The exclusion of \blocks with \blockVersionNumber{} \emph{greater than} $4$
        is not a consensus rule; such \blocks may exist in the \blockChain
        and \MUST be treated identically to version 4 \blocks by \fullValidators.
        Note that a future upgrade might use \blockVersionNumber{} either
        greater than or less than $4$. It is likely that such an upgrade will
        change the \block header and/or \transaction format, and software that
        parses \blocks \SHOULD take this into account.
        \vspace{-0.5ex}
  \item The $\nVersion$ field is a signed integer. (It was specified
        as unsigned in a previous version of this specification.) A future
        upgrade might use negative values for this field, or otherwise change
        its interpretation.
        \vspace{-0.5ex}
  \item There is no relation between the values of the $\versionField$ field of a \transaction,
        and the $\nVersion$ field of a \blockHeader.
        \vspace{-0.5ex}
  \item Like other serialized fields of type $\type{compactSize}$, the $\solutionSize$ field \MUST
        be encoded with the minimum number of bytes ($3$ in this case), and other encodings
        \MUST be rejected. This is necessary to avoid a potential attack in which a miner
        could test several distinct encodings of each \Equihash solution against the difficulty
        filter, rather than only the single intended encoding.
        \vspace{-0.5ex}
  \item As in \Bitcoin, the $\nTimeField$ field \MUST represent a time \emph{strictly greater than}
        the median of the timestamps of the past $\PoWMedianBlockSpan$ \blocks. The
        Bitcoin Developer Reference \cite{Bitcoin-Block} was previously in error on this point,
        but has now been corrected.
        \vspace{-0.5ex}
  \item The rule limiting $\nTimeField$ to be no later than $90 \mult 60$ seconds after the
        \medianTimePast is a retrospective consensus change, applied as a soft fork in
        \zcashdref{v2.1.1-1}. It had not been violated by any \block from the given \blockHeights
        in the consensus \blockChains of either \Mainnet or \Testnet.
\overwinter{
        \vspace{-0.5ex}
  \item There are no changes to the \blockVersionNumber or format for \Overwinter.
} %overwinter
\sapling{
        \vspace{-0.5ex}
  \item Although the \blockVersionNumber does not change for \Sapling,
        the previously reserved (and ignored) field $\hashReserved$ has been
        repurposed for $\hashFinalSaplingRoot$. There are no other format changes.
} %sapling
\blossom{
        \vspace{-0.5ex}
  \item There are no changes to the \blockVersionNumber or format for \Blossom.
} %blossom
\heartwood{
        \vspace{-0.5ex}
  \item For \Heartwood, the $\hashFinalSaplingRoot$ field is renamed to $\hashLightClientRoot$.
        Once \Heartwood activates, the meaning of this field changes according to \cite{ZIP-221}.
} %heartwood
\canopy{
        \vspace{-0.5ex}
  \item There are no changes to the \blockVersionNumber or format for \Canopy.
} %canopy
\nufive{
        \vspace{-0.5ex}
  \item For \NUFive, the $\hashLightClientRoot$ field is renamed to $\hashBlockCommitments$.
        Once \NUFive activates, the meaning of this field changes according to \cite{ZIP-244}.
} %nufive
\end{pnotes}

\introlist
The changes relative to \Bitcoin version 4 blocks as described in \cite{Bitcoin-Block} are:

\begin{itemize}
        \vspace{-0.5ex}
  \item \Blockversions less than $4$ are not supported.
        \vspace{-0.5ex}
  \item The $\hashReserved$\sapling{ (or $\hashFinalSaplingRoot$)}, $\solutionSize$, and
        $\solution$ fields have been added.
        \vspace{-0.5ex}
  \item The type of the $\nNonce$ field has changed from \type{uint32} to \type{byte[32]}.
        \vspace{-0.5ex}
  \item The maximum \block size has been doubled to $2000000$ bytes.
\end{itemize}


\vspace{-2ex}
\introsection
\lsubsection{Proof of Work}{pow}

\Zcash uses \Equihash \cite{BK2016} as its \proofOfWork. The original motivations for
changing the \proofOfWork from \shadHash used by \Bitcoin were described in \cite{WG2016}.

\vspace{1ex}
\introlist
A \block satisfies the \proofOfWork if and only if:

\begin{itemize}
  \item The $\solution$ field encodes a \validEquihashSolution according to \crossref{equihash}.
  \item The \blockHeader satisfies the difficulty check according to \crossref{difficulty}.
\end{itemize}


\vspace{-1ex}
\introsection
\lsubsubsection{Equihash}{equihash}

An instance of the \defining{\Equihash} algorithm is parameterized by positive integers $n$ and $k$,
such that $n$ is a multiple of $k+1$. We assume $k \geq 3$.

The \Equihash parameters for \Mainnet and \Testnet are $n = 200, k = 9$.

\Equihash is based on a variation of the Generalized Birthday Problem \cite{AR2017}:
given a sequence $X_\barerange{1}{\rmN}$ of $n$-bit strings, find $2^k$ distinct
$X_{i_j}$ such that $\sxor{j=1}{2^k} X_{i_j} = 0$.

In \Equihash, $\rmN = 2^{\frac{n}{k+1}+1}$, and the sequence $X_\barerange{1}{\rmN}$ is
derived from the \blockHeader and a nonce.

\newsavebox{\powheaderbox}
\begin{lrbox}{\powheaderbox}
\begin{bytefield}[bitwidth=0.054em]{1152}
    \sbitbox{136}{$32$-bit $\nVersion$} &
    \sbitbox{256}{$256$-bit $\hashPrevBlock$} &
    \sbitbox{256}{$256$-bit $\hashMerkleRoot$} \\
    \sbitbox{256}{$256$-bit $\hashReserved$} &
    \sbitbox{136}{$32$-bit $\nTimeField$} &
    \sbitbox{136}{$32$-bit $\nBitsField$} &
    \sbitbox{256}{$256$-bit $\nNonce$}
\end{bytefield}
\end{lrbox}

Let $\powheader := \Justthebox[-7.5ex]{\powheaderbox}$

\vspace{1ex}
For $i \in \range{1}{N}$, let $X_i = \EquihashGen{n, k}(\powheader, i)$.

$\EquihashGen{}$ is instantiated in \crossref{equihashgen}.

Define $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \binaryrange{\ell} \rightarrow \bitseq{\ell}$
as in \crossref{endian}.

\introsection
A \defining{\validEquihashSolution} is then a sequence $i \typecolon \range{1}{N}^{2^k}$ that
satisfies the following conditions:

\callout{}{Generalized Birthday condition}
$\vxor{j=1}{2^k} X_{i_j} = 0$.

\callout{}{Algorithm Binding conditions}
\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 \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.
\end{itemize}

\vspace{-1ex}
\begin{pnotes}
  \item This does not include a difficulty condition, because here we are
        defining validity of an \Equihash solution independent of difficulty.
  \item Previous versions of this specification incorrectly specified the
        range of $r$ to be $\range{1}{k\!-\!1}$ for both parts of the algorithm
        binding condition. The implementation in \zcashd was as intended.
\end{pnotes}

\introlist
An \Equihash solution with $n = 200$ and $k = 9$ is encoded in the $\solution$
field of a \blockHeader as follows:

\newsavebox{\solutionbox}
\begin{lrbox}{\solutionbox}
\begin{bytefield}[bitwidth=0.45em]{105}
    \sbitbox{21}{$\ItoBEBSP{21}(i_1-1)$} &
    \sbitbox{21}{$\ItoBEBSP{21}(i_2-1)$} &
    \sbitbox{42}{$\cdots$} &
    \sbitbox{21}{$\ItoBEBSP{21}(i_{512}-1)$}
\end{bytefield}
\end{lrbox}

\newcommand{\zb}{\sbitbox{1}{$0$}}
\newcommand{\ob}{\sbitbox{1}{$1$}}
\newsavebox{\eqexamplebox}
\begin{lrbox}{\eqexamplebox}
\begin{bytefield}[bitwidth=0.75em]{63}
    \sbitbox{21}{$\ItoBEBSP{21}(68)$} &
    \sbitbox{21}{$\ItoBEBSP{21}(41)$} &
    \sbitbox{21}{$\ItoBEBSP{21}(2^{21}-1)$} \\
    \zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\ob\zb\zb\zb\ob\zb\zb
    \zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\zb\ob\zb\ob\zb\zb\ob
    \ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob\ob \\
    \sbitbox{8}{8-bit $0$}
    \sbitbox{8}{8-bit $2$}
    \sbitbox{8}{8-bit $32$}
    \sbitbox{8}{8-bit $0$}
    \sbitbox{8}{8-bit $10$}
    \sbitbox{8}{8-bit $127$}
    \sbitbox{8}{8-bit $255$}
    \sbitbox{7}{$\cdots$}
\end{bytefield}
\end{lrbox}

\begin{formulae}
  \item $\Justthebox{\solutionbox}$
\end{formulae}

\introlist
Recall from \crossref{bitlayout} that the bits in the above diagram are
ordered from most to least significant in each byte.
For example, if the first $3$ elements of $i$ are $[69, 42, 2^{21}]$,
then the corresponding bit array is:

\begin{formulae}
  \item $\Justthebox{\eqexamplebox}$
\end{formulae}

and so the first $7$ bytes of $\solution$ would be
$[0, 2, 32, 0, 10, 127, 255]$.

\pnote{
$\ItoBEBSP{}$ is \bigEndian, while integer field encodings in $\powheader$
and in the instantiation of $\EquihashGen{}$ are \littleEndian.
The rationale for this is that \littleEndian serialization of
\blockHeaders is consistent with \Bitcoin, but \littleEndian
ordering of bits in the solution encoding would require bit-reversal
(as opposed to only shifting).
}

\lsubsubsection{Difficulty filter}{difficulty}

Let $\ToTarget$ be as defined in \crossref{nbits}.

Difficulty is defined in terms of a \targetThreshold, which is adjusted for each
\block according to the algorithm defined in \crossref{diffadjustment}.

The difficulty filter is unchanged from \Bitcoin, and is calculated using
\shadHash on the whole \blockHeader (including $\solutionSize$ and $\solution$).
The result is interpreted as a $256$-bit integer represented in \littleEndian
byte order, which \MUST be less than or equal to the \targetThreshold given by
$\ToTarget(\nBitsField)$.


\lsubsubsection{Difficulty adjustment}{diffadjustment}

The desired time between \blocks is called the \defining{\blockTargetSpacing}.
\Zcash uses a difficulty adjustment algorithm based on DigiShield v3/v4 \cite{DigiByte-PoW},
with simplifications and altered parameters, to adjust difficulty to target
the desired \blockTargetSpacing. Unlike \Bitcoin, the difficulty adjustment occurs
after every \block.

\notbeforeblossom{The constants }$\PoWLimit$, $\PreBlossomHalvingInterval$, $\PoWAveragingWindow$,
$\PoWMaxAdjustDown$, $\PoWMaxAdjustUp$, $\PoWDampingFactor$,\notblossom{ and}
$\PreBlossomPoWTargetSpacing$\blossom{, and $\PostBlossomPoWTargetSpacing$}
are specified in section \crossref{constants}.

Let $\ToCompact$ and $\ToTarget$ be as defined in \crossref{nbits}.

Let $\nTime(\BlockHeight)$ be the value of the $\nTimeField$ field in the \header of the
\block at \blockHeight $\BlockHeight$.

Let $\nBits(\BlockHeight)$ be the value of the $\nBitsField$ field in the \header of the
\block at \blockHeight $\BlockHeight$.

\Blockheader fields are specified in \crossref{blockheader}.

\vspace{1ex}
\introlist
Define:
\vspace{-1ex}
\begin{formulae}
\hfuzz=10pt
  \item $\mean(S) := \hfrac{\ssum{i=1}{\length(S)} S_i}{\length(S)}$
  \item $\median(S) := \sorted(S)_{\sceiling{(\length(S)+1) / 2}}$
  \item $\bound{\Lower}{\Upper}(x) := \maximum(\Lower, \minimum(\Upper, x)))$
  \item $\trunc{x} := \begin{cases}
          \floor{x},&\caseif x \geq 0 \\
          -\floor{-x},&\caseotherwise
        \end{cases}$
\blossom{
  \item $\IsBlossomActivated(\BlockHeight \typecolon \Nat) := (\BlockHeight \geq \BlossomActivationHeight)$
  \item $\BlossomPoWTargetSpacingRatio := \hfrac{\PreBlossomPoWTargetSpacing}{\PostBlossomPoWTargetSpacing}$
  \item $\PostBlossomHalvingInterval := \floor{\PreBlossomHalvingInterval \mult \BlossomPoWTargetSpacingRatio}$
  \item $\PoWTargetSpacingFunc(\BlockHeight \typecolon \Nat) := \begin{cases}
          \PreBlossomPoWTargetSpacing,&\caseif \text{not } \IsBlossomActivated(\BlockHeight) \\
          \PostBlossomPoWTargetSpacing,&\caseotherwise
        \end{cases}$
} %blossom

  \item $\AveragingWindowTimespan\blossom{(\BlockHeight \typecolon \Nat)} := \PoWAveragingWindow \mult \PoWTargetSpacingFunc\blossom{(\BlockHeight)}$
  \item $\MinActualTimespan\blossom{(\BlockHeight \typecolon \Nat)} := \floor{\AveragingWindowTimespan\blossom{(\BlockHeight)} \mult (1 - \PoWMaxAdjustUp)}$
  \item $\MaxActualTimespan\blossom{(\BlockHeight \typecolon \Nat)} := \floor{\AveragingWindowTimespan\blossom{(\BlockHeight)} \mult (1 + \PoWMaxAdjustDown)}$
  \item $\MedianTime(\BlockHeight \typecolon \Nat) :=
          \median(\listcomp{\nTime(i) \for i \from \maximum(0, \BlockHeight - \PoWMedianBlockSpan) \upto \BlockHeight - 1})$
  \item $\ActualTimespan(\BlockHeight \typecolon \Nat) := \MedianTime(\BlockHeight) - \MedianTime(\BlockHeight - \PoWAveragingWindow)$
  \item $\ActualTimespanDamped(\BlockHeight \typecolon \Nat) :=$
        \vspace{-0.8ex}
  \item \tab $\AveragingWindowTimespan\blossom{(\BlockHeight)} + \trunc{\hfrac{\ActualTimespan(\BlockHeight) - \AveragingWindowTimespan\blossom{(\BlockHeight)}}{\PoWDampingFactor}}$
  \item $\ActualTimespanBounded(\BlockHeight \typecolon \Nat) := \bound{\MinActualTimespan\blossom{(\BlockHeight)}}{\MaxActualTimespan\blossom{(\BlockHeight)}}(\ActualTimespanDamped(\BlockHeight))$
  \item $\MeanTarget(\BlockHeight \typecolon \Nat) := \!\begin{cases}
          \PoWLimit, \hspace{16em}\text{if } \BlockHeight \leq \PoWAveragingWindow \\
          \mean(\listcomp{\!\ToTarget(\nBits(i)\kern-0.1em) \for i \from \BlockHeight\!-\!\PoWAveragingWindow \upto \BlockHeight\!-\!1\!}),\\
                     \hspace{20.7em}\text{otherwise.}
        \end{cases}$
\end{formulae}

\introlist
The \targetThreshold for a given \blockHeight $\BlockHeight$ is then calculated as:

\begin{formulae}
  \item $\Threshold(\BlockHeight \typecolon \Nat) \hspace{0.43em} := \hspace{0.3em} \begin{cases}
               \PoWLimit, \hspace{16em}\text{if } \BlockHeight = 0 \\
               \minimum(\PoWLimit, \floor{\hfrac{\MeanTarget(\BlockHeight)}{\AveragingWindowTimespan}}
                                   \mult \ActualTimespanBounded(\BlockHeight)),\\
                          \hspace{20.7em}\text{otherwise}
             \end{cases}$
  \item $\ThresholdBits(\BlockHeight \typecolon \Nat) := \ToCompact(\Threshold(\BlockHeight))$.
\end{formulae}

\begin{pnotes}
  \item The convention used for the height parameters to the functions $\MedianTime$, $\MeanTarget$,
        $\ActualTimespan$, $\ActualTimespanDamped$, $\ActualTimespanBounded$, $\Threshold$, and $\ThresholdBits$
        is that these functions use only information from \blocks \emph{preceding} the given \blockHeight.
  \item When the $\median$ function is applied to a sequence of even length (which only happens
        in the definition of $\MedianTime$ during the first $\PoWAveragingWindow - 1$ \blocks of
        the \blockChain), the element that begins the second half of the sequence is taken.
        This corresponds to the \zcashd implementation, but was not specified correctly in versions
        of this specification prior to \historyref{2019.0.0}.
\end{pnotes}

On \Testnet from \blockHeight $299188$ onward, the difficulty adjustment algorithm
is changed to allow minimum-difficulty \blocks, as described in \cite{ZIP-205}.
\blossom{The \Blossom \networkUpgrade changes the minimum-difficulty time threshold to $6$ times
the \blockTargetSpacing, as described in \cite{ZIP-208}.}
\notbeforeblossom{These changes do}\notblossom{This change does} not apply to \Mainnet.


\introlist
\lsubsubsection{nBits conversion}{nbits}

Deterministic conversions between a \defining{\targetThreshold} and a ``compact" nBits value are not
fully defined in the Bitcoin documentation \cite{Bitcoin-nBits}, and so we define them here:

\begin{formulae}[leftmargin=1.5em,label=]
  \item $\size(x) := \ceiling{\hfrac{\bitlength(x)}{8}}$
  \item $\mantissa(x) := \floor{x \mult 256^{3 - \size(x)}}$
  \item $\ToCompact(x) := \begin{cases}
          \mantissa(x) + 2^{24} \smult \size(x),&\caseif \mantissa(x) < 2^{23} \\
          \floor{\hfrac{\mantissa(x)}{256}} + 2^{24} \smult (\size(x)+1),&\caseotherwise
        \end{cases}$
  \item $\ToTarget(x) := \begin{cases}
          0,&\caseif x \band 2^{23} = 2^{23} \\
          (x \band (2^{23}-1)) \mult 256^{\floor{x / 2^{24}} - 3},&\caseotherwise.
        \end{cases}$
\end{formulae}

\introlist
\vspace{-2ex}
\lsubsubsection{Definition of Work}{workdef}

As explained in \crossref{blockchain}, a node chooses the ``best'' \blockChain
visible to it by finding the chain of valid \blocks with the greatest total work.

Let $\ToTarget$ be as defined in \crossref{nbits}.

The work of a \block with value $\nBits$ for the $\nBitsField$ field
in its \blockHeader is defined as $\floor{\hfrac{2^{256}}{\ToTarget(\nBits) + 1}}$.


\introlist
\vspace{-2ex}
\lsubsection{Calculation of Block Subsidy\notbeforecanopy{, Funding Streams,} and Founders' Reward}{subsidies}

\crossref{subsidyconcepts} defines the \blockSubsidy, \minerSubsidy,\notcanopy{ and} \foundersReward\canopy{, and \fundingStreams}.
Their amounts in \zatoshi are calculated from the \blockHeight using
the formulae below.

Let\notbeforeblossom{ the constants} $\SlowStartInterval$,\, $\PreBlossomHalvingInterval$,\,
\blossom{$\PostBlossomHalvingInterval$,\, $\BlossomActivationHeight$,\, }$\MaxBlockSubsidy$,
and $\FoundersFraction$ be as defined in \crossref{constants}.

\canopy{Let $\FundingStreams$ be as specified in \crossref{zip214fundingstreams}.}

\vspace{1ex}
\begin{formulae}
  \item $\SlowStartShift \typecolon \Nat := \hfrac{\SlowStartInterval}{2}$
  \item $\SlowStartRate \typecolon \Nat := \hfrac{\MaxBlockSubsidy}{\SlowStartInterval}$
        \vspace{0.5ex}
  \item $\Halving(\BlockHeight \typecolon \Nat) := \begin{cases}
          0,&\caseif \BlockHeight < \SlowStartShift \\
        \notblossom{
          \floor{\hfrac{\BlockHeight - \SlowStartShift}{\PreBlossomHalvingInterval}}\kern-0.25em,&\caseotherwise
        } %notblossom
        \notbeforeblossom{
          \floor{\hfrac{\BlockHeight - \SlowStartShift}{\PreBlossomHalvingInterval}}\kern-0.25em,&\blossom{\caseif \text{not } \IsBlossomActivated(\BlockHeight)} \\[1.6ex]
          \multicolumn{2}{@{}l}{\blossom{\floor{\hfrac{\BlossomActivationHeight - \SlowStartShift}{\PreBlossomHalvingInterval} +
                                                \hfrac{\BlockHeight - \BlossomActivationHeight}{\PostBlossomHalvingInterval}}\kern-0.3em,\hspace{0.85em}\caseotherwise}}
        } %notbeforeblossom
        \end{cases}$
        \vspace{1ex}
  \item $\BlockSubsidy(\BlockHeight \typecolon \Nat) := \begin{cases}
          \SlowStartRate \mult \BlockHeight,&\caseif \BlockHeight < \SlowStartShift \\[1.2ex]
          \SlowStartRate \mult (\BlockHeight + 1),&\caseif \SlowStartShift \leq \BlockHeight \\[-0.8ex]
                                                  &\text{ and } \BlockHeight < \SlowStartInterval \\[1.2ex]
          \floor{\hfrac{\MaxBlockSubsidy}{2^{\Halving(\BlockHeight)}}}\kern-0.25em,&\notblossom{\caseotherwise}\notbeforeblossom{\caseif \SlowStartInterval \leq \BlockHeight} \\[-1.4ex]
\notbeforeblossom {
                                                                                   &\blossom{\text{ and not } \IsBlossomActivated(\BlockHeight)}\! \\[1.2ex]
          \blossom{\floor{\hfrac{\MaxBlockSubsidy}{\BlossomPoWTargetSpacingRatio \mult 2^{\Halving(\BlockHeight)}}}\kern-0.25em,}&\blossom{\caseotherwise}
} %notbeforeblossom
        \end{cases}$
        \vspace{0.5ex}
  \item $\FoundersReward(\BlockHeight \typecolon \Nat) := \begin{cases}
          \BlockSubsidy(\BlockHeight) \mult \FoundersFraction,&\caseif \Halving(\BlockHeight) < 1 \\
          0,&\caseotherwise
        \end{cases}$

\canopy {
        \vspace{0.5ex}
  \item for $\fs \in \FundingStreams$,\, $\fsValue(\BlockHeight) :=$
        \vspace{-0.5ex}
  \item \tab $\begin{cases}
          0,&\caseif \BlockHeight < \CanopyActivationHeight \\
          \floor{\BlockSubsidy(\BlockHeight) \mult
            \hfrac{\fsNumerator}{\fsDenominator}},&\caseif \fsStartHeight \leq \BlockHeight
                                                   \text{ and } \BlockHeight < \fsEndHeight \\
          0,&\caseotherwise
        \end{cases}$
} %canopy

  \item $\MinerSubsidy(\BlockHeight) := \BlockSubsidy(\BlockHeight) - \FoundersReward(\BlockHeight)
           \canopy{\,- \ssum{\fs\, \in\, \FundingStreams}{} \fsValue(\BlockHeight)}$.
\end{formulae}


\vspace{-2ex}
\lsubsection{Payment of Founders' Reward}{foundersreward}

\vspace{-1ex}
The \foundersReward is paid by a \transparentOutput in the \coinbaseTransaction, to
one of $\NumFounderAddresses$ \transparentAddresses, depending on the \blockHeight.

\renewcommand{\arraystretch}{1}

For \Mainnet, $\FounderAddressList_{\oneto{\NumFounderAddresses}}$ is:

\scalebox{0.95}{
\begin{tabular}{@{\hskip 2.5em}l@{\;}l}
[& \ascii{t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd}, \ascii{t3cL9AucCajm3HXDhb5jBnJK2vapVoXsop3}, \\
 & \ascii{t3fqvkzrrNaMcamkQMwAyHRjfDdM2xQvDTR}, \ascii{t3TgZ9ZT2CTSK44AnUPi6qeNaHa2eC7pUyF}, \\
 & \ascii{t3SpkcPQPfuRYHsP5vz3Pv86PgKo5m9KVmx}, \ascii{t3Xt4oQMRPagwbpQqkgAViQgtST4VoSWR6S}, \\
 & \ascii{t3ayBkZ4w6kKXynwoHZFUSSgXRKtogTXNgb}, \ascii{t3adJBQuaa21u7NxbR8YMzp3km3TbSZ4MGB}, \\
 & \ascii{t3K4aLYagSSBySdrfAGGeUd5H9z5Qvz88t2}, \ascii{t3RYnsc5nhEvKiva3ZPhfRSk7eyh1CrA6Rk}, \\
 & \ascii{t3Ut4KUq2ZSMTPNE67pBU5LqYCi2q36KpXQ}, \ascii{t3ZnCNAvgu6CSyHm1vWtrx3aiN98dSAGpnD}, \\
 & \ascii{t3fB9cB3eSYim64BS9xfwAHQUKLgQQroBDG}, \ascii{t3cwZfKNNj2vXMAHBQeewm6pXhKFdhk18kD}, \\
 & \ascii{t3YcoujXfspWy7rbNUsGKxFEWZqNstGpeG4}, \ascii{t3bLvCLigc6rbNrUTS5NwkgyVrZcZumTRa4}, \\
 & \ascii{t3VvHWa7r3oy67YtU4LZKGCWa2J6eGHvShi}, \ascii{t3eF9X6X2dSo7MCvTjfZEzwWrVzquxRLNeY}, \\
 & \ascii{t3esCNwwmcyc8i9qQfyTbYhTqmYXZ9AwK3X}, \ascii{t3M4jN7hYE2e27yLsuQPPjuVek81WV3VbBj}, \\
 & \ascii{t3gGWxdC67CYNoBbPjNvrrWLAWxPqZLxrVY}, \ascii{t3LTWeoxeWPbmdkUD3NWBquk4WkazhFBmvU}, \\
 & \ascii{t3P5KKX97gXYFSaSjJPiruQEX84yF5z3Tjq}, \ascii{t3f3T3nCWsEpzmD35VK62JgQfFig74dV8C9}, \\
 & \ascii{t3Rqonuzz7afkF7156ZA4vi4iimRSEn41hj}, \ascii{t3fJZ5jYsyxDtvNrWBeoMbvJaQCj4JJgbgX}, \\
 & \ascii{t3Pnbg7XjP7FGPBUuz75H65aczphHgkpoJW}, \ascii{t3WeKQDxCijL5X7rwFem1MTL9ZwVJkUFhpF}, \\
 & \ascii{t3Y9FNi26J7UtAUC4moaETLbMo8KS1Be6ME}, \ascii{t3aNRLLsL2y8xcjPheZZwFy3Pcv7CsTwBec}, \\
 & \ascii{t3gQDEavk5VzAAHK8TrQu2BWDLxEiF1unBm}, \ascii{t3Rbykhx1TUFrgXrmBYrAJe2STxRKFL7G9r}, \\
 & \ascii{t3aaW4aTdP7a8d1VTE1Bod2yhbeggHgMajR}, \ascii{t3YEiAa6uEjXwFL2v5ztU1fn3yKgzMQqNyo}, \\
 & \ascii{t3g1yUUwt2PbmDvMDevTCPWUcbDatL2iQGP}, \ascii{t3dPWnep6YqGPuY1CecgbeZrY9iUwH8Yd4z}, \\
 & \ascii{t3QRZXHDPh2hwU46iQs2776kRuuWfwFp4dV}, \ascii{t3enhACRxi1ZD7e8ePomVGKn7wp7N9fFJ3r}, \\
 & \ascii{t3PkLgT71TnF112nSwBToXsD77yNbx2gJJY}, \ascii{t3LQtHUDoe7ZhhvddRv4vnaoNAhCr2f4oFN}, \\
 & \ascii{t3fNcdBUbycvbCtsD2n9q3LuxG7jVPvFB8L}, \ascii{t3dKojUU2EMjs28nHV84TvkVEUDu1M1FaEx}, \\
 & \ascii{t3aKH6NiWN1ofGd8c19rZiqgYpkJ3n679ME}, \ascii{t3MEXDF9Wsi63KwpPuQdD6by32Mw2bNTbEa}, \\
 & \ascii{t3WDhPfik343yNmPTqtkZAoQZeqA83K7Y3f}, \ascii{t3PSn5TbMMAEw7Eu36DYctFezRzpX1hzf3M}, \\
 & \ascii{t3R3Y5vnBLrEn8L6wFjPjBLnxSUQsKnmFpv}, \ascii{t3Pcm737EsVkGTbhsu2NekKtJeG92mvYyoN}\, ]
\end{tabular}
} %scalebox

\vspace{1ex}
\introlist
For \Testnet, $\FounderAddressList_{\oneto{\NumFounderAddresses}}$ is:

\scalebox{0.96}{
\begin{tabular}{@{\hskip 2.5em}l@{\;}l}
[& \ascii{t2UNzUUx8mWBCRYPRezvA363EYXyEpHokyi}, \ascii{t2N9PH9Wk9xjqYg9iin1Ua3aekJqfAtE543}, \\
 & \ascii{t2NGQjYMQhFndDHguvUw4wZdNdsssA6K7x2}, \ascii{t2ENg7hHVqqs9JwU5cgjvSbxnT2a9USNfhy}, \\
 & \ascii{t2BkYdVCHzvTJJUTx4yZB8qeegD8QsPx8bo}, \ascii{t2J8q1xH1EuigJ52MfExyyjYtN3VgvshKDf}, \\
 & \ascii{t2Crq9mydTm37kZokC68HzT6yez3t2FBnFj}, \ascii{t2EaMPUiQ1kthqcP5UEkF42CAFKJqXCkXC9}, \\
 & \ascii{t2F9dtQc63JDDyrhnfpzvVYTJcr57MkqA12}, \ascii{t2LPirmnfYSZc481GgZBa6xUGcoovfytBnC}, \\
 & \ascii{t26xfxoSw2UV9Pe5o3C8V4YybQD4SESfxtp}, \ascii{t2D3k4fNdErd66YxtvXEdft9xuLoKD7CcVo}, \\
 & \ascii{t2DWYBkxKNivdmsMiivNJzutaQGqmoRjRnL}, \ascii{t2C3kFF9iQRxfc4B9zgbWo4dQLLqzqjpuGQ}, \\
 & \ascii{t2MnT5tzu9HSKcppRyUNwoTp8MUueuSGNaB}, \ascii{t2AREsWdoW1F8EQYsScsjkgqobmgrkKeUkK}, \\
 & \ascii{t2Vf4wKcJ3ZFtLj4jezUUKkwYR92BLHn5UT}, \ascii{t2K3fdViH6R5tRuXLphKyoYXyZhyWGghDNY}, \\
 & \ascii{t2VEn3KiKyHSGyzd3nDw6ESWtaCQHwuv9WC}, \ascii{t2F8XouqdNMq6zzEvxQXHV1TjwZRHwRg8gC}, \\
 & \ascii{t2BS7Mrbaef3fA4xrmkvDisFVXVrRBnZ6Qj}, \ascii{t2FuSwoLCdBVPwdZuYoHrEzxAb9qy4qjbnL}, \\
 & \ascii{t2SX3U8NtrT6gz5Db1AtQCSGjrpptr8JC6h}, \ascii{t2V51gZNSoJ5kRL74bf9YTtbZuv8Fcqx2FH}, \\
 & \ascii{t2FyTsLjjdm4jeVwir4xzj7FAkUidbr1b4R}, \ascii{t2EYbGLekmpqHyn8UBF6kqpahrYm7D6N1Le}, \\
 & \ascii{t2NQTrStZHtJECNFT3dUBLYA9AErxPCmkka}, \ascii{t2GSWZZJzoesYxfPTWXkFn5UaxjiYxGBU2a}, \\
 & \ascii{t2RpffkzyLRevGM3w9aWdqMX6bd8uuAK3vn}, \ascii{t2JzjoQqnuXtTGSN7k7yk5keURBGvYofh1d}, \\
 & \ascii{t2AEefc72ieTnsXKmgK2bZNckiwvZe3oPNL}, \ascii{t2NNs3ZGZFsNj2wvmVd8BSwSfvETgiLrD8J}, \\
 & \ascii{t2ECCQPVcxUCSSQopdNquguEPE14HsVfcUn}, \ascii{t2JabDUkG8TaqVKYfqDJ3rqkVdHKp6hwXvG}, \\
 & \ascii{t2FGzW5Zdc8Cy98ZKmRygsVGi6oKcmYir9n}, \ascii{t2DUD8a21FtEFn42oVLp5NGbogY13uyjy9t}, \\
 & \ascii{t2UjVSd3zheHPgAkuX8WQW2CiC9xHQ8EvWp}, \ascii{t2TBUAhELyHUn8i6SXYsXz5Lmy7kDzA1uT5}, \\
 & \ascii{t2Tz3uCyhP6eizUWDc3bGH7XUC9GQsEyQNc}, \ascii{t2NysJSZtLwMLWEJ6MH3BsxRh6h27mNcsSy}, \\
 & \ascii{t2KXJVVyyrjVxxSeazbY9ksGyft4qsXUNm9}, \ascii{t2J9YYtH31cveiLZzjaE4AcuwVho6qjTNzp}, \\
 & \ascii{t2QgvW4sP9zaGpPMH1GRzy7cpydmuRfB4AZ}, \ascii{t2NDTJP9MosKpyFPHJmfjc5pGCvAU58XGa4}, \\
 & \ascii{t29pHDBWq7qN4EjwSEHg8wEqYe9pkmVrtRP}, \ascii{t2Ez9KM8VJLuArcxuEkNRAkhNvidKkzXcjJ}, \\
 & \ascii{t2D5y7J5fpXajLbGrMBQkFg2mFN8fo3n8cX}, \ascii{t2UV2wr1PTaUiybpkV3FdSdGxUJeZdZztyt}\, ]
\end{tabular}
} %scalebox
\renewcommand{\arraystretch}{\defaultarraystretch}

\vspace{1ex}
\pnote{
For \Testnet only, the addresses from index $4$ onward have been changed from
what was implemented at launch. This reflects an upgrade on \Testnet, starting
from \blockHeight $53127$. \cite{Zcash-Issue2113}
}

\vspace{1ex}
Each address representation in $\FounderAddressList$ denotes a \transparent
P2SH multisig address.

\introlist
Let $\SlowStartShift$ and $\Halving$ be defined as in the previous section.

Define:

\begin{formulae}
  \item $\FounderAddressChangeInterval := \ceiling{\hfrac{\SlowStartShift + \PreBlossomHalvingInterval}{\NumFounderAddresses}}$
\blossom{
  \item $\FounderAddressAdjustedHeight(\BlockHeight \typecolon \Nat) :=$
        \vspace{-0.5ex}
  \item \tab $\begin{cases}
                \BlockHeight, &\caseif \text{ not } \IsBlossomActivated(\BlockHeight), \\
                \BlossomActivationHeight + \floor{\hfrac{\BlockHeight - \BlossomActivationHeight}{\BlossomPoWTargetSpacingRatio}}, &\caseotherwise
              \end{cases}$
}
  \item $\FounderAddressIndex(\BlockHeight \typecolon \Nat) := 1 + \floor{\hfrac{\blossom{\FounderAddressAdjustedHeight(}\BlockHeight\blossom{)}}{\FounderAddressChangeInterval}}$
  \item $\FoundersRewardLastBlockHeight :=
\notblossom{\SlowStartShift + \PreBlossomHalvingInterval - 1}
\blossom{\maximum\Of{\setof{\BlockHeight \typecolon \Nat \suchthat \Halving(\BlockHeight) < 1}}}$\,.
\end{formulae}

Let $\FounderRedeemScriptHash(\BlockHeight \typecolon \Nat)$ be the standard redeem script hash, as specified in
\cite{Bitcoin-Multisig}, for the P2SH multisig address with \BaseFiftyEightCheck form
given by $\FounderAddressList_{\,\FounderAddressIndex(\BlockHeight)}$.

\vspace{-1.5ex}
\consensusrule{\precanopy{
A \coinbaseTransaction at $\BlockHeight \in \range{1}{\FoundersRewardLastBlockHeight}$
\MUST include at least one output that pays exactly $\FoundersReward(\BlockHeight)$ \zatoshi
with a standard P2SH script of the form \ScriptOP{HASH160} \;$\FounderRedeemScriptHash(\BlockHeight)$\; \ScriptOP{EQUAL}
as its $\scriptPubKey$.
}}

\vspace{0.5ex}
\begin{pnotes}
        \vspace{-0.25ex}
  \item No \foundersReward is required to be paid for $\BlockHeight > \FoundersRewardLastBlockHeight$
        (i.e.\ after the first \halving), or for $\BlockHeight = 0$ (i.e.\ the \genesisBlock)\canopy{, or after \Canopy activation}.
        \vspace{-0.25ex}
  \item The \foundersReward addresses are not treated specially in any other way, and
        there can be other outputs to them, in \coinbaseTransactions or otherwise.
        In particular, it is valid for a \coinbaseTransaction with
        $\BlockHeight \in \range{1}{\FoundersRewardLastBlockHeight}$ to have
        other outputs, possibly to the same address, that do not meet the criterion
        in the above consensus rule, as long as at least one output meets it.
        \vspace{-0.25ex}
  \item The assertion $\FounderAddressIndex(\FoundersRewardLastBlockHeight) \leq \NumFounderAddresses$
        holds, ensuring that the \foundersReward address index remains in range for the
        whole period in which the \foundersReward is paid.
\end{pnotes}

\blossom{
\vspace{-0.75ex}
\begin{nnotes}
        \vspace{-0.25ex}
  \blossomonwarditem{$\FoundersRewardLastBlockHeight = 1046399$.}
        \vspace{-0.25ex}
  \item \Blossom is not intended to change the total \foundersReward or the effective period over which
        it is paid.
\end{nnotes}
} %blossom

\canopy{
\vspace{-2ex}
\lsubsection{Payment of Funding Streams}{fundingstreams}

\vspace{-1ex}
The \defining{\fundingStreams} are paid by outputs in the \coinbaseTransaction, to one of a pre-defined
set of addresses, depending on the \blockHeight.

A \fundingStream $\fs$ is defined by a \blockSubsidy fraction (represented as a numerator and
denominator), a start \blockHeight (inclusive), an end \blockHeight (exclusive), and a sequence
of address representations:

\introlist
\begin{formulae}
  \item $\fsNumerator \typecolon \PosInt$
        \vspace{-0.25ex}
  \item $\fsDenominator \typecolon \PosInt$
        \vspace{-0.25ex}
  \item $\fsStartHeight \typecolon \Nat$
  \item $\fsEndHeight \typecolon \Nat$
        \vspace{-1ex}
  \item $\fsAddressList \typecolon \typeexp{\byteseqs}{\PosInt}$.
\end{formulae}

Define:

\begin{formulae}
  \item $\HeightForHalving(\HalvingNum \typecolon \PosInt) :=
          \minimum\Of{\setof{\BlockHeight \typecolon \Nat \suchthat \Halving(\BlockHeight) = \HalvingNum}}$
  \item $\FundingStreamAddressChangeInterval := \PostBlossomHalvingInterval / 48$
  \item $\FundingStreamAddressPeriod(\BlockHeight) :=
          \floor{\hfrac{\BlockHeight - (\HeightForHalving(1) - \PostBlossomHalvingInterval)}{\FundingStreamAddressChangeInterval}}$.
\end{formulae}

For each \fundingStream $\fs$, define:

\begin{formulae}
  \item $\fsAddressIndex(\BlockHeight) := 1 + \FundingStreamAddressPeriod(\BlockHeight) - \FundingStreamAddressPeriod(\fsStartHeight)$
  \item $\fsNumAddresses := \fsAddressIndex(\fsEndHeight - 1)$.
\end{formulae}

$\fsAddressList$ \MUST be of length $\fsNumAddresses$. Each element of $\fsAddressList$
\MUST represent either a \transparent P2SH address as specified in \crossref{transparentaddrencoding},
or a \Sapling \shieldedPaymentAddress as specified in \crossref{saplingpaymentaddrencoding}.

Recall from \crossref{subsidies} the definition of $\fsValue$. A \fundingStream $\fs$ is
``active'' at \blockHeight $\BlockHeight$ when $\fsValue(\BlockHeight) > 0$.

\introlist
\consensusrule{
\canopyonward{
The \coinbaseTransaction at \blockHeight $\BlockHeight$ \MUST contain at least
one output per \fundingStream $\fs$ active at $\BlockHeight$, that pays
$\fsValue(\BlockHeight)$ \zatoshi in the prescribed way to the stream's
recipient address represented by $\fsAddressList_{\fsAddressIndex(\BlockHeight)}$.

\vspace{1ex}
\begin{itemize}
  \item The ``prescribed way'' to pay a \transparent P2SH address is to use a standard
        P2SH script of the form \ScriptOP{HASH160} \;$\fsRedeemScriptHash(\BlockHeight)$\; \ScriptOP{EQUAL}
        as the $\scriptPubKey$. Here $\fsRedeemScriptHash(\BlockHeight)$ is the standard
        redeem script hash for the recipient address given by
        $\fsAddressList_{\,\fsAddressIndex(\BlockHeight)}$ in \BaseFiftyEightCheck form. The
        standard redeem script hash is specified in \cite{Bitcoin-Multisig} for
        P2SH multisig addresses, or \cite{Bitcoin-P2SH} for other P2SH addresses.
        \vspace{1ex}
  \item The ``prescribed way" to pay a \Sapling address is as defined in \cite{ZIP-213},
        using the post-\Heartwood consensus rules specified for \Sapling outputs of
        \coinbaseTransactions in \crossref{txnconsensus}.
\end{itemize}
} %canopyonward
} %consensusrule

\begin{pnotes}
  \item The \fundingStream addresses are not treated specially in any other way, and
        there can be other outputs to them, in \coinbaseTransactions or otherwise.
        In particular, it is valid for a \coinbaseTransaction to have
        other outputs, possibly to the same address, that do not meet the criterion
        in the above consensus rule, as long as at least one output meets it.
\end{pnotes}

\lsubsubsection{ZIP 214 Funding Streams}{zip214fundingstreams}

Let $\CanopyActivationHeight$ be as defined in \crossref{constants}.

\vspace{1ex}
\cite{ZIP-214} defines these \fundingStreams for \Mainnet:

\renewcommand{\arraystretch}{1}

\begin{formulae}
\item \begin{tabular}{|l|c|c|c|c|}
\hline
Stream                   & Numerator & Denominator & Start height & End height \\\hline\raisedstrut
\texttt{FS\_ZIP214\_ECC} &    $7$     &    $100$   &  $1046400$   &  $2726400$ \\
\texttt{FS\_ZIP214\_ZF}  &    $5$     &    $100$   &  $1046400$   &  $2726400$ \\
\texttt{FS\_ZIP214\_MG}  &    $8$     &    $100$   &  $1046400$   &  $2726400$ \\\hline
\end{tabular}
\end{formulae}

It also defines these \fundingStreams for \Testnet:

\begin{formulae}
\item \begin{tabular}{|l|c|c|c|c|}
\hline
Stream                   & Numerator & Denominator & Start height & End height \\\hline\raisedstrut
\texttt{FS\_ZIP214\_ECC} &    $7$     &    $100$   &  $1028500$   &  $2796000$ \\
\texttt{FS\_ZIP214\_ZF}  &    $5$     &    $100$   &  $1028500$   &  $2796000$ \\
\texttt{FS\_ZIP214\_MG}  &    $8$     &    $100$   &  $1028500$   &  $2796000$ \\\hline
\end{tabular}
\end{formulae}

\begin{pnotes}
  \item The \blockHeights of \halvings are different between \Testnet and \Mainnet, as a
        result of different \activationHeights for the \Blossom \networkUpgrade (which
        changed the \blockTargetSpacing). The end height of these \fundingStreams
        corresponds to the second \halving on each \network.
  \item On \Testnet, the \activationHeight of \Canopy is before the first \halving.
        Therefore, the consequence of the above rules for \Testnet is that the amount sent
        to each \Zcash Development Fund recipient address will initially (before \Testnet
        \blockHeight $1116000$) be double the number of currency units as the corresponding
        initial amount on \Mainnet. This reduces to the same number of currency units as on
        \Mainnet, from \Testnet \blockHeights $1116000$ (inclusive) to $2796000$ (exclusive).
\end{pnotes}
} %canopy


\lsubsection{Changes to the Script System}{scripts}

The \ScriptOP{CODESEPARATOR} opcode has been disabled. This opcode also no longer
affects the calculation of \sighashTxHashes.


\lsubsection{Bitcoin Improvement Proposals}{bips}

In general, Bitcoin Improvement Proposals (BIPs) do not apply to \Zcash unless
otherwise specified in this section.

All of the BIPs referenced below should be interpreted by replacing
``BTC'', or ``bitcoin'' used as a currency unit, with ``ZEC''; and
``satoshi'' with ``zatoshi''.

The following BIPs apply, otherwise unchanged, to \Zcash:
\cite{BIP-11},
\cite{BIP-14},
\cite{BIP-31},
\cite{BIP-35},
\cite{BIP-37},
\cite{BIP-61}.

The following BIPs apply starting from the \Zcash \genesisBlock, i.e.\ any activation
rules or exceptions for particular \blocks in the \Bitcoin \blockChain are to
be ignored:
\cite{BIP-16},
\cite{BIP-30},
\cite{BIP-65},
\cite{BIP-66}.

The effect of \cite{BIP-34} has been incorporated into the consensus rules
(\crossref{txnconsensus}). This excludes the \Mainnet and \Testnet{} \genesisBlocks,
for which the ``height in coinbase'' was inadvertently omitted.

\cite{BIP-13} applies with the changes to address version bytes described
in \crossref{transparentaddrencoding}.

\introlist
\cite{BIP-111} applies from \peerToPeerProtocol version $170004$ onward; that is:
\begin{itemize}
  \item references to protocol version $70002$ are to be replaced by $170003$;
  \item references to protocol version $70011$ are to be replaced by $170004$;
  \item the reference to protocol version $70000$ is to be ignored (\Zcash nodes
        have supported Bloom-filtered connections since launch).
\end{itemize}

%\cite{BIP-22} and \cite{BIP-23} apply with some protocol changes, which are
%to be specified in a Zcash Improvement Proposal.

%The following BIPs can be used unchanged, but do not define consensus rules:
%\cite{BIP-69},
%\cite{BIP-126}.


\introsection
\lsection{Differences from the \ZerocashText{} paper}{differences}

\lsubsection{Transaction Structure}{trstructure}

\Zerocash introduces two new operations, which are described in
the paper as new transaction types, in addition to the original
transaction type of the cryptocurrency on which it is based
(e.g.\ \Bitcoin).

In \Zcash, there is only the original \Bitcoin transaction type,
which is extended to contain a sequence of zero or more
\Zcash-specific operations.

This allows for the possibility of chaining transfers of \shielded
value in a single \Zcash \transaction, e.g.\ to spend a \shielded \note
that has just been created. (In \Zcash, we refer to value stored in
\utxos as \transparent, and value stored in output \notes of
\joinSplitTransfers\sapling{ or \outputTransfers)} as \shielded.)
This was not possible in the \Zerocash design without using multiple
transactions. It also allows \transparent and \shielded transfers to
happen atomically --- possibly under the control of nontrivial script
conditions, at some cost in distinguishability.

Computation of \sighashTxHashes, as described in \crossref{sighash},
was changed to clean up handling of an error case for $\SIGHASHSINGLE$,
to remove the special treatment of \ScriptOP{CODESEPARATOR}, and to
include \Zcash-specific fields in the hash \cite{ZIP-76}.


\lsubsection{Memo Fields}{memodiffs}

\Zcash adds a \memo sent from the creator of a \joinSplitDescription to
the recipient of each output \note. This feature is described in
more detail in \crossref{noteptconcept}.


\introlist
\lsubsection{Unification of Mints and Pours}{mintsandpours}

In the original \Zerocash protocol, there were two kinds of transaction
relating to \shielded \notes:

\begin{itemize}
  \item a ``Mint'' transaction takes value from \utxosFull as input and
        produces a new \shielded \note as output.
  \item a ``Pour'' transaction takes up to $\NOld$ \shielded \notes
        as input, and produces up to $\NNew$ \shielded \notes and a
        \utxo as output.
\end{itemize}

\vspace{-1ex}
Only ``Pour'' transactions included a \zkSNARK proof.

\vspace{1ex}
\presapling{
In \Zcash, the sequence of operations added to a \transaction
(see \crossref{trstructure}) consists only of \joinSplitTransfers.
A \joinSplitTransfer is a Pour operation generalized to take a \utxo
as input, allowing \joinSplitTransfers to subsume the functionality of
Mints. An advantage of this is that a \Zcash \transaction that takes
input from a \utxo can produce up to $\NNew$ output \notes, improving
the indistinguishability properties of the protocol. A related change
conceals the input arity of the \joinSplitTransfer: an unused (zero-valued)
input is indistinguishable from an input that takes value from a \note.
}

This unification also simplifies the fix to the Faerie Gold attack
described below, since no special case is needed for Mints.

\saplingonward{
In \Sapling, there are still no ``Mint'' transactions. Instead of
\joinSplitTransfers, there are \spendTransfers and \outputTransfers.
These make use of \xPedersenValueCommitments to represent the shielded
values that are transferred. Because these commitments are additively
homomorphic, it is possible to check that all \spendTransfers and
\outputTransfers balance; see \crossref{saplingbalance}
for detail. This reduces the granularity of the circuit, allowing
a substantial performance improvement (orthogonal to other \Sapling
circuit improvements) when the numbers of \shielded inputs and outputs
are significantly different. This comes at the cost of revealing the
exact number of \shielded inputs and outputs, but \dummy (zero-valued)
outputs are still possible.
}

\lsubsection{Faerie Gold attack and fix}{faeriegold}

When a \shielded \note is created in \Zerocash, the creator is
supposed to choose a new $\NoteUniqueRand$ value at random.
The \nullifier of the \note is derived from its \spendingKey
($\AuthPrivate$) and $\NoteUniqueRand$. The \noteCommitment
is derived from the recipient address component $\AuthPublic$,
the value $\Value$, and the \commitmentTrapdoor $\NoteCommitRand$,
as well as $\NoteUniqueRand$. However nothing prevents creating
multiple \notes with different $\Value$ and $\NoteCommitRand$
(hence different \noteCommitments) but the same $\NoteUniqueRand$.

An adversary can use this to mislead a \note recipient, by sending
two \notes both of which are verified as valid by $\Receive$ (as
defined in \cite[Figure 2]{BCGGMTV2014}), but only one of
which can be spent.

We call this a ``Faerie Gold'' attack --- referring to various Celtic
legends in which faeries pay mortals in what appears to be gold,
but which soon after reveals itself to be leaves, gorse blossoms,
gingerbread cakes, or other less valuable things \cite{LG2004}.

\introlist
This attack does not violate the security definitions given in
\cite{BCGGMTV2014}. The issue could be framed as a problem
either with the definition of Completeness, or the definition of
Balance:

\begin{itemize}
  \item The Completeness property asserts that a validly received
\note can be spent provided that its \nullifier does not appear
on the ledger. This does not take into account the possibility
that distinct \notes, which are validly received, could have the
same \nullifier. That is, the security definition depends on
a protocol detail --\nullifiers-- that is not part of the
intended abstract security property, and that could be implemented
incorrectly.
  \item The Balance property only asserts that an adversary cannot
obtain \emph{more} funds than they have minted or received via
payments. It does not prevent an adversary from causing others'
funds to decrease. In a Faerie Gold attack, an adversary can cause
spending of a \note to reduce (to zero) the effective value of another
\note for which the adversary does not know the \spendingKey, which
violates an intuitive conception of global balance.
\end{itemize}

These problems with the security definitions need to be repaired;
how to do so is discussed in \cite{Hopwood2022}, but that is outside
the scope of this specification. Here we only describe how \Zcash
addresses the immediate attack.

It would be possible to address the attack by requiring that a
recipient remember all of the $\NoteUniqueRand$ values for all
\notes they have ever received, and reject duplicates (as proposed
in \cite{GGM2016}). However, this requirement would interfere
with the intended \Zcash feature that a holder of a \spendingKey
can recover access to (and be sure that they are able to spend) all
of their funds, even if they have forgotten everything but the
\spendingKey.

\sproutspecific{
Instead, \Zcash enforces that an adversary must choose distinct values
for each $\NoteUniqueRand$, by making use of the fact that all of the
\nullifiers in \joinSplitDescriptions that appear in a \validBlockChain
must be distinct. This is true regardless of whether the \nullifiers
corresponded to real or \dummyNotes (see \crossref{sproutdummynotes}).
The \nullifiers are used as input to $\hSigCRH$ to derive a public value
$\hSig$ which uniquely identifies the transaction, as described in
\crossref{joinsplitdesc}. ($\hSig$ was already used in \Zerocash
in a way that requires it to be unique in order to maintain
indistinguishability of \joinSplitDescriptions; adding the \nullifiers
to the input of the hash used to calculate it has the effect of making
this uniqueness property robust even if the \transaction creator is an
adversary.)
} %sproutspecific

\sproutspecific{
The $\NoteUniqueRand$ value for each output \note is then derived from
a random private seed $\NoteUniquePreRand$ and $\hSig$ using
$\PRFrho{\NoteUniquePreRand}$. The correct construction of
$\NoteUniqueRand$ for each output \note is enforced by
\crossref{sproutuniquerho} in the \joinSplitStatement.
} %sproutspecific

\sproutspecific{
Now even if the creator of a \joinSplitDescription does not choose
$\NoteUniquePreRand$ randomly, uniqueness of \nullifiers and
\collisionResistance of both $\hSigCRH$ and $\PRFrho{}$ will ensure
that the derived $\NoteUniqueRand$ values are unique, at least for
any two \joinSplitDescriptions that get into a \validBlockChain.
This is sufficient to prevent the Faerie Gold attack.
} %sproutspecific

A variation on the attack attempts to cause the \nullifier of a sent
\note to be repeated, without repeating $\NoteUniqueRand$.
However, since the \nullifier is computed as
$\PRFnf{Sprout}{\AuthPrivate}(\NoteUniqueRand)$\sapling{ or
$\PRFnf{Sapling}{\NullifierKey}(\NoteUniqueRandRepr)$}\nufive{ (for
\Orchard, see below)}; this is only possible if the adversary finds a
collision across both inputs on $\PRFnf{Sprout}{}$\sapling{ or
$\PRFnf{Sapling}{}$}, which is assumed to be infeasible --- see
\crossref{abstractprfs}.

\sproutspecific{
Crucially, ``\nullifier integrity'' is enforced whether or not the
$\EnforceMerklePath{i}$ flag is set for an input \note
(\crossref{sproutnullifierintegrity}). If this were not the case
then an adversary could perform the attack by creating a zero-valued
\note with a repeated \nullifier, since the \nullifier would not depend
on the value.
} %sproutspecific

\sproutspecific{
\xNullifier{} integrity also prevents a ``roadblock attack'' in which the
adversary sees a victim's \transaction, and is able to publish another
\transaction that is mined first and blocks the victim's \transaction.
This attack would be possible if the public value(s) used to
enforce uniqueness of $\NoteUniqueRand$ could be chosen arbitrarily
by the \transaction creator: the victim's \transaction, rather than
the adversary's, would be considered to be repeating these values.
In the chosen solution that uses \nullifiers for these public values,
they are enforced to be dependent on \spendingKeys controlled by the
original \transaction creator (whether or not each input \note is a
\dummy), and so a roadblock attack cannot be performed by another party
who does not know these keys.
} %sproutspecific

\saplingonward{
In \Sapling, uniqueness of $\NoteUniqueRand$ is ensured by making it
dependent on the position of the \noteCommitment in the \Sapling{}
\noteCommitmentTree. Specifically,
$\NoteUniqueRand = \cm + \scalarmult{\NotePosition}{\NotePositionBaseSapling}$,
where $\NotePositionBaseSapling$ is a generator independent of the generators
used in $\NoteCommitAlg{Sapling}$. Therefore, $\NoteUniqueRand$ commits uniquely
to the \note and its position, and this commitment is \collisionResistant
by the same argument used to prove \collisionResistance of \xPedersenHashes.
Note that it is possible for two distinct \Sapling \positionedNotes (having
different $\NoteUniqueRand$ values and \nullifiers, but different
\notePositions) to have the same \noteCommitment, but this causes no security
problem. Roadblock attacks are not possible because a given \notePosition
does not repeat for outputs of different \transactions in the same \blockChain.
Note that this depends on the fact that the value is bound by the \noteCommitment:
it could be the case that the adversary uses a \dummyNote that is not
required to have a \noteCommitment in the \noteCommitmentTree when it is spent.
If this happens and the victim's \note is not a \dummy, the \noteCommitments
will differ and so will the \nullifiers. If both \notes are dummies, the
adversary cannot know the inputs to the \noteCommitment since they are
generated at random for the victim's spend, regardless of the adversary's
potential knowledge of viewing keys.
} %saplingonward

\nufiveonward{
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{rhoandnullifiers}).

Resistance to Faerie Gold attacks, on the other hand, depends entirely on hardness
of the \xDiscreteLogarithmProblem. 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 \xDiscreteLogarithmProblem
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}

The \Zerocash security proof requires that the composition of
$\Commit{\NoteCommitRand}$ and $\Commit{\NoteCommitS}$ is a
computationally \binding commitment to its inputs $\AuthPublic$,
$\Value$, and $\NoteUniqueRand$. However, the instantiation of
$\Commit{\NoteCommitRand}$ and $\Commit{\NoteCommitS}$ in
section 5.1 of the paper did not meet the definition of a \binding
commitment at a $128$-bit security level. Specifically, the internal
hash of $\AuthPublic$ and $\NoteUniqueRand$ is truncated to $128$ bits
(motivated by providing statistical \hiding security). This allows an
attacker, with a work factor on the order of $2^{64}$, to find distinct
pairs $(\AuthPublic, \NoteUniqueRand)$ and $(\AuthPublic\!', \NoteUniqueRand')$
with colliding outputs of the truncated hash, and therefore the same
\noteCommitment. This would have allowed such an attacker to break the
Balance property by \doubleSpending \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 \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)}\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,
saving a total of four \shaCompress evaluations in the \joinSplitStatement.

\vspace{-1ex}
\sproutspecificpnote{
The full \shaHash algorithm is used for $\NoteCommitAlg{Sprout}$, with randomness
appended after the commitment input. The commitment input can be split into two
blocks, call them $x$ of length $64$ bytes, and $y$ of the remaining length ($9$ bytes).
Let $\CommitPrime{r}(z \typecolon \byteseq{41})$ be the \commitmentScheme that applies
$\SHACompress$ with the first $32$ bytes of $z$ in the IV, and the rest of $z$
($9$ bytes), the randomness $r$ ($32$ bytes), and padding up to $64$ bytes in the
$\SHACompress$ input block. Then we have
$\NoteCommit{Sprout}{r}(x \bconcat y) = \CommitPrime{r}(\SHACompress(x) \bconcat y)$.
Suppose we make the reasonable assumption that $\CommitPrimeAlg$ is a computationally
\binding and \hiding \commitmentScheme. If $\SHACompress$ is \collisionResistant with
the standard IV\footnote{If $\SHACompress$ is not \collisionResistant with the
standard IV, then \shaHash is not \collisionResistant for a $2$-block input.}, then
$\NoteCommitAlg{Sprout}$ is as secure for \binding as $\CommitPrimeAlg$. Also
$\NoteCommitAlg{Sprout}$ is as secure for \hiding as $\CommitPrimeAlg$ (without
any assumption on $\SHACompress$). This effectively rules out potential concerns
about the Merkle--Damgård structure \cite{Damgard1989} of \shaHash causing any
security problem for $\NoteCommitAlg{Sprout}$.
} %sproutspecificpnote

\vspace{-1ex}
\sproutspecificpnote{
\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
\commitmentScheme for this use at a 128-bit security level, the overhead of
doing so within the \joinSplitStatement was not considered to justify the
benefits.
} %sproutspecificpnote

\vspace{1ex}
\saplingonward{
In \Sapling, \xPedersenOrSinsemillaCommitments are used instead of \shaCompress.
These commitments are statistically \hiding, and so ``everlasting anonymity''
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 \xDecisionalDiffieHellmanProblem
on the \jubjubCurve\nufive{ or the \pallasCurve} can be broken.
} %saplingonward

\lsubsection{Changes to PRF inputs and truncation}{truncation}

The format of inputs to the \xPRFs instantiated in \crossref{concreteprfs}
has changed relative to \Zerocash. There is also a requirement for another \xPRF,
$\PRFrho{}$, which must be domain-separated from the others.

In the \Zerocash protocol, $\NoteUniqueRandOld{i}$ is truncated from $256$
to $254$ bits in the input to $\PRFsn{}$ (which corresponds to $\PRFnf{Sprout}{}$ in \Zcash).
Also, $\hSig$ is truncated from $256$ to $253$ bits in the input to $\PRFpk{}$.
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}.

\introsection
In more detail:

\begin{itemize}
  \item In the argument relating $\mathbf{H}$ and $\Game_2$, it is stated that in $\Game_2$,
        ``for each $i \in \setof{1, 2}, \mathsf{sn}_i := \PRFsn{\AuthPrivate}(\NoteUniqueRand)$
        for a random (and not previously used) $\NoteUniqueRand$''. It is also
        argued that ``the calls to $\PRFsn{\AuthPrivate}$ are each by definition unique''.
        The latter assertion depends on the fact that $\NoteUniqueRand$
        is ``not previously used''. However, the argument is incorrect
        because the truncated input to $\PRFsn{\AuthPrivate}$, i.e.
        $[\NoteUniqueRand]_{254}$, may repeat even if $\NoteUniqueRand$ does not.
  \item In the same argument, it is stated that ``with overwhelming probability,
        $\hSig$ is unique''. In fact what is required to be unique is the
        truncated input to $\PRFpk{}$, i.e.\ $[\hSig]_{253} = [\CRH(\pksig)]_{253}$.
        In practice this value will be unique under a plausible assumption on
        $\CRH$ provided that $\pksig$ is chosen randomly, but no formal argument
        for this is presented.
\end{itemize}

Note that $\NoteUniqueRand$ is truncated in the input to $\PRFsn{}$
but not in the input to $\Commit{\NoteCommitRand}$, which further
complicates the analysis.

As further evidence that it is essential for the proofs to explicitly take any
such truncations into account, consider a slightly modified protocol in which
$\NoteUniqueRand$ is truncated in the input to $\Commit{\NoteCommitRand}$
but not in the input to $\PRFsn{}$. In that case, it would be possible to
violate balance by creating two \notes for which $\NoteUniqueRand$ differs
only in the truncated bits. These \notes would have the same \noteCommitment
but different \nullifiers, so it would be possible to spend the same value
twice.

\sproutspecific{
For resistance to Faerie Gold attacks as described in
\crossref{faeriegold}, \Zcash depends on \collisionResistance of
$\hSigCRH$ and $\PRFrho{}$ (instantiated using $\BlakeTwob{256}$ and
\shaCompress respectively). \xCollisionResistance of a truncated hash
does not follow from \collisionResistance of the original hash, even if the
truncation is only by one bit. This motivated avoiding truncation along any
path from the inputs to the computation of $\hSig$ to the uses of
$\NoteUniqueRand$.
} %sproutspecific

\sproutspecific{
Since the \xPRFs are instantiated using \shaCompress which has an input block
size of $512$ bits (of which $256$ bits are used for the \xPRF input and $4$ bits
are used for domain separation), it was necessary to reduce the size of the
PRF key to $252$ bits. The key is set to $\AuthPrivate$ in the case of
$\PRFaddr{}$, $\PRFnf{Sprout}{}$, and $\PRFpk{}$, and to $\NoteUniquePreRand$ (which
does not exist in \Zerocash) for $\PRFrho{}$, and so those values have been
reduced to $252$ bits. This is preferable to requiring reasoning about truncation,
and $252$ bits is quite sufficient for security of these cryptovalues.
} %sproutspecific

\sapling{
\Sapling uses \xPedersenHashes and $\BlakeTwosGeneric$ where \Sprout used \shaCompress.
\xPedersenHashes can be efficiently instantiated for arbitrary input lengths.
$\BlakeTwosGeneric$ has an input block size of $512$ bits, and uses a finalization flag
rather than padding of the last input block; it also supports domain separation
via a personalization parameter distinct from the input. Therefore, there is
no need for truncation in the inputs to any of these hashes. Note however that the
\emph{output} of $\CRHivk$ is truncated, requiring a security assumption on
$\BlakeTwosGeneric$ truncated to $251$ bits (see \crossref{concretecrhivk}).
} %sapling

\nufive{
\Orchard replaces \xPedersenHashes by \xSinsemillaHashes which can also be efficiently
instantiated for arbitrary input lengths. It replaces uses of $\BlakeTwosGeneric$ in the
circuit by the \commitmentScheme $\CommitIvk{}$, and by a construction for \nullifier
derivation that uses the $\Poseidon$-based $\PRFnf{Orchard}{}$ (along with scalar
multiplication on the \pallasCurve). Again, there is no need for truncation in the
inputs to any of these functions, and the need for truncation in the derivation of
$\InViewingKey$ is removed.
} %nufive

\lsubsection{In-band secret distribution}{inbandrationale}

\Zerocash specified ECIES (referencing Certicom's SEC 1 standard) as the
encryption scheme used for the \inBand secret distribution. This has been
changed to a \keyAgreementScheme 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:

\begin{itemize}
  \item The \Zerocash paper did not specify the curve to be used.
        We believe that $\KASproutCurve$ has significant \sideChannel resistance,
        performance, implementation complexity, and robustness advantages
        over most other available curve choices, as explained in \cite{Bernstein2006}.
        \sapling{For \Sapling, the \jubjubCurve was designed according to a
        similar design process following the ``Safe curves'' criteria
        \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.} \nufive{For \Orchard, we define a \primeOrderCurve
        \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,
        ISO/IEC 18033-2, and SEC 1) that define ECIES variants \cite{MAEA2010}.
  \item Although the \Zerocash paper states that ECIES satisfies \keyPrivacy
        (as defined in \cite{BBDP2001}), it is not clear that this holds for
        all curve parameters and key distributions. For example, if a group of
        non-prime order is used, the distribution of ciphertexts could be
        distinguishable depending on the order of the points representing the
        ephemeral and recipient \publicKeys. Public key validity is also a concern.
        $\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)}. \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
        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 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 \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}\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$\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
        \joinSplitTransfers.
        This facilitates security analysis as explained in \cite{DGKM2011} --- see
        section 7 of that paper for a security proof that can be applied to this
        construction under the assumption that single-block $\BlakeTwob{256}$ is a
        \definingquotedterm{weak PRF}.
        Note that $\hSig$ is authenticated, by the \zkSNARKProof\!\!, as having been chosen
        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 \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.}
\end{itemize}

The security proofs of \cite{ABR1999} can be adapted straightforwardly to the
resulting scheme. Although DHAES as defined in that paper does not pass the
recipient \publicKey or a public seed to the \hashFunction $H$, this does not
impair the proof because we can consider $H$ to be the specialization of our
KDF to a given recipient key and seed. (Passing the recipient \publicKey to
the KDF could in principle compromise \keyPrivacy, but not confidentiality of
encryption.) \sproutspecific{It is necessary to adapt the
``HDH independence'' assumptions and the proof slightly to take into account
that the ephemeral key is reused for two encryptions.}

Note that the $256$-bit key for $\SymSpecific$ maintains a high concrete security
level even under attacks using parallel hardware \cite{Bernstein2005} in the multi-user
setting \cite{Zaverucha2012}. This is especially necessary because the privacy of
\Zcash transactions may need to be maintained far into the future, and upgrading
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: for \Sprout,
$\AuthPrivate$ is $252$ bits, and $\TransmitPrivate$ is no shorter than $\AuthPrivate$.

\sapling{
In \Sapling, $\InViewingKey$ is an output of $\CRHivk$, which is a $251$-bit value.
\nufive{In \Orchard, $\InViewingKey$ is an $x$-coordinate on the \pallasCurve.}
This degree of divergence from a uniform distribution on the scalar field is not
expected to cause any weakness in \note encryption.
} %sapling

For all shielded protocols, the checking of \noteCommitments makes
\defining{\partitioningOracleAttacks} \cite{LGR2021} against the \noteCiphertext
infeasible, at least in the absence of \sideChannel attacks. \sapling{The following
argument applies to \Sapling\nufive{ and \Orchard}, but can be adapted to \Sprout
by replacing $\InViewingKey$ with $\TransmitPrivate$, $\DiversifiedTransmitPublic$
with $\TransmitPublic$, and using a fixed base. The decryption procedure
for \noteCiphertexts in \Sapling\nufive{ and \Orchard} is specified in
\crossref{decryptivk}; it ensures that a successful decryption cannot occur unless
the decrypted \notePlaintext encodes a \note consistent with the \noteCommitment
(encoded as the $\cmU$ field of the \outputDescription\nufive{ or the $\cmX$ field
of the \actionDescription}). Suppose that it were feasible to find a pair of
\noteCiphertext and \noteCommitment that decrypts successfully for two different
\incomingViewingKeys $\InViewingKey_1$ and $\InViewingKey_2$. Assuming that the
\noteCommitmentScheme is \binding and that \noteCommitment opens to a \note
with $\DiversifiedTransmitPublic$ and $\DiversifiedTransmitBase$, we must have
$\DiversifiedTransmitPublic = \KAAgree{}(\InViewingKey_1, \DiversifiedTransmitBase) = \KAAgree{}(\InViewingKey_2, \DiversifiedTransmitBase)$.
But this is impossible given that $\DiversifiedTransmitBase$ has order greater than
the maximum value of $\InViewingKey$ that can be an output of $\CRHivk{}$\nufive{ or
$\CommitIvkAlg$}.

There is also a decryption procedure that makes use of \outgoingCiphertexts in
\Sapling\nufive{ and \Orchard}, as specified in \crossref{decryptovk}. It checks
(via $\KADerivePublic{}$\canopy{, and also via $\PRFexpand{\NoteSeedBytes}$ in the case
of post-\cite{ZIP-212} ciphertexts with $\notePlaintextLeadByte \neq \hexint{01}$})
that the decrypted $\EphemeralPrivate$ value is consistent with the \noteCiphertext,
which is protected from \partitioningOracleAttacks as described above. It also checks
that the $\DiversifiedTransmitPublic$ value is consistent with the \noteCommitment.
Since these are the only fields in an \outgoingCiphertext, even if a
\partitioningOracleAttack occurred against an \outgoingCiphertext, it could not
result in any equivocation of the decrypted data. Because $\OutViewingKey$ and
$\OutCipherKey$ are each $256$ bits, \partitioningOracleAttacks that speed up a
search for these keys (analogous to the attacks against Password-based AEAD in
\cite{LGR2021}) are infeasible, even given knowledge of $\InViewingKey$.}


\lsubsection{Omission in \ZerocashText{} security proof}{crprf}

The abstract \Zerocash protocol requires $\PRFaddr{}$ only to be a \xPRF;
it is not specified to be \collisionResistant\!. This reveals a flaw in
the proof of the Balance property.

Suppose that an adversary finds a collision on $\PRFaddr{}$ such that
$\AuthPrivateSup{1}$ and $\AuthPrivateSup{2}$ are distinct \spendingKeys for
the same $\AuthPublic$. Because the \noteCommitment is to $\AuthPublic$,
but the \nullifier is computed from $\AuthPrivate$ (and $\NoteUniqueRand$),
the adversary is able to \doubleSpend the note, once with each $\AuthPrivate$.
This is not detected because each Spend reveals a different \nullifier.
The \joinSplitStatements are still valid because they can only
check that the $\AuthPrivate$ in the witness is \emph{some} preimage of
the $\AuthPublic$ used in the \noteCommitment.

\introlist
The error is in the proof of Balance in \cite[Appendix D.3]{BCGGMTV2014}.
For the ``$\Adversary$ violates Condition I'' case, the proof says:

\begin{itemize}
  \item[``(i)] If $\cmOld{1} = \cmOld{2}$, then the fact that
    $\snOld{1} \neq \snOld{2}$ implies that the witness $a$ contains
    two distinct openings of $\cmOld{1}$ (the first opening contains
    $(\AuthPrivateOldX{1}, \NoteUniqueRandOld{1})$, while the second
    opening contains $(\AuthPrivateOldX{2}, \NoteUniqueRandOld{2})$).
    This violates the \binding property of the \commitmentScheme $\CommitAlg$."
\end{itemize}

In fact the openings do not contain $\AuthPrivateOld{i}$; they contain
$\AuthEmphPublicOld{i}$. (In \Sprout $\cmOld{i}$ opens directly to
$(\AuthEmphPublicOld{i}, \ValueOld{i}, \NoteUniqueRandOld{i})$, and
in \Zerocash it opens to $(\ValueOld{i},
\Commit{\NoteCommitS}(\AuthEmphPublicOld{i}, \NoteUniqueRandOld{i})$.)

A similar error occurs in the argument for the ``$\Adversary$ violates
Condition II'' case.

The flaw is not exploitable for the actual instantiations of $\PRFaddr{}$
in \Zerocash and \Sprout, which \emph{are} \collisionResistant assuming
that \shaCompress is.

The proof can be straightforwardly repaired. The intuition is that we can rely
on \collisionResistance of $\PRFaddr{}$ (on both its arguments) to argue that
distinctness of $\AuthPrivateOldX{1}$ and $\AuthPrivateOldX{2}$, together with
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}
    \item The paper defines a \note as $((\AuthPublic, \TransmitPublic), \Value,
          \NoteUniqueRand, \NoteCommitRand, \NoteCommitS, \cm)$, whereas this
          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
          instantiation of $\NoteCommit{Sprout}{}$ in \Sprout. $\TransmitPublic$ is also
          not needed as part of a \note: it is not an input to $\NoteCommit{Sprout}{}$ nor
          is it constrained by the \Zerocash \POUR{} \statement or the
          \Zcash \joinSplitStatement. $\cm$ can be computed from the other fields.
          \sapling{(The definition of \notes for \Sapling is different again.)}
    \item The length of proof encodings given in the paper is $288$
          bytes. \sproutspecific{This differs from the $296$ bytes specified in \crossref{bctv},
          because both the $x$-coordinate and compressed $y$-coordinate of each
          point need to be represented. Although it is possible to encode a proof
          in $288$ bytes by making use of the fact that elements of $\GF{q}$ can
          be represented in $254$ bits, we prefer to use the standard formats for points
          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\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
          of amounts in a given \joinSplitTransfer is in the latter range;
          this enforcement is technically redundant given that the Balance
          property holds.)
\end{itemize}


\introlist
\lsection{Acknowledgements}{acknowledgements}

The inventors of \Zerocash are Eli \nh{Ben-Sasson}, Alessandro Chiesa,
Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza.

The designers of the \Zcash protocol are the \Zerocash inventors
and also \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, Simon Liu, Taylor Hornby,
Nathan Wilcox, Zooko Wilcox, Jay Graber, Eirik \nh{Ogilvie-Wigley}, Ariel Gabizon,
George Tankersley, Ying~Tong Lai, Kris Nuttycombe, Jack Gavigan, Steven Smith,
and Greg Pfeil.
The \Equihash \proofOfWork algorithm was designed by Alex Biryukov and
Dmitry Khovratovich.

The authors would like to thank everyone with whom they have discussed the
\Zerocash and \Zcash protocol designs; in addition to the preceding, this
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, Kexin Hu, Brian Warner, Mary Maller,
Michael Dixon, Andrew Poelstra, Benjamin Winston, Josh Cincinnati,
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, 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, Sasha Meyer, and no
doubt others.
We would also like to thank the designers and developers of \Bitcoin and
\BitcoinCore.

\Zcash has benefited from security audits performed by NCC Group, Coinspect,
Least Authority, Mary Maller, Kudelski Security, QEDIT, and Trail of Bits.
We also thank Mary Maller for her work on reviewing the security proofs
for \HaloTwo (any remaining errors are ours).

The Faerie Gold attack was found by Zooko Wilcox (who also came up with the
name) and Brian Warner. The fix for this attack in \Sprout was proposed by
\nh{Daira-Emma} Hopwood; subsequent analysis of variations on the attack was
performed by \nh{Daira-Emma} Hopwood and Sean Bowe.

The internal hash collision attack was found by Taylor Hornby.

The error in the \Zerocash proof of Balance relating to \collisionResistance
of $\PRFaddr{}$ was found by \nh{Daira-Emma} Hopwood.

The errors in the proof of Ledger Indistinguishability mentioned in
\crossref{truncation} were also found by \nh{Daira-Emma} Hopwood.

The 2015 Soundness vulnerability in \BCTV \cite{Parno2015} was found by
Bryan Parno. An additional condition needed to resist this attack was
documented by Ariel Gabizon \cite[section 3]{Gabizon2019}.
The 2019 Soundness vulnerability in \BCTV \cite{Gabizon2019}
was found by Ariel Gabizon.

The design of \Sapling is primarily due to Matthew Green, Ian Miers,
\nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg, and Jack Gavigan. A potential attack
linking \diversifiedPaymentAddresses, avoided in the adopted design, was
found by Brian Warner.

The design of \Orchard is primarily due to \nh{Daira-Emma} Hopwood, Sean Bowe, Jack Grigg,
Kris Nuttycombe, Ying~Tong Lai, and Steven Smith.

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}
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.

Numerous people have contributed to the science of \zeroKnowledgeProvingSystems,
but we would particularly like to acknowledge the work of
Shafi Goldwasser, Silvio Micali, Oded Goldreich, Mihir Bellare, Charles Rackoff,
Rosario Gennaro, Bryan Parno, Jon Howell, Craig Gentry, Mariana Raykova,
Jens Groth, Rafail Ostrovsky, and Amit Sahai.

We thank the organizers of the ZKProof standardization effort and workshops;
and also Anna Rose, Fredrik Harrysson, Terun Chitra, James Prestwich,
Josh Cincinnati, Tanya Karsou, Henrik Jose, Chris Ward, and others for their
work on the Zero Knowledge Podcast, ZK Summits, and ZK Study Club. These
efforts have enriched the zero knowledge community immeasurably.

Many of the ideas used in \Zcash{} ---including the use of \zeroKnowledgeProofs
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
\doubleSpends--- were first applied to privacy-preserving digital currencies
by Tomas Sander and Amnon \nh{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
to scientific research.

This document is set in the beautiful Quattrocento font designed by Pablo Impallari.
The {\schoolbook New Century Schoolbook} font by URW Type Foundry, based on
Century Schoolbook designed by Morris Fuller, is used for \emph{italics}\!.

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{Unreleased}{2024-04-14}

\begin{itemize}
    \item Add the hyphen in \nh{Daira-Emma} Hopwood.
    \item Correct some author lists in the References.
    \item Prevent incorrect line-breaking on hyphens.
\end{itemize}


\historyentry{2023.4.0}{2023-12-19}

\begin{itemize}
\canopy{
    \item The domain separators $[4]$ and $[5]$ used in the input to $\PRFexpand{\NoteSeedBytes}$ for \Sapling
          were accidentally swapped in the protocol specification relative to \cite{ZIP-212}. The implementation
          in \zcashd followed \cite{ZIP-212}, using $[4]$ to derive $\NoteCommitRand$ and $[5]$ to derive
          $\EphemeralPrivate$. This has been corrected in the protocol specification.

\nufive{
          For \Orchard, the implementation in the \texttt{orchard} crate (and therefore in \zcashd) followed
          the protocol specification, using $[5] \bconcat \ItoLEOSPOf{256}{\NoteUniqueRand}$ to derive
          $\NoteCommitRand$ and $[4] \bconcat \ItoLEOSPOf{256}{\NoteUniqueRand}$ to derive $\EphemeralPrivate$.
          This cannot now be changed, and so \cite{ZIP-212} has been updated to follow this implementation.
          Notes have been added pointing out the discrepancy.
} %nufive
} %canopy
\nufive{
    \item Document that the attacks in \cite{DKLS2020} are no better than brute force key search against
          $\FFOneAESAlg$ as specified in \crossref{concreteprps}.
} %nufive
\heartwood{
    \item In the table of \crossref{blockheader}, clarify that $\hashLightClientRoot$ is used in \Heartwood
          and \Canopy, but not in \NUFive or later.
} %heartwood
\sapling{
    \item The return type of $\GroupJHash{}$ in \crossref{concretegrouphashjubjub} was
          incorrectly given as $\SubgroupJstar$, rather than the correct $\maybe{\SubgroupJstar}$.
    \item In the discussion of partitioning oracle attacks on \note encryption in \crossref{inbandrationale},
          we now use the fact that $\DiversifiedTransmitBase$ has order greater than the maximum value of
          $\InViewingKey$, rather than assuming that $\DiversifiedTransmitBase$ is a non-zero point
          in the \primeOrderSubgroup. (In the case of \Sapling, the circuits only enforce that
          $\DiversifiedTransmitBase$ is not a \smallOrderAdjective point, not that it is in the \primeOrderSubgroup.
          It is true that honestly generated addresses have \primeOrderAdjective $\DiversifiedTransmitBase$
          which would have been sufficient for the security argument against this class of attacks,
          but the chosen fix is more direct.)
    \item Delete a confusing claim in \crossref{spenddesc} that ``The check that $\AuthSignRandomizedPublic$
          is not of \smallOrder is technically redundant with a check in the \spendCircuit ...''.
          The \smallOrderAdjective check excludes the zero point $\ZeroJ$, which the \snarkref{Spend authority}{spendauthority}
          check that this claim was intending to reference does not.
    \item An implementation of $\HomomorphicPedersenCommit{Sapling}{}$ \MAY resample the
          \commitmentTrapdoor until the resulting commitment is not $\ZeroJ$, in order to avoid
          it being rejected as the $\cv$ field of a \spendDescription or \outputDescription.
          Add notes in \crossref{spenddesc}, \crossref{outputdesc}, and \crossref{concretehomomorphiccommit}
          to that effect.
} %sapling
    \item Rename the section ``Note Commitments and Nullifiers'' to \crossref{rhoandnullifiers},
          to more accurately reflect its contents.
    \item Split some of the content of the section ``Notes'' into subsections \crossref{notecommitmentconcept}
          and \crossref{nullifierconcept}. Make the descriptions of how \noteCommitments and
          \nullifiers are used more precise and explicit, and add forward references where
          helpful.
    \item Remove redundancy in the definition of \notePlaintexts between \crossref{noteptconcept}
          and \crossref{noteptencoding}.
\notbeforenufive{
    \item The abstract no longer describes the \NUFive version of the specification as a draft.
}
    \item Acknowledge Greg Pfeil as a co-designer of the \Zcash protocol.
    \item Acknowledge \nh{Daira-Emma} Hopwood for the fix to the Faerie Gold attack in \Sprout, and add a reference
          to hir \textsl{Explaining the Security of Zcash} talk at Zcon3 \cite{Hopwood2022} for repairs to the
          \Zerocash security definitions.
    \item Acknowledge the font designers Pablo Impallari and Morris Fuller.
    \item Change \nh{Daira-Emma} Hopwood's name.
\end{itemize}


\historyentry{2022.3.8}{2022-09-15}

\begin{itemize}
    \item Correct Jurgen Bos' name.
\end{itemize}


\historyentry{2022.3.7}{2022-09-10}

\begin{itemize}
\nufive{
    \item Remove a now-unused sampling of $\ValueCommitRand$ in \crossref{orcharddummynotes}.
} %nufive
    \item Specify in \crossref{blockchain} that \NUFive is the most recent settled \networkUpgrade.
\end{itemize}


\historyentry{2022.3.6}{2022-09-01}

\begin{itemize}
    \item Correct Kexin Hu's name.
    \item Correct cross-references for the definition of an \anchor.
\nufive{
    \item Remove a calculation of $\cv$ in \crossref{orcharddummynotes} that is
          not applicable to \Orchard (since $\cv$ for an \actionDescription
          depends on both the spent and output \notes).
    \item Clarify that the recommended format for a QR code starts with a \Bech
          encoding for a \Sapling \paymentAddress and with a \Bechm encoding for
          a \unifiedPaymentAddress.
} %nufive
    \item Replace ResearchGate links for \cite{CDvdG1987}\notbeforenufive{ and \cite{BDPA2007}}
          with alternatives that do not cause false-positive link checker errors.
    \item In \texttt{protocol/README.rst}: update the build dependency documentation
          for Debian Bullseye, mention the ``\texttt{make linkcheck}'' target, and
          correct the description of ``\texttt{make all}''.
    \item Update the \Makefile to build correctly with newer versions of \texttt{latexmk}.
\end{itemize}


\historyentry{2022.3.5}{2022-08-02}
\begin{itemize}
\nufive{
    \item ZIP 244 is not modified by ZIP 225.
} %nufive
\sapling{
    \item \crossref{concretecrhivk} incorrectly cross-referenced $\BlakeTwob{256}$ rather than $\BlakeTwos{256}$.
          The actual specification was correct.
} %sapling
\end{itemize}


\historyentry{2022.3.4}{2022-06-22}
\begin{itemize}
\canopy{
    \item Document in \crossref{concreteed25519} that a \fullValidator implementation
          that checkpoints on the \Canopy \activationBlock \MAY validate \EdSpecific
          signatures using the post-\Canopy rules for the whole chain.
} %canopy
    \item Update references for \cite{ECCZF2019} and \cite{ZIP-302}\nufive{ and \cite{ZIP-252}}.
\end{itemize}


\historyentry{2022.3.3}{2022-06-21}
\begin{itemize}
\nufive{
    \item In \crossref{networks}, update the settled activation \blockHashes to be
          those for \NUFive on \Mainnet and \Testnet.
    \item Correct the history entry for \historyref{2022.3.2} to include the
          entry about the calculation for \sizeProofsOrchard.
} %nufive
    \item Rename $\mathsf{ExcludedPointEncodings}$ to $\PreCanopyExcludedPointEncodings$.
    \item In \crossref{sproutspendingkeyencoding}, remove the statement that
          future key representations might use the padding bits of \Sprout
          spending keys.
    \item Give a full-text URL for \cite{Nakamoto2008}.
\end{itemize}


\historyentry{2022.3.2}{2022-06-06}
\begin{itemize}
\nufive{
    \item Set $\NUFiveActivationHeight$ for \Testnet and \Mainnet.
    \item An [\NUFive onward] consensus rule requiring the \nConsensusBranchId{}
          field to match the \consensusBranchID used for \sighashTxHashes, should
          apply only when $\effectiveVersion \geq 5$ (since v4 \transactions did
          not explicitly encode the \nConsensusBranchId{} field).
    \item Correction in \crossref{constants}:
          $\Uncommitted{Orchard} \typecolon \MerkleHashOrchard$ is not a \bitSequence.
    \item In \crossref{txnencoding}, add the calculation for \sizeProofsOrchard{}
          to the v5 \transaction format table.
}
    \item Make \crossref{overview} more precise about \chainValuePools.
\end{itemize}


\historyentry{2022.3.1}{2022-04-28}
\begin{itemize}
\nufive{
    \item In \crossref{orchardkeycomponents}, do not allow construction of \Orchard
          \spendingKeys such that the corresponding internal \incomingViewingKey is $0$
          or $\bot$. (This was already specified for the external \incomingViewingKey.)
          Similarly in \crossref{orchardfullviewingkeyencoding}, do not consider a
          decoded key valid if either its external or internal \incomingViewingKey
          would be $0$ or $\bot$.
    \item Clarify how to determine which table in \crossref{txnencoding} to use for
          \transaction parsing, depending on the $\effectiveVersion$ as determined by
          the $\headerField$ field.
}
    \item Correct ``block chain branch'' to ``~\!\!\consensusBranch'' to match
          \cite{ZIP-200}.
    \item Add an acknowledgement to Mary Maller for reviewing the \HaloTwo security proofs.
    \item Add an acknowledgement to Josh Cincinnati for discussions on the Zcash protocol.
    \item Add acknowledgements to more people associated with the ZK Podcast.
\end{itemize}


\historyentry{2022.3.0}{2022-03-18}
\begin{itemize}
\nufive{
    \item Correct a type error in the usage of $\CommitIvkAlg$: the output type
          $\CommitIvkOutput$ includes $0$, but the type of \incomingViewingKeys
          should not include $0$ because $\KAPrivate{Orchard}$ does not. This is
          now handled by explicitly rejecting $0$ as output from $\CommitIvkAlg$
          when generating $\InViewingKey$ in \crossref{orchardkeycomponents}.
          An encoding of $\InViewingKey$ as $0$ is also rejected in
          \crossref{orchardinviewingkeyencoding} when parsing an \incomingViewingKey.
          The \actionCircuit needed no changes because $\DiversifiedTransmitPublic$
          already could not be $\ZeroP$, and therefore the
          \snarkref{Diversified address integrity}{actionaddressintegrity}
          condition fails when $\InViewingKey = 0$.
} %nufive
    \item In \crossref{blockchain}, define what a \settled \networkUpgrade is,
          specify requirements for checkpointing, and allow nodes to impose
          a limitation on rollback depth.
\sapling{
    \item In \crossref{bctv}, note that the above checkpointing requirement
          mitigates the risks of not performing \BCTV \zkProof verification.
} %sapling
    \item Document the consensus rule that coinbase script length \MUST be
          $\range{2}{100}$ bytes.
    \item \crossref{coinbasetransactions} effectively defined a \coinbaseTransaction
          as the first \transaction in a \block. This wording was copied from the
          Bitcoin Developer Reference \cite{Bitcoin-CbInput}, but it does not match
          the implementation in \zcashd that was inherited from \BitcoinCore.
          Instead, a \coinbaseTransaction should be, and now is, defined as a
          \transaction with a single null \prevout.
          The specifications of consensus rules have been clarified and adjusted
          (without any actual consensus change) to take this into account, as follows:
          \begin{itemize}
            \item a \block \MUST have at least one \transaction;
            \item the first \transaction in a \block \MUST be a \coinbaseTransaction,
                  and subsequent \transactions \MUSTNOT be \coinbaseTransactions;
            \item a \transparentInput in a non-coinbase \transaction \MUSTNOT have
                  a null \prevout;
            \item every non-null \prevout \MUST point to a unique \utxo in either
                  a preceding \block, or a \emph{previous} \transaction in the
                  same \block (this rule was previously not given explicitly
                  because it was assumed to be inherited from \Bitcoin);
            \item the rule that ``A \coinbaseTransaction \MUSTNOT have any
                  \transparentInputs with non-null \prevoutField{} fields'' is
                  removed as an explicit consensus rule because it is implied by
                  the corrected definition of \coinbaseTransaction.
          \end{itemize}
\end{itemize}


\historyentry{2022.2.19}{2022-01-19}
\begin{itemize}
\nufive{
    \item In \crossref{sighash}, add a consensus rule that \sighashType encodings \MUST
          be canonical for v5 \transactions.
} %nufive
    \item In \crossref{joinsplit}, clarify that balance for \joinSplitTransfers is enforced
          by the \joinSplitStatement, and that there is no consensus rule to check it directly.
    \item In \crossref{internalh}, add a security argument for why the \shaHash-based
          \commitmentScheme $\NoteCommitAlg{Sprout}$ is \binding and \hiding, under reasonable
          assumptions about $\SHACompress$.
\end{itemize}


\historyentry{2022.2.18}{2022-01-03}
\begin{itemize}
\nufive{
    \item Change the types of $\cmX$, $\Uncommitted{Orchard}$, and $\AuthSignPublic$ in
          \Orchard to $\range{0}{\ParamP{q}-1}$, avoiding type errors and reflecting the
          implementation in \zcashd. This eliminates all uses of $\GroupP_{\!x}$ (except
          that $\AuthSignPublic$ in an \Orchard \fullViewingKey is still required to be a
          valid \Pallas \affineSW $x$-coordinate).
} %nufive
    \item Refine the security argument about \partitioningOracleAttacks in
          \crossref{inbandrationale}:\!\!
          \begin{itemize}
            \item The argument for decryption with an \incomingViewingKey does not need to
                  depend on the \xDecisionalDiffieHellmanProblem, since $\DiversifiedTransmitBase$
                  is committed to by the \noteCommitment as well as $\DiversifiedTransmitPublic$.
            \item It is necessary to say that the \noteCommitment is always checked for a
                  successful decryption.
            \item Pedantically, it was not correct to conclude from the given security argument
                  that \partitioningOracleAttacks against an \outgoingCiphertext are necessarily
                  prevented, according to the definition in \cite{LGR2021}. Instead, the correct
                  conclusions are that such attacks could not feasibly result in any equivocation
                  of the decrypted data, or in recovery of $\OutViewingKey$ or $\OutCipherKey$.
          \end{itemize}
    \item Correct the note about domain separators for $\PRFexpand{}$ in \crossref{abstractprfs},
          and ensure that new domain separators for deriving internal keys from \cite{ZIP-32} and
          \cite{ZIP-316} are included.
\end{itemize}


\historyentry{2021.2.17}{2021-12-01}
\begin{itemize}
    \item Add notes in\sapling{ \crossref{reddsabatchvalidate}\notcanopy{ and}\notbeforecanopy{,}
          \crossref{grothbatchverify}}\canopy{ and \crossref{ed25519batchvalidate}} that $z_j$
          may be sampled from $\range{0}{2^{128}-1}$ instead of $\range{1}{2^{128}-1}$.
    \item Add note in \crossref{inbandrationale} about resistance of \note encryption to
          \partitioningOracleAttacks \cite{LGR2021}.
    \item Add acknowledgement to Mihir Bellare for contributions to the science of \zeroKnowledgeProofs.
    \item Add acknowledgement to Sasha Meyer.
\end{itemize}


\historyentry{2021.2.16}{2021-09-30}
\begin{itemize}
\nufive{
    \item Use complete addition in $\SinsemillaCommitAlg$.
    \item Correct the proof of \theoremref{thmuncommittedorchard}.
    \item Change the type of $\cmOld{}$ in \Orchard to $\GroupP$ rather than $\GroupPstar$,
          i.e.\ allow the identity point.
    \item Change the type of $\rt{Orchard}$ from $\GroupP_{\!x}$ (i.e.\ a \Pallas $x$-coordinate
          or $0$) to $\range{0}{\ParamP{q}-1}$.
          This reflects the existing \zcashd implementation; also checking
          $\rt{Orchard} \in \GroupP_{\!x}$ would require a square root and is unnecessary.
    \item Witness $\DiversifiedTransmitBaseNew$ and $\DiversifiedTransmitPublicNew$ in
          the \Orchard \actionCircuit as $\GroupPstar$, i.e.\ non-identity Pallas points,
          rather than witnessing their representations as \bitSequences. This reflects
          the existing \zcashd implementation.
    \item Note that $\AuthSignPublicPoint$ in \Orchard cannot be the identity.
} %nufive
    \item Correct the consensus rule about the maximum value of outputs in a
          \coinbaseTransaction: it should reference the \blockSubsidy rather than
          the \minerSubsidy.
\end{itemize}


\historyentry{2021.2.15}{2021-09-01}
\begin{itemize}
\nufive{
    \item Correct a minor error in the proof of \theoremref{thmsinsemillacr}:
          the condition $\SinsemillaHashToPoint(D, M) \neq \bot$ is required in
          the proof. (The case $\SinsemillaHashToPoint(D, M) = \bot$ is covered by
          \theoremref{thmsinsemillaex}.) The proof had not been updated correctly
          when the statement was revised in \historyref{2021.2.0}. Also add a missing
          $D$ argument to $\SinsemillaHashToPoint$ in that proof.
} %nufive
    \item Fix a reference to nonexistent version 2019.0-beta-40 of this specification
          (in \crossref{diffadjustment}) that should be \historyref{2019.0.0}.
    \item Fix URL links to \cite{BBDP2001} and \cite{BDJR2000}.
    \item Improve \texttt{protocol/links\_and\_dests.py} to eliminate false positives
          when checking DOI links.
\end{itemize}


\historyentry{2021.2.14}{2021-08-12}
\begin{itemize}
\nufive{
    \item Fix the URL for \cite{ZIP-239} in the References.
} %nufive
\sapling{
    \item Reword the reference to a \Sapling \fullViewingKey in \crossref{saplingdummynotes}
          (the \fullViewingKey would include $\OutViewingKey$, although it is not used
          in that section).
} %sapling
\end{itemize}


\historyentry{2021.2.13}{2021-07-29}
\begin{itemize}
    \item Add consensus rules in \crossref{notecommitmenttrees} that, for each \noteCommitmentTree,
          a \block \MUSTNOT add \noteCommitments that exceed the capacity of that tree.
\end{itemize}


\historyentry{2021.2.12}{2021-07-29}
\begin{itemize}
\nufive{
    \item Change the number of partial rounds, $R_P$, for Poseidon from $58$ to $56$.
          This matches the number calculated by \texttt{calc\_round\_numbers.py} (for
          $128$-bit security ``with margin'') in Version 1.1 of the $\Poseidon$
          reference implementation \cite{Poseidon-1.1} \cite{Poseidon-Zc1.1}.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.2.11}{2021-07-20}
\begin{itemize}
\nufive{
    \item Change the definition of inputs to the \actionCircuit to split $\enableSpends$
          and $\enableOutputs$ into two field elements.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.2.10}{2021-07-13}
\begin{itemize}
\nufive{
    \item Clarify that decomposition of scalars for scalar multiplication in the
          \actionCircuit \MUST be canonical, unless a non-canonical decomposition
          can be proven to result in an equivalent statement -- and clarify for which
          multiplications the latter case applies.
    \item The encoding of the \blockHeight in the \scriptSig{} of a \coinbaseTransaction
          is now at most $5$ bytes (rather than $9$ bytes), because \blockHeight \MUST
          also be encoded in the $32$-bit $\nExpiryHeight$ field of \coinbaseTransactions
          after \NUFive activation.
    \item Clarify in \crossref{transactions} that the remaining value in a
          \transparentTxValuePool is only available to miners as a fee in the case
          of non-coinbase \transactions, and that the remaining value in the
          \transparentTxValuePool of a \coinbaseTransaction is destroyed.
} %nufive
    \item Remove a spurious reference to $\NoteSeedBytes$ in \crossref{sproutinband}.
          There were no changes for \Sprout in \cite{ZIP-212}.
\end{itemize}


\historyentry{2021.2.9}{2021-07-01}
\begin{itemize}
\nufive{
    \item Add a consensus rule for version 5 or later \transactions, that if
          $\nActionsOrchard > 0$ then at least one of $\enableSpendsOrchard$ and
          $\enableOutputsOrchard$ \MUST be $1$.
    \item Delete the consensus rule in \crossref{transactions} that required checking
          that each intermediate \merkleRoot of the \noteCommitmentTree is not $\bot$.
          Checking this rule would have imposed a significant performance penalty,
          since intermediate roots do not otherwise need to be computed.
    \item Change the type of $\MerkleCRH{Orchard}$ to have $\MerkleHashOrchard$ in place
          of $\maybe{\MerkleHashOrchard}$ for the inputs and output, and map a $\bot$
          output from $\SinsemillaHash$ to $0$. (We retain the original definitions
          of $\SinsemillaHash$ and $\SinsemillaHashToPoint$ both because it would be
          disruptive to change them at this point in the Network Upgrade Process, and
          because it is necessary to track $\bot$ outputs in order to correctly model
          non-determinism in the \actionCircuit.)
    \item Allow the Merkle path validity check in the \actionCircuit to pass if any
          output of $\MerkleCRH{Orchard}$ is $0$, and add a note in \crossref{merklepath}
          arguing that this is safe.
    \item Fix a typo in the Security Requirements for \crossref{orchardmerklecrh}: the
          length of the input to $\SinsemillaHash$ is $10 + 2 \mult \MerkleHashLength{Orchard}$
          bits, not $6 + 2 \mult \MerkleHashLength{Orchard}$ bits.
    \item Replace ``must'' with ``\MUST'' in two consensus rules specified in \crossref{txnencoding}.
} %nufive
\heartwood{
    \item Add a clarification in \crossref{txnconsensus} that after \Heartwood and before
          \Canopy activation, \Sapling outputs of a \coinbaseTransaction \MUST have
          \notePlaintextLeadByte equal to $\hexint{01}$. This was implied by the existing
          rule that such outputs \MUST decrypt successfully with an all-zero \outgoingViewingKey.
} %heartwood
\sapling{
    \item Correct $l$ to $\layerRepr$ in two places in \crossref{saplingmerklecrh}.
} %sapling
    \item Correct an erroneous statement in \crossref{transactions} that claimed
          \transactionIDs are not part of the consensus protocol.
\end{itemize}


\historyentry{2021.2.8}{2021-06-29}
\begin{itemize}
\nufive{
    \item Change one of the \sapling{[\Sapling onward]} consensus rules in \crossref{txnconsensus}
          to have the correct applicability: \sapling{[\Sapling to \Canopy inclusive, \nufive{pre-\NUFive}]}.
} %nufive
    \item Describe \transactionIDs\nufive{ and \wtxids} in \crossref{transactions}.
    \item Add a section \crossref{txnidentifiers} on how to compute \transactionIDs\nufive{ and \wtxids}.
    \item Split the \transaction-related consensus rules into their own subsection
          \crossref{txnconsensus}, for more precise cross-referencing.
\end{itemize}


\historyentry{2021.2.7}{2021-06-28}
\begin{itemize}
\nufive{
    \item Correct the type of $\Uncommitted{Orchard}$, which should be $\GroupP_{\!x}$ rather than a
          \bitSequence.
    \item Explicitly say that padding in \crossref{concretesinsemillahash} is by appending zero bits.
    \item Add a step to the algorithm for generating an \Orchard \note in \crossref{orchardsend},
          to restart if $\EphemeralPrivate = 0$.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.2.6}{2021-06-26}
\begin{itemize}
\nufive{
    \item Require that from \NUFive activation, the \nExpiryHeight field of a \coinbaseTransaction
          is set to the \blockHeight. This is needed to maintain the property that all \transactions
          have unique \transactionIDs, as explained in a note in \crossref{txnconsensus}.
          In order to avoid the \blockHeight being limited to $499999999$, we also remove that bound
          on \nExpiryHeight{} for \coinbaseTransactions.
    \item Remove the recommendation to support $63$-bit \blockHeights in \crossref{blockchain}
          (since it is incompatible with the above consensus rule for coinbase \nExpiryHeight).
    \item Ensure that the \merkleLayer number is passed to $\MerkleCRH{}$ in \crossref{merklepath}.
    \item Refine the key components diagram in \crossref{addressesandkeys} to show that \Orchard
          \incomingViewingKeys include both $\DiversifierKey$ and $\InViewingKey$.
    \item Clarify that the $\range{-\MAXMONEY}{\MAXMONEY}$ range restriction applies to both
          \valueBalance{Sapling} and \valueBalance{Orchard}.
    \item Update \crossref{noteptencoding} for \Orchard.
    \item Add \cite{ZIP-203}, \cite{ZIP-212}, and \cite{ZIP-213} to the list of ZIPs updated for \NUFive.
} %nufive
    \item Give cross-references to \crossref{notation} where $\optsqrt{\,\paramdot\,}$ and
          $\possqrt{\,\paramdot\,}$ are used.
\end{itemize}


\historyentry{2021.2.5}{2021-06-19}
\begin{itemize}
\nufive{
    \item Change the consensus rule that requires at least one input to, and at
          least one output from a v5 or later \transaction, to take into account
          the \enableSpendsOrchard{} and \enableOutputsOrchard{} flags.
    \item Correct the type of $\ExtractPbot$ imported in \crossref{concretesinsemillahash}\,
          (from $\GroupP \rightarrow \GroupP_{\!x}$ to \mbox{$\maybe{\GroupP} \rightarrow \maybe{\GroupP_{\!x}}$}).
    \item Add \cite{ZIP-209} to the list of ZIPs updated for \NUFive.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.2.4}{2021-06-08}
\begin{itemize}
\nufive{
    \item Add an explicit consensus rule in \crossref{txnconsensus} that the
          reserved bits of the \flagsOrchard{} field \MUST be zero.
    \item Correct a cut-and-paste error in the algorithm for \crossref{orcharddummynotes},
          which should refer to the \actionStatement rather than the \spendStatement.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.2.3}{2021-06-06}
\begin{itemize}
\nufive{
    \item Specify (as a note in \crossref{actionstatement}) the encoding of \primaryInputs
          to the \actionCircuit. This uses new helper functions $\Selectx$ and $\Selecty$ defined
          in \crossref{concreteextractorpallas}. The specification of $\ExtractP$ has also been
          refactored to use $\Selectx$ (this does not change the \Orchard protocol).
    \item In \crossref{poseidonhash}, say that the round constants as well as the MDS matrices
          are generated according to Version 1.1 of the reference implementation.
    \item Clarify that $\EphemeralPublic$ encoded in an \actionDescription cannot be $\ZeroP$.
    \item Specify that \Orchard \spendingKeys are encoded using \Bechm.
    \item Add \cite{ZIP-239} to the list of ZIPs included in \NUFive.
} %nufive
    \item Move the section on abstraction (previously section 5.1) to \crossref{abstractprotocol}.
          Section 5.2 has been split into two (\crossref{endian} and \crossref{bitlayout}) to
          avoid renumbering later subsections.
    \item Correct an error in the encoding of height-in-coinbase for \blocks at heights
          $\barerange{1}{16}$.
    \item Clarify, in \crossref{blockchain}, requirements on the range of \blockHeights that
          should be supported.
    \item Delete the sentence ``All conversions between \EdSpecific points, \byteSequences,
          and integers used in this section are as specified in \cite{BDLSY2012}.'' from
          \crossref{concreteed25519}. This sentence was misleading given that the conversions
          in $\cite{BDLSY2012}$ are not sufficiently well-specified for a consensus
          protocol; it should have been deleted earlier when explicit definitions for
          $\reprBytesEdSpecific$ and $\abstBytesEdSpecific$ were added.
    \item Make the \NUFive specification the default.
\end{itemize}


\historyentry{2021.2.2}{2021-05-20}
\begin{itemize}
\nufive{
    \item Clarify in \crossref{sighash} that v4 \transactions continue to use the
          \cite{ZIP-243} \sighashAlgorithm after \NUFive activation.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.2.1}{2021-05-20}
\begin{itemize}
\nufive{
    \item Correct the size of \vActionsOrchard{} in \crossref{txnencoding}.
    \item Change the type of \Orchard Merkle \merkleHashes to $\MerkleHashOrchard$, with
          a corresponding change to the signature of $\MerkleCRH{Orchard}$. Add a note to
          \crossref{merklepath} clarifying that \nonCanonicalFieldElement encodings are
          allowed as input to $\MerkleCRH{Orchard}$.
    \item Clarify the distinction between \Orchard \incomingViewingKeys and $\KA{Orchard}$
          \privateKeys.
    \item Add a note in \crossref{concretesinsemillahash} that \cite[Lemma 3]{JT2020} proves
          a tight reduction from finding a nontrivial discrete logarithm relation to the
          \xDiscreteLogarithmProblem.
} %nufive
\sapling{
    \item Add a note to \crossref{merklepath} clarifying the encoding of $\rt{Sapling}$
          as a \primaryInput to the \Sapling \spendCircuit, and that \nonCanonicalFieldElement
          encodings are allowed as input to $\MerkleCRH{Sapling}$.
    \item Change the notation $\mathcal{I}^{\kern-0.05em D}_{\kern0.1em i}$ for a \Sapling
          Pedersen generator to $\PedersenGen(D, i)$.
} %sapling
\end{itemize}


\historyentry{2021.2.0}{2021-05-07}
\begin{itemize}
\nufive{
    \item Include $\NoteUniqueRand$ as an input to the derivation of
          $\NoteNullifierRand$, $\EphemeralPrivate$, and $\NoteCommitRand$ in \Orchard.
          This was originally intended and as described in \cite[Section 3.5 Nullifiers]{Zcash-Orchard}.
    \item Change the statement of \theoremref{thmsinsemillacr} to exclude $\bot$ outputs
          from $\SinsemillaHashToPoint$. This does not affect security given
          \theoremref{thmsinsemillaex}, but the $\bot$ case is only handled by the latter
          proof and not the former.
    \item Delegate to \cite{ZIP-316} for the specification of \unifiedPaymentAddresses,
          \unifiedIncomingViewingKeys, and \unifiedFullViewingKeys (\crossref{unifiedencodings}).
    \item Specify that \diversifierIndices for \Orchard \paymentAddresses should be chosen
          uniquely, not randomly.
    \item Vanity \diversifiers are not an issue for \Orchard given that it does not have its own
          \paymentAddress format, and given the use of ``jumbling'' (\cite{ZIP-316}) in
          \unifiedPaymentAddresses. Remove the corresponding note from \crossref{orchardkeycomponents}.
    \item Clarify that the change to use \hashBlockCommitments{} in a \blockHeader for \NUFive is a
          consensus rule.
    \item Clarify that \transparentInputs are prohibited in \coinbaseTransactions only if they have
          a non-null $\prevoutField$ field.
    \item Caveat how the result of \cite{GG2015} applies to analysis of $\PRFnf{Orchard}{}$ in
          \crossref{concreteprfs}.
    \item Unlinkability of \diversifiedPaymentAddresses depends on the \xDecisionalDiffieHellmanProblem,
          not the \xDiscreteLogarithmProblem.
    \item Add a paragraph to \crossref{truncation} covering \Orchard.
    \item Clarify the definition of $\pad$ in \crossref{concretesinsemillahash} by
          disambiguating $\Mpieces$ from $\Mpadded$.
    \item State explicitly that \valueBalance{Orchard} can only be negative in a \coinbaseTransaction
          if it has \cite{ZIP-213} \shieldedOutputs.
    \item Update the list of ZIPs relevant to \NUFive in \crossref{networkupgrades}.
} %nufive
    \item Clarify notation by changing $\mathsf{\ell_{\NoteCommitRand}}$ to $\NoteCommitRandLengthSprout$.
\end{itemize}


\historyentry{2021.1.24}{2021-04-23}
\begin{itemize}
\nufive{
    \item Add the \nConsensusBranchId{} field to v5 \transactions, matching the \consensusBranchID
          used for \sighashTxHashes.
    \item Include the \diversifierKey in an encoded \Orchard Incoming Viewing Key.
    \item Remove an unused precomputation in \crossref{concretegrouphashpallasandvesta}.
    \item Clarify that only an \outgoingCipherKey is strictly needed to decrypt an \outgoingCiphertext.
} %nufive
    \item Explicitly say that \coinbaseTransactions \MUSTNOT have \transparentInputs
          (this is a consensus rule inherited from \Bitcoin which has been present since launch).
\end{itemize}


\historyentry{2021.1.23}{2021-04-19}
\begin{itemize}
\nufive{
    \item Correct errors in the definitions of $\ExtractP$ and $\ExtractPbot$ in \crossref{concreteextractorpallas}:
          $\ExtractP(\ZeroP)$ should be $0$, and $\ExtractPbot(\bot)$ should be $\bot$.
    \item Change the type of $\KA{Orchard}$ public keys and shared secrets to $\GroupPstar$ (i.e.\ exclude
          $\ZeroP$), and the type of $\KA{Orchard}$ \privateKeys to $\GFstar{\ParamP{r}}$ (i.e.\ exclude $0$).
    \item Change the type of an \Orchard $\InViewingKey$ to $\InViewingKeyTypeOrchard$ (i.e.\ exclude $0$).
    \item Change the types of $\DiversifiedTransmitPublicOld$, $\cmOld{}$ and $\AuthSignPublicPoint$ to
          $\GroupPstar$ in the \auxiliaryInputs to the \actionStatement.
    \item When creating \Orchard \notes, repeat with another $\NoteSeedBytes$ if $\cm$ is $\bot$.
    \item Add a note in \crossref{orchardkeycomponents} about non-uniformity of $\InViewingKey$.
    \item Fix a typo: ``Decription'' to ``Description''.
    \item Add \actionDescriptions to the introduction of \crossref{rhoandnullifiers}.
    \item Use a different footnote symbol for each \Sapling field cardinality rule in v5 \transactions.
} %nufive
    \item Fix some URLs in references.
\end{itemize}


\historyentry{2021.1.22}{2021-04-05}
\begin{itemize}
\nufive{
    \item Specify that a \unifiedPaymentAddress \MUST contain at least one \shieldedPaymentAddress.
    \item Further clarifications to \theoremref{thmsinsemillacr}.
} %nufive
\sapling{
    \item Correct $\SpendVerify$ to $\OutputVerify$ in \crossref{outputdesc}.
} %sapling
    \item Make sure that Change History entries are URL destinations.
\end{itemize}


\historyentry{2021.1.21}{2021-04-01}
\begin{itemize}
\nufive{
    \item Correct and clarify \theoremref{thmsinsemillacr} and \theoremref{thmsinsemillaex}.
    \item Clarify that a \dummyNote should be created if no real \Orchard \note is being
          spent in an \actionTransfer.
    \item Add a caveat in \crossref{orchardkeycomponents} about reuse of $\CommitIvkRand$
          between $\PRFexpand{}$ and $\CommitIvk{}$.
    \item Expand the set of ZIPs associated with \NUFive in \crossref{networkupgrades}, and
          reference \cite{Zcash-Orchard} and \cite{Zcash-halo2} there.
    \item Section \crossref{concreteorchardkdf} should be in \nufivecolorname.
    \item Explicitly note that the end of the \cite{ZIP-212} grace period precedes \NUFive activation.
    \item Change the condition for presence of $\anchorField{Sapling}$ in a version 5 \transaction
          to $\vSpendsSapling > 0$.
} %nufive
\sapling{
    \item Fix type error in $\kdfinput$ for $\KDF{Sapling}$\nufive{ and $\KDF{Orchard}$}
          ($\ephemeralKey$ is already a \byteSequence).
    \item Make a note in \crossref{inbandrationale} of the divergence of $\InViewingKey$ for
          \SaplingAndOrchard from a uniform scalar.
} %sapling
    \item Correct the set of inputs to $\PRFexpand{}$ used for \cite{ZIP-32}\nufive{ and \Orchard}
          in \crossref{abstractprfs}.
    \item Write the caution about linkage between the abstract and concrete protocols in
          \crossref{cautionlinkage}.
    \item Update the \Sprout key component diagram in \crossref{addressesandkeys} to remove
          magenta highlighting.
\end{itemize}


\historyentry{2021.1.20}{2021-03-25}
\begin{itemize}
    \item Credit Eirik \nh{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 Add proof of \collisionResistance for Sinsemilla.
    \item Correct some interim findings of the NCC specification audit:
          \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.
            \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$.
            \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 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 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 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 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 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$.
    \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{unifiedencodings}.
    \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
          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}).
    \item Remove magenta highlighting of differences from \Zerocash.
\end{itemize}


\historyentry{2021.1.19}{2021-03-17}
\begin{itemize}
\nufive{
    \item Correct the range of input to $\ValueCommitAlg{Orchard}$ in the \actionStatement, and
          the corresponding security argument in \crossref{orchardbalance}.
    \item Update the consensus rules that prevent trivial transactions (with no inputs or outputs)
          to take into account \actionTransfers in the v5 \transaction format.
    \item Make $\DiversifyHash{Orchard}$ total, by replacing an output of $\ZeroP$ with another base.
    \item Fix a type error in the non-normative note at the end of \crossref{concretesinsemillacommit}.
} %nufive
\notnufive{
    \item No changes before \NUFive.
} %notnufive
\end{itemize}


\historyentry{2021.1.18}{2021-03-17}
\begin{itemize}
\nufive{
    \item Define \unifiedPaymentAddresses in place of the \Bech form of \Orchard
          \shieldedPaymentAddresses.
    \item Remove \Sprout-specific fields from the v5 \transaction format.
    \item The $\NoteUniqueRand$ value for an \Orchard output \note was incorrectly described as
          being derived from $\NoteSeedBytes$, instead of being set to the nullifier from the same
          \actionDescription as intended.
    \item The $\NoteNullifierRand$ value is now derived using the $\PRFexpand{}$ input $[9]$,
          instead of $[10]$.
    \item Correct a note about the range of the Merkle hash inputs in \crossref{actionstatement}.
    \item Correct the validity condition for $\AuthSignPublic$ in \crossref{orchardfullviewingkeyencoding}.
    \item Add a definition for $\NullifierBaseOrchard$ in \crossref{rhoandnullifiers}.
    \item Correct the number of full and partial rounds for $\Poseidon$.
    \item Add a note explaining the origin of the $2^{65}$ constant in the definition of
          $\PoseidonHash$.
} %nufive
\sapling{
    \item The subgroup check added to \crossref{decryptovk} for \Sapling in \historyref{2021.1.17}
          was applied to the wrong variable ($\DiversifiedTransmitBase$, when it should have been
          $\DiversifiedTransmitPublic$), despite being described correctly in the Change History
          entry below.
} %sapling
\end{itemize}


\historyentry{2021.1.17}{2021-03-15}
\begin{itemize}
\nufive{
    \item Draft \NUFive specification.
} %nufive
\canopy{
    \item In the consensus rule that a \transaction with one or more \transparent inputs from
          \coinbaseTransactions \MUST have no \transparent outputs, explicitly say that inputs
          from \coinbaseTransactions include \fundingStream outputs.
} %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{}$. 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.)
\sapling{
    \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 \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:
          \begin{itemize}
            \item The specification had a type error in that it failed to check whether
                  $\abstJ\Of{\DiversifiedTransmitPublicRepr} = \bot$, which is needed in
                  order for its use as input to $\KAAgree{Sapling}$ to be well-typed.
            \item The specification did not require $\DiversifiedTransmitPublic$ to be
                  in the subgroup $\SubgroupJ$, while the implementation in \zcashd did.
                  This check is not needed for security; however, since \Jubjub public keys
                  are normally of type $\KAPublicPrimeSubgroup{Sapling}$, we change the
                  specification to match \zcashd.
          \end{itemize}
    \item Correct the procedure for generating \dummy \Sapling \notes in \crossref{saplingdummynotes}.
    \item Add a note in \crossref{bctv} describing conditions under which an implementation
          that checkpoints on \Sapling can omit verifying \BCTV proofs.
    \item Rename ``hash extractor'' to \coordinateExtractor. This is a more accurate name
          since it is also used on commitments.
} %sapling
    \item Rename \type{char} to \type{byte} in field type declarations.
\end{itemize}


\historyentry{2021.1.16}{2021-01-11}
\begin{itemize}
    \item Add macros and \Makefile support for building the \NUFive draft specification.
    \item Clarify the encoding of \blockHeights for the ``height in coinbase'' rule.
          The description of this rule has also moved from \shortcrossref{blockheader} to
          \crossref{txnconsensus}.
    \item Include the activation dates of \Heartwood and \Canopy in \crossref{networkupgrades}.
    \item Section links in the \Heartwood and \Canopy versions of the specification now go to
          the correct document URL.
    \item Attempt to improve search and cut-and-paste behaviour for ligatures in some
          PDF readers.
\end{itemize}


\historyentry{2020.1.15}{2020-11-06}
\begin{itemize}
    \item Add a missing consensus rule that has always been implemented in \zcashd: there
          must be at least one \transparentOutput, \outputDescription, or \joinSplitDescription
          in a \transaction.
    \item Add a consensus rule that the (zero-valued) \coinbaseTransaction output of the
          \genesisBlock cannot be spent.
    \item Define \SproutChainValuePoolBalance\sapling{ and \SaplingChainValuePoolBalance,} and include
          consensus rules from \cite{ZIP-209}.
\sapling{
    \item Correct the \Sapling \note decryption algorithms:
          \begin{itemize}
            \item $\ephemeralKey$ is kept as a \byteSequence rather than immediately converted to a
                  curve point; this matters because of \nonCanonicalPoint encoding.
            \item The representation of $\DiversifiedTransmitPublic$ in a \notePlaintext may also be
                  \nonCanonicalPoint and need not be in the \primeOrderSubgroup.
            \item Move checking of $\cmU$ in decryption with $\InViewingKey$ to the end of the
                  algorithm, to more closely match the implementation.
            \item The note about decryption of outputs in \mempool \transactions should have been
                  normative.
          \end{itemize}
          \vspace{-1.5ex}
} %sapling
    \item Reserve \transactionVersionNumber{} \hexint{7FFFFFFF} and \versionGroupID{} \hexint{FFFFFFFF}
          for experimental use.
    \item Remove a statement that the language consisting of key and address encoding
          possibilities is prefix-free. (The human-readable forms are prefix-free but the
          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.
    \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.
\end{itemize}


\historyentry{2020.1.14}{2020-08-19}
\begin{itemize}
    \item The consensus rule that a \coinbaseTransaction must not spend more than is
          available from the \blockSubsidy and \transactionFees, was not explicitly stated.
          (This rule was correctly implemented in \zcashd.)
\sapling{
    \item Fix a type error in the output of $\PRFnf{Sapling}{}$; a \Sapling \nullifier is a
          sequence of $32$ bytes, not a \bitSequence.
    \item Correct an off-by-one in an expression used in the definition of $c$ in
          \crossref{concretepedersenhash} (this does not change the value of $c$).
} %sapling
\end{itemize}


\historyentry{2020.1.13}{2020-08-11}
\begin{itemize}
\sapling{
    \item Rename the type of \Sapling \transmissionKeys from $\KA{Sapling}\mathsf{.PublicPrimeOrder}$
          to $\KAPublicPrimeSubgroup{Sapling}$. This type is defined as $\SubgroupJ$, which reflects
          the implementation in \zcashd (subject to the next point below); it was never enforced that a
          \transmissionKey ($\DiversifiedTransmitPublic$) cannot be $\ZeroJ$.
    \item Add a non-normative note saying that \zcashd does not fully conform to the requirement
          to treat \transmissionKeys not in $\KAPublicPrimeSubgroup{Sapling}$ as invalid when importing
          \shieldedPaymentAddresses.
} %sapling
\canopy{
    \item Set $\CanopyActivationHeight$ for \Testnet.
    \item Modify the tables and notes in \crossref{zip214fundingstreams} to reflect changes in
          \cite{ZIP-214}.
    \item Updates to reflect \cite{ZIP-211}: add a consensus rule on $\vpubOld$ in \crossref{joinsplitdesc},
          and a rule about node and wallet support for sending to \Sprout addresses in \crossref{sproutsend}.
} %canopy
\blossom{
    \item Refine the domain of $\HeightForHalving$ from $\Nat$ to $\PosInt$.
} %blossom
    \item Make $\Halving(\BlockHeight)$ return $0$ (rather than $-1$) for $\BlockHeight < \SlowStartShift$.
          This has no effect on consensus since the $\Halving$ function is not used in that case, but
          it makes the definition match the intuitive meaning of the function.
    \item Rename sections under \crossref{consensusfrombitcoin} to clarify that these sections do not only
          concern encoding, but also consensus rules.
    \item Make the \Canopy specification the default.
\end{itemize}


\historyentry{2020.1.12}{2020-08-03}
\begin{itemize}
    \item Include \bigShaHash in \crossref{concretesha}.
    \item Add a reference to \cite{BCCGLRT2014} in \crossref{abstractzk}.
\canopy{
    \item Use $\abstBytesEdSpecific$ and $\reprBytesEdSpecific$ for conversions in
          \crossref{ed25519batchvalidate}, and fix a missing requirement that
          $\EdDSASigS{j} < \ell$ for all signatures.
}
\end{itemize}


\historyentry{2020.1.11}{2020-07-13}
\begin{itemize}
    \item Change instances of ``the production network'' to ``\Mainnet'', and
          ``the test network'' to \Testnet. This follows the terminology used
          in ZIPs.
    \item Update stale references to \Bitcoin documentation.
\canopy{
    \item Add changes for \cite{ZIP-207} and \cite{ZIP-214}.
}
\end{itemize}


\historyentry{2020.1.10}{2020-07-05}
\begin{itemize}
    \item Corrections to a note in \crossref{concreteed25519}.
\end{itemize}


\historyentry{2020.1.9}{2020-07-05}
\begin{itemize}
    \item Add \crossref{networks}.
    \item Acknowledge Jane Lusby and teor.
    \item Precisely specify the encoding and decoding of \EdSpecific points.
\sapling{
    \item Correct an error introduced in \historyref{2020.1.8}; ``$-\ZeroJ$'' was incorrectly
          used when the point $(0, -1)$ on \Jubjub was meant.
    \item Precisely specify the conversion from a \bitSequence in $\abstJ$.
} %sapling
\end{itemize}


\historyentry{2020.1.8}{2020-07-04}
\begin{itemize}
    \item Add Ying Tong Lai and Kris Nuttycombe as \Zcash protocol designers.
\sapling{
    \item Change the specification of $\abstJ$ in \crossref{jubjub} to match the implementation.
    \item Repair the argument for $\GroupJHash{\URS}$ being usable as a \randomOracle, which
          previously depended on $\abstJ$ being injective.
    \item In $\RedDSA$ verification, clarify that $\RedDSAReprR{}$ used as part of the input to
          $\RedDSAHashToScalar$ \MUST be exactly as encoded in the signature.
} %sapling
\canopy{
    \item Specify that \shieldedOutputs of \coinbaseTransactions \MUST use v2 \notePlaintexts after
          \Canopy activation.
    \item Correct a bug in \crossref{decryptovk}:\\
          $\EphemeralPrivate$ is only to be checked against $\ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([4])\kern-0.1em\big)$
          when $\NotePlaintextLeadByte \neq \hexint{01}$.
          [Later edit: this should have been $\ToScalar{}\big(\PRFexpand{\NoteSeedBytes}([5])\kern-0.1em\big)$.]
} %canopy
\end{itemize}


\historyentry{2020.1.7}{2020-06-26}

\begin{itemize}
    \item Delete some `new' superscripts that only added notational clutter.
    \item Add an explicit lead byte field to \Sprout \notePlaintexts, and clearly specify
          the error handling when it is invalid.
\sapling{
    \item Define a \Sapling \notePlaintextLeadByte as having type $\byte$ (so that decoding to a \notePlaintext
          always succeeds, and error handling is more explicit).
    \item Fix a sign error in the fixed-base term of the batch validation equation in
          \crossref{reddsabatchvalidate}.
} %sapling
\canopy{
    \item Fix a sign error in the fixed-base term of the batch validation equation in
          \crossref{ed25519batchvalidate}.
} %canopy
\end{itemize}


\historyentry{2020.1.6}{2020-06-17}

\begin{itemize}
\canopy{
    \item Incorporate changes to \Sapling \note encryption from \cite{ZIP-212}.
} %canopy
    \item Correct an error in the specification of \EdSpecific \validatingKeys:
          they should not have been specified to be checked against $\PreCanopyExcludedPointEncodings$,
          since libsodium~v1.0.15 does not do so.
\canopy{
    \item Incorporate \EdSpecific changes for \Canopy from \cite{ZIP-215}.
    \item Add Appendix \crossref{ed25519batchvalidate}.
} %canopy
    \item Consistently use ``validating'' for signatures and ``verifying'' for proofs.
\sapling{
    \item Use the symbol $\possqrt{\,\paramdot\,}$ for positive square root.
} %sapling
\end{itemize}


\historyentry{2020.1.5}{2020-06-02}

\begin{itemize}
\sapling{
    \item Reference \cite{ZIP-173} instead of BIP 173.
} %sapling
    \item Mark more index entries as definitions.
\end{itemize}


\historyentry{2020.1.4}{2020-05-27}

\begin{itemize}
    \item Reference \cite{BIP-32} and \cite{ZIP-32} when describing keys and their encodings.
    \item Network Upgrade 4 has been given the name \Canopy.
\canopy{
    \item Reference \cite{ZIP-211}, \cite{ZIP-212}, and \cite{ZIP-215} for the \Canopy upgrade.
} %canopy
    \item Improve LaTeX portability of this specification.
\end{itemize}


\historyentry{2020.1.3}{2020-04-22}

\begin{itemize}
    \item Correct a wording error transposing \transparentInputs and \transparentOutputs
          in \crossref{joinsplitbalance}.
\heartwood{
    \item Minor wording clarifications.
} %heartwood
\canopy{
    \item Reference \cite{ZIP-251}, \cite{ZIP-207}, and \cite{ZIP-214} for the \Canopy upgrade.
} %canopy
\end{itemize}


\historyentry{2020.1.2}{2020-03-20}

\begin{itemize}
    \item The implementation of \Sprout \EdSpecific signature validation
          in \zcashd differed from what was specified in \crossref{concreteed25519}.
          The specification has been changed to match the implementation.
\heartwood{
    \item Add consensus rules for \Heartwood.
} %heartwood
    \item Remove ``pvc'' \Makefile targets.
    \item Make the \Heartwood specification the default.
    \item Add macros and \Makefile support for building the \Canopy specification.
\end{itemize}


\historyentry{2020.1.1}{2020-02-13}

\begin{itemize}
    \item Resolve conflicts in the specification of \memos by deferring to \cite{ZIP-302}.
\end{itemize}


\historyentry{2020.1.0}{2020-02-06}

\begin{itemize}
    \item Specify a retrospective soft fork implemented in \zcashdref{v2.1.1-1} that
          limits the $\nTimeField$ field of a \block relative to its \medianTimePast.
    \item Correct the definition of \medianTimePast for the first $\PoWMedianBlockSpan$
          \blocks in a \blockChain.
    \item Add acknowledgements to Henry de Valence, Deirdre Connolly, Chelsea Komlo,
          and Zancas Wilcox.
    \item Add an acknowledgement to Trail of Bits for their security audit.
    \item Change indices in the \incrementalMerkleTree diagram to be zero-based.
\sapling{
    \item Use the term \quotedterm{monomorphism} for an injective homomorphism, in
          the context of a \keyMonomorphicSignatureScheme.
} %sapling
\end{itemize}

\historyentry{2019.0.9}{2019-12-27}

\begin{itemize}
    \item No changes to \Sprout or \Sapling.
\blossom{
    \item Specify the height at which \Blossom activated.
    \item Add \Blossom to \crossref{networkupgrades}.
    \item Add a non-normative note giving the explicit value of $\FoundersRewardLastBlockHeight$.
    \item Clarify the effect of \Blossom on \sighashTxHashes.
} %blossom
    \item \Makefile updates for \Heartwood.
\end{itemize}

\historyentry{2019.0.8}{2019-09-24}

\begin{itemize}
\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}.
} %sapling
\end{itemize}

\historyentry{2019.0.7}{2019-09-24}

\begin{itemize}
\sapling{
    \item Fix a discrepancy in the number of constraints for BLAKE2s found by QED-it.
    \item Fix an error in the expression for $\PedersenRangeOffset$ in \crossref{cctpedersenhash},
          and add acknowledgement to Kobi Gurkan.
    \item Fix a typo in \crossref{merklepath} and add acknowledgement to Weikeng Chen.
} %sapling
    \item Update references to ZIPs and to the Electric Coin Company blog.
    \item \Makefile improvements to suppress unneeded output.
\end{itemize}

\historyentry{2019.0.6}{2019-08-23}

\begin{itemize}
    \item No changes to \Sprout or \Sapling.
\blossom{
    \item Replace dummy \Blossom \activationHeight with the \Testnet height, and a reference to \cite{ZIP-206}.
}
\end{itemize}

\historyentry{2019.0.5}{2019-08-23}

\begin{itemize}
\blossom{
    \item Note the change to the minimum-difficulty threshold time on \Testnet
          for \Blossom.
} %blossom
\sapling{
    \item Correct the packing of $\nfOld{}$ into input elements in \crossref{cctsaplingspend}.
    \item Add an epigraph from \cite{Carroll1876} to the start of \crossref{jubjub}.
    \item Clarify how the constant $c$ in \crossref{concretepedersenhash} is obtained.
    \item Add a footnote that \zcashd uses \cite{ZIP-32} \extendedSpendingKeys instead of
          the derivation from $\SpendingKey$ in \crossref{addressesandkeys}.
} %sapling
    \item Remove ``optimized'' \Makefile targets (which actually produced
          a larger PDF, with TeXLive 2019).
    \item Remove ``html'' \Makefile targets.
    \item Make the \Blossom spec the default.
\end{itemize}

\historyentry{2019.0.4}{2019-07-23}

\begin{itemize}
    \item Clicking on a section heading now shows section labels.
    \item Add a \snarkref{List of Theorems and Lemmata}{theorems}.
    \item Changes needed to support TeXLive 2019.
\end{itemize}

\historyentry{2019.0.3}{2019-07-08}

\begin{itemize}
    \item Experimental support for building using Lua\TeX{} and Xe\TeX.
    \item Add an \snarkref{Index}{index}.
\end{itemize}

\historyentry{2019.0.2}{2019-06-18}

\begin{itemize}
\sapling{
    \item Correct a misstatement in the security argument in \crossref{bindingsig}:
          \binding for a \commitmentScheme does not imply that the commitment
          determines its randomness. The rest of the security argument did not
          depend on this; it is simpler to rely on knowledge soundness of the
          Spend and Output proofs.
    \item Give a definition for \completeTwistedEdwardsEllipticCurves in \crossref{jubjub}.
    \item Clarify that \theoremref{thmuncommittedsapling} depends on the
          parameters of the \jubjubCurve.
} %sapling
    \item Ensure that this document builds correctly and without missing
          characters on recent versions of \TeX Live.
    \item Update the \Makefile to use Ghostscript for PDF optimization.
    \item Ensure that hyperlinks are preserved, and available as ``Destination names''
          in URL fragments and links from other PDF documents.
\end{itemize}

\historyentry{2019.0.1}{2019-05-20}

\begin{itemize}
    \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$
          for consistency.
} %blossom
\end{itemize}

\historyentry{2019.0.0}{2019-05-01}

\begin{itemize}
    \item Fix a specification error in the \foundersReward calculation during
          the slow start period.
    \item Correct an inconsistency in difficulty adjustment between the spec and
          \zcashd implementation for the first $\PoWAveragingWindow - 1$ \blocks
          of the \blockChain. This inconsistency was pointed out by NCC Group
          in their \Blossom specification audit.
\blossom{
    \item Revert changes for \fundingStreams from Withdrawn ZIP 207.
} %blossom
\end{itemize}

\historyentry{2019.0-beta-39}{2019-04-18}

\begin{itemize}
    \item Change author affiliations from ``Zerocoin Electric Coin Company'' to
          ``Electric Coin Company''.
    \item Add acknowledgement to Mary Maller for the observation that
          \diversifiedPaymentAddress unlinkability can be proven in the same way
          as \keyPrivacy for ElGamal.
\end{itemize}

\historyentry{2019.0-beta-38}{2019-04-18}

\begin{itemize}
\blossom{
    \item Update the following sections to match the current draft of \cite{ZIP-208}:
          \begin{itemize}
            \item \crossref{diffadjustment}
            \item \crossref{subsidies}
          \end{itemize}
    \item Specify \fundingStreams, along with the draft \fundingStreams defined
          in the current draft of ZIP 207.
    \item Update the following sections to match the current draft of ZIP 207:
          \begin{itemize}
            \item \crossref{subsidyconcepts}
            \item \crossref{coinbasetransactions}
            \item \crossref{subsidies}
            \item \crossref{foundersreward}
          \end{itemize}
} %blossom
\sapling{
    \item Correct the generators $\GenS{1}$ and $\GenS{2}$ for BLS12-381.
} %sapling
    \item Update \texttt{README.rst} to include \Makefile targets for
          \Blossom.
    \item \Makefile updates:
          \begin{itemize}
            \item Fix a typo for the \texttt{pvcblossom} target.
            \item Update the pinned \texttt{git} hashes for \texttt{sam2p} and
                  \texttt{pdfsizeopt}.
          \end{itemize}
\end{itemize}

\historyentry{2019.0-beta-37}{2019-02-22}

\begin{itemize}
    \item The rule that miners \SHOULDNOT mine \blocks that chain to other
          \blocks with a \blockVersionNumber{} greater than $4$, has been removed.
          This is because such \blocks (mined nonconformantly) exist in the
          current \Mainnet consensus \blockChain.
    \item Clarify that \Equihash is based on a \emph{variation} of the Generalized
          Birthday Problem, and cite \cite{AR2017}.
    \item Update reference \cite{BGG2017} (previously [BGG2016]).
\sapling{
    \item Clarify which transaction fields are added by \Overwinter and \Sapling.
    \item Correct the rule about when a \transaction is permitted to have no
          \transparent inputs.
    \item Explain the differences between the system in \cite{Groth2016} and what
          we refer to as \Groth.
    \item Reference Mary Maller's security proof for \Groth \cite{Maller2018}.
    \item Correct [BGM2018] to \cite{BGM2017}.
    \item Fix a typo in \crossref{grothbatchverify} and clarify the costs of \Groth
          batch verification.
} %sapling
    \item Add macros and \Makefile support for building the \Blossom specification.
\end{itemize}

\historyentry{2019.0-beta-36}{2019-02-09}

\begin{itemize}
    \item Correct isis agora lovecruft's name.
\end{itemize}

\historyentry{2019.0-beta-35}{2019-02-08}

\begin{itemize}
    \item Cite \cite{Gabizon2019} and acknowledge Ariel Gabizon.
    \item Correct [SBB2019] to \cite{SWB2019}.
    \item The \cite{Gabizon2019} vulnerability affected Soundness of \BCTV
          as well as Knowledge Soundness.
    \item Clarify the history of the \cite{Parno2015} vulnerability and acknowledge
          Bryan Parno.
    \item Specify the difficulty adjustment change that occurred on \Testnet
          at \blockHeight $299188$.
    \item Add Eirik \nh{Ogilvie-Wigley} and Benjamin Winston to acknowledgements.
\sapling{
    \item Rename \zkSNARK Parameters sections to be named according to the proving
          system (\BCTV or \Groth), not the shielded protocol construction
          (\Sprout or \Sapling).
    \item In \crossref{networkupgrades}, say when \Sapling activated.
} %sapling
\end{itemize}

\historyentry{2019.0-beta-34}{2019-02-05}

\begin{itemize}
    \item Disclose a security vulnerability in \BCTV that affected \Sprout
          before activation of the \Sapling \networkUpgrade (see \crossref{bctv}).
    \item Rename PHGR13 to BCTV2014.
    \item Rename reference [BCTV2015] to \cite{BCTV2014a}, and [BCTV2014] to \cite{BCTV2014b}.
\end{itemize}

\historyentry{2018.0-beta-33}{2018-11-14}

\begin{itemize}
\sapling{
    \item Complete \crossref{cctsaplingspend}.
    \item Add \crossref{cctsaplingoutput}.
    \item Change the description of window lookup in \crossref{cctfixedscalarmult}
          to match sapling-crypto.
    \item Describe $2$-bit window lookup with conditional negation in \crossref{cctpedersenhash}.
    \item Fix or complete various calculations of constraint costs.
    \item Adjust the notation used for scalar multiplication in Appendix A to allow \bitSequences
          as scalars.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-32}{2018-10-24}

\begin{itemize}
\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$.
          This matches the sapling-crypto implementation; the specification of this
          input was unintentionally changed in \historyref{2018.0-beta-20}.
    \item Clarify the description of the Merkle path check in \crossref{cctmerklepath}.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-31}{2018-09-30}

\begin{itemize}
\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{}$
          to ensure that $\ell$ is a multiple of $8$ as required.
    \item Minor changes to avoid clashing notation for
          Edwards curves $\Edwards{a,d}$, \MontgomeryCurves $\Montgomery{A,B}$, and
          extractors $\Extractor{\Adversary}$.
    \item Correct a use of $\GroupJ$ that should have been $\MontCurve$ in the proof of
          \theoremref{thmdistinctx}, and make a minor tweak to the theorem statement
          ($k_2 \neq \pm k_1$ instead of $k_1 \neq \pm k_2$) to make the contradiction
          derived by the proof clearer.
    \item Clarify notation in the proof of \theoremref{thmconversiontoedwardsnoexcept}.
    \item Address some of the findings of the QED-it report:
          \begin{itemize}
            \item Improved cross-referencing in \crossref{concretepedersenhash}.
            \item Clarify the notes concerning domain separation of prefixes in
                  \crossref{saplingmerklecrh} and \crossref{concretesaplingnotecommit}.
            \item Correct the statement and proof of \theoremref{thmconversiontomontnoexcept}.
          \end{itemize}
} %sapling
    \item Add the QED-it report to the acknowledgements.
\end{itemize}

\historyentry{2018.0-beta-30}{2018-09-02}

\begin{itemize}
\sapling{
    \item Give an informal security argument for Unlinkability of \diversifiedPaymentAddresses
          based on reduction to \keyPrivacy of ElGamal encryption, for which a security proof
          is given in \cite{BBDP2001}. (This argument has gaps which will be addressed in a future
          version.)
    \item Add a reference to \cite{BGM2017} for the \Sapling \zkSNARK parameters.
    \item Write \crossref{cctsaplingspend} (draft).
    \item Add a reference to the ristretto\_bulletproofs design notes
          \cite{Dalek-notes} for the synthetic blinding factor technique.
    \item Ensure that the constraint costs in \crossref{cctedvalidate} and
          \crossref{cctednonsmallorder} accurately reflect the implementation
          in sapling-crypto.
    \item Minor correction to the non-normative note in \crossref{cctrange}.
    \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
          \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.
} %sapling
    \item Add dates to Change History entries. (These are the dates of the git tags
          in local, i.e.\ UK, time.)
\end{itemize}

\historyentry{2018.0-beta-29}{2018-08-15}

\begin{itemize}
\sapling{
    \item Finish \crossref{cctrange}.
    \item Change \crossref{cctblake2s} to correct the constraint count and
          to describe batched equality checks performed by the sapling-crypto
          implementation.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-28}{2018-08-14}

\begin{itemize}
\sapling{
    \item Finish \crossref{cctblake2s}.
    \item Minor corrections to \crossref{cctvarscalarmult}.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-27}{2018-08-12}

\begin{itemize}
    \item Notational changes:
          \begin{itemize}
            \item Use a superscript $^{\subgroupr}$ to mark the subgroup order, instead of a
                  subscript.
            \item Use $\SubgroupGstar{}$ for the set of $\ParamG{r}$-order points in $\GroupG{}$.
            \item Mark the subgroup order in pairing groups, e.g. use $\SubgroupG{1}$ instead
                  of $\GroupG{1}$.
\sapling{
            \item Make the bit-representation indicator $\Repr$ an affix instead of a superscript.
} %sapling
          \end{itemize}
\sapling{
    \item Clarify that when validating a \Groth proof, it is necessary to perform a
          subgroup check for $\Proof{A}$ and $\Proof{C}$ as well as for $\Proof{B}$.
    \item Correct the description of \Groth batch verification to explicitly take account of
          how verification depends on \primaryInputs.
} %sapling
    \item Add Charles Rackoff, Rafail Ostrovsky, and Amit Sahai to the acknowledgements
          section for their work on \zeroKnowledgeProofs.
\end{itemize}

\historyentry{2018.0-beta-26}{2018-08-05}

\begin{itemize}
\sapling{
    \item Add \crossref{grothbatchverify}.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-25}{2018-08-05}

\begin{itemize}
\sapling{
    \item Add the hashes of parameter files for \Sapling.
    \item Add cross references for parameters and functions used in $\RedDSA$ batch validation.
} %sapling
    \item \Makefile changes: name the PDF file for the \Sprout version of the specification as \texttt{sprout.pdf},
          and make \texttt{protocol.pdf} link to the \Sapling version.
\end{itemize}

\historyentry{2018.0-beta-24}{2018-07-31}

\begin{itemize}
\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$.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-23}{2018-07-27}

\begin{itemize}
\sapling{
    \item Update $\RedDSA$ validation to use cofactor multiplication.
          This is necessary in order for the output of batch validation to match
          that of unbatched validation in all cases.
    \item Add \crossref{reddsabatchvalidate}.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-22}{2018-07-18}

\begin{itemize}
\overwinter{
    \item Update \crossref{networkupgrades} to take account that \Overwinter
          has activated.
    \item The recommendation for \transactions without \joinSplitDescriptions to be
          version 1 applies only before \Overwinter, not before \Sapling.
} %overwinter
\sapling{
    \item Complete the proof of \theoremref{thmpedersendistinctabsindices}.
    \item Add a note about redundancy in the nonsmall-order checking of $\AuthSignRandomizedPublic$.
    \item Clarify the use of $\cvNew{}$ and $\cmNew{}$, and the selection of
          \outgoingViewingKey, in sending Sapling notes.
    \item Delete the description of optimizations for the affine twisted Edwards nonsmall-order
          check, since the \Sapling circuit does not use them. Also clarify that some other
          optimizations are not used.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-21}{2018-06-22}

\begin{itemize}
    \item Remove the consensus rule
          ``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 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.
    \item Clarify the wording of the caveat\footnoteref{securitycaveat} about the claimed security
          of shielded \transactions.
    \item Correct the definition of set difference ($S \setminus T$).
    \item Add a note concerning malleability of \zkSNARKProofs.
    \item Clarify attribution of the \Zcash protocol design.
    \item Acknowledge Alex Biryukov and Dmitry Khovratovich as the designers of \Equihash.
    \item Acknowledge Shafi Goldwasser, Silvio Micali, Oded Goldreich, Rosario Gennaro, Bryan Parno, Jon Howell,
          Craig Gentry, Mariana Raykova, and Jens Groth for their work on \zeroKnowledgeProvingSystems.
    \item Acknowledge Tomas Sander and Amnon \nh{Ta-Shma} for \cite{ST1999}.
    \item Acknowledge Kudelski Security's audit.
\sapling{
    \item Use the more precise subgroup types $\SubgroupG{}$ and $\SubgroupJ$ in preference to
          $\GroupG{}$ and $\GroupJ$ where applicable.
    \item Change the types of \auxiliaryInputs to the \spendStatement and \outputStatement, to be more
          faithful to the implementation.
    \item Rename the $\texttt{cm}$ field of an \outputDescription to $\cmuField$, reflecting the fact that
          it is a \jubjubCurve $u$-coordinate.
    \item Add explicit consensus rules that the $\anchorField{Sapling}$ field of a \spendDescription and the $\cmuField$
          field of an \outputDescription{} must be canonical encodings.
    \item Enforce that $\EphemeralPrivate$ in $\outCiphertext$ is a canonical encoding.
    \item Add consensus rules that $\cv$ in a \spendDescription, and $\cv$ and $\EphemeralPublic$ in an
          \outputDescription, are not of \smallOrder. Exclude $0$ from the range of $\EphemeralPrivate$
          when encrypting \Sapling notes.
    \item Add a consensus rule that $\valueBalance{Sapling}$ is in the range $\range{-\MAXMONEY}{\MAXMONEY}$.
    \item Enforce stronger constraints on the types of key components $\DiversifiedTransmitPublic$,
          $\AuthSignPublic$, and $\NullifierKey$.
    \item Correct the conformance rule for \fOverwintered{} (it must not be set before \Overwinter has
          activated, not before \Sapling has activated).
    \item Correct the argument that $\vSum$ is in range in \crossref{saplingbalance}.
    \item Correct an error in the algorithm for $\RedDSAValidate{}$: the \validatingKey $\vk$ is given directly
          to this algorithm and should not be computed from the unknown \signingKey $\sk$.
    \item Correct or improve the types of $\GroupJHash{}$, $\FindGroupJHash$, $\ExtractJ$, $\PRFexpand{}$,
          $\PRFock{Sapling}{}$, and $\CRHivk$.
    \item Instantiate $\PRFock{Sapling}{}$ using $\BlakeTwob{256}$.
    \item Change the syntax of a \commitmentScheme to add $\CommitGenTrapdoor$. This is necessary
          because the intended distribution of \commitmentTrapdoors may not be uniform on all values
          that are acceptable \trapdoor inputs.
    \item Add notes on the purpose of \outgoingViewingKeys.
    \item Correct the encoding of a \fullViewingKey ($\OutViewingKey$ was missing).
    \item Ensure that \Sprout functions and values are given \Sprout-specific types where appropriate.
    \item Improve cross-referencing.
    \item Clarify the use of \BCTV vs \Groth proofs in \joinSplitStatements.
    \item Clarify that the $\possqrt{a}$ notation refers to the positive square root. (This matters for
          the conversion in \crossref{cctconversion}.)
    \item Model the group hash as a \randomOracle. This appears to be unavoidable in order to allow
          proving unlinkability of $\DiversifyHash{Sapling}$. Explain how this relates to the Discrete Logarithm
          Independence assumption used previously, and justify this modelling by showing that it
          follows from treating $\BlakeTwos{256}$ as a \randomOracle in the instantiation of
          $\GroupJHash{}$.
    \item Rename $\mathsf{CRS}$ (Common Random String) to $\URS$ (\uniformRandomString), to
          match the terminology adopted at the first ZKProof workshop held in Boston, Massachusetts
          on May~10--11, 2018.
    \item Generalize $\PRFexpand{}$ to accept an arbitrary-length input. (This specification does not
          use that generalization, but \cite{ZIP-32} does.)
    \item Change the notation for a multiplication constraint in Appendix \crossref{circuitdesign} to avoid
          potential confusion with cartesian product.
    \item Clarify the wording of the abstract.
    \item Correct statements about which algorithms are instantiated by $\BlakeTwosGeneric$ and
          $\BlakeTwobGeneric$.
    \item Add a note explaining which conformance requirements of BIP 173 (defining \Bech) apply.
    \item Add the Jubjub bird image to the title page. This image has been edited from a scan of
          Peter Newell's original illustration (as it appeared in \cite{Carroll1902}) to remove the
          background and Bandersnatch, and to restore the bird's clipped right wing.
    \item Change the light yellow background to white (indicating that this \Overwinter and \Sapling
          specification is no longer a draft).
} %sapling
\end{itemize}

\historyentry{2018.0-beta-20}{2018-05-22}

\begin{itemize}
    \item Add Michael Dixon and Andrew Poelstra to acknowledgements.
    \item Minor improvements to cross-references.
\sapling{
    \item Correct the order of arguments to $\RedDSARandomizePrivate$ and $\RedDSARandomizePublic$.
    \item Correct a reference to $\RedDSARandomizePrivate$ that was intended to be
          $\RedDSARandomizePublic$.
    \item Fix the description of the \saplingBalancingValue in \crossref{saplingbalance}.
    \item Correct a type error in \crossref{concretegrouphashjubjub}.
    \item Correct a type error in $\RedDSASign{}$ in \crossref{concreteredjubjub}.
    \item Ensure $\AuthSignBase{Sapling}$ is defined in \crossref{concretespendauthsig}.
    \item Make the \validatingKey prefix part of the input to the \hashFunction in $\RedDSA$,
          not part of the message.
    \item Correct the statement about $\FindGroupJHash$ never returning $\bot$.
    \item Correct an error in the computation of generators for \xPedersenHashes.
    \item Change the order in which $\NoteCommitAlg{Sapling}$ commits to its inputs, to match the
          sapling-crypto implementation.
    \item Fail \Sapling key generation if $\InViewingKey = 0$. (This has negligible probability.)
    \item Change the notation $\RedDSAHash^{\star}$ to $\RedDSAHashToScalar$ in \crossref{concreteredjubjub},
          to avoid confusion with the $^{\Repr}$ convention for representations of group elements.
    \item $\cmuField$ encodes only the $u$-coordinate of the \noteCommitment, not the full curve point.
    \item $\AuthSignRandomizedPublic$ is checked to be not of \smallOrder outside the \spendStatement,
          not in the \spendStatement.
    \item Change terminology describing constraint systems.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-19}{2018-04-23}

\begin{itemize}
\sapling{
    \item Minor clarifications.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-18}{2018-04-23}

\begin{itemize}
\sapling{
    \item Clarify the security argument for balance in \Sapling.
    \item Correct a subtle problem with the type of the value input to
          $\ValueCommitAlg{Sapling}$: although it is only directly used to commit to
          values in $\ValueType$, the security argument depends on a sum
          of commitments being \binding on $\ValueCommitTypeSapling$.
    \item Fix the loss of tightness in the use of $\PRFnf{Sapling}{}$ by
          specifying the keyspace more precisely.
    \item Correct type ambiguities for $\NoteUniqueRand$.
    \item Specify the representation of $i$ in group $\GroupG{2}$ of \BLSPairing.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-17}{2018-04-21}

\begin{itemize}
\sapling{
    \item Correct an error in the definition of $\DefaultDiversifier$.
} %sapling
\end{itemize}

\historyentry{2018.0-beta-16}{2018-04-21}

\begin{itemize}
    \item Explicitly note that outputs from \coinbaseTransactions include
          \foundersReward outputs.
    \item The point represented by $\EdDSAReprR{}$ in an \EdSpecific signature is checked
          to not be of \smallOrder; this is not the same as checking that it is of
          \primeOrder $\ell$.
    \item Specify support for \cite{BIP-111} (the \texttt{NODE\_BLOOM} service bit)
          in \peerToPeerProtocol version $170004$.
    \item Give references \cite{Vercauter2009} and \cite{AKLGL2010} for the optimal ate pairing.
    \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}.
    \item Do not require a generator as part of the specification of a \representedGroup;
          instead, define it in the \representedPairing or scheme using the group.
    \item Refactor the abstract definition of a \signatureScheme to allow derivation
          of \validatingKeys independent of key pair generation.
\sapling{
    \item Correct the explanation in \crossref{overview} to apply to \Sapling.
    \item Add the definition of a \signingKey to \validatingKey homomorphism for \signatureSchemes.
    \item Remove the output index as an input to $\KDF{Sapling}$.
    \item Allow dummy \Sapling input \notes.
    \item Specify $\RedDSA$ and $\RedJubjub$.
    \item Specify \saplingBindingSignatures and \spendAuthSignatures.
    \item Specify the randomness beacon.
    \item Add \outgoingCiphertexts and $\OutCipherKey$.
    \item Define $\DefaultDiversifier$.
    \item Change the \spendCircuit and \outputCircuit specifications to remove unintended differences
          from sapling-crypto.
    \item Use $\ParamJ{h}$ to refer to the \jubjubCurve cofactor, rather than $8$.
    \item Correct an error in the $y$-coordinate formula for addition
          in \crossref{cctmontarithmetic} (the constraints were correct).
} %sapling
    \item Add acknowledgements for Brian Warner, Mary Maller, and the Least Authority audit.
    \item \Makefile improvements.
\end{itemize}

\historyentry{2018.0-beta-15}{2018-03-19}

\begin{itemize}
    \item Clarify the bit ordering of SHA-256.
    \item Drop $\type{\_t}$ from the names of representation types.
    \item Remove functions from the \Sprout specification that it does not use.
\overwinter{
    \item Updates to transaction format and consensus rules for Overwinter and Sapling.
} %overwinter
\sapling{
    \item Add specification of the \outputStatement.
    \item Change $\MerkleDepth{Sapling}$ from $29$ to $32$.
    \item Updates to \Sapling construction, changing how the \nullifier is
          computed and separating it from the \authRandomizedValidatingKey
          ($\AuthSignRandomizedPublic$).
    \item Clarify conversions between \bitSequences and \byteSequences for
          $\SpendingKey$, $\reprJ\Of{\AuthSignPublic}$, and $\reprJ\Of{\NullifierKey}$.
} %sapling
    \item Change the \Makefile to avoid multiple reloads in PDF readers while
          rebuilding the PDF.
    \item Spacing and pagination improvements.
\end{itemize}

\historyentry{2018.0-beta-14}{2018-03-11}

\begin{itemize}
    \item Only cosmetic changes to \Sprout.
\sapling{
    \item Simplify $\FindGroupJHash$ to use a single-byte index.
    \item Changes to diversification for \xPedersenHashes and \xPedersenCommitments{}.
    \item Improve security definitions for signatures.
}
\end{itemize}

\historyentry{2018.0-beta-13}{2018-03-11}

\begin{itemize}
    \item Only cosmetic changes to \Sprout.
\sapling{
    \item Change how $(\AuthSignPrivate, \AuthProvePrivate)$ are derived from the \spendingKey
          $\SpendingKey$ to ensure they are on the full range of $\GF{\ParamJ{r}}$.
    \item Change $\PRF{}{\mathsf{nr}}$ to produce output computationally indistinguishable from uniform on
          $\GF{\ParamJ{r}}$.
    \item Change $\Uncommitted{Sapling}$ to be a $u$-coordinate for which there is no point on the curve.
    \item Appendix A updates:
          \begin{itemize}
            \item categorize components into larger sections
            \item fill in the [de]compression and validation algorithm
            \item more precisely state the assumptions for inputs and outputs
            \item delete not-all-one component which is no longer needed
            \item factor out xor into its own component
            \item specify [un]packing more precisely; separate it from boolean constraints
            \item optimize checking for non-\smallOrder
            \item notation in variable-base multiplication algorithm.
          \end{itemize}
}
\end{itemize}

\historyentry{2018.0-beta-12}{2018-03-06}

\begin{itemize}
\overwinter{
    \item Add references to \Overwinter ZIPs and update the section on
          \Overwinter/\Sapling transitions.
}
\sapling{
    \item Add a section on re-randomizable signatures.
    \item Add definition of $\PRF{}{\mathsf{nr}}$.
    \item Work-in-progress on \Sapling \statements.
    \item Rename \quotedtermnoindex{raw} to \quotedtermnoindex{homomorphic} \xPedersenCommitments.
    \item Add packing modulo the field size and range checks to Appendix A.
    \item Update the algorithm for variable-base scalar multiplication to
          what is implemented by sapling-crypto.
}
\end{itemize}

\historyentry{2018.0-beta-11}{2018-02-26}

\begin{itemize}
\sapling{
    \item Add sections on \spendDescriptions and \outputDescriptions.
    \item Swap order of $\cv$ and $\rt{}$ in a \spendDescription for consistency.
    \item Fix off-by-one error in the range of $\InViewingKey$.
}
\end{itemize}

\historyentry{2018.0-beta-10}{2018-02-26}

\begin{itemize}
    \item Split the descriptions of \shaHash and \shaCompress\sapling{, and of $\BlakeTwoGeneric$,}
          into their own sections. Specify \shaCompress more precisely.
    \item Add Kexin Hu to acknowledgements\sapling{ (for the idea of explicitly
          encoding the root of the \Sapling \noteCommitmentTree in \blockHeaders)}.
    \item Move bit/byte/integer conversion primitives into \crossref{endian}.
\sapling{
    \item Refer to \Overwinter and \Sapling just as ``upgrades'' in the abstract, not as
          the next ``minor version'' and ``major version''.
    \item $\PRF{}{\mathsf{nr}}$ must be \collisionResistant\!.
    \item Correct an error in the \xPedersenHash specification.
    \item Use a named variable, $c$, for chunks per segment in the \xPedersenHash
          specification, and change its value from $61$ to $63$. Add a proof
          justifying this value of $c$.
    \item Specify \xPedersenCommitments.
    \item Notation changes.
    \item Generalize the \distinctXCriterion (\theoremref{thmdistinctx})
          to allow negative indices.
}
\end{itemize}

\historyentry{2018.0-beta-9}{2018-02-10}

\begin{itemize}
    \item Specify the coinbase maturity rule, and the rule that \coinbaseTransactions
          cannot contain \joinSplitDescriptions\sapling{, \spendDescriptions, or
          \outputDescriptions}.
\overwinter{
    \item Delay lifting the 100000-byte \transaction size limit from \Overwinter to
          \Sapling.
}
\sapling{
    \item Improve presentation of the proof of injectivity for $\ExtractJ$.
    \item Specify $\GroupJHash{}$.
    \item Specify \xPedersenHashes.
}
\end{itemize}

\historyentry{2018.0-beta-8}{2018-02-08}

\begin{itemize}
\sapling{
    \item Add instantiation of $\CRHivk$.
    \item Add instantiation of a hash extractor (later renamed to \coordinateExtractor)
          for \Jubjub.
    \item Make the background lighter and the \Sapling green darker, for contrast.
}
\end{itemize}

\historyentry{2018.0-beta-7}{2018-02-07}

\begin{itemize}
    \item Specify the $100000$-byte limit on \transaction size.
          (The implementation in \zcashd was as intended.)
    \item Specify that $\hexint{F6}$ followed by $511$ zero bytes encodes an
          empty \memo.
    \item Reference security definitions for
          \pseudoRandomFunctions\sapling{ and \pseudoRandomGenerators}.
    \item Rename $\mathsf{clamp}$ to $\mathsf{bound}$ and
          $\mathsf{ActualTimespanClamped}$ to $\ActualTimespanBounded$
          in the difficulty adjustment algorithm, to avoid a name
          collision with $\KASproutCurve$ scalar ``clamping''.
    \item Change uses of the term \term{full node} to \fullValidator.
          A \defining{\term{full node}} by definition participates in the
          \peerToPeerNetwork, whereas a \fullValidator just needs a copy
          of the \blockChain from somewhere. The latter is what was meant.
\sapling{
    \item Add an explanation of how \Sapling prevents Faerie Gold and
          roadblock attacks.
    \item \Sapling work in progress.
}
\end{itemize}

\historyentry{2018.0-beta-6}{2018-01-31}

\begin{itemize}
\sapling{
    \item \Sapling work in progress, mainly on Appendix \crossref{circuitdesign}.
}
\end{itemize}

\historyentry{2018.0-beta-5}{2018-01-30}

\begin{itemize}
    \item Specify more precisely the requirements on \EdSpecific
          \validatingKeys and signatures.
\sapling{
    \item \Sapling work in progress.
}
\end{itemize}

\historyentry{2018.0-beta-4}{2018-01-25}

\begin{itemize}
\sapling{
    \item Update key components diagram for \Sapling.
}
\end{itemize}

\historyentry{2018.0-beta-3}{2018-01-22}

\begin{itemize}
    \item Explain how the chosen fix to Faerie Gold avoids a potential
          ``roadblock'' attack.
\sapling{
    \item Update some explanations of changes from \Zerocash for \Sapling.
    \item Add a description of the \jubjubCurve.
    \item Add an acknowledgement to George Tankersley.
    \item Add an appendix on the design of the \Sapling circuits at the
          \quadraticConstraintProgram level.
}
\end{itemize}

\historyentry{2017.0-beta-2.9}{2017-12-17}

\begin{itemize}
    \item Refer to $\TransmitPrivate$ as a \receivingKey rather than as a
          viewing key.
    \item Updates for \incomingViewingKey support.
\overwinter{
    \item Refer to Network Upgrade 0 as \Overwinter.
}
\end{itemize}

\historyentry{2017.0-beta-2.8}{2017-12-02}

\begin{itemize}
    \item Correct the non-normative note describing how to check the order
          of $\Proof{B}$.
\sapling{
    \item Initial version of draft \Sapling protocol specification.
}
\end{itemize}

\historyentry{2017.0-beta-2.7}{2017-07-10}

\begin{itemize}
    \item Fix an off-by-one error in the specification of the \Equihash algorithm
          binding condition. (The implementation in \zcashd was as intended.)
    \item Correct the types and consensus rules for \transactionVersionNumbers
          and \blockVersionNumbers. (Again, the implementation in \zcashd was as
          intended.)
    \item Clarify the computation of $\h{i}$ in a \joinSplitStatement.
\end{itemize}

\historyentry{2017.0-beta-2.6}{2017-05-09}

\begin{itemize}
    \item Be more precise when talking about curve points and pairing groups.
\end{itemize}

\historyentry{2017.0-beta-2.5}{2017-03-07}

\begin{itemize}
    \item Clarify the consensus rule preventing \doubleSpends.
    \item Clarify what a \noteCommitment opens to in \crossref{crprf}.
    \item Correct the order of arguments to $\CommitAlg$ in \crossref{concretesproutnotecommit}.
    \item Correct a statement about indistinguishability of \joinSplitDescriptions.
    \item Change the \foundersReward addresses, for \Testnet only, to
          reflect the hard-fork upgrade described in \cite{Zcash-Issue2113}.
\end{itemize}

\historyentry{2017.0-beta-2.4}{2017-02-25}

\begin{itemize}
    \item Explain a variation on the Faerie Gold attack and why it is prevented.
    \item Generalize the description of the InternalH attack to include finding
          collisions on $(\AuthPublic, \NoteUniqueRand)$ rather than just on
          $\NoteUniqueRand$.
    \item Rename $\mathsf{enforce}_i$ to $\EnforceMerklePath{i}$.
\end{itemize}

\historyentry{2017.0-beta-2.3}{2017-02-12}

\begin{itemize}
    \item Specify the security requirements on the \shaCompress function, in order
          for the scheme in \crossref{concretesproutnotecommit} to be a secure commitment.
    \item Specify $\GroupG{2}$ more precisely.
    \item Explain the use of interstitial \treestates in chained \joinSplitTransfers.
\end{itemize}

\historyentry{2017.0-beta-2.2}{2017-02-11}

\begin{itemize}
    \item Give definitions of computational \binding and computational \hiding
          for \commitmentSchemes.
    \item Give a definition of statistical zero knowledge.
    \item Reference the white paper on MPC parameter generation \cite{BGG2017}.
\end{itemize}

\historyentry{2017.0-beta-2.1}{2017-02-06}

\begin{itemize}
    \item $\MerkleHashLength{}$ is a bit length, not a byte length.
    \item Specify the maximum \block size.
\end{itemize}

\historyentry{2017.0-beta-2}{2017-02-04}

\begin{itemize}
    \item Add abstract and keywords.
    \item Fix a typo in the definition of \nullifier integrity.
    \item Make the description of \blockChains more consistent with
          upstream \Bitcoin documentation (referring to ``best`` chains
          rather than using the concept of a \termnoindex{block chain view}).
    \item Define how nodes select a \bestValidBlockChain.
\end{itemize}

\historyentry{2016.0-beta-1.13}{2017-01-20}

\begin{itemize}
    \item Specify the difficulty adjustment algorithm.
    \item Clarify some definitions of fields in a \blockHeader.
    \item Define $\PRFaddr{}$ in \crossref{sproutkeycomponents}.
\end{itemize}

\historyentry{2016.0-beta-1.12}{2017-01-09}

\begin{itemize}
    \item Update the hashes of proving and verifying keys for the final Sprout parameters.
    \item Add cross references from \shieldedPaymentAddress and \spendingKey encoding
          sections to where the key components are specified.
    \item Add acknowledgements for Filippo Valsorda and Zaki Manian.
\end{itemize}

\historyentry{2016.0-beta-1.11}{2016-12-19}

\begin{itemize}
    \item Specify a check on the order of $\Proof{B}$ in a \zkSNARKProof.
    \item Note that due to an oversight, the \Zcash \genesisBlock does not
          follow \cite{BIP-34}.
\end{itemize}

\historyentry{2016.0-beta-1.10}{2016-10-30}

\begin{itemize}
    \item Update reference to the \Equihash paper \cite{BK2016}. (The newer version
          has no algorithmic changes, but the section discussing potential ASIC
          implementations is substantially expanded.)
    \item Clarify the discussion of proof size in ``Differences from the \Zerocash paper''.
\end{itemize}

\historyentry{2016.0-beta-1.9}{2016-10-28}

\begin{itemize}
    \item Add \foundersReward addresses for \Mainnet.
    \item Change \quotedtermnoindex{protected} terminology to \quotedtermnoindex{shielded}.
\end{itemize}

\historyentry{2016.0-beta-1.8}{2016-10-04}

\begin{itemize}
    \item Revise the lead bytes for \transparent P2SH and P2PKH addresses,
          and reencode the \Testnet \foundersReward addresses.
    \item Add a section on which BIPs apply to \Zcash.
    \item Specify that \ScriptOP{CODESEPARATOR} has been disabled, and
          no longer affects \sighashTxHashes.
    \item Change the representation type of $\vpubOldField$ and $\vpubNewField$
          to \type{uint64}. (This is not a consensus change because the type of
          $\vpubOld$ and $\vpubNew$ was already specified to be $\range{0}{\MAXMONEY}$;
          it just better reflects the implementation.)
    \item Correct the representation type of the \block $\nVersion$ field to
          \type{uint32}.
\end{itemize}

\historyentry{2016.0-beta-1.7}{2016-10-02}

\begin{itemize}
    \item Clarify the consensus rule for payment of the \foundersReward, in
          response to an issue raised by the NCC audit.
\end{itemize}

\historyentry{2016.0-beta-1.6}{2016-09-26}

\begin{itemize}
    \item Fix an error in the definition of the sortedness condition for \Equihash:
          it is the sequences of indices that are sorted, not the sequences of
          hashes.
    \item Correct the number of bytes in the encoding of $\solutionSize$.
    \item Update the section on encoding of \transparentAddresses.
          (The precise prefixes are not decided yet.)
    \item Clarify why $\BlakeTwob{\ell}$ is different from truncated $\BlakeTwob{512}$.
    \item Clarify a note about \nh{SU-CMA} security for signatures.
    \item Add a note about $\PRFnf{Sprout}{}$ corresponding to $\PRFsn{}$ in \Zerocash.
    \item Add a paragraph about key length in \crossref{inbandrationale}.
    \item Add acknowledgements for John Tromp, Paige Peterson, Maureen Walsh,
          Jay Graber, and Jack Gavigan.
\end{itemize}

\historyentry{2016.0-beta-1.5}{2016-09-22}

\begin{itemize}
    \item Update the \foundersReward address list.
    \item Add some clarifications based on Eli \nh{Ben-Sasson}'s review.
\end{itemize}

\historyentry{2016.0-beta-1.4}{2016-09-19}

\begin{itemize}
    \item Specify the \blockSubsidy, \minerSubsidy, and the \foundersReward.
    \item Specify \coinbaseTransaction outputs to \foundersReward addresses.
    \item Improve notation (for example ``$\mult$'' for multiplication and
          ``$\typeexp{T}{\ell}$'' for sequence types) to avoid ambiguity.
\end{itemize}

\historyentry{2016.0-beta-1.3}{2016-09-16}

\begin{itemize}
    \item Correct the omission of $\solutionSize$ from the \blockHeader format.
    \item Document that \type{compactSize}{} encodings must be canonical.
    \item Add a note about conformance language in the introduction.
    \item Add acknowledgements for Solar Designer, Ling Ren and Alison Stevenson,
          and for the NCC Group and Coinspect security audits.
\end{itemize}

\historyentry{2016.0-beta-1.2}{2016-09-11}

\begin{itemize}
    \item Remove $\mathsf{GeneralCRH}$ in favour of specifying $\hSigCRH$ and
          $\EquihashGen{}$ directly in terms of $\BlakeTwob{\ell}$.
    \item Correct the security requirement for $\EquihashGen{}$.
\end{itemize}

\historyentry{2016.0-beta-1.1}{2016-09-05}

\begin{itemize}
    \item Add a specification of abstract signatures.
    \item Clarify what is signed in the ``Sending Notes'' section.
    \item Specify ZK parameter generation as a randomized algorithm, rather
          than as a distribution of parameters.
\end{itemize}

\historyentry{2016.0-beta-1}{2016-09-04}

\begin{itemize}
    \item Major reorganization to separate the abstract cryptographic protocol
          from the algorithm instantiations.
    \item Add type declarations.
    \item Add a ``\nh{High-level} Overview'' section.
    \item Add a section specifying the \zeroKnowledgeProvingSystem and the
          encoding of proofs. Change the encoding of points in proofs to follow
          IEEE Std 1363[a].
    \item Add a section on consensus changes from \Bitcoin, and the specification
          of \Equihash.
    \item Complete the ``Differences from the \Zerocash paper'' section.
    \item Correct the Merkle tree depth to 29.
    \item Change the length of \memos to 512 bytes.
    \item Switch the \joinSplitSignature scheme to \EdSpecific, with consequent
          changes to the computation of $\hSig$.
    \item Fix the lead bytes in \shieldedPaymentAddress and \spendingKey encodings to
          match the implemented protocol.
    \item Add a consensus rule about the ranges of $\vpubOld$ and $\vpubNew$.
    \item Clarify cryptographic security requirements and added definitions
          relating to the \inBand secret distribution.
    \item Add various citations: the ``Fixing Vulnerabilities in the Zcash
          Protocol'' and ``Why Equihash?'' blog posts, several crypto papers
          for security definitions, the \Bitcoin whitepaper, the \CryptoNote
          whitepaper, and several references to \Bitcoin documentation.
    \item Reference the extended version of the \Zerocash paper rather than the
          Oakland proceedings version.
    \item Add \joinSplitTransfers to the Concepts section.
    \item Add a section on Coinbase Transactions.
    \item Add acknowledgements for Jack Grigg, Simon Liu, Ariel Gabizon, jl777,
          Ben Blaxill, Alex Balducci, and Jake Tarren.
    \item Fix a \Makefile compatibility problem with the escaping behaviour
          of \texttt{echo}.
    \item Switch to \texttt{biber} for the bibliography generation, and add
          backreferences.
    \item Make the date format in references more consistent.
    \item Add visited dates to all URLs in references.
    \item Terminology changes.
\end{itemize}

\historyentry{2016.0-alpha-3.1}{2016-05-20}

\begin{itemize}
    \item Change main font to Quattrocento.
\end{itemize}

\historyentry{2016.0-alpha-3}{2016-05-09}

\begin{itemize}
    \item Change version numbering convention (no other changes).
\end{itemize}

\historyentry{2.0-alpha-3}{2016-05-06}

\begin{itemize}
    \item Allow anchoring to any previous output \treestate in the same \transaction,
          rather than just the immediately preceding output \treestate.
    \item Add change history.
\end{itemize}

\historyentry{2.0-alpha-2}{2016-04-21}

\begin{itemize}
    \item Change from truncated $\BlakeTwob{512}$ to $\BlakeTwob{256}$.
    \item Clarify endianness, and that uses of $\BlakeTwobGeneric$ are unkeyed.
    \item Minor correction to what \sighashTypes cover.
    \item Add ``as intended for the \Zcash release of summer 2016" to title page.
    \item Require $\PRFaddr{}$ to be \collisionResistant (see \crossref{crprf}).
    \item Add specification of path computation for the \incrementalMerkleTree.
    \item Add a note in \crossref{sproutmerklepathvalidity} about how this condition
          corresponds to conditions in the \Zerocash paper.
    \item Changes to terminology around keys.
\end{itemize}

\historyentry{2.0-alpha-1}{2016-03-30}

\begin{itemize}
    \item First version intended for public review.
\end{itemize}


\intropart
\lsection{References}{references}

\begingroup
\hfuzz=2pt
\renewcommand{\section}[2]{}
\renewcommand{\emph}[1]{\textit{#1}}
\widowpenalties 1 10000
\printbibliography
\endgroup

\pagebreak
\appendix
\lpart{Appendices}{appendices}

\lsection{Circuit Design}{circuitdesign}

\lsubsection{Quadratic Constraint Programs}{constraintprograms}

\Sapling defines two circuits, Spend and Output, each implementing an abstract
\statement described in \crossref{spendstatement} and \crossref{outputstatement}
respectively. It also adds a \Groth circuit for the \joinSplitStatement
described in \crossref{joinsplitstatement}.

At the next lower level, each circuit is defined in terms of a
\defining{\quadraticConstraintProgram} (specifying a \defining{\rankOneConstraintSystem}),
as detailed in this section. In the \BCTV or \Groth proving systems, this program is
translated to a \defining{\quadraticArithmeticProgram} \cite[section 2.3]{BCTV2014a}
\cite{WCBTV2015}. The circuit descriptions given here are necessary to compute
witness elements for each circuit, as well as the proving and verifying keys.

\vspace{1.5ex}
Let $\GF{\ParamS{r}}$ be the finite field over which \Jubjub is defined, as
given in \crossref{jubjub}.

\introlist
A \quadraticConstraintProgram consists of a set of constraints over
variables in $\GF{\ParamS{r}}$, each of the form:

\begin{formulae}
  \item $\constraint{A}{B}{C}$
\end{formulae}
\vspace{-2ex}
where $\lincomb{A}$, $\lincomb{B}$, and $\lincomb{C}$ are \defining{\linearCombinations}
of variables and constants in $\GF{\ParamS{r}}$.

Here $\vartimes$ and $\mult$ both represent multiplication in the field $\GF{\ParamS{r}}$,
but we use $\vartimes$ for multiplications corresponding to gates of the circuit,
and $\mult$ for multiplications by constants in the terms of a \linearCombination.
$\vartimes$ should not be confused with $\times$ which is defined as cartesian product
in \crossref{notation}.

\lsubsection{Elliptic curve background}{ecbackground}

The \Sapling circuits make use of a \completeTwistedEdwardsEllipticCurve (``\ctEdwardsCurve'')
\Jubjub, defined in \crossref{jubjub}, and also a \MontgomeryEllipticCurve $\MontCurve$
that is birationally equivalent to \Jubjub. Following the notation in \cite{BL2017} we use
$(u, \varv)$ for affine coordinates on the \ctEdwardsCurve, and $(x, y)$ for
affine coordinates on the \MontgomeryCurve.

A point $P$ is normally represented by two $\GF{\ParamS{r}}$ variables, which
we name as $(P^u, P^{\spv})$ for an \affineCtEdwards point, for instance.

The implementations of scalar multiplication require the scalar to be represented
as a \bitSequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning
$\scalarmult{\LEBStoIPOf{\length(k\Repr)}{k\Repr}}{P}$. There will be no ambiguity
because variables representing \bitSequences are named with a $\Repr$ suffix.

\introlist
The \defining{\MontgomeryCurve} $\MontCurve$ has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$.
We use an affine representation of this curve with the formula:

\begin{formulae}
  \item $\ParamM{B} \smult y^2 = x^3 + \ParamM{A} \smult x^2 + x$
\end{formulae}

Usually, elliptic curve arithmetic over prime fields is implemented using
some form of projective coordinates, in order to reduce the number of expensive
inversions required. In the circuit, it turns out that a division can be
implemented at the same cost as a multiplication, i.e.\ one constraint.
Therefore it is beneficial to use affine coordinates for both curves.

\introlist
\defining{We define the following types representing \affineCtEdwards and \affineMontgomery
coordinates respectively:}

\begin{tabular}{@{\hskip 2em}r@{\;}l@{\;}l}
  $\AffineCtEdwardsJubjub$ &$:= (u \typecolon \GF{\ParamS{r}}) \times (\hspace{0.04em}\varv\hspace{0.04em} \typecolon \GF{\ParamS{r}})$
    &$: \ParamJ{a} \smult u^2 + \varv^2 = 1 + \ParamJ{d} \smult u^2 \smult \varv^2$ \\
  $\AffineMontJubjub$    &$:= (x \typecolon \GF{\ParamS{r}}) \times (y \typecolon \GF{\ParamS{r}})$
    &$: \ParamM{B} \smult y^2 = x^3 + \ParamM{A} \smult x^2 + x$
\end{tabular}

\introlist
We also define a type representing compressed, \emph{not necessarily valid},
ctEdwards coordinates:

\begin{formulae}
  \item $\CompressedCtEdwardsJubjub := (\tilde{u} \typecolon \bit) \times (\varv \typecolon  \GF{\ParamS{r}})$
\end{formulae}
\vspace{-1.5ex}
See \crossref{jubjub} for how this type is represented as a \byteSequence in
external encodings.

\vspace{2ex}
We use \affineMontgomery arithmetic in parts of the circuit because it is
more efficient, in terms of the number of constraints, than \affineCtEdwards
arithmetic.

An important consideration when using Montgomery arithmetic is that the
addition formula is not complete, that is, there are cases where it produces
the wrong answer. We must ensure that these cases do not arise.

\introlist
We will need the theorem below about $y$-coordinates of points on
\MontgomeryCurves.

\vspace{1ex}
\fact{$\ParamM{A}^2 - 4$ is a nonsquare in $\GF{\ParamS{r}}$.}

\vspace{-1ex}
\introlist
\theoremlabel{thmmontynotzero}
\begin{theorem}[$(0, 0)$ is the only point with $y = 0$ on certain \MontgomeryCurves]

Let $P = (x, y)$ be a point other than $(0, 0)$ on a \MontgomeryCurve $\Montgomery{A,B}$
over $\GF{r}$, such that $A^2 - 4$ is a nonsquare in $\GF{r}$.
Then $y \neq 0$.
\end{theorem}

\begin{proof}
Substituting $y = 0$ into the \MontgomeryCurve equation gives
$0 = x^3 + A \mult x^2 + x = x \mult (x^2 + A \mult x + 1)$.
So either $x = 0$ or $x^2 + A \mult x + 1 = 0$.
Since $P \neq (0, 0)$, the case $x = 0$ is excluded.
In the other case, complete the square for $x^2 + A \mult x + 1 = 0$
to give the equivalent $(2 \mult x + A)^2 = A^2 - 4$.
The left-hand side is a square, so if the right-hand side is a nonsquare,
then there are no solutions for $x$.
\end{proof}


\introsection
\lsubsection{Circuit Components}{cctcomponents}

Each of the following sections describes how to implement a particular
component of the circuit, and counts the number of constraints required.
Some components make use of others; the order of presentation is ``bottom-up''.

It is important for security to ensure that variables intended to be of
boolean type are boolean-constrained; and for efficiency that they are
boolean-constrained only once. We explicitly state for the boolean inputs and
outputs of each component whether they are boolean-constrained by the component,
or are assumed to have been boolean-constrained separately.

Affine coordinates for elliptic curve points are assumed to represent points
on the relevant curve, unless otherwise specified.

In this section, variables have type $\GF{\ParamS{r}}$ unless otherwise specified.
In contrast to most of this document, we use zero-based indexing in order
to more closely match the implementation.


\introsection
\lsubsubsection{Operations on individual bits}{cctbitops}

\lsubsubsubsection{Boolean constraints}{cctboolean}

A boolean constraint $b \in \bit$ can be implemented as:

\begin{formulae}
  \item $\constraint{1 - b}{b}{0}$
\end{formulae}


\introlist
\lsubsubsubsection{Conditional equality}{cctcondeq}

The constraint ``either $a = 0$ or $b = c$'' can be implemented as:

\begin{formulae}
  \item $\constraint{a}{b - c}{0}$
\end{formulae}


\introlist
\lsubsubsubsection{Selection constraints}{cctselection}

A selection constraint $(b \bchoose x : y) = z$, where $b \typecolon \bit$ has been
boolean-constrained, can be implemented as:

\begin{formulae}
  \item $\constraint{b}{y - x}{y - z}$
\end{formulae}


\introsection
\lsubsubsubsection{Nonzero constraints}{cctnonzero}

Since only nonzero elements of $\GF{\ParamS{r}}$ have a multiplicative inverse, the
assertion $a \neq 0$ can be implemented by witnessing the inverse,
$\Inv{a} = a^{-1} \pmod{\ParamS{r}}$:

\begin{formulae}
  \item $\constraint{\Inv{a}}{a}{1}$
\end{formulae}

This technique comes from \cite[Appendix D.1]{SVPBABW2012}.

\nnote{A global optimization allows to use a single inverse computation outside
the circuit for any number of nonzero constraints. Suppose that we have
$n$ variables (or \linearCombinations) that are supposed to be nonzero:
$a_\barerange{0}{n-1}$. Multiply these together (using $n\!-\!1$ constraints)
to give $a^* = \sproduct{i=0}{n-1} a_i$; then, constrain $a^*$ to be nonzero.
This works because the product $a^*$ is nonzero if and only if all of
$a_\barerange{0}{n-1}$ are nonzero. However, the \Sapling circuit does not use
this optimization.}


\introsection
\lsubsubsubsection{Exclusive-or constraints}{cctxor}

An exclusive-or operation $a \xor b = c$, where $a, b \typecolon \bit$ are
already boolean-constrained, can be implemented in one constraint as:

\begin{formulae}
  \item $\constraint{2 \smult a}{b}{a + b - c}$
\end{formulae}

This automatically boolean-constrains $c$. Its correctness can be seen
by checking the truth table of $(a, b)$.


\introsection
\lsubsubsection{Operations on multiple bits}{cctmultibitops}

\lsubsubsubsection{[Un]packing modulo \rS}{cctmodpack}

Let $n \typecolon \PosInt$ be a constant.
The operation of converting a field element, $a \typecolon \GF{\ParamS{r}}$,
to a sequence of boolean variables $b_\barerange{0}{n-1} \typecolon \bitseq{n}$
such that $a = \ssum{i=0}{n-1} b_i \mult 2^i \pmod{\ParamS{r}}$, is called
\definingquotedterm{unpacking}. The inverse operation is called \definingquotedterm{packing}.

In the \quadraticConstraintProgram these are the same operation (but
see the note about canonical representation below). We assume that
the variables $b_\barerange{0}{n-1}$ are boolean-constrained separately.

We have $a \bmod \ParamS{r} = \left(\vsum{i=0}{n-1} b_i \mult 2^i\right) \bmod \ParamS{r}
                            = \left(\vsum{i=0}{n-1} b_i \mult (2^i \bmod \ParamS{r})\!\right) \bmod \ParamS{r}$.

\introlist
This can be implemented in one constraint:

\begin{formulae}
  \item $\constraint{\vsum{i=0}{n-1} b_i \mult (2^i \bmod \ParamS{r})}{1}{a}$
\end{formulae}

\begin{pnotes}
  \item The bit length $n$ is not limited by the field element size.
  \item Since the constraint has only a trivial multiplication, it is
        possible to eliminate it by merging it into the boolean constraint
        of one of the output bits, expressing that bit as a linear
        combination of the others and $a$. However, this optimization
        requires substitutions that would interfere with the modularity
        of the circuit implementation (for a saving of only one constraint
        per unpacking operation), and so we do not use it for the
        \Sapling circuit.
  \item In the case $n = 255$, for $a < 2^{255} - \ParamS{r}$ there are two
        possible representations of $a \typecolon \GF{\ParamS{r}}$ as a
        sequence of $255$ bits, corresponding to $\ItoLEBSPOf{255}{a}$ and
        $\ItoLEBSPOf{255}{a + \ParamS{r}}$. This is a potential hazard, but
        it may or may not be necessary to force use of the canonical
        representation $\ItoLEBSPOf{255}{a}$, depending on the context
        in which the [un]packing operation is used. We therefore do not
        consider this to be part of the [un]packing operation itself.
\end{pnotes}


\introlist
\lsubsubsubsection{Range check}{cctrange}

Let $n \typecolon \PosInt$ be a constant, and let
$a = \ssum{i=0}{n-1} a_i \mult 2^i \typecolon \Nat$.
Suppose we want to constrain $a \leq c$ for some \emph{constant}
$c = \ssum{i=0}{n-1} c_i \mult 2^i \typecolon \Nat$.

Without loss of generality we can assume that $c_{n-1} = 1$, because if it
were not then we would decrease $n$ accordingly.

Note that since $a$ and $c$ are provided in binary representation, their
bit length $n$ is not limited by the field element size. We \emph{do not} assume
that the bits $a_\barerange{0}{n-1}$ are already boolean-constrained.

Define $\Pi_{m} = \sproduct{i=m}{n-1} (c_i = 0 \bor a_i = 1)$ for $m \in \range{0}{n-1}$.
Notice that for any $m < n-1$ such that $c_m = 0$, we have $\Pi_m = \Pi_{m+1}$,
and so it is only necessary to allocate separate variables for the $\Pi_m$
such that $m < n-1$ and $c_m = 1$. Furthermore if $c_{\barerange{n-2}{0}}$ has
$t > 0$ trailing $1$ bits, then we do not need to allocate variables for
$\Pi_{\barerange{0}{t-1}}$ because those variables will not be used below.

\introlist
More explicitly:

Let $\Pi_{n-1} = a_{n-1}$.

For $i \from n-2 \downto t$,
\begin{itemize}
  \item if $c_i = 0$, then let $\Pi_i = \Pi_{i+1}$;
  \item if $c_i = 1$, then constrain $\constraint{\Pi_{i+1}}{a_i}{\Pi_i}$.
\end{itemize}

\introlist
Then we constrain the $a_i$ as follows:

For $i \from n-1 \downto 0$,
\begin{itemize}
  \item if $c_i = 0$, constrain $\constraint{1 - \Pi_{i+1} - a_i}{a_i}{0}$;
  \item if $c_i = 1$, boolean-constrain $a_i$ as in \crossref{cctboolean}.
\end{itemize}

Note that the constraints corresponding to zero bits of $c$ are \emph{in place of}
boolean constraints on bits of $a_i$.

This costs $n + k$ constraints, where $k$ is the number of non-trailing $1$ bits in
$c_{\barerange{n-2}{0}}$.

\introsection
\theoremlabel{thmrangeconstraints}
\begin{theorem}[Correctness of a constraint system for range checks]

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$ 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}

\begin{proof}
For $i \in \range{0}{n-1}$ such that $c_i = 1$, the corresponding $a_i$ are
unconditionally boolean-constrained. This implies that the system
constrains $\Pi_i \in \bit$ for all $i \in \range{0}{n-1}$. For $i \in \range{0}{n-1}$
such that $c_i = 0$, the constraint $\constraint{1 - \Pi_{i+1} - a_i}{a_i}{0}$
constrains $a_i$ to be $0$ if $\Pi_{i+1} = 1$, otherwise it constrains $a_i \in \bit$.
So all of $a_{\barerange{0}{n-1}}$ are at least boolean-constrained.

To prove the rest of the theorem we proceed by induction on decreasing $m$,
i.e.\ taking successively longer prefixes of the \bigEndian binary representations
of $a$ and $c$.

Base case $m = n-1$: since $c_{n-1} = 1$, the constraint system has
just one boolean constraint on $a_{n-1}$, which fulfils the theorem since
$A_{n-1} \leq C_{n-1}$ is always satisfied.

\introlist
Inductive case $m < n-1$:
\begin{itemize}
  \item If $A_{m+1} > C_{m+1}$, then by the inductive hypothesis the constraint system
        must fail, which fulfils the theorem regardless of the value of $a_m$.
  \item If $A_{m+1} \leq C_{m+1}$, then by the inductive hypothesis the constraint system
        restricted to $i \in \range{m+1}{n-1}$ succeeds. We have
        $\Pi_{m+1} =
        \sproduct{i=m+1}{n-1} (c_i = 0 \bor a_i = 1) =
        \sproduct{i=m+1}{n-1} (a_i \geq c_i)$.
        \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$ 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$
                for all $i \in \range{m+1}{n-1}$, so $\Pi_{m+1} = 0$. \\
                This implies that the constraint on $a_m$ is always equivalent to
                a boolean constraint, which fulfils the theorem because $A_m \leq C_m$ must
                be true regardless of the value of $a_m$.
        \end{itemize}
\end{itemize}
\vspace{-2ex}
This covers all cases.
\end{proof}

\vspace{-2ex}
Correctness of the full constraint system follows by taking $m = 0$ in the above theorem.

\vspace{1ex}
The algorithm in \crossref{ccteddecompressvalidate} uses range checks with
$c = \ParamS{r}-1$ to validate \ctEdwardsCompressedEncodings. In that case $n = 255$ and
$k = 132$, so the cost of each such range check is $387$ constraints.

\introsection
\nnote{It is possible to optimize the computation of $\Pi_{\barerange{t}{n-2}}$ further.
Notice that $\Pi_m$ is only used when $m$ is the index of the last bit of a run of $1$ bits
in $c$. So for each such run of $1$ bits $c_{\barerange{m}{m+N-2}}$ of length $N-1$, it is
sufficient to compute an \Nary{} AND of $a_{\barerange{m}{m+N-2}}$ and $\Pi_{m+N-1}$:
$R = \sproduct{i=0}{N-1}{X_i}$. This can be computed in $3$ constraints for any
$N$; boolean-constrain the output $R$, and then add constraints

\newcommand{\NminusSumOfX}{\vphantom{\Big(}\smash{N - \ssum{i=0}{N-1}{X_i}}}

\vspace{0.5ex}
\begin{tabular}{@{\tab}l@{\;\;}l}
  $\constraint{\NminusSumOfX}{\mathsf{inv}}{1-R}$ &to enforce that
    $\ssum{i=0}{N-1}{X_i} \neq N$ when $R = 0$; \\[2ex]
  $\constraint{\NminusSumOfX}{R}{0}$              &to enforce that
    $\ssum{i=0}{N-1}{X_i} = N$ when $R = 1$. \\
\end{tabular}

\vspace{1ex}
where $\mathsf{inv}$ is witnessed as $\smash{\Of{\NminusSumOfX}^{-1}}$ if $R = 0$
or is unconstrained otherwise. (Since $N < \ParamS{r}$, the sums cannot overflow.)

In fact the last constraint is not needed in this context because it is sufficient to
compute an upper bound on each $\Pi_m$ (i.e.\ it does not benefit a malicious prover to
witness $R = 1$ when the result of the AND should be $0$).
So the cost of computing $\Pi$ variables for an arbitrarily long run of $1$ bits can be
reduced to $2$ constraints. For example, for $c = \ParamS{r}-1$ the overall cost would
be reduced to $255 + 68 = 323$ constraints.

These optimizations are not used in \Sapling.}


\introsection
\lsubsubsection{Elliptic curve operations}{cctelliptic}

\lsubsubsubsection{Checking that Affine-ctEdwards coordinates are on the curve}{cctedvalidate}

\vspace{-1ex}
To check that $(u, \varv)$ is a point on the \ctEdwardsCurve, the \Sapling circuit uses
$4$ constraints:

\begin{formulae}
  \item $\constraint{u}{u}{uu}$
  \item $\constraint{\varv}{\varv}{\varvv}$
  \item $\constraint{uu}{\varvv}{uu\varvv}$
  \item $\constraint{\ParamJ{a} \smult uu + \varvv}{1}{1 + \ParamJ{d} \smult uu\varvv}$
\end{formulae}

\vspace{-3ex}
\nnote{The last two constraints can be combined into
$\constraint{\ParamJ{d} \smult uu}{\varvv}{\ParamJ{a} \smult uu + \varvv - 1}$.
The \Sapling circuit does not use this optimization.}


\introsection
\vspace{-2ex}
\lsubsubsubsection{ctEdwards [de]compression and validation}{ccteddecompressvalidate}

\introlist
\vspace{-1ex}
Define $\DecompressValidate \typecolon \CompressedCtEdwardsJubjub \rightarrow \AffineCtEdwardsJubjub$
as follows:

\begin{algorithm}
  \item $\DecompressValidate(\tilde{u}, \varv):$
  \item \tab // Prover supplies the $u$-coordinate.
             \vspace{-0.4ex}
  \item \tab Let $u \typecolon \GF{\ParamS{r}}$.
             \vspace{0.8ex}
  \item \tab // \crossref{cctedvalidate}.
             \vspace{-0.4ex}
  \item \tab Check that $(u, \varv)$ is a point on the \ctEdwardsCurve.
             \vspace{0.8ex}
  \item \tab // \crossref{cctmodpack}.
             \vspace{-0.4ex}
  \item \tab Unpack $u$ to $\ssum{i=0}{254} u_i \mult 2^i$, equating $\tilde{u}$ with $u_0$.
             \vspace{0.8ex}
  \item \tab // \crossref{cctrange}.
             \vspace{-0.4ex}
  \item \tab Check that $\ssum{i=0}{254} u_i \mult 2^i \leq \ParamS{r}-1$.
             \vspace{0.6ex}
  \item \tab Return $(u, \varv)$.
\end{algorithm}

This costs $4$ constraints for the curve equation check, $1$ constraint for the
unpacking, and $387$ constraints for the range check (as computed in \crossref{cctrange})
for a total of $392$ constraints. The cost of the range check includes
boolean-constraining $u_\barerange{0}{254}$.

The same \quadraticConstraintProgram is used for compression and decompression.

\vspace{-1ex}
\nnote{
The point-on-curve check could be omitted if $(u, \varv)$ were already known to be on the curve.
However, the \Sapling circuit never omits it; this provides a consistency check on the elliptic
curve arithmetic.
}


\introlist
\vspace{-1ex}
\lsubsubsubsection{ctEdwards \lrarrow\ Montgomery conversion}{cctconversion}

\vspace{-1.5ex}
Define the notation $\possqrt{\,\paramdot\,}$ as in \crossref{notation}.

Define $\CtEdwardsToMont \typecolon \AffineCtEdwardsJubjub \rightarrow \AffineMontJubjub$
as follows:

\begin{formulae}
  \item \makebox[25em][l]{$\CtEdwardsToMont(u, \varv) = \left(\hfrac{1 + \varv}{1 - \varv},\,
                                                              \scalebox{0.8}{$\possqrt{-40964}$} \mult \hfrac{1 + \varv}{(1 - \varv) \mult u}\right)$}
        $[1 - \varv \neq 0 \tand u \neq 0]$
\end{formulae}

\introlist
\vspace{-0.5ex}
Define $\MontToCtEdwards \typecolon \AffineMontJubjub \rightarrow \AffineCtEdwardsJubjub$
as follows:

\begin{formulae}
  \item \makebox[25em][l]{$\MontToCtEdwards(x, y) = \left(\scalebox{0.8}{$\possqrt{-40964}$} \mult \hfrac{x}{y},\,
                                                          \hfrac{x - 1}{x + 1}\right)$}
        $[x + 1 \neq 0 \tand y \neq 0]$
\end{formulae}

\introlist
Either of these conversions can be implemented by the same \quadraticConstraintProgram:
\begin{formulae}
  \item $\constraint{y}{u}{\possqrt{-40964} \mult x}$
        \vspace{-0.5ex}
  \item $\constraint{x + 1}{\varv}{x - 1}$
\end{formulae}

\vspace{-0.5ex}
The above conversions should only be used if the input is guaranteed to be
a point on the relevant curve. If that is the case, the theorems below
enumerate all exceptional inputs that may violate the side-conditions.

\vspace{-2.5ex}
\introlist
\theoremlabel{thmconversiontomontnoexcept}
\begin{theorem}[Exceptional points (ctEdwards $\rightarrow$ Montgomery)]

Let $(u, \varv)$ be an affine point on a \ctEdwardsCurve $\ctEdwards{a,d}$.
Then the only points with $u = 0$ or $1 - \varv = 0$ are $(0, 1) = \ZeroJ$, and
$(0, -1)$ of order $2$.
\end{theorem}

\begin{proof}
The curve equation is $a \smult u^2 + \varv^2 = 1 + d \smult u^2 \smult \varv^2$
with $a \neq d$ (see \cite[Definition 2.1]{BBJLP2008}). By substituting $u = 0$ we
obtain $\varv = \pm 1$, and by substituting $\varv = 1$ and using $a \neq d$ we obtain $u = 0$.
\end{proof}

\vspace{-3.5ex}
\introlist
\theoremlabel{thmconversiontoedwardsnoexcept}
\begin{theorem}[Exceptional points (Montgomery $\rightarrow$ ctEdwards)]

Let $(x, y)$ be an affine point on a \MontgomeryCurve $\Montgomery{A,B}$ over $\GF{r}$
with parameters $A$ and $B$ such that $A^2 - 4$ is a nonsquare in $\GF{r}$,
that is birationally equivalent to a \ctEdwardsCurve.
Then $x + 1 \neq 0$, and the only point $(x, y)$ with $y = 0$ is
$(0, 0)$ of order 2.
\end{theorem}

\begin{proof}
That the only point with $y = 0$ is $(0, 0)$ is proven by \theoremref{thmmontynotzero}.

If $x + 1 = 0$, then subtituting $x = -1$ into the \MontgomeryCurve equation gives
$B \mult y^2 = x^3 + A \mult x^2 + x = A - 2$.
So in that case $y^2 = (A - 2)/B$. The right-hand-side is equal
to the parameter $d$ of a particular \ctEdwardsCurve birationally
equivalent to the \MontgomeryCurve (see \cite[section 4.3.5]{BL2017}).
For all \ctEdwardsCurves, $d$ is nonsquare, so this equation
has no solutions for $y$, hence $x + 1 \neq 0$.
\end{proof}

\vspace{-0.5ex}
(When the theorem is applied with $\Montgomery{A,B} = \MontCurve$ defined in \crossref{ecbackground},
the \ctEdwardsCurve referred to in the proof is an isomorphic
rescaling of the \jubjubCurve.)


\introsection
\vspace{-1ex}
\lsubsubsubsection{Affine-Montgomery arithmetic}{cctmontarithmetic}

\vspace{-2ex}
The incomplete \affineMontgomery addition formulae given in
\cite[section 4.3.2]{BL2017} are:

\begin{formulae}
  \item $x_3 = \ParamM{B} \smult \lambda^2 - \ParamM{A} - x_1 - x_2$
  \item $y_3 = (x_1 - x_3) \smult \lambda - y_1$
  \item where $\lambda = \begin{cases}
          \hfrac{3 \smult x_1^2 + 2 \smult \ParamM{A} \smult x_1 + 1}{2 \smult \ParamM{B} \smult y_1},
                                        &\caseif x_1 = x_2 \\[1.4ex]
          \hfrac{y_2 - y_1}{x_2 - x_1}, &\caseotherwise.
        \end{cases}$
\end{formulae}

\introlist
The following theorem helps to determine when these incomplete addition formulae
can be safely used:

\newcommand{\halfs}{\frac{s-1}{2}}

\vspace{-2ex}
\theoremlabel{thmdistinctx}
\begin{theorem}[\vphantom{p}Distinct-$x$ theorem]

Let $Q$ be a point of odd-prime order $s$ on a \MontgomeryCurve
$\MontCurve = \Montgomery{\ParamM{A},\ParamM{B}}$ over $\GF{\ParamS{r}}$.
Let $k_\barerange{1}{2}$ be integers in $\bigrangenozero{-\halfs}{\halfs}$.
Let $P_i = \scalarmult{k_i}{Q} = (x_i, y_i)$ for $i \in \range{1}{2}$, with
$k_2 \neq \pm k_1$. Then the non-unified addition constraints
\vspace{-0.5ex}
\begin{formulae}
  \item $\constraint{x_2 - x_1}{\lambda}{y_2 - y_1}$
  \item $\constraint{\ParamM{B} \smult \lambda}{\lambda}{\ParamM{A} + x_1 + x_2 + x_3}$
  \item $\constraint{x_1 - x_3}{\lambda}{y_3 + y_1}$
\end{formulae}
\vspace{-0.5ex}
implement the \affineMontgomery addition $P_1 + P_2 = (x_3, y_3)$ for all such $P_\barerange{1}{2}$.
\end{theorem}

\begin{proof}
The given constraints are equivalent to the Montgomery addition formulae
under the side condition that $x_1 \neq x_2$. (Note that neither $P_i$ can be
the zero point since $k_\barerange{1}{2} \neq 0 \pmod s$.)
Assume for a contradiction that $x_1 = x_2$. For any
$P_1 = \scalarmult{k_1}{Q}$, there can be only one other point $-P_1$ with
the same $x$-coordinate. (This follows from the fact that the curve equation
determines $\pm y$ as a function of $x$.)
But $-P_1 = \scalarmult{-1}{\scalarmult{k_1}{Q}} = \scalarmult{-k_1}{Q}$.
Since $\fun{k \typecolon \bigrange{-\halfs}{\halfs}}{\scalarmult{k}{Q} \typecolon \MontCurve}$
is injective and $k_\barerange{1}{2}$ are in $\bigrange{-\halfs}{\halfs}$,
then $k_2 = \pm k_1$ (contradiction).
\end{proof}

\defining{The conditions of this theorem are called the \distinctXCriterion.}

In particular, if $k_\barerange{1}{2}$ are integers in $\bigrange{1}{\halfs}$
then it is sufficient to require $k_2 \neq k_1$, since that implies
$k_2 \neq \pm k_1$.

\vspace{2ex}
\introlist
\xAffineMontgomery doubling can be implemented as:

\begin{formulae}
  \item $\constraint{x}{x}{xx}$
  \item $\constraint{2 \smult \ParamM{B} \smult y}{\lambda}{3 \smult xx + 2 \smult \ParamM{A} \smult x + 1}$
  \item $\constraint{\ParamM{B} \smult \lambda}{\lambda}{\ParamM{A} + 2 \smult x + x_3}$
  \item $\constraint{x - x_3}{\lambda}{y_3 + y}$
\end{formulae}

This doubling formula is valid when $y \neq 0$, which is the case when $(x, y)$
is not the point $(0, 0)$ (the only point of order $2$), as proven in
\theoremref{thmmontynotzero}.


\introlist
\lsubsubsubsection{Affine-ctEdwards arithmetic}{cctedarithmetic}

Formulae for \affineCtEdwards addition are given in \cite[section 6]{BBJLP2008}.
With a change of variable names to match our convention, the formulae for
$(u_1, \varv_1) + (u_2, \varv_2) = (u_3, \varv_3)$ are:

\begin{formulae}
  \item $u_3     = \cfrac{u_1 \smult \varv_2 + \varv_1 \smult u_2}{1 + \ParamJ{d} \smult u_1 \smult u_2 \smult \varv_1 \smult \varv_2}$
  \item $\varv_3 = \cfrac{\varv_1 \smult \varv_2 - \ParamJ{a} \smult u_1 \smult u_2}{1 - \ParamJ{d} \smult u_1 \smult u_2 \smult \varv_1 \smult \varv_2}$
\end{formulae}

\introlist
We use an optimized implementation found by \nh{Daira-Emma} Hopwood making use of an
observation by Bernstein and Lange in \cite[last paragraph of section 4.5.2]{BL2017}:

\begin{formulae}
  \item $\constraint{u_1 + \varv_1}{\varv_2 - \ParamJ{a} \smult u_2}{T}$
  \item $\constraint{u_1}{\varv_2}{A}$
  \item $\constraint{\varv_1}{u_2}{B}$
  \item $\constraint{\ParamJ{d} \smult A}{B}{C}$
  \item $\constraint{1 + C}{u_3}{A + B}$
  \item $\constraint{1 - C}{\varv_3}{T - A + \ParamJ{a} \smult B}$
\end{formulae}

\introlist
The correctness of this implementation can be seen by expanding $T - A + \ParamJ{a} \smult B$:

\begin{tabular}{@{\hskip 2em}r@{\;}l}
  $T - A + \ParamJ{a} \smult B$
    & $= (u_1 + \varv_1) \mult (\varv_2 - \ParamJ{a} \smult u_2) - u_1 \smult \varv_2 + \ParamJ{a} \smult \varv_1 \smult u_2$ \\
    & $= \varv_1 \smult \varv_2 - \ParamJ{a} \smult u_1 \smult u_2 + u_1 \smult \varv_2 - \ParamJ{a} \smult \varv_1 \smult u_2
                                                                   - u_1 \smult \varv_2 + \ParamJ{a} \smult \varv_1 \smult u_2$ \\
    & $= \varv_1 \smult \varv_2 - \ParamJ{a} \smult u_1 \smult u_2$
\end{tabular}

\vspace{2ex}
\introlist
The above addition formulae are ``unified'', that is, they can also be
used for doubling. \xAffineCtEdwards doubling $\scalarmult{2}{(u, \varv)} = (u_3, \varv_3)$
can also be implemented slightly more efficiently as:

\begin{formulae}
  \item $\constraint{u + \varv}{\varv - \ParamJ{a} \smult u}{T}$
  \item $\constraint{u}{\varv}{A}$
  \item $\constraint{\ParamJ{d} \smult A}{A}{C}$
  \item $\constraint{1 + C}{u_3}{2 \smult A}$
  \item $\constraint{1 - C}{\varv_3}{T + (\ParamJ{a} - 1) \smult A}$
\end{formulae}

This implementation is obtained by specializing the addition formulae to
$(u, \varv) = (u_1, \varv_1) = (u_2, \varv_2)$ and observing that $u \mult \varv = A = B$.


\introsection
\lsubsubsubsection{Affine-ctEdwards nonsmall-order check}{cctednonsmallorder}

In order to avoid small-subgroup attacks, we check that certain points used in the
circuit are not of \smallOrder. In practice the \Sapling circuit uses this
in combination with a check that the coordinates are on the curve (\crossref{cctedvalidate}),
so we combine the two operations.

The \jubjubCurve has a large \primeOrderSubgroup with a cofactor of $8$.
To check for a point $P$ of order $8$ or less, the \Sapling circuit doubles
three times (as in \crossref{cctedarithmetic}) and checks that the resulting
$u$-coordinate is not $0$ (as in \crossref{cctnonzero}).

On a \ctEdwardsCurve, only the zero point $\ZeroJ$, and the unique point
of order $2$ at $(0, -1)$ have zero $u$-coordinate. The point of order $2$ cannot
occur as the result of three doublings. So this $u$-coordinate check rejects
only $\ZeroJ$.

The total cost, including the curve check, is $4 + 3 \mult 5 + 1 = 20$ constraints.

\pnote{This \emph{does not} ensure that the point is in the \primeOrderSubgroup.}

\begin{nnotes}
  \item It would have been sufficient to do two doublings rather than three, because
        the check that the $u$-coordinate is nonzero would reject both $\ZeroJ$
        and the point of order $2$.
  \item It is possible to reduce the cost to $8$ constraints by eliminating the
        redundant constraint in the curve point check (as mentioned in
        \crossref{cctedvalidate}); merging the first doubling with the curve point check;
        and then optimizing the second doubling based on the fact that we only need
        to check whether the resulting $u$-coordinate is zero.
        The \Sapling circuit does not use these optimizations.
\end{nnotes}


\introsection
\lsubsubsubsection{Fixed-base Affine-ctEdwards scalar multiplication}{cctfixedscalarmult}

If the base point $B$ is fixed for a given scalar multiplication $\scalarmult{k}{B}$,
we can fully precompute window tables for each window position.

It is most efficient to use $3$-bit fixed windows. Since the length of
$\ParamJ{r}$ is $252$ bits, we need $84$ windows.

Express $k$ in base $8$, i.e.\ $k = \vsum{i=0}{83} k_i \smult 8^i$.

Then $\scalarmult{k}{B} = \vsum{i=0}{83} w_{(B,\,i,\,k_i)}$, where
$w_{(B,\,i,\,k_i)} = \scalarmult{k_i \smult 8^i}{B}$.

We precompute all of $w_{(B,\,i,\,s)}$ for $i \in \range{0}{83}, s \in \range{0}{7}$.

\introlist
To look up a given window entry $w_{(B,\,i,\,s)} = (u_s, \varv_s)$, where
$s = 4 \smult s_2 + 2 \smult s_1 + s_0$, we use:

\begin{formulae}
  \item $\constraint{s_1}{s_2}{s\suband}$
  \item $\lconstraint{s_0} \big(\!- u_0 \smult s\suband \plus u_0 \smult s_2 \plus u_0 \smult s_1 - u_0 \plus u_2 \smult s\suband
                                  - u_2 \smult s_1 \plus u_4 \smult s\suband - u_4 \smult s_2 - u_6 \smult s\suband \\
         \mhspace{3.52em}     \plus u_1 \smult s\suband - u_1 \smult s_2 - u_1 \smult s_1 \plus u_1 - u_3 \smult s\suband
                              \plus u_3 \smult s_1 - u_5 \smult s\suband \plus u_5 \smult s_2 \plus u_7 \smult s\suband\big) = \\
         \mhspace{1.92em}  \lincomb{u_s - u_0 \smult s\suband \plus u_0 \smult s_2 \plus u_0 \smult s_1 - u_0 \plus u_2 \smult s\suband
                                  - u_2 \smult s_1 \plus u_4 \smult s\suband - u_4 \smult s_2 - u_6 \smult s\suband}$
  \item $\lconstraint{s_0} \big(\!- \spv_0 \smult s\suband \plus \spv_0 \smult s_2 \plus \spv_0 \smult s_1 - \spv_0 \plus \spv_2 \smult s\suband
                                  - \spv_2 \smult s_1 \plus \spv_4 \smult s\suband - \spv_4 \smult s_2 - \spv_6 \smult s\suband \\
         \mhspace{3.51em}     \plus \spv_1 \smult s\suband - \spv_1 \smult s_2 - \spv_1 \smult s_1 \plus \spv_1 - \spv_3 \smult s\suband
                              \plus \spv_3 \smult s_1 - \spv_5 \smult s\suband \plus \spv_5 \smult s_2 \plus \spv_7 \smult s\suband\big) = \\
         \mhspace{1.90em}  \lincomb{\spv_s - \spv_0 \smult s\suband \plus \spv_0 \smult s_2 \plus \spv_0 \smult s_1 - \spv_0 \plus \spv_2 \smult s\suband
                                  - \spv_2 \smult s_1 \plus \spv_4 \smult s\suband - \spv_4 \smult s_2 - \spv_6 \smult s\suband}$
\end{formulae}

For a \nh{full-length ($252$-bit)} scalar this costs $3$ constraints for each of $84$ window lookups,
plus $6$ constraints for each of $83$ \xCtEdwards additions (as in \crossref{cctedarithmetic}), for
a total of $750$ constraints.

Fixed-base scalar multiplication is also used in two places with shorter scalars:
\begin{itemize}
  \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;
        \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}

\vspace{-1ex}
None of these costs include the cost of boolean-constraining the scalar.

\begin{nnotes}
        \vspace{-0.5ex}
  \item It would be more efficient to use arithmetic on the \MontgomeryCurve, as in
        \crossref{cctpedersenhash}. However since there are only three instances of
        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.5ex}
  \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{-2.5ex}


\introsection
\lsubsubsubsection{Variable-base Affine-ctEdwards scalar multiplication}{cctvarscalarmult}

\vspace{-1.5ex}
When the base point $B$ is not fixed, the method in the preceding section
cannot be used. Instead we use a naïve double-and-add method.

\introlist
Given $k = \ssum{i=0}{250} k_i \smult 2^i$, we calculate $R = \scalarmult{k}{B}$ using:

\begin{algorithm}
        \vspace{-0.4ex}
  \item // $\Base_i = \scalarmult{2^i}{B}$
        \vspace{-0.2ex}
  \item let $\Base_0 = B$
        \vspace{-0.2ex}
  \item let $\Acc^u_0 = k_0 \bchoose \Base^u_0 : 0$
        \vspace{-0.2ex}
  \item let $\Acc^{\spv}_0\hairspace = k_0 \bchoose \Base^{\spv}_0 : 1$
        \vspace{0.8ex}
  \item for $i$ from $1$ up to $250$:
             \vspace{-0.4ex}
  \item \tab let $\Base_i = \scalarmult{2}{\Base_{i-1}}$
             \vspace{0.4ex}
  \item \tab // select $\Base_i$ or $\ZeroJ$ depending on the bit $k_i$
             \vspace{-0.2ex}
  \item \tab let $\Addend^u_i = k_i \bchoose \Base^u_i : 0$
             \vspace{-0.2ex}
  \item \tab let $\Addend^{\spv}_i\hairspace = k_i \bchoose \Base^{\spv}_i : 1$
             \vspace{-0.4ex}
  \item \tab let $\Acc_i = \Acc_{i-1} + \Addend_i$
        \vspace{0.8ex}
  \item let $R = \Acc_{250}$.
\end{algorithm}

This costs $5$ constraints for each of $250$ \xCtEdwards doublings, $6$ constraints for each
of $250$ \xCtEdwards additions, and $2$ constraints for each of $251$ point selections,
for a total of $3252$ constraints.

\nnote{
It would be more efficient to use $2$-bit fixed windows, and/or to use arithmetic
on the \MontgomeryCurve in a similar way to \crossref{cctpedersenhash}. However
since there are only two instances of variable-base scalar multiplication in the
\spendCircuit and one in the \outputCircuit, the additional complexity was not
considered justified for \Sapling.
} %nnote


\introsection
\lsubsubsubsection{Pedersen hash}{cctpedersenhash}

The specification of the \xPedersenHashes used in \Sapling is given in
\crossref{concretepedersenhash}. It is based on the scheme from
\cite[section 5.2]{CvHP1991} --for which a tighter security reduction to
the \xDiscreteLogarithmProblem was given in \cite{BGG1995}-- but tailored
to allow several optimizations in the circuit implementation.

\xPedersenHashes are the single most commonly used primitive in the
\Sapling circuits. $\MerkleDepth{Sapling}$ \xPedersenHash instances are used
in the \spendCircuit to check a \merklePath to the \noteCommitment of the
\note being spent. We also reuse the \xPedersenHash implementation to
construct the \noteCommitmentScheme $\NoteCommitAlg{Sapling}$.

This motivates considerable attention to optimizing this circuit
implementation of this primitive, even at the cost of complexity.

First, we use a windowed scalar multiplication algorithm with signed digits.
Each $3$-bit message chunk corresponds to a window; the chunk is encoded
as an integer from the set $\Digits = \rangenozero{-4}{4}$.
This allows a more efficient lookup of the window entry for each chunk than
if the set $\range{1}{8}$ had been used, because a point can be conditionally
negated using only a single constraint.

Next, we optimize the cost of point addition by allowing as many additions
as possible to be performed on the \MontgomeryCurve. An incomplete
Montgomery addition costs $3$ constraints, in comparison with a
ctEdwards addition which costs $6$ constraints.

However, we cannot do all additions on the \MontgomeryCurve because the
Montgomery addition is incomplete. In order to be able to prove that
exceptional cases do not occur, we need to ensure that the \distinctXCriterion
from \crossref{cctmontarithmetic} is met. This requires splitting the
input into segments (each using an independent generator), calculating
an intermediate result for each segment, and then converting to the
\ctEdwardsCurve and summing the intermediate results using
ctEdwards addition.

\introlist
Abstracting away the changes of curve, this calculation can be written as:

\begin{formulae}
  \item $\PedersenHashToPoint(D, M) = \vsum{j=1}{N} \scalarmult{\PedersenEncode{M_j}}{\PedersenGen(D, j)}$
\end{formulae}
\vspace{-2ex}
where $\PedersenEncode{\paramdot}$ and $\PedersenGen(D, j)$
are defined as in \crossref{concretepedersenhash}.

\introlist
\vspace{1ex}
We have to prove that:
\begin{itemize}
  \item the Montgomery-to-\xCtEdwards conversions can be implemented without
        exceptional cases;
  \item the \distinctXCriterion is met for all Montgomery additions within
        a segment.
\end{itemize}

The proof of \theoremref{thmpedersenencodeinjective} showed that
all indices of addition inputs are in the range
$\bigrangenozero{-\frac{\ParamJ{r}-1}{2}}{\frac{\ParamJ{r}-1}{2}}$.

Because the $\PedersenGen(D, j)$ (which are outputs of $\GroupJHash{}$)
are all of \primeOrder, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$,
it is guaranteed that all of the terms
$\scalarmult{\PedersenEncode{M_j}}{\PedersenGen(D, j)}$
to be converted to \xCtEdwards form are of \primeOrder.
From \theoremref{thmconversiontoedwardsnoexcept}, we can infer that
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]

For all disjoint nonempty subsets $S$ and $S'$ of $\range{1}{c}$, all
$m \in \typeexp{\bitseq{3}}{c}$, and all $\Sign \in \setof{-1, 1}$:

\begin{formulae}
  \item $\vsum{j \in S\vphantom{S'}}{} \enc(m_j) \mult 2^{4 \mult (j-1)} \neq
         \Sign \mult\!\!\vsum{j' \in S'}{} \enc(m_{\kern -0.1em j'}) \mult 2^{4 \mult (j'-1)}$.
\end{formulae}
\end{theorem}

\begin{proof}
Suppose for a contradiction that $S$, $S'$, $m$, $\Sign$ is a counterexample. Taking the multiplication
by $\Sign$ on the right hand side inside the summation, we have:
\begin{formulae}
  \item $\vsum{j \in S\vphantom{S'}}{} \enc(m_j) \mult 2^{4 \mult (j-1)} =
         \!\!\vsum{j' \in S'}{} \Sign \mult \enc(m_{\kern -0.1em j'}) \mult 2^{4 \mult (j'-1)}$.
\end{formulae}

Define $\enc' \typecolon \setof{-1, 1} \times \bitseq{3} \rightarrow \range{0}{8} \setminus \setof{4}$ as
$\enc'_\theta(m_i) := 4 + \theta \mult \enc(m_i)$.

Let $\PedersenRangeOffset = 4 \mult \ssum{i=1}{c} 2^{4 \mult (i-1)}$
as in the proof of \theoremref{thmpedersenencodeinjective}.
By adding $\PedersenRangeOffset$ to both sides, we get
\begin{formulae}
  \item $\vsum{j \in S\vphantom{S'}}{} \enc'_1(m_j) \mult 2^{4 \mult (j-1)} + \vsum{j \in \range{1}{c} \setminus S\vphantom{S'}}{} 4 \mult 2^{4 \mult (j-1)} =
         \vsum{j' \in S'}{} \enc'_{\Sign}(m_{\kern -0.1em j'}) \mult 2^{4 \mult (j'-1)} + \vsum{j' \in \range{1}{c} \setminus S'}{} 4 \mult 2^{4 \mult (j'-1)}$
\end{formulae}
\vspace{-1ex}
where all of the $\enc'_1(m_j)$ and $\enc'_{\Sign}(m_{\kern -0.1em j'})$ are in $\range{0}{8} \setminus \setof{4}$.

Each term on the left and on the right affects the single hex digit indexed by
$j$ and $j'$ respectively. Since $S$ and $S'$ are disjoint subsets of $\range{1}{c}$
and $S$ is nonempty, $S \intersection (\range{1}{c} \setminus S')$ is nonempty.
Therefore the left hand side has at least one hex digit not equal to $4$ such that
the corresponding right hand side digit is $4$; contradiction.
\end{proof}

This implies that the terms in the Montgomery addition --as well as any intermediate
results formed from adding a distinct subset of terms-- have distinct indices
disregarding sign, hence distinct $x$-coordinates by \theoremref{thmdistinctx}.
(We make no assumption about the order of additions.)

We now describe the subcircuit used to process each chunk, which contributes most of
the constraint cost of the hash. This subcircuit is used to perform a lookup of a
Montgomery point in a $2$-bit window table, conditionally negate the result, and add
it to an accumulator holding another Montgomery point.

Suppose that the bits of the chunk, $[s_0, s_1, s_2]$, are already boolean-constrained.

We aim to compute $C = A + \scalarmult{(1 - 2 \mult s_2) \mult (1 + s_0 + 2 \mult s_1)}{P}$
for some fixed base point $P$ and accumulated sum $A$.

\introlist
We first compute $s\suband = s_0 \band s_1$:

\begin{formulae}
  \item $\constraint{s_0}{s_1}{s\suband}$
\end{formulae}

\introlist
Let $(x_k, y_k) = \scalarmult{k}{P}$ for $k \in \range{1}{4}$. Define each coordinate of
$(x_S, y_R) = \scalarmult{1 + s_0 + 2 \mult s_1}{P}$ as a linear combination of $s_0$, $s_1$, and $s\suband$:

\begin{formulae}
  \item let $x_S = x_1 + (x_2-x_1) \mult s_0 + (x_3-x_1) \mult s_1 + (x_4+x_1-x_2-x_3) \mult s\suband$
  \item let $y_R\hspace{0.01em} = \yy_1 + (\yy_2-\yy_1) \mult s_0 + (\yy_3-\yy_1) \mult s_1 + (\yy_4+\yy_1-\yy_2-\yy_3) \mult s\suband$
\end{formulae}

\introlist
We implement the conditional negation as $\constraint{2 \mult y_R}{s_2}{y_R - y_S}$.
After substitution of $y_R$ this becomes:

\begin{formulae}
  \item $\lconstraint{2 \mult (y_1 + (y_2-y_1) \mult s_0 + (y_3-y_1) \mult s_1 + (y_4+y_1-y_2-y_3) \mult s\suband)}\!\lincomb{s_2} = \\
         \mhspace{1.45em}\lincomb{y_1 + (y_2-y_1) \mult s_0 + (y_3-y_1) \mult s_1 + (y_4+y_1-y_2-y_3) \mult s\suband - y_S}$
\end{formulae}

\introlist
Then we substitute $x_S$ into the Montgomery addition constraints from \crossref{cctmontarithmetic}, as follows:

\begin{formulae}
  \item $\constraint{x_1 + (x_2-x_1) \mult s_0 + (x_3-x_1) \mult s_1 + (x_4+x_1-x_2-x_3) \mult s\suband - x_A}{\lambda}{y_S - y_A}$
  \item $\constraint{\ParamM{B} \smult \lambda}{\lambda}{\ParamM{A} + x_A + x_1 + (x_2-x_1) \mult s_0 + (x_3-x_1) \mult s_1 + (x_4+x_1-x_2-x_3) \mult s\suband + x_C}$
  \item $\constraint{x_A - x_C}{\lambda}{y_C + y_A}$
\end{formulae}

(In the sapling-crypto implementation, linear combinations are first-class values, so these substitutions
do not need to be done ``by hand''.)

For the first addition in each segment, both sides are looked up and substituted into the Montgomery
addition, so the first lookup takes only $2$ constraints.

When these hashes are used in the circuit, the first 6 bits of the input
are fixed. For example, in the Merkle tree hashes they represent the layer number.
This would allow a precomputation for the first two windows, but that
optimization is not done in \Sapling.

The cost of a Pedersen hash over $\ell$ bits (where $\ell$ includes the fixed
bits) is as follows. The number of chunks is $c = \ceiling{\hfrac{\ell}{3}}$ and
the number of segments is $n = \ceiling{\hfrac{\ell}{3 \mult 63}}$.

\introlist
The cost is then:

\begin{itemize}
  \item $2 \smult c$ constraints for the lookups;
  \item $3 \smult (c-n)$ constraints for incomplete additions on the \MontgomeryCurve;
  \item $2 \smult n$ constraints for Montgomery-to-\xCtEdwards conversions;
  \item $6 \smult (n-1)$ constraints for \xCtEdwards additions;
\end{itemize}

\vspace{-1ex}
for a total of $5 \smult c + 5 \smult n - 6$ constraints. This does not include
the cost of boolean-constraining inputs.

\introlist
In particular,
\begin{itemize}
  \item for the Merkle tree hashes $\ell = 516$, so $c = 172$, $n = 3$,
        and the cost is $869$ constraints;
  \item when a Pedersen hash is used to implement part of a Pedersen commitment
        for $\NoteCommitAlg{Sapling}$ (\crossref{concretesaplingnotecommit}),
        $\ell = 6 + \ValueLength + 2 \smult \ellJ = 582$, $c = 194$, and $n = 4$,
        so the cost of the hash alone is $984$ constraints.
\end{itemize}


\introlist
\lsubsubsubsection{Mixing Pedersen hash}{cctmixinghash}

A mixing \xPedersenHash is used to compute $\NoteUniqueRand$ from
$\cm$ and $\NotePosition$ in \crossref{rhoandnullifiers}. It takes as
input a \xPedersenCommitment $P$, and hashes it with another input $x$.

Let $\NotePositionBaseSapling$ be as defined in \crossref{concretemixinghash}.

\introlist
We define $\MixingPedersenHash \typecolon \range{0}{\ParamJ{r}-1}
\times \GroupJ \rightarrow \GroupJ$ by:

\begin{formulae}
  \item $\MixingPedersenHash(P, x) := P + \scalarmult{x}{\NotePositionBaseSapling}$.
\end{formulae}

This costs $92$ constraints for a scalar multiplication
(\crossref{cctfixedscalarmult}), and $6$ constraints for a \xCtEdwards addition
(\crossref{cctedarithmetic}), for a total of $98$ constraints.


\introsection
\lsubsubsection{Merkle path check}{cctmerklepath}

Checking each layer of a Merkle authentication path, as described in \crossref{merklepath},
requires to:

\begin{itemize}
  \item boolean-constrain the path bit specifying whether the previous node
        is a left or right child;
  \item conditionally swap the previous-layer and sibling hashes
        (as $\GF{r}$ elements) depending on the path bit;
  \item unpack the left and right hash inputs to two sequences of $255$ bits;
  \item compute the Merkle hash for this node.
\end{itemize}

The unpacking need not be canonical in the sense discussed in \crossref{cctmodpack};
that is, it is \emph{not} necessary to ensure that the left or right inputs to the
hash represent integers in the range $\range{0}{\ParamS{r}-1}$.
Since the root of the Merkle tree is calculated outside the circuit using the
canonical representations, and since the \xPedersenHashes are \collisionResistant
on arbitrary \bitSequenceAdjective inputs, an attempt by an adversarial prover to use a
\nonCanonicalFieldElement input would result in the wrong root being calculated, and the
overall path check would fail.

For each layer, the cost is $1 + 2 \smult 255$ boolean constraints,
$2$ constraints for the conditional swap (implemented as two selection
constraints), and $869$ constraints for the Merkle hash (\crossref{cctpedersenhash}),
for a total of $1380$ constraints.

\nnote{The conditional swap $(a_0, a_1) \mapsto (c_0, c_1)$ could be implemented
in only one constraint by substituting $c_1 = a_0 + a_1 - c_0$ into the
uses of $c_1$. The \Sapling circuit does not use this optimization.}


\introsection
\lsubsubsection{Windowed Pedersen Commitment}{cctwindowedcommit}

We construct \defining{\windowedPedersenCommitments} by reusing the Pedersen hash
implementation described in \crossref{cctpedersenhash}, and adding a
randomized point:

\begin{formulae}
  \item $\WindowedPedersenCommit{r}(s) =
           \PedersenHashToPoint\Of{\ascii{Zcash\_PH}, s}\, + \scalarmult{r}{\FindGroupJHash\Of{\ascii{Zcash\_PH}, \ascii{r}}}$
\end{formulae}

\introlist
This can be implemented in:
\begin{itemize}
  \item $5 \smult c + 5 \smult n - 6$ constraints for the Pedersen hash applied to
        $\ell = 6 + \length(s)$ bits, where $c = \ceiling{\hfrac{\ell}{3}}$ and
        $n = \ceiling{\hfrac{\ell}{3 \mult 63}}$;
  \item $750$ constraints for the fixed-base scalar multiplication;
  \item $6$ constraints for the final \xCtEdwards addition.
\end{itemize}

When $\WindowedPedersenCommit{}$ is used to instantiate $\NoteCommitAlg{Sapling}$,
the cost of the Pedersen hash is $984$ constraints as calculated in
\crossref{cctpedersenhash}, and so the total cost in that case is $1740$ constraints.
This does not include the cost of boolean-constraining the input $s$ or the
randomness $r$.


\lsubsubsection{Homomorphic Pedersen Commitment}{ccthomomorphiccommit}

The \windowedPedersenCommitments defined in the preceding section are
highly efficient, but they do not support the homomorphic property we
need when instantiating $\ValueCommitAlg{}$.

In order to support this property, we also define \homomorphicPedersenCommitments
as follows:

\begin{formulae}
  \item $\HomomorphicPedersenCommit{Sapling}{\ValueCommitRand}(D, \Value) =
           \scalarmult{\Value}{\FindGroupJHash\Of{D, \ascii{v}}}\, + \scalarmult{\ValueCommitRand}{\FindGroupJHash\Of{D, \ascii{r}}}$
\end{formulae}

In the case that we need for $\ValueCommitAlg{}$, $\Value$ has $64$
bits\footnote{It would be sufficient to use $51$ bits, which accomodates the range
$\range{0}{\MAXMONEY}$, but the \Sapling circuit uses $64$.}.
This value is given as a bit representation, which does not need to be constrained
equal to an integer.

\introlist
$\ValueCommitAlg{}$ can be implemented in:
\vspace{1ex}
\begin{itemize}
  \item $750$ constraints for the $252$-bit fixed-base multiplication by $\ValueCommitRand$;
  \item $191$ constraints for the $64$-bit fixed-base multiplication by $\Value$;
  \item $6$ constraints for the \xCtEdwards addition
\end{itemize}
\vspace{-1.5ex}
for a total cost of $947$ constraints. This does not include the cost to boolean-constrain
the input $\Value$ or randomness $\ValueCommitRand$.


\intropart
\lsubsubsection{BLAKE2s hashes}{cctblake2s}

\introlist
$\BlakeTwosGeneric$ is defined in \cite{ANWW2013}. Its main subcomponent is a
``$G$ function'', defined as follows:

\begin{formulae}
  \item $G \typecolon \range{0}{9} \times \typeexp{\binaryrange{32}}{4} \rightarrow \typeexp{\binaryrange{32}}{4}$
  \item $G(a, b, c, d, x, y) = (a'', b'', c'', d'')$ where
  \item \begin{tabular}{@{\tab}l@{\;}l}
          $a' $ &$= (a + b + x) \bmod 2^{32}$ \\
          $d' $ &$= (d \xor a') \rotr 16$ \\
          $c' $ &$= (c + d') \bmod 2^{32}$ \\
          $b' $ &$= (b \xor c') \rotr 12$ \\
          $a''$ &$= (a' + b' + y) \bmod 2^{32}$ \\
          $d''$ &$= (d' \xor a'') \rotr 8$ \\
          $c''$ &$= (c' + d'') \bmod 2^{32}$ \\
          $b''$ &$= (b' \xor c'') \rotr 7$ \\
        \end{tabular}
\end{formulae}

\introlist
The following table is used to determine which message words the $x$ and $y$ arguments
to $G$ are selected from:

\begin{tabular}{@{\tab}S@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}R@{}S@{}S}
  \sigma_0 = [& 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 &10 &11 &12 &13 &14 &15 &] \\
  \sigma_1 = [&14 &10 & 4 & 8 & 9 &15 &13 & 6 & 1 &12 & 0 & 2 &11 & 7 & 5 & 3 &] \\
  \sigma_2 = [&11 & 8 &12 & 0 & 5 & 2 &15 &13 &10 &14 & 3 & 6 & 7 & 1 & 9 & 4 &] \\
  \sigma_3 = [& 7 & 9 & 3 & 1 &13 &12 &11 &14 & 2 & 6 & 5 &10 & 4 & 0 &15 & 8 &] \\
  \sigma_4 = [& 9 & 0 & 5 & 7 & 2 & 4 &10 &15 &14 & 1 &11 &12  &6 & 8 & 3 &13 &] \\
  \sigma_5 = [& 2 &12 & 6 &10 & 0 &11  &8 & 3 & 4 &13 & 7 & 5 &15 &14 & 1 & 9 &] \\
  \sigma_6 = [&12 & 5 & 1 &15 &14 &13 & 4 &10 & 0 & 7 & 6 & 3 & 9 & 2 & 8 &11 &] \\
  \sigma_7 = [&13 &11 & 7 &14 &12 & 1 & 3 & 9 & 5 & 0 &15 & 4 & 8 & 6 & 2 &10 &] \\
  \sigma_8 = [& 6 &15 &14 & 9 &11 & 3 & 0 & 8 &12 & 2 &13 & 7 & 1 & 4 &10 & 5 &] \\
  \sigma_9 = [&10 & 2 & 8 & 4 & 7 & 6 & 1 & 5 &15 &11 & 9 &14 & 3 &12 &13 & 0 &] \\
\end{tabular}

\introlist
\vspace{2ex}
The Initialization Vector is defined as:

\begin{tabular}{@{\tab}S@{}R@{}R@{}R@{}U}
  \BlakeIV \typecolon \typeexp{\binaryrange{32}}{8} := [\,
      &\hexint{6A09E667} &\hexint{BB67AE85} &\hexint{3C6EF372} &\hexint{A54FF53A}    \\
      &\hexint{510E527F} &\hexint{9B05688C} &\hexint{1F83D9AB} &\hexint{5BE0CD19}\,] \\
\end{tabular}

\vspace{2ex}
\intropart
The full hash function applied to an $8$-byte personalization string and a single
$64$-byte block, in sequential mode with $32$-byte output, can be expressed as follows.

Define $\BlakeTwos{256} \typecolon (p \typecolon \byteseq{8}) \times (x \typecolon \byteseq{64}) \rightarrow \byteseq{32}$ as:

\begin{formulae}
  \item let $\BlakeParamBlock \typecolon \byteseq{32} = [32, 0, 1, 1] \bconcat\, \zerobytes{20} \bconcat p$
  \item let $[\,t_0, t_1, f_0, f_1\,] \typecolon \typeexp{\binaryrange{32}}{4} = [\,0, 0, 0, \hexint{FFFFFFFF}, 0\,]$
  \item \blank
  \item let $h \typecolon \typeexp{\binaryrange{32}}{8} =
             \listcomp{\LEOStoIPOf{32}{\BlakeParamBlock_{\barerange{4 \mult i}{4 \mult i\,+\,3}}} \xor \BlakeIV_i \for i \from 0 \upto 7}$
  \item let $m \typecolon \typeexp{\binaryrange{32}}{16} =
             \listcomp{\LEOStoIPOf{32}{x_{\barerange{4 \mult i}{4 \mult i\,+\,3}}} \for i \from 0 \upto 15}$
  \item let mutable $v \typecolon \typeexp{\binaryrange{32}}{16} \leftarrow
             h \bconcat\,[\,\BlakeIV_0, \BlakeIV_1, \BlakeIV_2, \BlakeIV_3,
                            t_0 \xor \BlakeIV_4, t_1 \xor \BlakeIV_5, f_0 \xor \BlakeIV_6, f_1 \xor \BlakeIV_7\,]$
        \vspace{1ex}
  \item for $r$ from $0$ up to $9$:
        \vspace{-2ex}
  \item \begin{tabular}{@{\tab set\;}T@{}T@{}T@{}U@{}T@{}T@{}T@{}T@{}T@{}U@{}U}
          (v_{ 0}, &v_{ 4}, &v_{ 8}, &v_{12}&) \leftarrow G(v_{ 0}, &v_{ 4}, &v_{ 8}, &v_{12}, &m_{\sigma_{r, 0}}, &m_{\sigma_{r, 1}}&) \\
          (v_{ 1}, &v_{ 5}, &v_{ 9}, &v_{13}&) \leftarrow G(v_{ 1}, &v_{ 5}, &v_{ 9}, &v_{13}, &m_{\sigma_{r, 2}}, &m_{\sigma_{r, 3}}&) \\
          (v_{ 2}, &v_{ 6}, &v_{10}, &v_{14}&) \leftarrow G(v_{ 2}, &v_{ 6}, &v_{10}, &v_{14}, &m_{\sigma_{r, 4}}, &m_{\sigma_{r, 5}}&) \\
          (v_{ 3}, &v_{ 7}, &v_{11}, &v_{15}&) \leftarrow G(v_{ 3}, &v_{ 7}, &v_{11}, &v_{15}, &m_{\sigma_{r, 6}}, &m_{\sigma_{r, 7}}&) \\[1ex]
          (v_{ 0}, &v_{ 5}, &v_{10}, &v_{15}&) \leftarrow G(v_{ 0}, &v_{ 5}, &v_{10}, &v_{15}, &m_{\sigma_{r, 8}}, &m_{\sigma_{r, 9}}&) \\
          (v_{ 1}, &v_{ 6}, &v_{11}, &v_{12}&) \leftarrow G(v_{ 1}, &v_{ 6}, &v_{11}, &v_{12}, &m_{\sigma_{r,10}}, &m_{\sigma_{r,11}}&) \\
          (v_{ 2}, &v_{ 7}, &v_{ 8}, &v_{13}&) \leftarrow G(v_{ 2}, &v_{ 7}, &v_{ 8}, &v_{13}, &m_{\sigma_{r,12}}, &m_{\sigma_{r,13}}&) \\
          (v_{ 3}, &v_{ 4}, &v_{ 9}, &v_{14}&) \leftarrow G(v_{ 3}, &v_{ 4}, &v_{ 9}, &v_{14}, &m_{\sigma_{r,14}}, &m_{\sigma_{r,15}}&) \\
        \end{tabular}
  \item \vspace{-1ex}
  \item return $\LEBStoOSPOf{256}{\concatbits\Of{\listcomp{\ItoLEBSPOf{32}{h_i \xor v_i \xor v_{i+8}} \for i \from 0 \upto 7}}}$
\end{formulae}

In practice the message and output will be expressed as \bitSequences. In the \Sapling
circuit, the personalization string will be constant for each use.

Each 32-bit exclusive-or is implemented in $32$ constraints, one for each bit position
$a \xor b = c$ as in \crossref{cctxor}.

Additions not involving a message word, i.e.\ $(a + b) \bmod 2^{32} = c$, are implemented
using $33$ constraints and a $33$-bit equality check: constrain $33$ boolean variables
$c_{\barerange{0}{32}}$, and then check
$\ssum{i=0}{i=31}{(a_i + b_i) \mult 2^i} = \ssum{i=0}{i=32}{c_i \mult 2^i}$.

Additions involving a message word, i.e.\ $(a + b + m) \bmod 2^{32} = c$, are implemented
using $34$ constraints and a 34-bit equality check: constrain $34$ boolean variables
$c_{\barerange{0}{33}}$, and then check
$\ssum{i=0}{i=31}{(a_i + b_i + m_i) \mult 2^i} = \ssum{i=0}{i=33}{c_i \mult 2^i}$.

For each addition, only $c_{\barerange{0}{31}}$ are used subsequently.

The equality checks are batched; as many sets of $33$ or $34$ boolean variables as
will fit in a $\GF{\ParamS{r}}$ field element are equated together using one constraint.
This allows $7$ such checks per constraint.

\vspace{1ex}
\introlist
Each $G$ evaluation requires $262$ constraints:
\begin{itemize}
  \item $4 \mult 32 = 128$ constraints for $\xor$ operations;
  \item $2 \mult 33 = 66$ constraints for $32$-bit additions not involving message words
        (excluding equality checks);
  \item $2 \mult 34 = 68$ constraints for $32$-bit additions involving message words
        (excluding equality checks).
\end{itemize}

\introlist
The overall cost is $21006$ constraints:
\begin{itemize}
  \item $10 \mult 8 \mult 262 - 4 \mult 2 \mult 32 = 20704$ constraints for
        $80$ $G$ evaluations, excluding equality checks (the deduction of
        $4 \mult 2 \mult 32$ is because $v$ is constant at the start of the
        first round, so in the first four calls to $G$, the parameters $b$ and
        $d$ are constant, eliminating the constraints for the first two XORs
        in those four calls to $G$);
  \item $\ceiling{\hfrac{10 \mult 8 \mult 4}{7}} = 46$ constraints for equality checks;
  \item $8 \mult 32 = 256$ constraints for final $v_i \xor v_{i+8}$ operations
        (the $h_i$ words are constants so no additional constraints
        are required to exclusive-or with them).
\end{itemize}

This cost includes boolean-constraining the hash output bits (done implicitly by the
final $\xor$ operations), but not the message bits.

\begin{nnotes}
  \item The equality checks could be eliminated entirely by substituting each check
        into a boolean constraint for $c_0$, for instance, but this optimization
        is not done in \Sapling.
  \item It should be clear that $\BlakeTwosGeneric$ is very expensive in the circuit
        compared to elliptic curve operations. This is primarily because it is
        inefficient to use $\GF{\ParamS{r}}$ elements to represent single bits.
        However Pedersen hashes do not have the necessary cryptographic properties
        for the two cases where the \spendCircuit uses $\BlakeTwosGeneric$.
        While it might be possible to use variants of functions with low circuit cost
        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}


\pagebreak
\lsubsection{The \SaplingText{} Spend circuit}{cctsaplingspend}

The \Sapling Spend \statement is defined in \crossref{spendstatement}.

The primary input is
\vspace{1ex}
\begin{formulae}
  \item $\oparen\rt{Sapling} \typecolon \MerkleHash{Sapling},\\
         \hparen\cvOld{} \typecolon \ValueCommitOutput{Sapling},\\
         \hparen\nfOld{} \typecolon \PRFOutputNfSapling,\\
         \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 $\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}\big(\nfOld{}\big)$.

\introlist
\vspace{1ex}
The auxiliary input is
\vspace{1ex}
\begin{formulae}
  \item $\oparen\TreePath{} \typecolon \typeexp{\MerkleHash{Sapling}}{\MerkleDepth{Sapling}},\\
         \hparen\NotePosition \typecolon \NotePositionType{Sapling},\vspace{0.4ex}\\
         \hparen\DiversifiedTransmitBase \typecolon \GroupJ,\\
         \hparen\DiversifiedTransmitPublic \typecolon \GroupJ,\vspace{0.6ex}\\
         \hparen\vOld{} \typecolon \ValueType,\\
         \hparen\ValueCommitRandOld{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
         \hparen\cmOld{} \typecolon \GroupJ,\\
         \hparen\NoteCommitRandOld{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
         \hparen\AuthSignRandomizer \typecolon \binaryrange{\ScalarLength{Sapling}},\\
         \hparen\AuthSignPublic \typecolon \SpendAuthSigPublic{Sapling},\\
         \hparen\AuthProvePrivate \typecolon \binaryrange{\ScalarLength{Sapling}}\cparen$.
\end{formulae}

\introlist
$\ValueCommitOutput{Sapling}$ and $\SpendAuthSigPublic{Sapling}$ are of type $\GroupJ$,
so we have $\cvOld{}$, $\cmOld{}$, $\AuthSignRandomizedPublic$, $\DiversifiedTransmitBase$,
$\DiversifiedTransmitPublic$, and $\AuthSignPublic$ that represent \jubjubCurve points.
However,
\vspace{1ex}
\begin{itemize}
  \item $\cvOld{}$ will be constrained to an output of $\ValueCommitAlg{Sapling}$;
  \item $\cmOld{}$ will be constrained to an output of $\NoteCommitAlg{Sapling}$;
  \item $\AuthSignRandomizedPublic$ will be constrained to
        $\scalarmult{\AuthSignRandomizer}{\AuthSignBase{Sapling}} + \AuthSignPublic$;
  \item $\DiversifiedTransmitPublic$ will be constrained to
        $\scalarmult{\InViewingKey}{\DiversifiedTransmitBase}$
\end{itemize}
\vspace{-1ex}
so $\cvOld{}$, $\cmOld{}$, $\AuthSignRandomizedPublic$, and $\DiversifiedTransmitPublic$
do not need to be explicitly checked to be on the curve.

In addition, $\NullifierKeyRepr$ and $\NoteUniqueRandRepr$ used in
\textbf{Nullifier integrity} are compressed representations of
\jubjubCurve points.
\todo{explain why these are implemented as \crossref{ccteddecompressvalidate} even
though the statement spec doesn't explicitly say to do validation.}

Therefore we have $\DiversifiedTransmitBase$, $\AuthSignPublic$, $\NullifierKey$,
and $\NoteUniqueRand$ that need to be constrained to valid \jubjubCurve points as
described in \crossref{ccteddecompressvalidate}.

\introsection
In order to aid in comparing the implementation with the specification,
we present the checks needed in the order in which they are implemented
in the sapling-crypto code:

\begin{center}
\begin{tabular}{|p{16em}|l|C|l|}
\hline
Check & Implements & \heading{Cost} & Reference \\
\hhline{|=|=|=|=|}

  $\AuthSignPublic$ is on the curve \small\todo{FIXME also decompressed below}
      & $\AuthSignPublic \typecolon \SpendAuthSigPublic{Sapling}$
      & 4     & \shortcrossref{cctedvalidate} \\ \hline
  $\AuthSignPublic$ is not \smallOrderAdjective
      & \snarkref{Small order checks}{spendnonsmall}
      & 16    & \shortcrossref{cctednonsmallorder} \\ \hline
  $\AuthSignRandomizerRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\AuthSignRandomizer \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\AuthSignRandomizer' = \scalarmult{\AuthSignRandomizerRepr}{\AuthSignBase{Sapling}}$
      & \snarkref{Spend authority}{spendauthority}
      & 750   & \shortcrossref{cctfixedscalarmult} \\ \cline{1-1}\cline{3-4}
  $\AuthSignRandomizedPublic = \AuthSignRandomizer' + \AuthSignPublic$
      &
      & 6     & \shortcrossref{cctedarithmetic} \\ \hline
  inputize $\AuthSignRandomizedPublic$ \small\todo{not ccteddecompressvalidate => wrong count}
      & $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic{Sapling}$
      & 392?  & \shortcrossref{ccteddecompressvalidate} \\ \hline
  $\AuthProvePrivateRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\AuthProvePrivate \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\NullifierKey = \scalarmult{\AuthProvePrivateRepr}{\AuthProveBaseSapling}$
      & \snarkref{Nullifier integrity}{spendnullifierintegrity}
      & 750   & \shortcrossref{cctfixedscalarmult} \\ \hline
  $\AuthSignPublicRepr = \reprJ\Of{\AuthSignPublic \typecolon \GroupJ}$
      & \snarkref{Diversified address integrity}{spendaddressintegrity}
      & 392   & \shortcrossref{ccteddecompressvalidate} \\ \hline
  $\NullifierKeyRepr = \reprJ\Of{\NullifierKey}$
  \small\todo{spec doesn't say to validate $\NullifierKey$ since it's calculated}
      & \snarkref{Nullifier integrity}{spendnullifierintegrity}
      & 392   & \shortcrossref{ccteddecompressvalidate} \\ \hline
  $\InViewingKeyRepr = \ItoLEBSP{251}\big(\CRHivk(\AuthSignPublic, \NullifierKey)\kern-0.08em\big)\;\dagger$
      & \snarkref{Diversified address integrity}{spendaddressintegrity}
      & 21006 & \shortcrossref{cctblake2s} \\ \hline
  $\DiversifiedTransmitBase$ is on the curve
      & $\DiversifiedTransmitBase \typecolon \GroupJ$
      & 4     & \shortcrossref{cctedvalidate} \\ \hline
  $\DiversifiedTransmitBase$ is not \smallOrderAdjective
      & \snarkref{Small order checks}{spendnonsmall}
      & 16    & \shortcrossref{cctednonsmallorder} \\ \hline
  $\DiversifiedTransmitPublic = \scalarmult{\InViewingKeyRepr}{\DiversifiedTransmitBase}$
      & \snarkref{Diversified address integrity}{spendaddressintegrity}
      & 3252  & \shortcrossref{cctvarscalarmult} \\ \hline
  $\vOldRepr \typecolon \bitseq{64}$
      & $\vOld{} \typecolon \binaryrange{64}$
      & 64    & \shortcrossref{cctboolean} \\ \hline
  $\ValueCommitRandRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\ValueCommitRand \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\cv = \ValueCommit{\ValueCommitRand}(\vOld{})$
      & \snarkref{Value commitment integrity}{spendvaluecommitmentintegrity}
      & 947   & \shortcrossref{ccthomomorphiccommit} \\ \cline{1-1}\cline{3-4}
  inputize $\cv$
      &
      & ?     & \\ \hline
  $\NoteCommitRandRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\NoteCommitRand \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\cm = \NoteCommit{Sapling}{\NoteCommitRand}(\DiversifiedTransmitBase, \DiversifiedTransmitPublic, \vOld{})$
%      = \WindowedPedersenCommit{\NoteCommitRand}(\vOldRepr \bconcat \DiversifiedTransmitBaseRepr \bconcat \DiversifiedTransmitPublicRepr)
      & \snarkref{Note commitment integrity}{spendnotecommitmentintegrity}
      & 1740  & \shortcrossref{cctwindowedcommit} \\ \hline
  $\cmU = \ExtractJ(\cm)$
      & \snarkref{Merkle path validity}{spendmerklepathvalidity}
      & 0     & \\ \cline{1-1}\cline{3-4}
  \raggedright ${\rt{}}'$ is the root of a Merkle tree with leaf $\cmU$, and authentication path $(\TreePath{}, \NotePositionRepr)$
      &
      & 32 \mult 1380 & \shortcrossref{cctmerklepath} \\ \cline{1-1}\cline{3-4}
  $\NotePositionRepr = \ItoLEBSPOf{\MerkleDepth{Sapling}}{\NotePosition}$
      &
      & 1     & \shortcrossref{cctmodpack} \\ \cline{1-1}\cline{3-4}
  if $\vOld{} \neq 0$ then ${\rt{}}' = \rt{Sapling}$
      &
      & 1     & \shortcrossref{cctcondeq} \\ \cline{1-1}\cline{3-4}
  inputize $\rt{Sapling}$
      &
      & ?     & \\ \hline
  $\NoteUniqueRand = \MixingPedersenHash(\cmOld{}, \NotePosition)$
      & \snarkref{Nullifier integrity}{spendnullifierintegrity}
      & 98    & \shortcrossref{cctmixinghash} \\ \cline{1-1}\cline{3-4}
  $\NoteUniqueRandRepr = \reprJ\Of{\NoteUniqueRand}$
  \small\todo{spec doesn't say to validate $\NoteUniqueRand$ since it's calculated}
      &
      & 392   & \shortcrossref{ccteddecompressvalidate} \\ \cline{1-1}\cline{3-4}
  $\nfOld{} = \PRFnf{Sapling}{\NullifierKeyRepr}(\NoteUniqueRandRepr)$
      &
      & 21006 & \shortcrossref{cctblake2s} \\ \hline
  \raggedright pack $\nfOld{\barerange{0}{253}}$ and $\nfOld{\barerange{254}{255}}$ into two $\GF{\ParamS{r}}$ inputs
      & input encoding
      & 2     & \shortcrossref{cctmodpack} \\ \hline
\end{tabular}
\end{center}

\vspace{1ex}
$\dagger$ This is implemented by taking the output of $\BlakeTwos{256}$ as a \bitSequence and dropping the most
significant $5$~bits, not by converting to an integer and back to a \bitSequence as literally specified.

\pnote{The implementation represents $\AuthSignRandomizerRepr$, $\AuthProvePrivateRepr$, $\InViewingKeyRepr$,
$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers. It
represents $\nf$ as a \bitSequence rather than a \byteSequence.}


\introsection
\lsubsection{The \SaplingText{} Output circuit}{cctsaplingoutput}

The \Sapling Output \statement is defined in \crossref{outputstatement}.

The primary input is
\begin{formulae}
  \item $\oparen\cvNew{} \typecolon \ValueCommitOutput{Sapling},\\
         \hparen\cmU \typecolon \MerkleHash{Sapling},\\
         \hparen\EphemeralPublic \typecolon \GroupJ\cparen$,
\end{formulae}

which is encoded as $6$ $\GF{\ParamS{r}}$ elements (starting with the fixed element $1$ required by \Groth):
\begin{formulae}
  \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
\begin{formulae}
  \item $(\DiversifiedTransmitBase \typecolon \GroupJ,\\[0.5ex]
   \hparen\DiversifiedTransmitPublicRepr \typecolon \ReprJ,\\
   \hparen\vNew{} \typecolon \ValueType,\\
   \hparen\ValueCommitRandNew{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
   \hparen\NoteCommitRandNew{} \typecolon \binaryrange{\ScalarLength{Sapling}},\\
   \hparen\EphemeralPrivate \typecolon \binaryrange{\ScalarLength{Sapling}})$
\end{formulae}

$\ValueCommitOutput{Sapling}$ is of type $\GroupJ$, so we have $\cvNew{}$, $\EphemeralPublic$,
and $\DiversifiedTransmitBase$ that represent \jubjubCurve points. However,
\vspace{1ex}
\begin{itemize}
  \item $\cvNew{}$ will be constrained to an output of $\ValueCommitAlg{Sapling}$;
  \item $\EphemeralPublic$ will be constrained to
        $\scalarmult{\EphemeralPrivate}{\DiversifiedTransmitBase}$
\end{itemize}
\vspace{-1ex}
so $\cvNew{}$ and $\EphemeralPublic$ do not need to be explicitly checked
to be on the curve.

Therefore we have only $\DiversifiedTransmitBase$ that needs to be constrained
to a valid \jubjubCurve point as described in \crossref{ccteddecompressvalidate}.

\pnote{$\DiversifiedTransmitPublicRepr$ is \emph{not} checked to be a valid
compressed representation of a \jubjubCurve point.}


\introsection
In order to aid in comparing the implementation with the specification,
we present the checks needed in the order in which they are implemented
in the sapling-crypto code:

\begin{center}
\begin{tabular}{|p{16em}|l|C|l|}
\hline
Check & Implements & \heading{Cost} & Reference \\
\hhline{|=|=|=|=|}

  $\vOldRepr \typecolon \bitseq{64}$
      & $\vOld{} \typecolon \binaryrange{64}$
      & 64    & \shortcrossref{cctboolean} \\ \hline
  $\ValueCommitRandRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\ValueCommitRand \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\cv = \ValueCommit{Sapling}{\ValueCommitRand}(\vOld{})$
      & \snarkref{Value commitment integrity}{outputvaluecommitmentintegrity}
      & 947   & \shortcrossref{ccthomomorphiccommit} \\ \cline{1-1}\cline{3-4}
  inputize $\cv$
      &
      & ?     & \\ \hline
  $\DiversifiedTransmitBaseRepr = \reprJ(\DiversifiedTransmitBase \typecolon \GroupJ)$
      & \snarkref{Note commitment integrity}{outputnotecommitmentintegrity}
      & 392   & \shortcrossref{ccteddecompressvalidate} \\ \hline
  $\DiversifiedTransmitBase$ is not \smallOrderAdjective
      & \snarkref{Small order checks}{outputnonsmall}
      & 16    & \shortcrossref{cctednonsmallorder} \\ \hline
  $\EphemeralPrivateRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\EphemeralPrivate \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\EphemeralPublic = \scalarmult{\EphemeralPrivateRepr}{\DiversifiedTransmitBase}$
      & \snarkref{Ephemeral public key integrity}{outputepkintegrity}
      & 3252  & \shortcrossref{cctvarscalarmult} \\ \hline
  inputize $\EphemeralPublic$
      &
      & ?     & \\ \hline
  $\DiversifiedTransmitPublicRepr \typecolon \ReprJ$
      & $\DiversifiedTransmitPublicRepr \typecolon \ReprJ$
      & 256   & \shortcrossref{cctboolean} \\ \hline
  $\NoteCommitRandRepr \typecolon \bitseq{\ScalarLength{Sapling}}$
      & $\NoteCommitRand \typecolon \binaryrange{\ScalarLength{Sapling}}$
      & 252   & \shortcrossref{cctboolean} \\ \hline
  $\cm = \NoteCommit{Sapling}{\NoteCommitRand}(\DiversifiedTransmitBase, \DiversifiedTransmitPublic, \vOld{})$
%      = \WindowedPedersenCommit{\NoteCommitRand}(\vOldRepr \bconcat \DiversifiedTransmitBaseRepr \bconcat \DiversifiedTransmitPublicRepr)
      & \snarkref{Note commitment integrity}{outputnotecommitmentintegrity}
      & 1740  & \shortcrossref{cctwindowedcommit} \\ \hline
  pack inputs
      &
      & ?     & \\ \hline %\shortcrossref{cctpackinputs}
\end{tabular}
\end{center}

\pnote{The implementation represents $\EphemeralPrivateRepr$, $\DiversifiedTransmitPublicRepr$,
$\NoteCommitRandRepr$, $\ValueCommitRandRepr$, and $\vOldRepr$ as \bitSequences rather than integers.}


\lsection{Batching Optimizations}{batching}

\extralabel{reddsabatchverify}{\lsubsection{\RedDSAText{} batch validation}{reddsabatchvalidate}}

The reference validation algorithm for $\RedDSA$ signatures is defined in \crossref{concretereddsa}.

Let the $\RedDSA$ parameters $\GroupG{}$ (defining a subgroup $\SubgroupG{}$ of order $\ParamG{r}$,
a cofactor $\ParamG{h}$, a group operation $+$, an additive identity $\ZeroG{}$, a bit-length $\ellG{}$,
a representation function $\reprG{}$, and an abstraction function $\abstG{}$); $\GenG{} \typecolon \GroupG{}$;
$\RedDSAHashLength \typecolon \Nat$; $\RedDSAHash \typecolon \byteseqs \rightarrow \byteseq{\RedDSAHashLength/8}$;
and the derived hash function $\RedDSAHashToScalar \typecolon \byteseqs \rightarrow \GF{\ParamG{r}}$
be as defined in that section.

\vspace{2ex}
Implementations \MAY alternatively use the optimized procedure described in this section to perform
faster validation of a batch of signatures, i.e.\ to determine whether all signatures in a batch are valid.
Its input is a sequence of $N$ \defining{\sigBatchEntries}, each of which is a
(\validatingKey, message, signature) triple.

\vspace{2ex}
Let $\LEOStoBSP{}$, $\LEOStoIP{}$, and $\LEBStoOSP{}$ be as defined in \crossref{endian}.

Define $\RedDSABatchEntry := \RedDSAPublic \times \RedDSAMessage \times \RedDSASignature$.

\introsection
Define $\RedDSABatchValidate \typecolon (\Entry{\barerange{0}{N-1}} \typecolon \typeexp{\RedDSABatchEntry}{N})
                                        \rightarrow \bit$ as:
\begin{algorithm}
  \item For each $j \in \range{0}{N-1}$:
  \item \tab Let $(\vk_j, M_j, \sigma_j) = \Entry{j}$.
  \item \tab Let $\RedDSAReprR{j}$ be the first $\ceiling{\ellG{}/8}$ bytes of $\sigma_j$, and
             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)$.
  \item \tab Choose random $z_j \typecolon \GFstar{\ParamG{r}} \leftarrowR \range{1}{2^{128}-1}$.
  \item \blank
  \item Return $1$ if
        \vspace{1ex}
        \begin{itemize}
          \item for all $j \in \range{0}{N-1}$, $\RedDSASigR{j} \neq \bot$ and $\RedDSASigS{j} < \ParamG{r}$; and
          \item $\scalarmult{\ParamG{h}}{\Big(\!-\kern-0.2em\Bigscalarmult{\ssum{j=0}{N-1}{(z_j \mult \RedDSASigS{j})
                                                                                           \pmod{\ParamG{r}}}}{\GenG{}} +
                                              \ssum{j=0}{N-1}{\scalarmult{z_j}{\RedDSASigR{j}}} +
                                              \ssum{j=0}{N-1}{\scalarmult{z_j \mult \RedDSASigc{j}
                                                                      \pmod{\ParamG{r}}}{\vk_j}}\!\Big)}
                = \ZeroG{}$,
        \end{itemize}
        \vspace{-1ex}
        otherwise $0$.
\end{algorithm}

The $z_j$ values \MUST be chosen independently of the \sigBatchEntries.

\nnote{
It is also acceptable to sample each $z_j$ from $\range{0}{2^{128}-1}$, since the probability of obtaining
zero for any $z_j$ is negligible.
} %nnote

The performance benefit of this approach arises partly from replacing the per-signature
scalar multiplication of the base $\GenG{}$ with one such multiplication per batch,
and partly from using an efficient algorithm for multiscalar multiplication such
as Pippinger's method \cite{Bernstein2001} or the Bos--Coster method \cite{deRooij1995}, as explained in
\cite[section 5]{BDLSY2012}.

\pnote{Spend authorization signatures (\crossref{concretespendauthsig}) and
binding signatures (\crossref{concretebindingsig}) use different bases $\raisedstrut\GenG{}$.
It is straightforward to adapt the above procedure to handle multiple bases;
there will be one
$- \Bigscalarmult{\ssum{j}{}{(z_j \mult \RedDSASigS{j}) \pmod{\ParamG{r}}}}{\Generator}$ term for each base $\Generator$.
The benefit of this relative to using separate batches is that the multiscalar multiplication
can be extended across a larger batch.} %pnote


\lsubsection{\GrothText{} batch verification}{grothbatchverify}

The reference verification algorithm for \Groth proofs is defined in \crossref{groth}.
The batch verification algorithm in this section applies techniques from \cite[section 4]{BFIJSV2010}.

Let $\ParamS{q}$, $\ParamS{r}$, $\SubgroupS{1, 2, T}$, $\SubgroupSstar{1, 2, T}$, $\GenS{1, 2, T}$,
$\OneS$, and $\PairingS$ be as defined in \crossref{blspairing}.

Define $\MillerLoopS \typecolon \SubgroupS{1} \times \SubgroupS{2} \rightarrow \SubgroupS{T}$
and $\FinalExpS \typecolon \SubgroupS{T} \rightarrow \SubgroupS{T}$ to be the Miller loop and
final exponentiation respectively of the $\PairingS$ pairing computation, so that:
\vspace{0.5ex}
\begin{formulae}
  \item $\PairingS\Of{P, Q} = \FinalExpS\Of{\MillerLoopS\Of{P, Q}\kern 0.05em}$
\end{formulae}
\vspace{-1ex}
where $\FinalExpS\Of{R} = R^{t}$ for some fixed $t$.

\vspace{2ex}
Define $\GrothSProof := \SubgroupSstar{1} \times \SubgroupSstar{2} \times \SubgroupSstar{1}$.

A $\GrothS$ proof comprises a tuple $(\Proof{A}, \Proof{B}, \Proof{C}) \typecolon \GrothSProof$.

\introlist
Verification of a single $\GrothS$ proof against an instance encoded as $a_{\barerange{0}{\ell}} \typecolon \typeexp{\GF{\ParamS{r}}}{\ell+1}$
requires checking the equation
\vspace{-0.5ex}
\begin{formulae}
  \item $\PairingS(\Proof{A}, \Proof{B}) = \PairingS(\Proof{C}, \Delta) \mult
                                           \PairingS\Big(\ssum{i=0}{\ell}{\scalarmult{a_i}{\Psi_i}}, \Gamma\Big) \mult Y$
\end{formulae}
\vspace{-1ex}
where $\Delta = \scalarmult{\delta}{\GenS{2}}, \Gamma = \scalarmult{\gamma}{\GenS{2}}$, $Y = \scalarmult{\alpha \smult \beta}{\GenS{T}}$,
and $\Psi_i = \Bigscalarmult{\hfrac{\beta \smult u_i(x) + \alpha \smult v_i(x) + w_i(x)}{\gamma}}{\GenS{1}}$
for $i \in \range{0}{\ell}$ are elements of the verification key, as described (with slightly different notation)
in \cite[section 3.2]{Groth2016}.

\introlist
\vspace{1ex}
This can be written as:
\begin{formulae}
  \item $\PairingS(\Proof{A}, -\Proof{B}) \mult \PairingS(\Proof{C}, \Delta) \mult
         \PairingS\Big(\ssum{i=0}{\ell}{\scalarmult{a_i}{\Psi_i}}, \Gamma\Big) \mult Y = \OneS$.
\end{formulae}

\introlist
Raising to the power of random $z \neq 0$ gives:
\begin{formulae}
  \item $\PairingS\Of{\scalarmult{z}{\Proof{A}}, -\Proof{B}} \mult \PairingS\Of{\scalarmult{z}{\Proof{C}}, \Delta} \mult
         \PairingS\Big(\ssum{i=0}{\ell}{\scalarmult{z \mult a_i}{\Psi_i}}, \Gamma\Big) \mult Y^z = \OneS$.
\end{formulae}

\vspace{1ex}
This justifies the following optimized procedure for performing faster verification of a batch of $\GrothS$ proofs.
Implementations \MAY use this procedure to determine whether all proofs in a batch are valid.

\vspace{1ex}
Define a type $\GrothSBatchEntry := \GrothSProof \times \GrothSPrimaryInput$ representing \defining{\proofBatchEntries}.

\introlist
Define $\GrothSBatchVerify \typecolon (\Entry{\barerange{0}{N-1}} \typecolon \typeexp{\GrothSBatchEntry}{N})
                                       \rightarrow \bit$ as:
\begin{algorithm}
  \item For each $j \in \range{0}{N-1}$:
  \item \tab Let $((\Proof{j,A},\, \Proof{j,B},\, \Proof{j,C}),\; a_{j,\,\barerange{0}{\ell}}) = \Entry{j}$.
  \item \tab Choose random $z_j \typecolon \GFstar{\ParamS{r}} \leftarrowR \range{1}{2^{128}-1}$.
  \item \blank
  \item \begin{tabular}{@{}l@{\;}l}
        Let $\Accum{AB}$       &$= \sproduct{j=0}{N-1}{\MillerLoopS\Of{\scalarmult{z_j}{\Proof{j,A}}, -\Proof{j,B}}}$\,. \\[1.5ex]
        Let $\Accum{\Delta}$   &$= \ssum{j=0}{N-1}{\scalarmult{z_j}{\Proof{j,C}}}$. \\[1.5ex]
        Let $\Accum{\Gamma,i}$ &$= \ssum{j=0}{N-1}{(z_j\kern-0.08em \mult a_{j,i}) \pmod{\ParamS{r}}}$ for $i \in \range{0}{\ell}$. \\[1.5ex]
        Let $\Accum{Y}$        &$= \ssum{j=0}{N-1}{z_j \pmod{\ParamS{r}}}$. \\[2.5ex]
        \end{tabular}
  \item Return $1$ if
        \vspace{1ex}
        \begin{formulae}
          \item $\FinalExpS\Of{\!\Accum{AB} \mult \MillerLoopS\big(\Accum{\Delta}, \Delta\big) \mult
                               \MillerLoopS\Big(\ssum{i=0}{\ell}{\scalarmult{\Accum{\Gamma,i}}{\Psi_i}}, \Gamma\Big)\kern-0.25em}
                 \mult Y^{\Accum{Y}} = \OneS$,
        \end{formulae}
        \vspace{-2ex}
        otherwise $0$.
\end{algorithm}

The $z_j$ values \MUST be chosen independently of the \proofBatchEntries.

\nnote{
It is also acceptable to sample each $z_j$ from $\range{0}{2^{128}-1}$, since the probability of obtaining
zero for any $z_j$ is negligible.
} %nnote

The performance benefit of this approach arises from computing two of the three Miller loops, and
the final exponentation, per batch instead of per proof. For the multiplications by $z_j$, an efficient
algorithm for multiscalar multiplication such as Pippinger's method \cite{Bernstein2001} or the Bos--Coster
method \cite{deRooij1995} may be used.

\pnote{
Spend proofs (of the \statement in \crossref{spendstatement}) and output proofs (of the \statement
in \crossref{outputstatement}) use different verification keys, with different parameters $\Delta$, $\Gamma$,
$Y$, and $\Psi_{\barerange{0}{\ell}}$. It is straightforward to adapt the above procedure to handle multiple
verification keys; the accumulator variables $\Accum{\Delta}$, $\Accum{\Gamma,i}$, and $\Accum{Y}$ are duplicated,
with one term in the verification equation for each variable, while $\Accum{AB}$ is shared.

\introlist
Neglecting multiplications in $\SubgroupS{T}$ and $\GF{\ParamS{r}}$, and other trivial operations,
the cost of batched verification is therefore
\begin{itemize}
  \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
        $\ssum{i=0}{\ell}{\scalarmult{\Accum{\Gamma,i}}{\Psi_i}}$;
  \item one final exponentiation.
\end{itemize}
} %pnote


\canopy{
\lsubsection{\EdSpecificText{} batch validation}{ed25519batchvalidate}

The reference validation algorithm for \EdSpecific signatures is defined in \crossref{concreteed25519}.

\vspace{1ex}
\canopyonward{Implementations \MAY alternatively use the optimized procedure described in this section to perform
faster validation of a batch of signatures, i.e.\ to determine whether all signatures in a batch are valid.
The correctness of this procedure is dependent on the \EdSpecific validation changes made for the \Canopy
\networkUpgrade in \cite{ZIP-215} (in particular the change to use the cofactor variant of the validation equation).
The input is a sequence of $N$ \defining{\sigBatchEntries}, each of which is a
(\validatingKey, message, signature) triple.}

\vspace{2ex}
Let $\ell$, $\EdDSABase$, $\abstBytesEdSpecific$, and $\reprBytesEdSpecific$ be as defined in \crossref{concreteed25519}.

Let $\LEOStoIP{}$ be as defined in \crossref{endian}.

\bigShaHash is defined in \crossref{concretesha}.

Define $\EdSpecificBatchEntry := \EdSpecificPublic \times \EdSpecificMessage \times \EdSpecificSignature$.

\introsection
Define $\EdSpecificBatchValidate \typecolon (\Entry{\barerange{0}{N-1}} \typecolon \typeexp{\EdSpecificBatchEntry}{N})
                                            \rightarrow \bit$ as:
\begin{algorithm}
  \item For each $j \in \range{0}{N-1}$:
  \item \tab Let $(\EdDSASigA{j}, M_j, \sigma_j) = \Entry{j}$.
  \item \tab Let $\EdDSAReprR{j}$ be the first $32$ bytes of $\sigma_j$, and
             let $\EdDSAReprS{j}$ be the remaining $32$ bytes.
  \item \tab Let $\EdDSASigR{j} = \abstBytesEdSpecific(\EdDSAReprR{j})$, and
             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)$.
  \item \tab Choose random $z_j \typecolon \GFstar{\ell} \leftarrowR \range{1}{2^{128}-1}$.
  \item \blank
  \item Return $1$ if
        \vspace{1ex}
        \begin{itemize}
          \item for all $j \in \range{0}{N-1}$, $\EdDSASigR{j} \neq \bot$ and $\EdDSASigS{j} < \ell$; and
          \item $\scalarmult{8}{\Big(\!-\kern-0.2em\Bigscalarmult{\ssum{j=0}{N-1}{(z_j \mult \EdDSASigS{j})
                                                                                  \pmod{\ell}}}{\EdDSABase} +
                                     \ssum{j=0}{N-1}{\scalarmult{z_j}{\EdDSASigR{j}}} +
                                     \ssum{j=0}{N-1}{\scalarmult{z_j \mult \EdDSASigc{j}
                                                                      \pmod{\ell}}{\EdDSASigA{j}}}\!\Big)}
                = \Zero_{\EdSpecificAlg}$,
        \end{itemize}
        \vspace{-1ex}
        otherwise $0$.
\end{algorithm}

The $z_j$ values \MUST be chosen independently of the \sigBatchEntries.

\nnote{
It is also acceptable to sample each $z_j$ from $\range{0}{2^{128}-1}$, since the probability of obtaining
zero for any $z_j$ is negligible.
} %nnote

The performance benefits of this approach are the same as for \crossref{reddsabatchvalidate}.
} %canopy


\lpart{List of Theorems and Lemmata}{theorems}

\hfuzz=10pt \hbadness=10000
\listtheorems{theorem,lemma}

\needspace{30ex}
\phantompart{Index}{index}

\begin{flushleft}
\vfuzz=14pt
\printindex
\end{flushleft}

\end{document}