mirror of https://github.com/zcash/zips.git
19208 lines
914 KiB
TeX
19208 lines
914 KiB
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{pagecolor}
|
||
\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
|
||
|
||
|
||
% Load version-specific properties from protocol.ver
|
||
\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}
|
||
\newcommand{\NUSixSpec}{NU6}
|
||
\newtoggle{issapling}
|
||
\togglefalse{issapling}
|
||
\newtoggle{isblossom}
|
||
\togglefalse{isblossom}
|
||
\newtoggle{isheartwood}
|
||
\togglefalse{isheartwood}
|
||
\newtoggle{iscanopy}
|
||
\togglefalse{iscanopy}
|
||
\newtoggle{isnufive}
|
||
\togglefalse{isnufive}
|
||
\newtoggle{isnusix}
|
||
\togglefalse{isnusix}
|
||
\newtoggle{darkmode}
|
||
\togglefalse{darkmode}
|
||
\InputIfFileExists{protocol.ver}{}{}
|
||
|
||
\iftoggle{darkmode}{
|
||
\colorlet{crossrefblue}{MidnightBlue}
|
||
\colorlet{citationpurple}{red!60!blue!95}
|
||
\colorlet{linkred}{black!25!BrickRed}
|
||
}{
|
||
\colorlet{crossrefblue}{MidnightBlue}
|
||
\colorlet{citationpurple}{Plum}
|
||
\colorlet{linkred}{BrickRed}
|
||
}
|
||
|
||
% 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=crossrefblue,citebordercolor=citationpurple,urlbordercolor=linkred,
|
||
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{\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}
|
||
|
||
|
||
% Colors
|
||
% <https://en.wikibooks.org/wiki/LaTeX/Colors#The_68_standard_colors_known_to_dvips>
|
||
|
||
\iftoggle{darkmode}{
|
||
% The colors need to be adjusted to maintain a comfortable contrast, saturation,
|
||
% and brightness in dark mode.
|
||
\definecolor{darkpage}{RGB}{30,30,30}
|
||
\definecolor{lighttext}{RGB}{220,220,220}
|
||
\definecolor{red}{RGB}{215,20,20}
|
||
\definecolor{green}{RGB}{10,175,20}
|
||
\definecolor{blue}{RGB}{65,65,245}
|
||
\definecolor{slateblue}{RGB}{98,139,190}
|
||
\colorlet{reddishorange}{red!30!orange}
|
||
\definecolor{purple}{RGB}{157,68,150}
|
||
\colorlet{pink}{magenta!70}
|
||
\definecolor{brown}{RGB}{160,50,50}
|
||
\colorlet{warningred}{BrickRed}
|
||
\colorlet{cream}{yellow!20}
|
||
|
||
\pagecolor{darkpage}
|
||
\color{lighttext}
|
||
\newcommand{\imagesuffix}{_dark}
|
||
}{
|
||
\definecolor{green}{RGB}{0,100,10}
|
||
\colorlet{slateblue}{black!25!blue!65!green!65}
|
||
\colorlet{reddishorange}{red!30!orange}
|
||
\colorlet{purple}{red!50!blue!85}
|
||
\colorlet{pink}{magenta!75}
|
||
\colorlet{brown}{Sepia}
|
||
\colorlet{warningred}{BrickRed}
|
||
\colorlet{cream}{yellow!20}
|
||
|
||
\newcommand{\imagesuffix}{}
|
||
}
|
||
|
||
\newcommand{\todo}[1]{{\color{brown}\sf{TODO: #1}}}
|
||
|
||
\newcommand{\vulncolor}{warningred}
|
||
\newcommand{\setwarning}{\color{\warningcolor}}
|
||
\newcommand{\warningcolor}{warningred}
|
||
\newcommand{\saplingcolor}{green}
|
||
\newcommand{\saplingcolorname}{\saplingcolor}
|
||
\newcommand{\overwintercolor}{blue}
|
||
\newcommand{\overwintercolorname}{bright blue}
|
||
\newcommand{\blossomcolor}{red}
|
||
\newcommand{\blossomcolorname}{\blossomcolor}
|
||
\newcommand{\heartwoodcolor}{reddishorange}
|
||
\newcommand{\heartwoodcolorname}{orange}
|
||
\newcommand{\canopycolor}{purple}
|
||
\newcommand{\canopycolorname}{\canopycolor}
|
||
\newcommand{\nufivecolor}{slateblue}
|
||
\newcommand{\nufivecolorname}{slate blue}
|
||
\newcommand{\nusixcolor}{pink}
|
||
\newcommand{\nusixcolorname}{\nusixcolor}
|
||
\newcommand{\labelcolor}{cream}
|
||
|
||
\iftoggle{isnusix}{
|
||
\iftoggle{darkmode}{
|
||
\providecommand{\baseurl}{https://zips.z.cash/protocol/protocol-dark.pdf}
|
||
}{
|
||
\providecommand{\baseurl}{https://zips.z.cash/protocol/protocol.pdf}
|
||
}
|
||
\toggletrue{isnufive}
|
||
\newcommand{\setnusix}{\color{\nusixcolor}}
|
||
\newcommand{\nusix}[1]{\texorpdfstring{{\setnusix{#1}}}{#1}}
|
||
\newcommand{\notnusix}[1]{}
|
||
\newcommand{\notbeforenusix}[1]{#1}
|
||
} {
|
||
\newcommand{\setnusix}{}
|
||
\newcommand{\nusix}[1]{}
|
||
\newcommand{\notnusix}[1]{#1}
|
||
\newcommand{\notbeforenusix}[1]{}
|
||
}
|
||
|
||
\iftoggle{isnufive}{
|
||
\providecommand{\baseurl}{https://zips.z.cash/protocol/nu5.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{\Sapling}{\termbf{Sapling}}
|
||
\newcommand{\SaplingText}{\textbf{Sapling}}
|
||
\newcommand{\Blossom}{\termbf{Blossom}}
|
||
\newcommand{\Heartwood}{\termbf{Heartwood}}
|
||
\newcommand{\Canopy}{\termbf{Canopy}}
|
||
\newcommand{\NUFive}{\readasunicode{004e200b0055200b0035}{\termbf{NU5}}\xspace}
|
||
\newcommand{\NUSix}{\readasunicode{004e200b0055200b0036}{\termbf{NU6}}\xspace}
|
||
\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}{\termsf{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}{\termandindex{trans\-action}{transaction}}
|
||
\newcommand{\transactions}{\termandindex{trans\-actions}{transactions}}
|
||
\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{\standardPtoSHScript}{\term{standard P2SH script}}
|
||
\newcommand{\standardRedeemScript}{\term{standard redeem script}}
|
||
\newcommand{\xStandardRedeemScript}{\termx{standard redeem script}}
|
||
\newcommand{\transparent}{\term{transparent}}
|
||
\newcommand{\xTransparent}{\termx{transparent}}
|
||
\newcommand{\transparentAddress}{\term{transparent address}}
|
||
\newcommand{\transparentAddresses}{\termes{transparent address}}
|
||
\newcommand{\xTransparentAddresses}{\termxes{transparent address}}
|
||
\newcommand{\PtoSH}{\termandindex{P2SH}{transparent address (P2SH)}}
|
||
\newcommand{\PtoSHAddress}{\termandindex{P2SH address}{transparent address (P2SH)}}
|
||
\newcommand{\PtoSHAddresses}{\termandindex{P2SH addresses}{transparent address (P2SH)}}
|
||
\newcommand{\transparentPtoSHAddress}{\termandindex{transparent P2SH address}{transparent address (P2SH)}}
|
||
\newcommand{\PtoSHMultisigAddress}{\termandindex{P2SH multisig address}{transparent address (P2SH multisig)}}
|
||
\newcommand{\PtoSHMultisigAddresses}{\termandindex{P2SH multisig addresses}{transparent address (P2SH multisig)}}
|
||
\newcommand{\transparentPtoSHMultisigAddress}{\termandindex{transparent P2SH multisig address}{transparent address (P2SH multisig)}}
|
||
\newcommand{\PtoPKH}{\termandindex{P2PKH}{transparent address (P2PKH)}}
|
||
\newcommand{\PtoPKHAddress}{\termandindex{P2PKH address}{transparent address (P2PKH)}}
|
||
\newcommand{\PtoPKHAddresses}{\termandindex{P2PKH addresses}{transparent address (P2PKH)}}
|
||
\newcommand{\transparentPtoPKHAddress}{\termandindex{transparent P2PKH address}{transparent address (P2PKH)}}
|
||
\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{\TransparentChainValuePoolBalance}{\termandindex{transparent chain value pool balance}{chain value pool balance (transparent)}}
|
||
\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{\DeferredChainValuePoolBalance}{\termandindex{deferred development fund chain value pool balance}{chain value pool balance (deferred development fund)}}
|
||
\newcommand{\chainValuePool}{\term{chain value pool}}
|
||
\newcommand{\chainValuePools}{\terms{chain value pool}}
|
||
\newcommand{\deferredChainValuePool}{\term{deferred development fund chain value pool}}
|
||
\newcommand{\totalIssuedSupply}{\term{total issued supply}}
|
||
\newcommand{\totalOutputValue}{\term{total output value}}
|
||
\newcommand{\totalInputValue}{\term{total input value}}
|
||
\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{\cb}{\mathsf{cb}}
|
||
\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{\fsRecipient}{\fs\mathsf{.Recipient}}
|
||
\newcommand{\fsRecipients}{\fs\mathsf{.Recipients}}
|
||
\newcommand{\fsRecipientIndex}{\fs\mathsf{.RecipientIndex}}
|
||
\newcommand{\fsNumRecipients}{\fs\mathsf{.NumRecipients}}
|
||
\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{\FSRecipientChangeInterval}{\mathsf{FSRecipientChangeInterval}}
|
||
\newcommand{\FSRecipientPeriod}{\mathsf{FSRecipientPeriod}}
|
||
\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{\ChainValuePoolBalance}[1]{\mathsf{ChainValuePoolBalance^{#1}}}
|
||
\newcommand{\IssuedSupply}{\mathsf{IssuedSupply}}
|
||
|
||
\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{\prescribedWay}{\termandindex{prescribed way}{prescribed way (to pay a funding stream recipient)}}
|
||
|
||
\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{\totalDeferredOutput}{\mathsf{totalDeferredOutput}}
|
||
\newcommand{\DeferredPool}{\mathsf{DEFERRED\_POOL}}
|
||
\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{\sighashAlgorithms}{\terms{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{\prenusixitem}[1]{\item \prenusix{#1}}
|
||
\newcommand{\nusixonlyitem}[1]{\nusix{\item {[\NUSix only]}\, {#1}}}
|
||
\newcommand{\nusixonwarditem}[1]{\nusix{\item {[\NUSix onward]}\, {#1}}}
|
||
\newcommand{\prenufiveitem}[1]{\item \prenufive{#1}}
|
||
\newcommand{\nufiveonlyitem}[1]{\nufive{\item {[\NUFive only\notbeforenusix{, pre-\NUSix}]}\, {#1}}}
|
||
\newcommand{\nufiveonwarditem}[1]{\nufive{\item {[\NUFive onward]}\, {#1}}}
|
||
\newcommand{\precanopyitem}[1]{\item \precanopy{#1}}
|
||
\newcommand{\canopyonlyitem}[1]{\canopy{\item {[\Canopy only\notbeforenufive{, pre-\NUFive}]}\, {#1}}}
|
||
\newcommand{\canopyonwarditem}[1]{\canopy{\item {[\Canopy onward]}\, {#1}}}
|
||
\newcommand{\preheartwooditem}[1]{\item \preheartwood{#1}}
|
||
\newcommand{\heartwoodonlyitem}[1]{\heartwood{\item {[\Heartwood only\notbeforecanopy{, pre-\Canopy}]}\, {#1}}}
|
||
\newcommand{\heartwoodonwarditem}[1]{\heartwood{\item {[\Heartwood onward]}\, {#1}}}
|
||
\newcommand{\heartwoodandcanopyitem}[1]{\heartwood{\item \heartwoodandcanopy{#1}}}
|
||
\newcommand{\preblossomitem}[1]{\item \preblossom{#1}}
|
||
\newcommand{\blossomonlyitem}[1]{\blossom{\item {[\Blossom only\notbeforeheartwood{, pre-\Heartwood}]}\, {#1}}}
|
||
\newcommand{\blossomonwarditem}[1]{\blossom{\item {[\Blossom onward]}\, {#1}}}
|
||
\newcommand{\presaplingitem}[1]{\item \presapling{#1}}
|
||
\newcommand{\saplingonlyitem}[1]{\sapling{\item {[\Sapling only\notbeforeblossom{, pre-\Blossom}]}\, {#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, 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{\prenusix}[1]{\notbeforenusix{\nusix{[Pre-\NUSix\!]\,}} {#1}}
|
||
\newcommand{\nusixonly}[1]{\nusix{[\NUSix only]\, {#1}}}
|
||
\newcommand{\nusixonward}[1]{\nusix{[\NUSix onward]\, {#1}}}
|
||
\newcommand{\prenufive}[1]{\notbeforenufive{\nufive{[Pre-\NUFive\!]\,}} {#1}}
|
||
\newcommand{\nufiveonly}[1]{\nufive{[\NUFive only\notbeforenusix{, pre-\NUSix}]\, {#1}}}
|
||
\newcommand{\nufiveonward}[1]{\nufive{[\NUFive onward]\, {#1}}}
|
||
\newcommand{\precanopy}[1]{\notbeforecanopy{\canopy{[Pre-\Canopy\!]\,}} {#1}}
|
||
\newcommand{\canopyonly}[1]{\canopy{[\Canopy only\notbeforenufive{, pre-\NUFive}]\, {#1}}}
|
||
\newcommand{\canopyonward}[1]{\canopy{[\Canopy onward]\, {#1}}}
|
||
\newcommand{\preheartwood}[1]{\notbeforeheartwood{\heartwood{[Pre-\Heartwood\!]\,}} {#1}}
|
||
\newcommand{\heartwoodonward}[1]{\heartwood{[\Heartwood onward]\, {#1}}}
|
||
\newcommand{\heartwoodonly}[1]{\heartwood{[\Heartwood only\notbeforecanopy{, pre-\Canopy}]\, {#1}}}
|
||
\newcommand{\heartwoodandcanopy}[1]{\heartwood{[\Heartwood\notbeforecanopy{ and \Canopy}\notbeforenufive{ only, pre-\NUFive}]\, {#1}}}
|
||
\newcommand{\preblossom}[1]{\notbeforeblossom{\blossom{[Pre-\Blossom\!]\,}} {#1}}
|
||
\newcommand{\blossomonly}[1]{\blossom{[\Blossom only\notbeforeheartwood{, pre-\Heartwood}]\, {#1}}}
|
||
\newcommand{\blossomonward}[1]{\blossom{[\Blossom onward]\, {#1}}}
|
||
\newcommand{\presapling}[1]{\sapling{[Pre-\Sapling\!]\,} {#1}}
|
||
\newcommand{\saplingonly}[1]{\sapling{[\Sapling only\notbeforeblossom{, pre-\Blossom}]\, {#1}}}
|
||
\newcommand{\saplingonward}[1]{\sapling{[\Sapling onward]\, {#1}}}
|
||
\newcommand{\saplingandblossom}[1]{\sapling{[\Sapling\notbeforeblossom{ and \Blossom}\notbeforeheartwood{ only, pre-\Heartwood}]\, {#1}}}
|
||
\newcommand{\saplingprenufive}[1]{\sapling{[\Sapling \notnufive{onward}\notbeforenufive{ to \Canopy inclusive, pre-\NUFive}]\, {#1}}}
|
||
\newcommand{\preoverwinter}[1]{\overwinter{[Pre-\Overwinter\!]\,} {#1}}
|
||
\newcommand{\overwinteronly}[1]{\overwinter{[\Overwinter only, pre-\Sapling]\, {#1}}}
|
||
\newcommand{\overwinteronward}[1]{\overwinter{[\Overwinter onward]\, {#1}}}
|
||
\newcommand{\overwinterprenufive}[1]{\overwinter{[\Overwinter \notnufive{onward}\notbeforenufive{ to \Canopy inclusive, 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{\nusixonwardnnote}[1]{\nusix{\callout{[\NUSix onward]\,\,}{Non-normative note:}{#1}}}
|
||
\newcommand{\nusixonwardpnote}[1]{\nusix{\callout{[\NUSix onward]\,\,}{Note:}{#1}}}
|
||
\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}
|
||
\newcommand{\thisspecdefines}[1]{This specification defines the \Zcash consensus protocol at launch, and after each of the upgrades codenamed {#1}.}
|
||
\noindent \notblossom{\sapling{\thisspecdefines{\Overwinter and \Sapling}}}%
|
||
\notheartwood{\blossom{\thisspecdefines{\Overwinter, \Sapling, and \Blossom}}}%
|
||
\notcanopy{\heartwood{\thisspecdefines{\Overwinter, \Sapling, \Blossom, and \Heartwood}}}%
|
||
\notnufive{\canopy{\thisspecdefines{\Overwinter, \Sapling, \Blossom, \Heartwood, and \Canopy}}}%
|
||
\notnusix{\nufive{\thisspecdefines{\Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, and \NUFive}}}%
|
||
\nusix{This specification defines the \Zcash consensus protocol at launch; after each of the upgrades
|
||
codenamed \Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, and \NUFive; and proposed changes for \NUSix.} %
|
||
It is a work in progress. Protocol differences from \Zerocash and \Bitcoin are also explained.
|
||
|
||
\vspace{2ex}
|
||
\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
|
||
|
||
\vspace{-2ex}
|
||
\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}.}
|
||
|
||
\notbeforenusix{Changes specific to the proposed \NUSix upgrade following \NUFive
|
||
are highlighted in \nusix{\nusixcolorname}.}
|
||
|
||
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{1ex}
|
||
\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}
|
||
|
||
|
||
\vspace{-2ex}
|
||
\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,\notnusix{ and also} a \chainValuePool for each
|
||
\defining{\shielded} protocol (\Sprout\sapling{ or \Sapling}\nufive{ or \Orchard})\nusix{,
|
||
and a \deferredChainValuePool}.
|
||
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 rounded boxes 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.}{\vspace{-2ex}\begin{center}
|
||
\notnufive{\includegraphics[scale=.5]{key_components_sapling}}
|
||
\nufive{\includegraphics[scale=.385]{key_components_orchard\imagesuffix}}
|
||
\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}.
|
||
|
||
\introlist
|
||
\vspace{1.5ex}
|
||
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{
|
||
\introlist
|
||
\vspace{1.5ex}
|
||
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{
|
||
\introlist
|
||
\vspace{1.5ex}
|
||
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}.
|
||
|
||
\introlist
|
||
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{1ex}
|
||
\defining{\xTransparentInputs} to a \transaction insert value into a \defining{\transparentTxValuePool}
|
||
associated with the \transaction, and \defining{\transparentOutputs} remove value from this pool.
|
||
The effect of \Sprout \joinSplitTransfers\sapling{,\notnufive{ and} \Sapling \spendTransfers and
|
||
\outputTransfers}\nufive{, and \Orchard \actionTransfers} on the \transparentTxValuePool are specified
|
||
in \crossref{sproutbalance}\sapling{,\notnufive{ and} \crossref{saplingbalance}}\nufive{, and
|
||
\crossref{orchardbalance}} respectively.
|
||
|
||
As in \Bitcoin, the remaining value in the \transparentTxValuePool of a non-coinbase \transaction
|
||
is available to miners as a fee. That is, the sum of those values for non-coinbase \transactions
|
||
in each \block is treated as an implicit input to the \transparentTxValuePool balance of the
|
||
\block's \coinbaseTransaction (in addition to the implicit input created by issuance).
|
||
|
||
The remaining value in the \transparentTxValuePool of \coinbaseTransactions\nusix{ in \blocks
|
||
prior to \NUSix} is destroyed. \nusix{From \NUSix, this remaining value is required to be zero;
|
||
that is, all of the available balance \MUST be consumed by outputs of the \coinbaseTransaction.}
|
||
|
||
\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\imagesuffix}
|
||
\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}
|
||
\introsection
|
||
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
|
||
|
||
\begin{consensusrules}
|
||
\nufiveonwarditem{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.)}
|
||
\preoverwinteritem{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).}
|
||
\overwinteronlyitem{The \sighashAlgorithm used after \Overwinter activation and before
|
||
\Sapling activation, i.e.\ for version 3 \transactions, is defined in \cite{ZIP-143}.}
|
||
\overwinteronlyitem{All \transactions \MUST use the \Overwinter \consensusBranchID \hexint{5BA81B19}
|
||
as defined in \cite{ZIP-201}.}
|
||
\saplingonwarditem{The \sighashAlgorithm used after \Sapling activation, i.e.\ for
|
||
version 4 \transactions, is defined in \cite{ZIP-243}.}
|
||
\saplingonlyitem{All \transactions \MUST use the \Sapling \consensusBranchID \hexint{76B809BB}
|
||
as defined in \cite{ZIP-205}.}
|
||
\blossomonlyitem{All \transactions \MUST use the \Blossom \consensusBranchID \hexint{2BB40E60}
|
||
as defined in \cite{ZIP-206}.}
|
||
\heartwoodonlyitem{All \transactions \MUST use the \Heartwood \consensusBranchID \hexint{F5B9230B}
|
||
as defined in \cite{ZIP-250}.}
|
||
\canopyonlyitem{All \transactions \MUST use the \Canopy \consensusBranchID \hexint{E9FF75A6}
|
||
as defined in \cite{ZIP-251}.}
|
||
\nufiveonwarditem{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}.}
|
||
\nufiveonlyitem{All \transactions \MUST use the \NUFive \consensusBranchID \hexint{F919A198}
|
||
as defined in \cite{ZIP-252}.}
|
||
\nusixonlyitem{All \transactions \MUST use the \NUSix \consensusBranchID \hexint{C8E71055}
|
||
as defined in \cite{ZIP-253}.}
|
||
\end{consensusrules}
|
||
|
||
|
||
\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}
|
||
|
||
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.
|
||
|
||
\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{
|
||
\introlist
|
||
\extralabel{bindingsig}{\lsubsection{Balance and Binding Signature (\SaplingText)}{saplingbalance}}
|
||
|
||
\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.
|
||
|
||
\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 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.
|
||
|
||
\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
|
||
|
||
\introsection
|
||
\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
|
||
|
||
|
||
\vspace{-2ex}
|
||
\introsection
|
||
\lsubsection{Chain Value Pool Balances}{chainvaluepoolbalances}
|
||
|
||
The \defining{\TransparentChainValuePoolBalance} for a given \blockChain is the sum of
|
||
the values of all \utxos in the \utxoSetFull for that chain.
|
||
It is denoted by $\ChainValuePoolBalance{Transparent}(\BlockHeight)$.
|
||
|
||
\vspace{1.5ex}
|
||
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$ field values for transactions in the \blockChain.
|
||
It is denoted by $\ChainValuePoolBalance{Sprout}(\BlockHeight)$.
|
||
|
||
\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.}
|
||
|
||
\sapling{
|
||
\vspace{1.5ex}
|
||
As defined in \cite{ZIP-209}, the \defining{\SaplingChainValuePoolBalance} for a given
|
||
\blockChain is the negation of the sum of all $\valueBalance{Sapling}$ values for
|
||
\transactions in the \blockChain.
|
||
It is denoted by $\ChainValuePoolBalance{Sapling}(\BlockHeight)$.
|
||
|
||
\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.}
|
||
} %sapling
|
||
|
||
\nufive{
|
||
\vspace{1.5ex}
|
||
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.
|
||
It is denoted by $\ChainValuePoolBalance{Orchard}(\BlockHeight)$.
|
||
|
||
\vspace{-2ex}
|
||
\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.}
|
||
} %nufive
|
||
|
||
\nusix{
|
||
\vspace{1.5ex}
|
||
Define $\totalDeferredOutput$ as in \crossref{subsidies}.
|
||
|
||
Then, consistent with \cite{ZIP-207}, the \defining{\DeferredChainValuePoolBalance}
|
||
for a \blockChain up to and including height $\BlockHeight$ is given by
|
||
$\ChainValuePoolBalance{Deferred}(\BlockHeight) := \sum_{\mathsf{h} = 0}^{\BlockHeight} \totalDeferredOutput(\mathsf{h})$.
|
||
|
||
\begin{nnotes}
|
||
\item $\totalDeferredOutput(\mathsf{h})$ is necessarily zero for heights $\mathsf{h}$
|
||
prior to \NUSix activation.
|
||
\item Currently there is no way to withdraw from the \deferredChainValuePool, so
|
||
there is no possibility of it going negative. Therefore, no consensus rule to
|
||
prevent that eventuality is needed at this time.
|
||
\end{nnotes}
|
||
} %nusix
|
||
|
||
\vspace{1ex}
|
||
The \defining{\totalIssuedSupply} of a \blockChain at \blockHeight $\BlockHeight$ is given
|
||
by the function:
|
||
$$
|
||
\begin{array}{rl}
|
||
\IssuedSupply(\BlockHeight) \; := &\!\!\! \ChainValuePoolBalance{Transparent}(\BlockHeight) \\
|
||
& +\,\; \ChainValuePoolBalance{Sprout}(\BlockHeight) \\
|
||
& \sapling{+\,\; \ChainValuePoolBalance{Sapling}(\BlockHeight)} \\
|
||
\notbeforenufive{
|
||
& \nufive{+\,\; \ChainValuePoolBalance{Orchard}(\BlockHeight)} \\
|
||
}
|
||
\notbeforenusix{
|
||
& \nusix{+\,\; \ChainValuePoolBalance{Deferred}(\BlockHeight)}
|
||
}
|
||
\end{array}
|
||
$$
|
||
|
||
\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 that:
|
||
\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 $\LEBStoIP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \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 \defining{\PtoSH (Pay to Script Hash)} addresses \cite{BIP-13}
|
||
or \defining{\PtoPKH (Pay to Public Key Hash)} addresses \cite{Bitcoin-P2PKH}.
|
||
|
||
\introlist
|
||
\defining{The \rawEncoding of a \PtoSHAddress} 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 \PtoSHAddress
|
||
on \Mainnet. (Addresses on \Testnet use
|
||
$[\PtoSHAddressTestnetLeadByte, \PtoSHAddressTestnetSecondByte]$
|
||
instead.)
|
||
\item $20$ bytes specifying a script hash \cite{Bitcoin-P2SH}.
|
||
\end{itemize}
|
||
|
||
\introlist
|
||
\defining{The \rawEncoding of a \PtoPKHAddress} 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 \PtoPKHAddress
|
||
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 \PtoSHAddresses, and as \ascii{t1} for \PtoPKHAddresses. (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}$ -- \transparentPtoSHAddress, \emph{or} typecode $\hexint{00}$ -- \transparentPtoPKHAddress.
|
||
\end{itemize}
|
||
|
||
\vspace{-2ex}
|
||
with the restrictions that there \MUST be at least one \shieldedPaymentAddress (typecodes $\geq \hexint{02})$,
|
||
and that both \PtoSH and \PtoPKH 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}.
|
||
Additional information and rationale is given in \cite{ZIP-1014}.}
|
||
|
||
\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}.}
|
||
|
||
\nusix{
|
||
This draft specification describes the set of changes proposed for the \NUSix \networkUpgrade,
|
||
for which the \Mainnet activation \blockHeight has been set at $2726400$. Its specifications are
|
||
described in this document, \cite{ZIP-253}, \cite{ZIP-236}, and \cite{ZIP-2001}, with updates to
|
||
\cite{ZIP-207} and \cite{ZIP-214}.
|
||
Additional information and rationale is given in \cite{ZIP-1015}.}
|
||
|
||
\introlist
|
||
\vspace{2ex}
|
||
This section summarizes the strategy for upgrading from \Sprout to subsequent versions
|
||
of the protocol (\Overwinter, \Sapling, \Blossom, \Heartwood, \Canopy, \NUFive, and \NUSix),
|
||
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 \nusix{Let $\totalDeferredOutput$ be as defined in \shortcrossref{subsidies}.}
|
||
For the \block at \blockHeight $\mathsf{height}$:
|
||
\begin{itemize}
|
||
\item define the \totalOutputValue of its \coinbaseTransaction to be the total value
|
||
in \zatoshi of its \transparentOutputs\heartwood{, minus $\vBalance{Sapling}$}\nufive{,
|
||
minus $\vBalance{Orchard}$}\nusix{, plus $\totalDeferredOutput(\mathsf{height})$};
|
||
\item define the \totalInputValue of its \coinbaseTransaction to be the value in \zatoshi
|
||
of the \blockSubsidy, plus the \transactionFees paid by \transactions in the \block.
|
||
\end{itemize}
|
||
\vspace{-1ex}
|
||
\prenusix{The \totalOutputValue of a \coinbaseTransaction \MUSTNOT be greater than its \totalInputValue.}
|
||
|
||
\nusixonward{The \totalOutputValue of a \coinbaseTransaction \MUST be equal to its \totalInputValue.}
|
||
\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
|
||
\nusix{
|
||
\vspace{-0.5ex}
|
||
\item There are no changes to the \blockVersionNumber or format for \NUSix.
|
||
} %nusix
|
||
\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{ / $\hashFinalSaplingRoot$}\heartwood{ / $\hashLightClientRoot$}\nufive{ / $\hashBlockCommitments$},
|
||
$\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}
|
||
|
||
\vspace{-2ex}
|
||
\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.
|
||
\introlist
|
||
\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
|
||
\vspace{-0.5ex}
|
||
\lsubsubsection{nBits conversion}{nbits}
|
||
|
||
\vspace{-0.5ex}
|
||
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:
|
||
|
||
\introlist
|
||
\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}
|
||
|
||
\vspace{-0.5ex}
|
||
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{-1.5ex}
|
||
\lsubsection{Calculation of Block Subsidy\notbeforecanopy{, Funding Streams,} and Founders' Reward}{subsidies}
|
||
|
||
\vspace{-0.5ex}
|
||
In \crossref{subsidyconcepts} the \blockSubsidy, \minerSubsidy,\notcanopy{ and} \foundersReward\canopy{,
|
||
and \fundingStreams} are defined. 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
|
||
|
||
\nusix{
|
||
\vspace{1ex}
|
||
\item $\totalDeferredOutput(\BlockHeight) := \ssum{\fs\, \in\, \FundingStreams \;:\; \fsRecipient(\BlockHeight) \;=\; \DeferredPool}{} \fsValue(\BlockHeight)$
|
||
} %nusix
|
||
|
||
\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 \transparentPtoSHMultisigAddress.
|
||
|
||
\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 \standardRedeemScript hash, as
|
||
specified in \cite{Bitcoin-Multisig}, for the \PtoSHMultisigAddress 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 \standardPtoSHScript 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{-0.5ex}
|
||
Let $\PostBlossomHalvingInterval$ be as defined in \crossref{constants}.
|
||
|
||
Let $\Halving$ be as defined in \crossref{subsidies}.
|
||
|
||
\vspace{1ex}
|
||
The \defining{\fundingStreams} are paid to one of a pre-defined set of recipients, depending
|
||
on the \blockHeight. Each recipient identifier is either the string encoding of an address
|
||
to be paid by an output in the \coinbaseTransaction\nusix{, or the identifier $\DeferredPool$}.
|
||
\nusix{The latter indicates that the value is to be paid to a reserve to be used for development
|
||
funding, the distribution of which is to be determined via a future ZIP.}
|
||
|
||
\introlist
|
||
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 recipients:
|
||
|
||
\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 $\fsRecipients \typecolon \typeexp{\big(\byteseqs\nusix{ \,\union\, \setof{\DeferredPool}}\big)}{\PosInt}$.
|
||
\end{formulae}
|
||
|
||
\introlist
|
||
Define:
|
||
|
||
\begin{formulae}
|
||
\item $\HeightForHalving(\HalvingNum \typecolon \PosInt) :=
|
||
\minimum\Of{\setof{\BlockHeight \typecolon \Nat \suchthat \Halving(\BlockHeight) = \HalvingNum}}$
|
||
\item $\FSRecipientChangeInterval := \PostBlossomHalvingInterval / 48$
|
||
\item $\FSRecipientPeriod(\BlockHeight) :=
|
||
\floor{\hfrac{\BlockHeight - (\HeightForHalving(1) - \PostBlossomHalvingInterval)}{\FSRecipientChangeInterval}}$.
|
||
\end{formulae}
|
||
|
||
\introlist
|
||
For each \fundingStream $\fs$, define:
|
||
|
||
\begin{formulae}
|
||
\item $\fsRecipientIndex(\BlockHeight) := 1 + \FSRecipientPeriod(\BlockHeight) - \FSRecipientPeriod(\fsStartHeight)$
|
||
\item $\fsRecipient(\BlockHeight) := \fsRecipients_{\,\fsRecipientIndex(\BlockHeight)}$
|
||
\item $\fsNumRecipients := \fsRecipientIndex(\fsEndHeight - 1)$.
|
||
\end{formulae}
|
||
|
||
$\fsRecipients$ \MUST be of length $\fsNumRecipients$. Each element of $\fsRecipients$
|
||
\MUST represent either a \transparentPtoSHAddress as specified in \crossref{transparentaddrencoding},
|
||
or a \Sapling \shieldedPaymentAddress as specified in \crossref{saplingpaymentaddrencoding}\nusix{,
|
||
or the identifier $\DeferredPool$}.
|
||
|
||
Recall from \crossref{subsidies} the definition of $\fsValue$. A \fundingStream $\fs$ is
|
||
``active'' at \blockHeight $\BlockHeight$ when $\fsValue(\BlockHeight) > 0$.
|
||
|
||
\introlist
|
||
\consensusrule{
|
||
\canopyonward{In each \block with \coinbaseTransaction $\cb$ at \blockHeight $\BlockHeight$,
|
||
for each \fundingStream $\fs$ active at that \blockHeight with a recipient identifier\nusix{ other than $\DeferredPool$}
|
||
given by $\fsRecipient(\BlockHeight)$, $\cb$ \MUST contain at least one output that pays
|
||
$\fsValue(\BlockHeight)$ \zatoshi in the \prescribedWay to the address represented by that
|
||
recipient identifier.
|
||
|
||
\vspace{1ex}
|
||
\begin{itemize}
|
||
\item The \defining{\prescribedWay} to pay a \transparentPtoSHAddress is to use a
|
||
\defining{\standardPtoSHScript} of the form
|
||
$\ScriptOP{HASH160}$ $\fsRedeemScriptHash(\BlockHeight)\; \ScriptOP{EQUAL}$
|
||
as the $\scriptPubKey$. Here $\fsRedeemScriptHash(\BlockHeight)$ is the
|
||
\standardRedeemScript hash for the recipient address for
|
||
$\fsRecipient(\BlockHeight)$ in \BaseFiftyEightCheck form.
|
||
|
||
\defining{\xStandardRedeemScript} hashes are defined in \cite{Bitcoin-Multisig} for
|
||
\PtoSHMultisigAddresses, or \cite{Bitcoin-P2SH} for other \PtoSHAddresses.
|
||
\vspace{1ex}
|
||
\item The \defining{\prescribedWay} to pay a \Sapling \paymentAddress is defined in
|
||
\cite{ZIP-213}, using the post-\Heartwood consensus rules specified for \Sapling
|
||
outputs of \coinbaseTransactions in \crossref{txnconsensus}.
|
||
\end{itemize}
|
||
} %canopyonward
|
||
} %consensusrule
|
||
|
||
\vspace{-3ex}
|
||
\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} Revision 0 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\_BP} & $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\_BP} & $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
|
||
|
||
\nusix{
|
||
\vspace{1ex}
|
||
\introlist
|
||
\nusixonward{\cite{ZIP-214} Revision 1 defines these \fundingStreams for \Mainnet:}
|
||
|
||
\begin{formulae}
|
||
\item \begin{tabular}{|l|c|c|c|c|}
|
||
\hline
|
||
Stream & Numerator & Denominator & Start height & End height \\\hline\raisedstrut
|
||
\texttt{FS\_FPF\_ZCG} & $8$ & $100$ & $2726400$ & $3146400$ \\
|
||
\texttt{FS\_DEFERRED} & $12$ & $100$ & $2726400$ & $3146400$ \\\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\_FPF\_ZCG} & $8$ & $100$ & $2976000$ & $3396000$ \\
|
||
\texttt{FS\_DEFERRED} & $12$ & $100$ & $2976000$ & $3396000$ \\\hline
|
||
\end{tabular}
|
||
\end{formulae}
|
||
|
||
\pnote{The new funding streams begin at the second halving for Mainnet, but the second
|
||
halving on Testnet occurred prior to the introduction of the new funding streams.
|
||
For both new funding streams on each network, the associated duration corresponds to
|
||
approximately one year's worth of blocks.}
|
||
} %nu6
|
||
|
||
|
||
\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,
|
||
Conrado Gouvêa, Aditya Bharadwaj, Andrew Arnott, Arya, Andrea Kobrlova,
|
||
Lukas Korba, Honza Rychnovský, 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}{}
|
||
|
||
\begin{itemize}
|
||
\nusix{
|
||
\item Clarify \crossref{transactions}, taking into account the \NUSix consensus changes from \cite{ZIP-236}.
|
||
} %nusix
|
||
\item Added dark mode rendering (\url{https://zips.z.cash/protocol/protocol-dark.pdf}).
|
||
\end{itemize}
|
||
|
||
|
||
\historyentry{2024.5.1}{2024-09-26}
|
||
|
||
\begin{itemize}
|
||
\nusix{
|
||
\item Apply \NUSix consensus changes from \cite{ZIP-2001} and \cite{ZIP-236}.
|
||
} %nusix
|
||
\item Collect the definitions of balances for each \chainValuePool into
|
||
\crossref{chainvaluepoolbalances}.
|
||
\item Add a definition of \totalIssuedSupply.
|
||
\item Add acknowledgements to Aditya Bharadwaj, Andrew Arnott, Arya,
|
||
Andrea Kobrlova, Lukas Korba, and Honza Rychnovský for discussions
|
||
on the Zcash protocol.
|
||
\end{itemize}
|
||
|
||
|
||
\historyentry{2024.5.0}{2024-08-28}
|
||
|
||
\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.
|
||
\nufive{
|
||
\item In \crossref{concretesinsemillahash}, declare use of $\LEBStoIP{}$ instead of $\LEOStoIP{}$.
|
||
} %nufive
|
||
\item Add an acknowledgement to Conrado Gouvêa for discussions on the Zcash protocol.
|
||
\item Add boilerplate support for \NUSix.
|
||
\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 \blockChain scanning algorithm 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 \PtoPKHAddresses 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 \PtoSH and \PtoPKH 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 exponentiation, 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}
|