From 977d881064ff4a9ac0130bddbbd77c47188fa7d4 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 26 Feb 2018 09:44:19 +0000 Subject: [PATCH] Work in progress. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 1775 +++++++++++++++++++++++++++-------------- protocol/zcash.bib | 42 +- 2 files changed, 1216 insertions(+), 601 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 327a2269..d29118e1 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -69,7 +69,7 @@ \setlength{\textheight}{9.2in} \setlength{\parindent}{0ex} \renewcommand{\arraystretch}{1.4} -\overfullrule=2cm +%\overfullrule=2cm \setlength{\footnotemargin}{0.6em} \setlength{\footnotesep}{2ex} @@ -117,10 +117,18 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \makeatletter \renewcommand*{\@fnsymbol}[1]{\ensuremath{\ifcase#1\or \dagger\or \ddagger\or \mathsection\or \mathparagraph\else\@ctrerr\fi}} +\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} \makeatother +\titleformat*{\subsection}{\larger\bfseries} +\titleformat*{\subsubsection}{\largeish\bfseries} +\titleformat*{\paragraph}{\notsolarge\bfseries} +\titleformat*{\subparagraph}{\slightlylarge\bfseries} + \renewcommand{\sectionautorefname}{\S\!} \renewcommand{\subsectionautorefname}{\S\!} \renewcommand{\subsubsectionautorefname}{\S\!} @@ -131,6 +139,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % \newcommand{\subsubsubsection}[1]{\paragraph{#1}\mbox{}\\} +\newcommand{\subsubsubsubsection}[1]{\subparagraph{#1}\mbox{}\\} \setcounter{secnumdepth}{4} \setcounter{tocdepth}{4} @@ -139,6 +148,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\nsubsection}[1]{\subsection{\nstrut{#1}}} \newcommand{\nsubsubsection}[1]{\subsubsection{\nstrut{#1}}} \newcommand{\nsubsubsubsection}[1]{\subsubsubsection{\nstrut{#1}}} +\newcommand{\nsubsubsubsubsection}[1]{\subsubsubsubsection{\nstrut{#1}}} \newcommand{\introlist}{\needspace{15ex}} \newcommand{\introsection}{\needspace{35ex}} @@ -146,7 +156,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \mathchardef\mhyphen="2D \newcommand{\lrarrow}{\texorpdfstring{$\leftrightarrow$}{↔}} -\newcommand{\titlemu}{\texorpdfstring{$\upmu$}{μ}} % \DeclareFontFamily{U}{FdSymbolA}{} @@ -166,6 +175,12 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \makeatother \newcommand{\typecolon}{\;\hollowcolon\;} +% +\makeatletter +\newcommand*\bigcdot{\mathpalette\bigcdot@{.5}} +\newcommand*\bigcdot@[2]{\mathbin{\vcenter{\hbox{\scalebox{#2}{$\m@th#1\bullet$}}}}} +\makeatother + % We just want one ampersand symbol from boisik. \DeclareSymbolFont{bskadd}{U}{bskma}{m}{n} \DeclareFontFamily{U}{bskma}{\skewchar\font130 } @@ -263,6 +278,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\dummyNotes}{\term{dummy notes}} \newcommand{\DummyNotes}{\titleterm{Dummy Notes}} \newcommand{\commitmentScheme}{\term{commitment scheme}} +\newcommand{\commitmentSchemes}{\term{commitment schemes}} \newcommand{\commitmentTrapdoor}{\term{commitment trapdoor}} \newcommand{\commitmentTrapdoors}{\term{commitment trapdoors}} \newcommand{\trapdoor}{\term{trapdoor}} @@ -274,6 +290,10 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\noteCommitmentTree}{\term{note commitment tree}} \newcommand{\noteCommitmentTrees}{\term{note commitment trees}} \newcommand{\NoteCommitmentTrees}{\titleterm{Note Commitment Trees}} +\newcommand{\notePosition}{\term{note position}} +\newcommand{\notePositions}{\term{note positions}} +\newcommand{\positionedNote}{\term{positioned note}} +\newcommand{\positionedNotes}{\term{positioned notes}} \newcommand{\noteTraceabilitySet}{\term{note traceability set}} \newcommand{\noteTraceabilitySets}{\term{note traceability sets}} \newcommand{\valueCommitment}{\term{value commitment}} @@ -312,8 +332,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\spendStatements}{\term{Spend statements}} \newcommand{\SpendStatement}{\titleterm{Spend Statement}} \newcommand{\spendProof}{\term{Spend proof}} -\newcommand{\spendAuthorizationSignature}{\term{spend authorization signature}} -\newcommand{\SpendAuthorizationSignature}{\titleterm{Spend Authorization Signature}} +\newcommand{\spendAuthSignature}{\term{spend authorization signature}} +\newcommand{\spendAuthSignatures}{\term{spend authorization signatures}} +\newcommand{\SpendAuthSignature}{\titleterm{Spend Authorization Signature}} \newcommand{\outputDescription}{\term{Output description}} \newcommand{\outputDescriptions}{\term{Output descriptions}} \newcommand{\OutputDescriptions}{\titleterm{Output Descriptions}} @@ -327,10 +348,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\outputProof}{\term{Output proof}} \newcommand{\shieldedOutput}{\term{shielded output}} \newcommand{\shieldedOutputs}{\term{shielded outputs}} -\newcommand{\shieldedOutputsSignature}{\term{shielded outputs signature}} -\newcommand{\ShieldedOutputsSignature}{\titleterm{Shielded Outputs Signature}} -\newcommand{\shieldedOutputsSigningKey}{\term{shielded outputs signing key}} -\newcommand{\shieldedOutputsVerifyingKey}{\term{shielded outputs verifying key}} \newcommand{\statement}{\term{statement}} \newcommand{\ZkSNARKStatements}{\titleterm{Zk-SNARK Statements}} \newcommand{\zeroKnowledgeProof}{\term{zero-knowledge proof}} @@ -406,6 +423,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\blockTime}{\term{block time}} \newcommand{\blockHeight}{\term{block height}} \newcommand{\blockHeights}{\term{block heights}} +\newcommand{\activationHeight}{\term{activation block height}} +\newcommand{\activationHeights}{\term{activation block heights}} \newcommand{\genesisBlock}{\term{genesis block}} \newcommand{\transaction}{\term{transaction}} \newcommand{\transactions}{\term{transactions}} @@ -448,10 +467,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\nullifierSet}{\term{nullifier set}} \newcommand{\nullifierSets}{\term{nullifier sets}} \newcommand{\NullifierSets}{\titleterm{Nullifier Sets}} -\newcommand{\outputUniqueValue}{\term{$\OutputUnique$-value}} -\newcommand{\outputUniqueValues}{\term{$\OutputUnique$-values}} -\newcommand{\outputUniquenessSet}{\term{$\OutputUnique$-uniqueness set}} -\newcommand{\OutputUniquenessSet}{\titleterm{\titlemu-Uniqueness Set}} \newcommand{\paymentAddress}{\term{shielded payment address}} \newcommand{\paymentAddresses}{\term{shielded payment addresses}} \newcommand{\PaymentAddresses}{\titleterm{Shielded Payment Addresses}} @@ -517,6 +532,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\keyDerivationFunctions}{\term{Key Derivation Functions}} \newcommand{\KeyAgreement}{\titleterm{Key Agreement}} \newcommand{\KeyDerivation}{\titleterm{Key Derivation}} +\newcommand{\KeyAgreementAndDerivation}{\titleterm{Key Agreement and Derivation}} \newcommand{\hashFunction}{\term{hash function}} \newcommand{\hashFunctions}{\term{hash functions}} \newcommand{\HashFunction}{\titleterm{Hash Function}} @@ -549,7 +565,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\bytes}[1]{\underline{\raisebox{-0.22ex}{}\smash{#1}}} \newcommand{\zeros}[1]{[0]^{#1}} +\newcommand{\ones}[1]{[1]^{#1}} \newcommand{\bit}{\mathbb{B}} +\newcommand{\byte}{\mathbb{Y}} \newcommand{\Nat}{\mathbb{N}} \newcommand{\PosInt}{\mathbb{N}^+} \newcommand{\Rat}{\mathbb{Q}} @@ -558,11 +576,10 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\typeexp}[2]{{#1}\vphantom{)}^{[{#2}]}} \newcommand{\bitseq}[1]{\typeexp{\bit}{#1}} \newcommand{\bitseqs}{\bitseq{\Nat}} -\newcommand{\byteseq}[1]{\bitseq{8 \mult {#1}}} +\newcommand{\byteseq}[1]{\typeexp{\byte}{#1}} \newcommand{\byteseqs}{\byteseq{\Nat}} \newcommand{\concatbits}{\mathsf{concat}_\bit} \newcommand{\bconcat}{\,||\,} -\newcommand{\drop}[1]{\mathsf{drop}_{#1}} \newcommand{\listcomp}[1]{[~{#1}~]} \newcommand{\fun}[2]{{#1} \mapsto {#2}} \newcommand{\first}{\mathsf{first}} @@ -570,9 +587,11 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\from}{\text{ from }} \newcommand{\upto}{\text{ up to }} \newcommand{\downto}{\text{ down to }} +\newcommand{\tand}{\text{ \;and\, }} \newcommand{\squash}{\!\!\!} \newcommand{\caseif}{\squash\text{if }} \newcommand{\caseotherwise}{\squash\text{otherwise}} +\newcommand{\sidecondition}[1]{\hspace{3em}\left[{#1}\right]} \newcommand{\sorted}{\mathsf{sorted}} \newcommand{\length}{\mathsf{length}} \newcommand{\mean}{\mathsf{mean}} @@ -616,6 +635,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\trunc}[1]{\mathsf{trunc}\!\left({#1}\right)} \newcommand{\ceiling}[1]{\mathsf{ceiling}\left({#1}\right)} \newcommand{\vsum}[2]{\smashoperator[r]{\sum_{#1}^{#2}}} +\newcommand{\vproduct}[2]{\smashoperator[r]{\prod_{#1}^{#2}}} \newcommand{\vxor}[2]{\smashoperator[r]{\bigoplus_{#1}^{#2}}} \newcommand{\xor}{\oplus} \newcommand{\band}{\binampersand} @@ -630,6 +650,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\intersection}{\cap} \newcommand{\difference}{\setminus} \newcommand{\suchthat}{\,\vert\;} +\newcommand{\paramdot}{\bigcdot} \newcommand{\lincomb}[1]{\left(\vphantom{a^q_b}\kern-.025em{#1}\kern-0.04em\right)} \newcommand{\constraint}[3]{\lincomb{#1}\hairspace \times\hairspace \lincomb{#2}\hairspace =\hairspace \lincomb{#3}} @@ -683,6 +704,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\TransmitPublicNew}[1]{\mathsf{pk^{new}_{\enc,\mathnormal{#1}}}} \newcommand{\TransmitPrivate}{\mathsf{sk_{enc}}} \newcommand{\TransmitPrivateSup}[1]{\mathsf{sk}^{#1}_\mathsf{enc}} +\newcommand{\TransmitBase}{\mathsf{g}} % Sapling @@ -698,9 +720,12 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\AuthProvePublic}{\mathsf{rk}} \newcommand{\ValueCommitBase}{\mathcal{V}} \newcommand{\TrapdoorBase}{\mathcal{R}} +\newcommand{\NotePosition}{\mathsf{pos}} +\newcommand{\NotePositionBase}{\mathcal{J}} \newcommand{\NullifierRand}{\mathsf{nr}} \newcommand{\Diversifier}{\mathsf{d}} \newcommand{\DiversifierLength}{\mathsf{\ell_{\Diversifier}}} +\newcommand{\DiversifierType}{\byteseq{\DiversifierLength/8}} \newcommand{\DiversifiedTransmitBase}{\mathsf{g_d}} \newcommand{\DiversifiedTransmitPublic}{\mathsf{pk_d}} \newcommand{\CRHivk}{\mathsf{CRH}^{\InViewingKey}} @@ -754,11 +779,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ValueCommitTrapdoor}{\ValueCommitAlg\mathsf{.Trapdoor}} \newcommand{\ValueCommitInput}{\ValueCommitAlg\mathsf{.Input}} \newcommand{\ValueCommitOutput}{\ValueCommitAlg\mathsf{.Output}} -\newcommand{\UniqueCommitAlg}{\mathsf{UniqueCommit}} -\newcommand{\UniqueCommit}[1]{\UniqueCommitAlg_{#1}} -\newcommand{\UniqueCommitTrapdoor}{\UniqueCommitAlg\mathsf{.Trapdoor}} -\newcommand{\UniqueCommitInput}{\UniqueCommitAlg\mathsf{.Input}} -\newcommand{\UniqueCommitOutput}{\UniqueCommitAlg\mathsf{.Output}} % Symmetric encryption @@ -789,6 +809,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\KAFormatPrivate}{\KA\mathsf{.FormatPrivate}} \newcommand{\KADerivePublic}{\KA\mathsf{.DerivePublic}} \newcommand{\KAAgree}{\KA\mathsf{.Agree}} +\newcommand{\KABase}{\KA\mathsf{.Base}} \newcommand{\KASprout}{\mathsf{\optSprout{KA}}} \newcommand{\KASproutPublic}{\KASprout\mathsf{.Public}} @@ -797,6 +818,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\KASproutFormatPrivate}{\KASprout\mathsf{.FormatPrivate}} \newcommand{\KASproutDerivePublic}{\KASprout\mathsf{.DerivePublic}} \newcommand{\KASproutAgree}{\KASprout\mathsf{.Agree}} +\newcommand{\KASproutBase}{\KASprout\mathsf{.Base}} \newcommand{\KASapling}{\mathsf{KA^{Sapling}}} \newcommand{\KASaplingPublic}{\KASapling\mathsf{.Public}} @@ -823,6 +845,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\Value}{\mathsf{v}} \newcommand{\ValueNew}[1]{\Value^\mathsf{new}_{#1}} \newcommand{\ValueOld}[1]{\Value^\mathsf{old}_{#1}} +\newcommand{\ValueCommitRand}{\mathsf{rcv}} +\newcommand{\ValueCommitRandLength}{\mathsf{\ell_{\ValueCommitRand}}} +\newcommand{\ValueCommitRandNew}[1]{\ValueCommitRand^\mathsf{new}_{#1}} \newcommand{\NoteTuple}[1]{\mathbf{n}_{#1}} \newcommand{\NoteTypeSprout}{\optSprout{\mathsf{Note}}} \newcommand{\NoteTypeSapling}{\mathsf{Note^{Sapling}}} @@ -832,15 +857,15 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\NoteCommitRandOld}[1]{\NoteCommitRand^\mathsf{old}_{#1}} \newcommand{\NoteCommitRandNew}[1]{\NoteCommitRand^\mathsf{new}_{#1}} \newcommand{\NoteAddressRand}{\mathsf{\uprho}} -\newcommand{\NoteAddressRandOldX}[1]{\mathsf{\uprho^{old}_\mathrm{#1}}} \newcommand{\NoteAddressRandOld}[1]{\NoteAddressRand^\mathsf{old}_{#1}} \newcommand{\NoteAddressRandNew}[1]{\NoteAddressRand^\mathsf{new}_{#1}} \newcommand{\NoteAddressPreRand}{\mathsf{\upvarphi}} \newcommand{\NoteAddressPreRandLength}{\mathsf{\ell_{\NoteAddressPreRand}}} -\newcommand{\OutputUnique}{\upmu} \newcommand{\OutputIndex}{\mathsf{idx}} \newcommand{\OutputIndexType}{\mathsf{OutputIndex}} \newcommand{\NoteCommitS}{\mathsf{s}} +\newcommand{\cv}{\mathsf{cv}} +\newcommand{\cvNew}[1]{\cv^\mathsf{new}_{#1}} \newcommand{\cm}{\mathsf{cm}} \newcommand{\cmOld}[1]{\cm^\mathsf{old}_{#1}} \newcommand{\cmNew}[1]{\cm^\mathsf{new}_{#1}} @@ -921,27 +946,16 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\JoinSplitSigSpecific}{\mathsf{Ed25519}} \newcommand{\JoinSplitSigHashName}{\mathsf{SHA\mhyphen512}} -\newcommand{\ShieldedOutputsSig}{\mathsf{ShieldedOutputsSig}} -\newcommand{\ShieldedOutputsSigPublic}{\ShieldedOutputsSig\mathsf{.Public}} -\newcommand{\ShieldedOutputsSigPrivate}{\ShieldedOutputsSig\mathsf{.Private}} -\newcommand{\ShieldedOutputsSigMessage}{\ShieldedOutputsSig\mathsf{.Message}} -\newcommand{\ShieldedOutputsSigSignature}{\ShieldedOutputsSig\mathsf{.Signature}} -\newcommand{\ShieldedOutputsSigGen}{\ShieldedOutputsSig\mathsf{.Gen}} -\newcommand{\ShieldedOutputsSigSign}[1]{\ShieldedOutputsSig\mathsf{.Sign}_{#1}} -\newcommand{\ShieldedOutputsSigVerify}[1]{\ShieldedOutputsSig\mathsf{.Verify}_{#1}} -\newcommand{\ShieldedOutputsSigSpecific}{\mathsf{EdJubjub}} -\newcommand{\ShieldedOutputsSigHashName}{\mathsf{BlakeTwob{512}}} - -\newcommand{\SpendAuthorizationSig}{\mathsf{SpendAuthorizationSig}} -\newcommand{\SpendAuthorizationSigPublic}{\SpendAuthorizationSig\mathsf{.Public}} -\newcommand{\SpendAuthorizationSigPrivate}{\SpendAuthorizationSig\mathsf{.Private}} -\newcommand{\SpendAuthorizationSigMessage}{\SpendAuthorizationSig\mathsf{.Message}} -\newcommand{\SpendAuthorizationSigSignature}{\SpendAuthorizationSig\mathsf{.Signature}} -\newcommand{\SpendAuthorizationSigGen}{\SpendAuthorizationSig\mathsf{.Gen}} -\newcommand{\SpendAuthorizationSigSign}[1]{\SpendAuthorizationSig\mathsf{.Sign}_{#1}} -\newcommand{\SpendAuthorizationSigVerify}[1]{\SpendAuthorizationSig\mathsf{.Verify}_{#1}} -\newcommand{\SpendAuthorizationSigSpecific}{\mathsf{EdJubjub}} -\newcommand{\SpendAuthorizationSigHashName}{\mathsf{BlakeTwob{512}}} +\newcommand{\SpendAuthSig}{\mathsf{SpendAuthSig}} +\newcommand{\SpendAuthSigPublic}{\SpendAuthSig\mathsf{.Public}} +\newcommand{\SpendAuthSigPrivate}{\SpendAuthSig\mathsf{.Private}} +\newcommand{\SpendAuthSigMessage}{\SpendAuthSig\mathsf{.Message}} +\newcommand{\SpendAuthSigSignature}{\SpendAuthSig\mathsf{.Signature}} +\newcommand{\SpendAuthSigGen}{\SpendAuthSig\mathsf{.Gen}} +\newcommand{\SpendAuthSigSign}[1]{\SpendAuthSig\mathsf{.Sign}_{#1}} +\newcommand{\SpendAuthSigVerify}[1]{\SpendAuthSig\mathsf{.Verify}_{#1}} +\newcommand{\SpendAuthSigSpecific}{\mathsf{EdJubjub}} +\newcommand{\SpendAuthSigHashName}{\mathsf{BlakeTwob{512}}} \newcommand{\EdDSAr}{R} \newcommand{\EdDSAs}{S} @@ -971,9 +985,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\MerkleHash}{\bitseq{\MerkleHashLength}} \newcommand{\MerkleHashSprout}{\bitseq{\MerkleHashLengthSprout}} \newcommand{\MerkleHashSapling}{\bitseq{\MerkleHashLengthSapling}} +\newcommand{\MerkleLayer}{\range{0}{\MerkleDepth-1}} +\newcommand{\MerkleLayerSprout}{\range{0}{\MerkleDepthSprout-1}} +\newcommand{\MerkleLayerSapling}{\range{0}{\MerkleDepthSapling-1}} % Transactions +\newcommand{\fOverwintered}{\mathtt{fOverwintered}} \newcommand{\versionField}{\mathtt{version}} \newcommand{\txInCount}{\mathtt{tx\_in\_count}} \newcommand{\txIn}{\mathtt{tx\_in}} @@ -988,9 +1006,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\joinSplitSig}{\mathtt{joinSplitSig}} \newcommand{\joinSplitPrivKey}{\mathtt{joinSplitPrivKey}} \newcommand{\joinSplitPubKey}{\mathtt{joinSplitPubKey}} -\newcommand{\shieldedOutputsSig}{\mathtt{shieldedOutputsSig}} -\newcommand{\shieldedOutputsPrivKey}{\mathtt{shieldedOutputsPrivKey}} -\newcommand{\shieldedOutputsPubKey}{\mathtt{shieldedOutputsPubKey}} \newcommand{\nullifiersField}{\mathtt{nullifiers}} \newcommand{\commitments}{\mathtt{commitments}} \newcommand{\ephemeralKey}{\mathtt{ephemeralKey}} @@ -1001,6 +1016,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\type}[1]{\texttt{#1}} \newcommand{\compactSize}{\type{compactSize uint}} +\newcommand{\spendAuthSig}{\mathtt{spendAuthSig}} + +\newcommand{\sighashTxHashes}{\term{SIGHASH transaction hashes}} \newcommand{\sighashType}{\term{SIGHASH type}} \newcommand{\sighashTypes}{\term{SIGHASH types}} \newcommand{\SIGHASHALL}{\mathsf{SIGHASH\_ALL}} @@ -1018,6 +1036,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\hashPrevBlock}{\mathtt{hashPrevBlock}} \newcommand{\hashMerkleRoot}{\mathtt{hashMerkleRoot}} \newcommand{\hashReserved}{\mathtt{hashReserved}} +\newcommand{\hashFinalSaplingRoot}{\mathtt{hashFinalSaplingRoot}} \newcommand{\nTimeField}{\mathtt{nTime}} \newcommand{\nTime}{\mathsf{nTime}} \newcommand{\nBitsField}{\mathtt{nBits}} @@ -1148,7 +1167,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\GenJ}{\Generator_{\GroupJ}} \newcommand{\ellJ}{\ell_{\GroupJ}} \newcommand{\reprJ}{\repr_{\GroupJ}} +\newcommand{\reprJOf}[1]{\reprJ\!\left({#1}\right)} \newcommand{\abstJ}{\abst_{\GroupJ}} +\newcommand{\abstJOf}[1]{\abstJ\!\left({#1}\right)} \newcommand{\ExtractJ}{\ParamJ{\mathsf{Extract}}} \newcommand{\FindGroupJHash}{\mathsf{FindGroupHash}^\mathbb{J}} \newcommand{\FindGroupJHashOf}[1]{\FindGroupJHash\!\left({#1}\right)} @@ -1161,7 +1182,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\Acc}{\mathsf{Acc}} \newcommand{\Sum}{\mathsf{Sum}} -\newcommand{\uinv}{u_{\mathsf{inv}}} +\newcommand{\ainv}{a_{\mathsf{inv}}} \newcommand{\repr}{\mathsf{repr}} \newcommand{\abst}{\mathsf{abst}} @@ -1176,13 +1197,14 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ECtoOSP}{\mathsf{EC2OSP}} \newcommand{\ECtoOSPXL}{\mathsf{EC2OSP\mhyphen{}XL}} \newcommand{\ECtoOSPXS}{\mathsf{EC2OSP\mhyphen{}XS}} -\newcommand{\ItoOSP}[1]{\mathsf{I2OSP}_{#1}} -\newcommand{\ItoOSPvar}{\mathsf{I2OSP_{var}}} -\newcommand{\ItoBSP}[1]{\mathsf{I2BSP}_{#1}} -\newcommand{\ItoLEBSP}[1]{\mathsf{I2LEBSP}_{#1}} \newcommand{\FEtoIP}{\mathsf{FE2IP}} \newcommand{\FEtoIPP}{\mathsf{FE2IPP}} -\newcommand{\BStoIP}[1]{\mathsf{BS2IP}_{#1}} +\newcommand{\ItoLEBSP}[1]{\mathsf{I2LEBSP}_{#1}} +\newcommand{\ItoBEBSP}[1]{\mathsf{I2BEBSP}_{#1}} +\newcommand{\ItoLEOSPvar}{\mathsf{I2LEOSP_{var}}} +\newcommand{\LEOStoIP}[1]{\mathsf{LEOS2IP}_{#1}} +\newcommand{\LEBStoOSP}[1]{\mathsf{LEBS2OSP}_{#1}} +\newcommand{\LEBStoOSPOf}[2]{\LEBStoOSP{#1}\!\left({#2}\right)} % Sapling circuits @@ -1195,16 +1217,20 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\AffineMontJubjub}{\mathsf{AffineMontJubjub}} \newcommand{\CompressedEdwardsJubjub}{\mathsf{CompressedEdwardsJubjub}} \newcommand{\PedersenHash}{\mathsf{PedersenHash}} -\newcommand{\PedersenBaseAlg}{\mathcal{I}} -\newcommand{\PedersenBase}[2]{\PedersenBaseAlg_{{#1},\,{#2}}} -\newcommand{\PedersenGenAlg}{\mathcal{J}} -\newcommand{\PedersenGen}[2]{\PedersenGenAlg_{{#1},\,{#2}}} +\newcommand{\PedersenGenAlg}{\mathcal{I}} +\newcommand{\PedersenGen}[2]{\PedersenGenAlg^{\kern -0.05em{#1}}_{\kern 0.1em {#2}}} \newcommand{\PedersenEncode}[1]{\langle{#1}\rangle} -\newcommand{\PedersenHashSegment}{\mathsf{PedersenHashSegment}} -\newcommand{\PedersenHashPoint}{\mathsf{PedersenHashPoint}} -\newcommand{\WindowedPedersenCommit}[1]{\mathsf{WindowedPedersenCommit}_{#1}} -\newcommand{\RawPedersenCommit}[1]{\mathsf{RawPedersenCommit}_{#1}} +\newcommand{\PedersenEncodeSub}[2]{\langle{#2}\rangle_{\kern -0.1em {#1}\vphantom{S'}}} +\newcommand{\PedersenEncodeNonneg}[1]{\langle{#1}\rangle^{\PedersenRangeOffset}} +\newcommand{\PedersenHashToPoint}{\mathsf{PedersenHashToPoint}} +\newcommand{\MixingPedersenHash}{\mathsf{MixingPedersenHash}} +\newcommand{\WindowedPedersenCommitAlg}{\mathsf{WindowedPedersenCommit}} +\newcommand{\WindowedPedersenCommit}[1]{\WindowedPedersenCommitAlg_{#1}} +\newcommand{\RawPedersenCommitAlg}{\mathsf{RawPedersenCommit}} +\newcommand{\RawPedersenCommit}[1]{\RawPedersenCommitAlg_{#1}} \newcommand{\Digits}{\mathsf{Digits}} +\newcommand{\PedersenRangeOffset}{\Delta} +\newcommand{\Mask}{\mathsf{Mask}} \newcommand{\abs}{\mathsf{abs}} % Consensus rules @@ -1212,21 +1238,24 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\consensusrule}[1]{\needspace{3ex}\subparagraph{Consensus rule:}{#1}} \newenvironment{consensusrules}{\introlist\subparagraph{Consensus rules:}\begin{itemize}}{\end{itemize}} \newcommand{\sproutonlyitem}[1]{\item \notsprout{[\Sprout only]\,} {#1}} -\newcommand{\saplingonlyitem}[1]{\sapling{\item {[\Sapling only]}\, {#1}}} +\newcommand{\saplingonwarditem}[1]{\sapling{\item {[\Sapling onward]}\, {#1}}} \newcommand{\prenuzeroitem}[1]{\item \notsprout{[Pre-\NUZero\!]\,} {#1}} -\newcommand{\nuzeroonlyitem}[1]{\nuzero{\item {[\NUZero only]}\, {#1}}} +\newcommand{\nuzeroonwarditem}[1]{\nuzero{\item {[\NUZero onward]}\, {#1}}} +\newcommand{\nuzeroonlyitem}[1]{\nuzero{\item {[\NUZero only, pre-\Sapling\!]}\, {#1}}} \newcommand{\sproutonly}[1]{\notsprout{[\Sprout only]\,} {#1}} -\newcommand{\saplingonly}[1]{\sapling{[\Sapling only]\, {#1}}} -\newcommand{\prenuzero}[1]{\notsprout{[Pre-\NUZero]\,} {#1}} -\newcommand{\nuzeroonly}[1]{\nuzero{[\NUZero only]\, {#1}}} +\newcommand{\saplingonward}[1]{\sapling{[\Sapling onward]\, {#1}}} +\newcommand{\prenuzero}[1]{\notsprout{[Pre-\NUZero\!]\,} {#1}} +\newcommand{\nuzeroonward}[1]{\nuzero{[\NUZero onward]\, {#1}}} +\newcommand{\nuzeroonly}[1]{\nuzero{[\NUZero only, pre-\Sapling\!]\, {#1}}} \newcommand{\securityrequirement}[1]{\needspace{3ex}\subparagraph{Security requirement:}{#1}} \newenvironment{securityrequirements}{\introlist\subparagraph{Security requirements:}\begin{itemize}}{\end{itemize}} \newcommand{\pnote}[1]{\subparagraph{Note:}{#1}} \newenvironment{pnotes}{\introlist\subparagraph{Notes:}\begin{itemize}}{\end{itemize}} \newcommand{\sproutonlypnote}[1]{\notsprout{[\Sprout only]\,\,} \textbf{Note:\,} {#1}} -\newcommand{\prenuzeropnote}[1]{\notsprout{[Pre-\NUZero]\,\,} \textbf{Note:\,} {#1}} -\newcommand{\nuzeroonlypnote}[1]{\nuzero{[\NUZero only]\,\,} \textbf{Note:\,} {#1}} +\newcommand{\prenuzeropnote}[1]{\notsprout{[Pre-\NUZero\!]\,\,} \textbf{Note:\,} {#1}} +\newcommand{\nuzeroonwardpnote}[1]{\nuzero{[\NUZero onward]\,\,} \textbf{Note:\,} {#1}} +\newcommand{\nuzeroonlypnote}[1]{\nuzero{[\NUZero only, pre-\Sapling\!]\,\,} \textbf{Note:\,} {#1}} \newcommand{\fact}[1]{\subparagraph{Fact:}{#1}} \newcommand{\facts}[1]{\subparagraph{Facts:}{#1}} @@ -1258,9 +1287,9 @@ memory-hard proof-of-work algorithm. \vspace{1.5ex} \sprout{\noindent This specification defines the \Zcash consensus protocol and explains its differences from \Zerocash and \Bitcoin.} -\sapling{\noindent This \em{draft} specification defines the next minor -version of the \Zcash consensus protocol, codenamed \NUZero, and the -subsequent major version, codenamed \Sapling. It is a work in progress +\sapling{\noindent This \em{draft} specification defines the next +upgrade of the \Zcash consensus protocol, codenamed \NUZero, and the +subsequent upgrade, codenamed \Sapling. It is a work in progress and should not be used as a reference for the current protocol.} \vspace{2.5ex} @@ -1379,6 +1408,7 @@ It is infeasible to correlate the \noteCommitment with the corresponding 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. +\notsprout{\todo{The ``1:1:1'' part isn't correct for \Sapling.}} \introlist A \transaction can contain \transparent inputs, outputs, and scripts, which all @@ -1430,7 +1460,7 @@ that all of the following hold except with negligable probability: For each \shieldedInput, \begin{itemize} - \item \saplingonly{there is a revealed \valueCommitment to the same value as + \item \saplingonward{there is a revealed \valueCommitment to the same value as the input \note;} \item some revealed \noteCommitment exists for the input \note; \item the prover knew the \authProvingKey of the input \note; @@ -1440,7 +1470,7 @@ For each \shieldedInput, and for each \shieldedOutput, \begin{itemize} - \item \saplingonly{there is a revealed \valueCommitment to the same value as + \item \saplingonward{there is a revealed \valueCommitment to the same value as the output \note;} \item the \noteCommitment is computed correctly; \item the output \note is generated in such a way that it is infeasible to @@ -1490,6 +1520,8 @@ one valid \nullifier, and so attempting to spend a \note twice would reveal the $\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. $\Rat$ means the type of rationals. @@ -1517,7 +1549,10 @@ The types $T$ and $U$ are always explicit. $\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. +$\bitseq{\ell}$ means the set of sequences of $\ell$ bits, and +$\byteseq{k}$ means the set of seqences of $k$ bytes. + +$\byteseqs$ means the type of byte sequences of arbitrary length. $\length(S)$ means the length of (number of elements in) $S$. @@ -1538,9 +1573,6 @@ $S \difference T$ means the set difference obtained by removing elements in $T$ from $S$, i.e. $\setof{x \typecolon S \suchthat x \neq T}$. } -$\byteseqs$ means the type of bit sequences constrained to be of length -a multiple of 8 bits. - $\hexint{}$ followed by a string of $\mathtt{monospace}$ hexadecimal digits means the corresponding integer converted from hexadecimal. @@ -1549,6 +1581,7 @@ sequence of bytes in US-ASCII. For example, $\ascii{abc}$ represents the byte sequence $[\hexint{61}, \hexint{62}, \hexint{63}]$. $\zeros{\ell}$ means the sequence of $\ell$ zero bits. +\notsprout{$\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, @@ -1575,13 +1608,6 @@ concatenating the elements of $S$ viewed as bit sequences. If the elements of $S$ are byte sequences, they are converted to bit sequences with the \emph{most significant} bit of each byte first. -\notsprout{ -$\drop{\ell}(S)$ means the sequence of bits obtained by -discarding the first $\ell$ bits of $S$ and taking the remaining bits -in the original order. If $S$ is a byte sequence, it is converted to -a bit sequence with the \emph{most significant} bit of each byte first. -} - $\sorted(S)$ means the sequence formed by sorting the elements of $S$. @@ -1605,6 +1631,8 @@ and $a \band b$ means the bitwise-and of $a$ and $b$. These are defined on integers or bit sequences according to context. $\vsum{i=1}{\mathrm{N}} a_i$ means the sum of $a_{\allN{}}$.\; +\notsprout{$\vproduct{i=1}{\mathrm{N}} a_i$ means the product +of $a_{\allN{}}$.\;} $\vxor{i=1}{\mathrm{N}} a_i$ means the bitwise exclusive-or of $a_{\allN{}}$. \notsprout{ @@ -1625,13 +1653,15 @@ The symbol $\bot$ is used to indicate unavailable information, or a failed decryption or validity check. The following integer constants will be instantiated in \crossref{constants}: -$\MerkleDepthSprout$, \sapling{$\MerkleDepthSapling$,} $\NOld$, $\NNew$, -$\MerkleHashLengthSprout$, \sapling{$\MerkleHashLengthSapling$,} $\hSigLength$, -$\PRFOutputLength$, \sapling{$\PRGOutputLength$,} $\NoteCommitRandLength$, -$\RandomSeedLength$, $\AuthPrivateLength$, \sapling{$\AuthPrivateSeedLength$,} -$\NoteAddressPreRandLength$, $\MAXMONEY$, $\SlowStartInterval$, $\HalvingInterval$, -$\MaxBlockSubsidy$, $\NumFounderAddresses$, $\PoWLimit$, $\PoWAveragingWindow$, -$\PoWMedianBlockSpan$, $\PoWDampingFactor$, $\PoWTargetSpacing$. +\notsprout{\begin{formulae} \item} + $\MerkleDepthSprout$, \sapling{$\MerkleDepthSapling$,} + $\NOld$, $\NNew$, $\MerkleHashLengthSprout$, \sapling{$\MerkleHashLengthSapling$,} + $\hSigLength$, $\PRFOutputLength$, \sapling{$\PRGOutputLength$,} $\NoteCommitRandLength$, + $\RandomSeedLength$, $\AuthPrivateLength$, \sapling{$\AuthPrivateSeedLength$, $\DiversifierLength$,} + $\NoteAddressPreRandLength$, $\MAXMONEY$, $\SlowStartInterval$, $\HalvingInterval$, + $\MaxBlockSubsidy$, $\NumFounderAddresses$, $\PoWAveragingWindow$, $\PoWLimit$, + $\PoWMedianBlockSpan$, $\PoWDampingFactor$, $\PoWTargetSpacing$. +\notsprout{\end{formulae}} \sprout{The bit sequence constant $\UncommittedSprout \typecolon \bitseq{\MerkleHashLengthSprout}$,} \notsprout{The bit sequence constants $\UncommittedSprout \typecolon \bitseq{\MerkleHashLengthSprout}$ @@ -1640,6 +1670,7 @@ and rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$ will also be defined in that section. +\introsection \nsection{Concepts} \nsubsection{Payment Addresses and Keys} \label{addressesandkeys} @@ -1667,7 +1698,7 @@ $\PaymentAddress = (\AuthPublic, \TransmitPublic)$ are derived from $\AuthPrivate$, as described in \crossref{sproutkeycomponents}. } -\saplingonly{ +\saplingonward{ The \authSigningKey $\AuthSignPrivate$, the \authProvingKey $(\AuthSignPublic, \AuthProvePrivate)$, the \fullViewingKey $(\AuthSignPublic, \AuthProvePublic)$, @@ -1691,7 +1722,7 @@ paying parties. \emph{However} if two parties collude to compare a case that a payee wishes to prevent this they should create a distinct \paymentAddress for each payer. -\saplingonly{ +\saplingonward{ \Sapling provides a mechanism to allow the efficient creation of \diversifiedPaymentAddresses with the same spending authority. A group of such addresses shares the same \fullViewingKey and \incomingViewingKey, and @@ -1741,7 +1772,7 @@ A \SproutOrNothing \note is a tuple $\changed{(\AuthPublic, is used as input to $\PRFnf{\AuthPrivate}$ to derive the \nullifier of the \note; \item $\NoteCommitRand \typecolon \NoteCommitSproutTrapdoor$ - is a random \commitmentTrapdoor as defined in \crossref{abstractcomm}. + is a random \commitmentTrapdoor as defined in \crossref{abstractcommit}. \end{itemize} Let $\NoteTypeSprout$ be the type of a \SproutOrNothing \note, @@ -1751,31 +1782,29 @@ i.e.\ \changed{$\PRFOutput \times \range{0}{\MAXMONEY} \times \PRFOutput \sapling{ \vspace{2ex} A \Sapling \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, -\Value, \NoteAddressRand, \NoteCommitRand)$, where: +\Value, \NoteCommitRand)$, where: \begin{itemize} - \item $\Diversifier \typecolon \bitseq{\DiversifierLength}$ + \item $\Diversifier \typecolon \DiversifierType$ is the \diversifier of the recipient's \paymentAddress; \item $\DiversifiedTransmitPublic \typecolon \bitseq{\ellJ}$ is the \diversifiedTransmissionKey of the recipient's \paymentAddress; \item $\Value \typecolon \range{0}{\MAXMONEY}$ is an integer representing the value of the \note in \zatoshi; - \item $\NoteAddressRand \typecolon \bitseq{\ellJ}$ - is used as input to $\PRFnr{\AuthProvePublic}$ as part of deriving the - \nullifier of the \note; \item $\NoteCommitRand \typecolon \NoteCommitSaplingTrapdoor$ - is a random \commitmentTrapdoor as defined in \crossref{abstractcomm}. + is a random \commitmentTrapdoor as defined in \crossref{abstractcommit}. \end{itemize} Let $\NoteTypeSapling$ be the type of a \Sapling \note, -i.e.\ $\bitseq{\DiversifierLength} \times \bitseq{\ellJ} \times \range{0}{\MAXMONEY} +i.e.\ $\DiversifierType \times \bitseq{\ellJ} \times \range{0}{\MAXMONEY} \times \bitseq{\ellJ} \times \NoteCommitSaplingTrapdoor$. } Creation of new \notes is described in \crossref{send}. When \notes are sent, -only a commitment (see \crossref{abstractcomm}) to the above values is disclosed -publically. This allows the value and recipient to be kept private, while the -commitment is used by the \zeroKnowledgeProof when the \note is spent, to check -that it exists on the \blockchain. +only a commitment (see \crossref{abstractcommit}) to the above values is disclosed +publically, and added to a data structure called the \noteCommitmentTree. +This allows the value and recipient to be kept private, while the commitment is +used by the \zeroKnowledgeProof when the \note is spent, to check that it exists +on the \blockchain. \vspace{2ex} A \notsprout{\Sprout} \noteCommitment is computed as @@ -1784,36 +1813,38 @@ A \notsprout{\Sprout} \noteCommitment is computed as \NoteCommitSprout{\NoteCommitRand}(\AuthPublic, \Value, \NoteAddressRand)$, \end{formulae} \vspace{-1.5ex} -where $\NoteCommitSprout{}$ is instantiated in \crossref{concretecomm}. +where $\NoteCommitSprout{}$ is instantiated in \crossref{concretesproutcommit}. \sapling{ \vspace{2ex} +Let $\GroupJHash{}$ and $U$ be as defined in \crossref{concretegrouphashjubjub}. + A \Sapling \noteCommitment is computed as -\begin{formulae} - \item $\NoteCommitmentSapling(\NoteTuple{}) = - \NoteCommitSapling{\NoteCommitRand}(\Diversifier, \DiversifiedTransmitPublic, - \Value, \NoteAddressRand)$, -\end{formulae} -\vspace{-1.5ex} -where $\NoteCommitSapling{}$ is instantiated in \crossref{concretecomm}. +\begin{tabular}{@{\hskip 2em}r@{\;}l} + $\DiversifiedTransmitBase$ &$:= \GroupJHash{U}(\ascii{Zcash\_gd}, \Diversifier)$ \\ + $\NoteCommitmentSapling(\NoteTuple{})$ &$:= + \NoteCommitSapling{\NoteCommitRand}(\reprJ{\DiversifiedTransmitBase}, \DiversifiedTransmitPublic, \Value)$ +\end{tabular} +\vspace{-1ex} +where $\NoteCommitSapling{}$ is instantiated in \crossref{concretewindowedcommit}. + +Notice that the above definition of a \Sapling \note does not have a +$\NoteAddressRand$ field. There is in fact a $\NoteAddressRand$ value associated +with each \Sapling \note, but this only be computed once its position in the +\noteCommitmentTree is known (see \crossref{blockchain} and \crossref{transactions}). +We refer to the combination of a \note and its \notePosition $\NotePosition$, as a +\positionedNote. + +For a \positionedNote, we can compute the value +$\NoteAddressRand \typecolon \bitseq{\ellJ}$ as described in \crossref{commitmentsandnullifiers}. } \vspace{2ex} -A \nullifier (denoted $\nf$) is derived from the $\NoteAddressRand$ component +A \nullifier (denoted $\nf$) is derived from the $\NoteAddressRand$ value of a \note and the recipient's \spendingKey $\AuthPrivate$\sapling{ or \fullViewingKey $(\AuthSignPublic, \AuthProvePublic)$}, -using a \pseudoRandomFunction (see \crossref{abstractprfs}). - -\sprout{Specifically}\notsprout{For a \Sprout \note,} -it is derived as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$ -where $\PRFnf{}{}$ is instantiated in \crossref{concreteprfs}. - -% TODO: \scalarmults should only be in the concrete section -\sapling{ -For a \Sapling \note, it is derived as -$\scalarmult{\PRFnr{\AuthProvePublic}(\NoteAddressRand)}{\scalarmult{8}{\AuthSignPublic}}$ -where $\PRFnr{}{}$ is instantiated in \crossref{concreteprfs}. -} +using a \pseudoRandomFunction (see \crossref{abstractprfs}). This computation +is described in \crossref{commitmentsandnullifiers}. A \note is spent by proving knowledge of $\NoteAddressRand$ and $\AuthPrivate$\sapling{ or $(\AuthSignPrivate, \AuthProvePrivate)$} @@ -1831,11 +1862,11 @@ respective \transmissionKeys $\TransmitPublicNew{\allNew}$. Each \notsprout{\Sprout} \notePlaintext (denoted $\NotePlaintext{}$) consists of $(\Value, \NoteAddressRand, \NoteCommitRand\changed{, \Memo})$. -\saplingonly{ +\saplingonward{ The \notePlaintext in each \outputDescription is encrypted to the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$. Each \Sapling \notePlaintext (denoted $\NotePlaintext{}$) consists of -$(\Diversifier, \Value, \NoteAddressRand, \NoteCommitRand, \Memo)$. +$(\Diversifier, \Value, \NoteCommitRand, \Memo)$. } \changed{ @@ -1866,8 +1897,8 @@ Each \block in a \blockchain has a \blockHeight. The \blockHeight of the In order to choose the \bestValidBlockchain in its view of the overall \block tree, a node sums the work, as defined in \crossref{workdef}, of -all \blocks in each chain, and considers the chain with greatest total work -to be best. To break ties between leaf \blocks, a node will prefer the +all \blocks in each chain, 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, @@ -1891,23 +1922,14 @@ The remaining value in the \transparentValuePool{} \MUST be nonnegative. \sprout{To each \transaction there is associated an initial \treestate.} \notsprout{To each \transaction there are associated initial \treestates -for \Sprout and for \Sapling.} +for \Sprout\sapling{ and for \Sapling}.} -A \SproutOrNothing \treestate consists of: +\sprout{A}\sapling{Each} \treestate consists of: \begin{itemize} \item a \noteCommitmentTree (\crossref{merkletree}); \item a \nullifierSet (\crossref{nullifierset}). \end{itemize} -\saplingonly{ -A \Sapling \treestate consists of: -\begin{itemize} - \item another \noteCommitmentTree; - \item another \nullifierSet; - \item a \outputUniquenessSet (\crossref{outputuniqueset}). -\end{itemize} -} - Validation state associated with \transparentTransfers, such as the UTXO (Unspent Transaction Output) set, is not described in this document; it is used in essentially the same way as in \Bitcoin. @@ -1917,7 +1939,7 @@ An \anchor is a Merkle tree root of a \noteCommitmentTree\sapling{ (either the 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\sapling{ and, in the case of \Sapling, \outputUniquenessSet}. +\nullifierSet. \introlist In a given \blockchain, \sapling{for each of \Sprout and \Sapling,} @@ -2069,7 +2091,7 @@ is denoted $\MerkleNode{h}{i}$. Each \fullValidator maintains a \nullifierSet logically associated with each \treestate. As valid \transactions containing \joinSplitTransfers \sapling{ or \spendTransfers} are processed, the \nullifiers revealed in \joinSplitDescriptions \sapling{ and \spendDescriptions} -are inserted into this \nullifierSet. +are inserted into the \nullifierSet associated with the new \treestate. \xNullifiers are enforced to be unique within a \validBlockchain, in order to prevent double-spends. @@ -2081,31 +2103,9 @@ A \nullifier{} \MUSTNOT repeat either within a \transaction, or across \sapling{\pnote{ \Sprout and \Sapling \nullifiers are considered disjoint, even if they have -the same bit pattern. As a result there are two \nullifierSets, one -for \Sprout and one for \Sapling. +the same bit pattern. }} -\sapling{ -\nsubsection{\OutputUniquenessSet} \label{outputuniqueset} - -For \Sapling, there is also a set of \outputUniqueValues, called the -\outputUniquenessSet. When a valid \transaction containing one or more -\outputTransfers is processed, the \outputUniqueValue revealed in the -\transaction is inserted into this set. - -Like \nullifiers, \outputUniqueValues are enforced to be unique within a -\validBlockchain. This is needed to prevent Faerie Gold attacks on \Sapling -transactions (\crossref{faeriegold}). - -\consensusrule{ -A \outputUniqueValue{} \MUSTNOT repeat across \transactions in a \validBlockchain. -} - -\pnote{ -Since there is at most one \outputUniqueValue revealed by a \transaction, -repetition of \outputUniqueValues within a \transaction is not an issue. -} -} \nsubsection{Block Subsidy and Founders' Reward} \label{subsidyconcepts} @@ -2133,9 +2133,21 @@ as described in \crossref{foundersreward}. \nsubsubsection{\HashFunctions} \label{abstracthashes} -$\MerkleCRH \typecolon \MerkleHash \times \MerkleHash \rightarrow \MerkleHash$ +\sprout{ +$\MerkleCRH \typecolon \MerkleHashSprout \times \MerkleHashSprout \rightarrow \MerkleHashSprout$ is a collision-resistant \hashFunction used in \crossref{merklepath}. It is instantiated in \crossref{merklecrh}. +} +\notsprout{ +The functions $\MerkleCRHSprout \typecolon \MerkleLayerSprout \times \MerkleHashSprout \times \MerkleHashSprout +\rightarrow \MerkleHashSprout$ +\sapling{and (for \Sapling), +$\MerkleCRHSapling \typecolon \MerkleLayerSapling \times \MerkleHashSapling \times \MerkleHashSapling +\rightarrow \MerkleHashSapling$ +} +are collision-resistant \hashFunctions used in \crossref{merklepath}. +Both of these functions are instantiated in \crossref{merklecrh}. +} \changed{ $\hSigCRH{} \typecolon \bitseq{\RandomSeedLength} \times \typeexp{\PRFOutput}{\NOld} \times \JoinSplitSigPublic \rightarrow \hSigType$ @@ -2217,6 +2229,7 @@ Security definitions for \pseudoRandomGenerators are given in \cite[section 1.2] } +\introsection \nsubsubsection{\SymmetricEncryption} \label{abstractsym} Let $\Sym$ be an \symmetricEncryptionScheme with keyspace $\Keyspace$, encrypting @@ -2250,12 +2263,15 @@ of private keys $\KAPrivate$, and a type of shared secrets $\KASharedSecret$. Let $\KAFormatPrivate \typecolon \PRFOutput \rightarrow \KAPrivate$ be a function that converts a bit string of length $\PRFOutputLength$ to a $\KA$ private key. -Let $\KADerivePublic \typecolon \KAPrivate \rightarrow \KAPublic$ be a function -that derives the $\KA$ public key corresponding to a given $\KA$ private key. +Let $\KADerivePublic \typecolon \KAPrivate \times \KAPublic \rightarrow \KAPublic$ +be a function that derives the $\KA$ public key corresponding to a given $\KA$ +private key 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$. } @@ -2288,14 +2304,17 @@ for $\SymEncrypt{}$. In addition to adaptive security of the key agreement and KDF, the following security property is required: -\sapling{ +\notsprout{ \todo{adapt this definition to handle \Sapling, or maybe just remove it.} + +Let $\TransmitBase := \todo{?}$ } +\sprout{Let $\TransmitBase := \KABase$.} Let $\TransmitPrivateSup{1}$ and $\TransmitPrivateSup{2}$ each be chosen uniformly and independently at random from $\KAPrivate$. -Let $\TransmitPublicSup{j} := \KADerivePublic(\TransmitPrivateSup{j})$. +Let $\TransmitPublicSup{j} := \KADerivePublic(\TransmitPrivateSup{j}, \TransmitBase)$. \introlist An adversary can adaptively query a function @@ -2303,7 +2322,7 @@ $Q \typecolon \range{1}{2} \times \hSigType \rightarrow \KAPublic \times \Keyspace_{\allNew}$ where $Q_j(\hSig)$ is defined as follows: \begin{enumerate} \item Choose $\EphemeralPrivate$ uniformly at random from $\KAPrivate$. - \item Let $\EphemeralPublic := \KADerivePublic(\EphemeralPrivate)$. + \item Let $\EphemeralPublic := \KADerivePublic(\EphemeralPrivate, \TransmitBase)$. \item For $i \in \setofNew$, let $\Key_i := \KDF(i, \hSig, \KAAgree(\EphemeralPrivate, \TransmitPublicSup{j}), \EphemeralPublic, \TransmitPublicSup{j}))$. \item Return $(\EphemeralPublic, \Key_{\allNew})$. @@ -2345,36 +2364,24 @@ such that for any key pair $(\sk, \vk) \leftarrowR \SigGen()$, and any $m \typecolon \SigMessage$ and $s \typecolon \SigSignature \leftarrowR \SigSign{\sk}(m)$, $\SigVerify{\vk}(m, s) = 1$. -\sprout{ -\Zcash uses two signature schemes, one used for signatures that can be verified -by script operations such as \ScriptOP{CHECKSIG} and \ScriptOP{CHECKMULTISIG} as -in \Bitcoin, and one called $\JoinSplitSig$ which is used to sign \transactions -that contain at least one \joinSplitDescription. The latter is instantiated in -\crossref{concretesig}. The following defines only the security properties needed -for $\JoinSplitSig$. -} -\notsprout{ -\Zcash uses three signature schemes: +\Zcash uses \sprout{two}\sapling{three} signature schemes: \begin{itemize} \item one used for signatures that can be verified by script operations such as \ScriptOP{CHECKSIG} and \ScriptOP{CHECKMULTISIG} as in \Bitcoin; - \item one called $\JoinSplitSig$ (instantiated in \crossref{concretesig}), + \item one called $\JoinSplitSig$ (instantiated in \crossref{concretejssig}), which is used to sign \transactions that contain at least one - \joinSplitDescription; -\sapling{ - \item \saplingonly{one called $\ShieldedOutputsSigSpecific$ (instantiated in \crossref{concretesig}), - which is used to sign authorizations of \spendDescriptions, and in - \transactions that contain at least one \outputDescription.} -} + \joinSplitDescription\sprout{.}\notsprout{;} + \saplingonwarditem{one called $\SpendAuthSig$ (instantiated + in \crossref{concretespendauthsig}), which is used to sign authorizations of + \spendDescriptions.} \end{itemize} The following defines only the security properties needed -for $\JoinSplitSig$\sapling{ and $\ShieldedOutputsSigSpecific$}. -} +for $\JoinSplitSig$\sapling{ and $\SpendAuthSig$}. \securityrequirement{ -$\JoinSplitSig$\sapling{ and $\ShieldedOutputsSigSpecific$} must be +$\JoinSplitSig$\sapling{ and $\SpendAuthSig$} must be Strongly Unforgeable under (non-adaptive) Chosen Message Attack (SU-CMA), as defined for example in \cite[Definition 6]{BDEHR2011}. This allows an adversary to obtain signatures on chosen messages, and then requires it to be infeasible @@ -2383,23 +2390,25 @@ pair without access to the signing key. } \begin{pnotes} - \item Since a fresh key pair is generated for every \transaction containing - a \joinSplitDescription and is only used for one signature (see - \crossref{nonmalleability}), a one-time signature scheme 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. + \item A fresh signature key pair is generated for each \transaction containing + a \joinSplitDescription\sapling{, and for each \spendDescription}. + Since each key pair is only used for one signature (see \crossref{nonmalleability}), + a one-time signature scheme would suffice for $\JoinSplitSig$\sapling{ and $\SpendAuthSig$}. + This is also the reason why only security against \emph{non-adaptive} + chosen message attack is needed. + In fact the instantiation of $\JoinSplitSig$ + \sprout{uses a scheme}\sapling{and $\SpendAuthSig$ use schemes} + designed for security under adaptive attack even when multiple signatures + are signed under the same key. \item SU-CMA security requires it to be infeasible for the adversary, not knowing the private key, to forge a distinct signature on a previously - seen message. That is, \joinSplitSignatures are intended to be - nonmalleable in the sense of \cite{BIP-62}. + seen message. That is, \joinSplitSignatures\sapling{ and \spendAuthSignatures} + are intended to be nonmalleable in the sense of \cite{BIP-62}. \end{pnotes} \introlist -\nsubsubsection{Commitment} \label{abstractcomm} +\nsubsubsection{Commitment} \label{abstractcommit} A \commitmentScheme is a function that, given a random \commitmentTrapdoor and an input, can be used to commit to the input in such a way that: @@ -2429,6 +2438,13 @@ be a function satisfying the security requirements below. such that $x \neq x'$ and $\Commit{r}(x) = \Commit{r'}(x')$. \end{securityrequirements} +\pnote{ +If it were 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 by itself contradict +the computational binding security requirement. +} + \introsection \nsubsubsection{\RepresentedGroup} \label{abstractgroup} @@ -2486,7 +2502,11 @@ efficiently computable left inverse. Given a represented group $\GroupG{}$ and a type $\CRSType$, we define a \term{family of group hashes into\, $\GroupG{}$} as a function -$\GroupGHash{} \typecolon \CRSType \times \bitseq{\ell} \rightarrow \GroupG{}$ + +\begin{formulae} + \item $\GroupGHash{} \typecolon \CRSType \times \bitseq{\ell} \rightarrow \GroupG{}$ +\end{formulae} +\vspace{-1ex} with the following security requirement. \begin{securityrequirements} @@ -2660,7 +2680,7 @@ Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concretep Let $\KASprout$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}. -A new \SproutOrNothing \spendingKey $\AuthPrivate$ is generated by choosing a bit string +A new \SproutOrNothing \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence uniformly at random from $\bitseq{\AuthPrivateLength}$. \introlist @@ -2672,7 +2692,7 @@ as follows:} \begin{tabular}{@{\hskip 2em}r@{\;}l} $\AuthPublic$ &$:= \changed{\PRFaddr{\AuthPrivate}(0)}$ \\ $\TransmitPrivate$ &$:= \changed{\KASproutFormatPrivate(\PRFaddr{\AuthPrivate}(1))}$ \\ - $\TransmitPublic$ &$:= \changed{\KASproutDerivePublic(\TransmitPrivate)}$. + $\TransmitPublic$ &$:= \changed{\KASproutDerivePublic(\TransmitPrivate, \KASproutBase)}$. \end{tabular} \sapling{ @@ -2684,23 +2704,19 @@ Let $\KASapling$ be a \keyAgreementScheme, instantiated in \crossref{concretesap Let $\CRHivk$ be a \hashFunction, instantiated in \crossref{concretecrhivk}. -Let $\GroupJHash{U}$ be a \term{hash into the group of the $\JubjubCurve$ curve}, -instantiated in \crossref{concretegh}. +Let $\FindGroupJHash{U}$ be as defined in \crossref{concretegrouphashjubjub}. -Let $\AuthSignBase = \GroupJHash{U}(\ascii{Zcash\_G\_}, \ascii{})$ and -let $\AuthProveBase = \GroupJHash{U}(\ascii{Zcash\_H\_}, \ascii{})$. - -\todo{The second inputs to $\GroupJHash{}$ need to be chosen to produce valid points.} +Let $\AuthSignBase = \FindGroupJHashOf{\ascii{Zcash\_G\_}, \ascii{}}$ and +let $\AuthProveBase = \FindGroupJHashOf{\ascii{Zcash\_H\_}, \ascii{}}$. Let $\reprJ$ be the representation function for the $\JubjubCurve$ \representedGroup, instantiated in \crossref{jubjub}. -Define $\BStoIP{} \typecolon (u \typecolon \Nat) \times \bitseq{u} \rightarrow \range{0}{2^u\!-\!1}$ -such that $\BStoIP{u}(S)$ is the integer represented in big-endian order by the -bit sequence $S$ of length $u$. +Let $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\ceiling{\ell/8}}$ +be defined as in \crossref{endian}. \vspace{2ex} -A new \Sapling \spendingKey $\AuthPrivateSeed$ is generated by choosing a bit string +A new \Sapling \spendingKey $\AuthPrivateSeed$ is generated by choosing a bit sequence uniformly at random from $\bitseq{\AuthPrivateSeedLength}$. This is expanded using $\PRGExpandSeed{}$ to a $512$-bit \expandedSeed, @@ -2712,7 +2728,7 @@ $\PreAuthProvePrivate \typecolon \range{0}{2^{256}-1}$: \newsavebox{\expandedseedbox} \begin{lrbox}{\expandedseedbox} -\begin{bytefield}[bitwidth=0.04em]{512} +\begin{bytefield}[bitwidth=0.06em]{512} \sapling{ \bitbox{256}{$256$-bit $\PreAuthSignPrivate$} & \bitbox{256}{$256$-bit $\PreAuthProvePrivate$} @@ -2722,10 +2738,10 @@ $\PreAuthProvePrivate \typecolon \range{0}{2^{256}-1}$: \newsavebox{\crhivkinputbox} \begin{lrbox}{\crhivkinputbox} -\begin{bytefield}[bitwidth=0.04em]{512} +\begin{bytefield}[bitwidth=0.06em]{512} \sapling{ - \bitbox{256}{$256$-bit $\reprJ(\AuthSignPublic)$} & - \bitbox{256}{$256$-bit $\reprJ(\AuthProvePublic)$} + \bitbox{256}{$256$-bit $\LEBStoOSPOf{256}{\reprJOf{\AuthSignPublic}}$} & + \bitbox{256}{$256$-bit $\LEBStoOSPOf{256}{\reprJOf{\AuthProvePublic}}$} } \end{bytefield} \end{lrbox} @@ -2735,6 +2751,9 @@ $\PreAuthProvePrivate \typecolon \range{0}{2^{256}-1}$: \item $\Justthebox{\expandedseedbox} := \PRGExpandSeed{\AuthPrivateSeed}()$ \\ \end{formulae} +\todo{Check byte and bit order. Also, we shouldn't use bit layout diagrams in +the abstract protocol; they are only defined in \crossref{endian}.} + \introlist $\AuthSignPrivate$, $\AuthProvePrivate$, $\AuthSignPublic$, $\AuthProvePublic$, and $\InViewingKey$ are then derived as follows: @@ -2744,7 +2763,7 @@ and $\InViewingKey$ are then derived as follows: $\AuthProvePrivate$ &$:= \PreAuthProvePrivate \bmod \JubjubScalarThreshold$ \\ $\AuthSignPublic$ &$:= \scalarmult{\AuthSignPrivate}{\AuthSignBase}$ \\ $\AuthProvePublic$ &$:= \scalarmult{\AuthProvePrivate}{\AuthProveBase}$ \\ - $\InViewingKey$ &$:= \BStoIP{251}(\CRHivkBox{\crhivkinputbox})$. + $\InViewingKey$ &$:= \CRHivkBox{\crhivkinputbox}$. \end{tabular} \vspace{2ex} @@ -2755,12 +2774,12 @@ authority. A group of such addresses shares the same \fullViewingKey and To create a new \diversifiedPaymentAddress given an \incomingViewingKey $\InViewingKey$, first choose a \diversifier $\Diversifier$ uniformly at -random from $\bitseq{\DiversifierLength}$. +random from $\DiversifierType$. Then calculate: \begin{tabular}{@{\hskip 2em}r@{\;}l} $\DiversifiedTransmitBase$ &$:= \GroupJHash{U}(\ascii{Zcash\_gd}, \Diversifier)$ \\ - $\DiversifiedTransmitPublic$ &$:= \KASaplingDerivePublic(\DiversifiedTransmitBase, \InViewingKey)$. + $\DiversifiedTransmitPublic$ &$:= \reprJOf{\KASaplingDerivePublic(\InViewingKey, \DiversifiedTransmitBase)}$. \end{tabular} The resulting \diversifiedPaymentAddress is $(\Diversifier, \DiversifiedTransmitPublic)$. @@ -2781,6 +2800,7 @@ The resulting \diversifiedPaymentAddress is $(\Diversifier, \DiversifiedTransmit \end{pnotes} } + \nsubsection{\JoinSplitDescriptions} \label{joinsplitdesc} A \joinSplitTransfer, as specified in \crossref{joinsplit}, is encoded in @@ -2846,6 +2866,76 @@ $\hSigCRH$ is instantiated in \crossref{hsigcrh}. \vpubOld, \vpubNew, \hSig, \h{\allOld}), \Proof{\JoinSplit}) = 1$. \end{consensusrules} + +\sapling{ +\nsubsection{\SpendDescriptions} \label{spenddesc} + +A \spendTransfer, as specified in \crossref{spendsandoutputs}, is encoded in +\transactions as a \spendDescription. + +Each \transaction includes a sequence of zero or more \spendDescriptions. + +Unlike \joinSplitSignatures of which there is at most one per \transaction, +\emph{each} \spendDescription is authorized by a signature, called the +\spendAuthSignature. + +\introlist +A \spendDescription consists of $(\rt, \cv, \nf, \ProofSpend, \spendAuthSig)$ + +where +\begin{itemize} + \item $\rt \typecolon \MerkleHashSapling$ is an \anchor, as defined in + \crossref{blockchain}, for the output \treestate of a previous \block. + \item $\cv \typecolon \bitseq{\ellJ}$ is the \valueCommitment to the value of the input \note; + \item $\nf \typecolon \bitseq{\ellJ}$ is the \nullifier for the input \note; + \item $\ProofSpend \typecolon \SpendProof$ is + the \zeroKnowledgeProof for the \spendStatement; + \item $\spendAuthSig \typecolon \SpendAuthSigSignature$ is a signature authorizing this spend. +\end{itemize} + +\begin{consensusrules} + \item Elements of a \spendDescription{} \MUST have the types given above. + \item The proof $\Proof{\Spend}$ \MUST be valid given a \primaryInput formed + from the other fields except $\spendAuthSig$. + I.e.\ it must be the case that $\SpendVerify{}((\rt, \cv, \nf), \Proof{\Spend}) = 1$. + \item The \spendAuthSignature{} \MUST be a valid $\SpendAuthSig$ signature using + $\nf$ as the public key, over \todo{...} +\end{consensusrules} + + +\nsubsection{\OutputDescriptions} \label{outputdesc} + +An \outputTransfer, as specified in \crossref{spendsandoutputs}, is encoded in +\transactions as an \outputDescription. + +Each \transaction includes a sequence of zero or more \outputDescriptions. +There are no signatures associated with \outputDescriptions. + +\introlist +An \outputDescription consists of $(\cv, \cm, \EphemeralPublic, \TransmitCiphertext{}, \ProofOutput)$ + +where +\begin{itemize} + \item $\cv \typecolon \bitseq{\ellJ}$ is the \valueCommitment to the value of the output \note; + \item $\cm \typecolon \bitseq{\ellJ}$ is the \noteCommitment for the output \note; + \item $\EphemeralPublic \typecolon \KASaplingPublic$ is + a key agreement public key, used to derive the key for encryption + of the \notesCiphertext (\crossref{inband}); + \item $\TransmitCiphertext{} \typecolon \Ciphertext$ is + a ciphertext component for the encrypted output \note. + \item $\ProofOutput \typecolon \OutputProof$ is + the \zeroKnowledgeProof for the \outputStatement. +\end{itemize} + +\begin{consensusrules} + \item Elements of an \outputDescription{} \MUST have the types given above. + \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed + from the other fields except $\TransmitCiphertext{}$. + I.e.\ it must be the case that $\SpendVerify{}((\cv, \cm, \EphemeralPublic), \Proof{\Output}) = 1$. +\end{consensusrules} +} + + \introlist \nsubsection{Sending \Notes} \label{send} @@ -2925,14 +3015,7 @@ sent to a random \paymentAddress. \nsubsubsection{Sending \Notes{} (\Sapling)} \label{saplingsend} In order to send \shielded value, the sender constructs a \transaction -containing one or more \shieldedOutputs. This involves first generating -a new $\ShieldedOutputsSig$ key pair: - -\begin{formulae} - \item $(\shieldedOutputsPrivKey, \shieldedOutputsPubKey) \leftarrowR \ShieldedOutputsSigGen()$. -\end{formulae} - -Let $\OutputUnique := \reprJ(\shieldedOutputsPubKey)$. +containing one or more \shieldedOutputs. Let $\OutputIndexType$ be the type $\range{0}{2^{32}-1}$. @@ -2944,8 +3027,8 @@ $(\Diversifier, \DiversifiedTransmitPublic)$, and then performs the following st \begin{enumerate} \item Check that $\DiversifiedTransmitPublic$ is a valid compressed representation of an Edwards point on the $\JubjubCurve$ curve and this point is not of small order - (i.e. $\abstJ(\DiversifiedTransmitPublic) \neq \bot$ and - $\scalarmult{8}{\abstJ(\DiversifiedTransmitPublic)} \neq \ZeroJ$). + (i.e. $\abstJOf{\DiversifiedTransmitPublic} \neq \bot$ and + $\scalarmult{8}{\abstJOf{\DiversifiedTransmitPublic}} \neq \ZeroJ$). \item Calculate $\DiversifiedTransmitBase = \GroupJHash{U}(\ascii{Zcash\_gd}, \Diversifier)$ and check that $\DiversifiedTransmitBase \neq \bot$. @@ -2956,20 +3039,19 @@ $(\Diversifier, \DiversifiedTransmitPublic)$, and then performs the following st \item Choose independent random commitment trapdoors: \begin{tabular}{@{\hskip 2em}r@{\;}l} - $rcvnew$ &$\typecolon \ValueCommitTrapdoor$ \\ - $rcmnew$ &$\typecolon \NoteCommitSaplingTrapdoor$ \\ - $\NoteAddressPreRand$ &$\typecolon \UniqueCommitTrapdoor$. + $\ValueCommitRandNew{\OutputIndex}$ &$\typecolon \ValueCommitTrapdoor$ \\ + $\NoteCommitRandNew{\OutputIndex}$ &$\typecolon \NoteCommitSaplingTrapdoor$ \end{tabular} \item Calculate \begin{tabular}{@{\hskip 2em}r@{\;}l} - $\NoteAddressRand$ &$:= \UniqueCommit{\NoteAddressPreRand}(\OutputUnique, \OutputIndex)$ - where $\OutputIndex$ is an output index \\ - $cvnew$ &$:= \ValueCommit{rcvnew}(\ValueNew{\OutputIndex})$ \\ - $cmnew$ &$:= \NoteCommitSapling{rcmnew}(\ValueNew{\OutputIndex}, \NoteAddressRand, - \reprJ(\DiversifiedTransmitBase), \DiversifiedTransmitPublic)$ \\ - $\EphemeralPublic$ &$:= \KASaplingDerivePublic(\DiversifiedTransmitBase, \EphemeralPrivate)$. + $\cvNew{\OutputIndex}$ &$:= \ValueCommit{\ValueCommitRandNew{\OutputIndex}}(\ValueNew{\OutputIndex})$ \\ + $\cmNew{\OutputIndex}$ &$:= + \NoteCommitSapling{\NoteCommitRandNew{\OutputIndex}}(\reprJOf{\DiversifiedTransmitBase), + \DiversifiedTransmitPublic, + \ValueNew{\OutputIndex}}$ \\ + $\EphemeralPublic$ &$:= \KASaplingDerivePublic(\EphemeralPrivate, \DiversifiedTransmitBase)$. \end{tabular} \item Calculate $\DHSecret{} \typecolon \AffineEdwardsJubjub$ using an @@ -2979,17 +3061,17 @@ $(\Diversifier, \DiversifiedTransmitPublic)$, and then performs the following st $\DHSecret{}$ &$:= \KASaplingAgree(\EphemeralPrivate, \DiversifiedTransmitPublic)$ \end{tabular} - \item Let $\Key := \KDFSapling(\OutputUnique, \OutputIndex, \DHSecret{}, \EphemeralPublic)$. + \item Let $\Key := \KDFSapling(\OutputIndex, \DHSecret{}, \EphemeralPublic)$. \item Let $\Ptext$ be the raw encoding of the \notePlaintext - $(\ValueNew{\OutputIndex}, \NoteAddressRand, \Diversifier, rcmnew, \Memo)$. + $(\Diversifier, \ValueNew{\OutputIndex}, \NoteCommitRandNew{\OutputIndex}, \Memo)$. \item Encrypt $\Ptext$ using the IETF version of $\SymSpecific$, with empty associated data, all zero $96$-bit nonce, and $256$-bit key $\Key$, giving $\Ctext$. \item Generate a proof $\ProofOutput$ for the \outputCircuit described below. - \item Return $(cvnew, cmnew, \OutputUnique, \EphemeralPublic, \Ctext, \ProofOutput)$. + \item Return $(\cvNew{\OutputIndex}, \cmNew{\OutputIndex}, \EphemeralPublic, \Ctext, \ProofOutput)$. % \item Encrypt the \note to the recipient \transmissionKey $\TransmitPublicNew{i}$, % as described in \crossref{inbandsapling}, giving the ciphertext component @@ -3001,17 +3083,7 @@ 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. -\introlist -After generating all of the \spendDescriptions and \outputDescriptions, the sender -obtains the $\dataToBeSigned$ (\crossref{nonmalleability}), and signs it with -the private \shieldedOutputsPrivKey: - -\begin{formulae} - \item $\shieldedOutputsSig \leftarrowR \ShieldedOutputsSigSign{\text{\small\shieldedOutputsPrivKey}}(\dataToBeSigned)$ -\end{formulae} - -Then the encoded \transaction including the \shieldedOutputsSignature is submitted -to the network. +The encoded \transaction is submitted to the network. } \nsubsection{Merkle path validity} \label{merklepath} @@ -3031,7 +3103,7 @@ The following discussion applies independently to the \Sprout and \Sapling \note } Each \merkleNode in the \incrementalMerkleTree is associated with a \merkleHash, -which is a byte sequence. The \merkleLayer numbered $h$, counting from +which is a bit sequence. The \merkleLayer numbered $h$, counting from \merkleLayer $0$ at the \merkleRoot, has $2^h$ \merkleNodes with \merkleIndices $0$ to $2^h-1$ inclusive. @@ -3040,16 +3112,19 @@ Let $\MerkleNode{h}{i}$ be the \merkleHash associated with the \merkleNode at The \merkleNodes at \merkleLayer $\MerkleDepth$ are called \merkleLeafNodes. When a \noteCommitment is added to the tree, it occupies the \merkleLeafNode -\merkleHash $\MerkleNode{\MerkleDepthSprout}{i}$ for the next available $i$. As-yet unused -\merkleLeafNodes are associated with a distinguished \merkleHash $\UncommittedSprout$ -\sapling{ or \merkleHash $\UncommittedSapling$}. +\merkleHash $\MerkleNode{\MerkleDepth}{i}$ for the next available $i$. + +As-yet unused \merkleLeafNodes are associated with a distinguished \merkleHash +$\UncommittedSprout$ \sapling{ or $\UncommittedSapling$}. It is assumed to be infeasible to find a preimage \note $\NoteTuple{}$ such that -$\NoteCommitmentSprout(\NoteTuple{}) = \UncommittedSprout$. \sapling{Similarly, it -is assumed infeasible to find a preimage \note $\NoteTuple{}$ such that -$\NoteCommitmentSapling(\NoteTuple{}) = \UncommittedSapling$.} +$\NoteCommitmentSprout(\NoteTuple{}) = \UncommittedSprout$. +\sapling{(No similar assumption is needed for \Sapling because we use a representation +for $\UncommittedSapling$ that cannot occur as an output of $\NoteCommitmentSapling$, +and explicitly check when a \note is spent that this representation is not given as +its purported \noteCommitment.)} \introlist -The \merkleNodes at \merkleLayers $0$ to $\MerkleDepthSprout-1$ inclusive are called +The \merkleNodes at \merkleLayers $0$ to $\MerkleDepth-1$ inclusive are called \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$, @@ -3099,7 +3174,7 @@ key pair is generated for each \transaction, and the $\dataToBeSigned$ is signed with the private signing key of this key pair. The corresponding public verification key is included in the \transaction encoding as $\joinSplitPubKey$. -$\JoinSplitSig$ is instantiated in \crossref{concretesig}. +$\JoinSplitSig$ is instantiated in \crossref{concretejssig}. \changed{ If $\nJoinSplit$ is zero, the $\joinSplitPubKey$ and $\joinSplitSig$ fields are @@ -3124,12 +3199,12 @@ all of the $\AuthPrivateOld{\allOld}$ for every \joinSplitDescription in the to $\joinSplitPubKey$ to sign this \transaction. } -\saplingonly{ -\todo{Specify the Signature-of-Knowledge used to authorize spends.} +\saplingonward{ +\todo{Specify the \spendAuthSignature.} } -\nsubsection{Balance} +\nsubsection{Balance} \label{balance} \label{saplingbalance} A \joinSplitTransfer can be seen, from the perspective of the \transaction, as an input \changed{and an output simultaneously}. @@ -3155,14 +3230,43 @@ This restriction helps to avoid unnecessary distinctions between \transactions according to client implementation. } -\nsubsection{\NoteCommitments{} and \Nullifiers} +\sapling{\todo{Add details of balance checking for \Sapling \transactions.}} -A \transaction that contains one or more \joinSplitDescriptions, when entered + +\nsubsection{\NoteCommitments{} and \Nullifiers} \label{commitmentsandnullifiers} + +A \transaction that contains one or more +\joinSplitDescriptions\sapling{ or \spendDescriptions}, when entered into the \blockchain, appends to the \noteCommitmentTree with all constituent \noteCommitments. All of the constituent \nullifiers are also entered into the \nullifierSet of the associated \treestate. A \transaction is not valid if it attempts to add a \nullifier to the \nullifierSet that already exists in the set. +\sprout{Each}\notsprout{In \Sprout, each} \note has a $\NoteAddressRand$ component. + +\sapling{ +In \Sapling, each \positionedNote has an associated $\NoteAddressRand$ value which +is computed from its \noteCommitment $\cm$ and \notePosition $\NotePosition$ +as follows: + +\begin{formulae} + \item $\NoteAddressRand := \MixingPedersenHash(\ascii{Zcashrho}, \cm, \NotePosition)$. +\end{formulae} + +$\MixingPedersenHash$ is defined in \crossref{concretemixinghash}. +} + +Let $\PRFnf{}{}$\sapling{ and $\PRFnr{}{}$} be as instantiated in \crossref{concreteprfs}. + +\sprout{The \nullifier of a \note}\notsprout{For a \Sprout \note, the \nullifier} +is derived as $\PRFnf{\AuthPrivate}(\NoteAddressRand)$. + +% TODO: \scalarmults should only be in the concrete section +\sapling{ +For a \Sapling \note, the \nullifier is derived as +$\scalarmult{\PRFnr{\AuthProvePublic}(\NoteAddressRand)}{\scalarmult{8}{\AuthSignPublic}}$. +} + \introsection \nsubsection{\ZkSNARKStatements} \label{snarkstatements} @@ -3258,7 +3362,7 @@ For details of the form and encoding of proofs, see \crossref{phgr}. \introsection \nsubsubsection{\SpendStatement{} (\Sapling)} \label{spendstatement} -A valid instance of $\ProofSpend$ assures that given a \term{primary input}: +%A valid instance of $\ProofSpend$ assures that given a \term{primary input}: \todo{} %\begin{formulae} @@ -3271,45 +3375,46 @@ A valid instance of $\ProofSpend$ assures that given a \term{primary input}: % \hparen\h{\allOld} \typecolon \typeexp{\PRFOutput}{\NOld})$, %\end{formulae} -\introlist -the prover knows an \term{auxiliary input}: - -\begin{formulae} - \item $(\treepath{} \typecolon \typeexp{\MerkleHash}{\MerkleDepthSapling},\\ - \hparen\nOld{} \typecolon \NoteTypeSapling,\\ - \hparen\AuthProvePrivate \typecolon \bitseq{252})$ +%\introlist +%the prover knows an \term{auxiliary input}: +% +%\begin{formulae} +% \item $(\treepath{} \typecolon \typeexp{\MerkleHash}{\MerkleDepthSapling},\\ +% \hparen\nOld{} \typecolon \NoteTypeSapling,\\ +% \hparen\AuthProvePrivate \typecolon \bitseq{252})$ % \hparen\nNew{\allNew} \typecolon \typeexp{\NoteTypeSapling}{\NNew},\vspace{0.8ex}\\ % \hparen\NoteAddressPreRand \typecolon \bitseq{\NoteAddressPreRandLength} -\end{formulae} +%\end{formulae} -where $\nOld{} = (\Diversifier, \DiversifiedTransmitPublic, -\vOld{}, \NoteAddressRandOld{}, \NoteCommitRandOld{})$ +%where $\nOld{} = (\Diversifier, \DiversifiedTransmitPublic, +%\vOld{}, \NoteAddressRandOld{}, \NoteCommitRandOld{})$ -\introlist -such that the following conditions hold: +%\introlist +%such that the following conditions hold: -\subparagraph{Merkle path validity} \label{saplingmerklepathvalidity} +%\subparagraph{Merkle path validity} \label{saplingmerklepathvalidity} -$\treepath{}$ must be a valid \merklePath of depth $\MerkleDepthSapling$, as defined in -\crossref{merklepath}, from $\NoteCommitmentSapling(\nOld{})$ to \noteCommitmentTree root $\rt$. +%$\treepath{}$ must be a valid \merklePath of depth $\MerkleDepthSapling$, as defined in +%\crossref{merklepath}, from $\NoteCommitmentSapling(\nOld{})$ to \noteCommitmentTree root $\rt$. -\subparagraph{\Nullifier{} integrity} \label{saplingnullifierintegrity} +%\subparagraph{\Nullifier{} integrity} \label{saplingnullifierintegrity} -$\nfOld{} = \scalarmult{\PRFnr{\AuthProvePublic}(\NoteAddressRand)}{\scalarmult{8}{\AuthSignPublic}}$. +%$\nfOld{} = \scalarmult{\PRFnr{\AuthProvePublic}(\NoteAddressRand)}{\scalarmult{8}{\AuthSignPublic}}$. -\subparagraph{Spend authority} \label{saplingspendauthority} +%\subparagraph{Spend authority} \label{saplingspendauthority} -\todo{} %for each $i \in \setofOld$: %$\AuthPublicOld{i} = \PRFaddr{\AuthPrivateOld{i}}(0)$. -\vspace{2.5ex} -For details of the form and encoding of proofs, see \crossref{groth}. +%\vspace{2.5ex} +For details of the form and encoding of \spendStatement proofs, see \crossref{groth}. \introsection \nsubsubsection{\OutputStatement{} (\Sapling)} \label{outputstatement} \todo{} + +For details of the form and encoding of \outputStatement proofs, see \crossref{groth}. } @@ -3346,7 +3451,7 @@ For both encryption and decryption, \item Let $\KDFSprout$\sapling{ and $\KDFSapling$} be the \keyDerivationFunctions instantiated in \crossref{concretesproutkdf}. \item Let $\KASprout$\sapling{ and $\KASapling$} be the \keyAgreementSchemes instantiated in - \crossref{concretekeyagreement}. + \crossref{concretekaandkdf}. \item \sproutonly{Let $\hSig$ be the value computed for this \joinSplitDescription in \crossref{joinsplitdesc}.} \end{itemize} @@ -3386,7 +3491,7 @@ The resulting \notesCiphertext is $\changed{(\EphemeralPublic, It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band transmission of the \note to the recipient. In this case the ephemeral key \MUST -still be generated as a random public key (rather than a random bit string) to ensure +still be generated as a random public key (rather than a random bit sequence) to ensure indistinguishability from other \joinSplitDescriptions. This mode of operation raises further security considerations, for example of how to validate a \note received out-of-band, which are not addressed in this document. @@ -3453,17 +3558,41 @@ engineering rationale behind this encryption scheme. \todo{Explain the kind of things that can go wrong with linkage between abstract and concrete protocol. E.g. \crossref{internalh}} -\nsubsection{Integers, Bit Sequences, and Endianness} \label{boxnotation} +\nsubsection{Integers, Bit Sequences, and Endianness} \label{boxnotation} \label{endian} All integers in \emph{\Zcash-specific} encodings are unsigned, have a fixed bit length, and are encoded in little-endian byte order \emph{unless otherwise specified}. +The following functions convert between sequences of bits, sequences of bytes, +and integers: + +\begin{itemize} + \item $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \range{0}{2^\ell\!-\!1} \rightarrow \bitseq{\ell}$, + such that $\ItoLEBSP{\ell}(x)$ is the sequence of $\ell$ bits representing $x$ in + little-endian order; + \item $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \range{0}{2^\ell\!-\!1} \rightarrow \bitseq{\ell}$ + such that $\ItoBEBSP{u}(\ell)$ is the sequence of $\ell$ bits representing $x$ in + big-endian order. + \item $\ItoLEOSPvar \typecolon \Nat \rightarrow \byteseqs$, + such that $\ItoLEOSPvar(i)$ is the shortest little-endian encoding of $i$ + as a byte sequence, i.e. so that the encoding does not end in a zero + byte. ($\ItoLEOSPvar(0) = []$.) + \item $\LEOStoIP{} \typecolon (k \typecolon \Nat) \times \byteseq{k} \rightarrow \range{0}{256^k\!-\!1}$ + such that $\LEOStoIP{k}(S)$ is the integer represented in little-endian order by the + byte sequence $S$ of length $k$. + \item $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\ceiling{\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. +\end{itemize} + In bit layout diagrams, each box of the diagram represents a sequence of bits. Diagrams are read from left-to-right, with lines read from top-to-bottom; the breaking of boxes across lines has no significance. -The bit length is given explicitly in each box, except for the case of a single -bit, or for the notation $\zeros{\ell}$ representing the sequence of $\ell$ +The bit length $\ell$ is given explicitly in each box, except for the case of a +single bit, or for the notation $\zeros{\ell}$ representing the sequence of $\ell$ zero bits. The entire diagram represents the sequence of \emph{bytes} formed by first @@ -3479,7 +3608,10 @@ clarify their position in each case. Define: \begin{formulae} - \item $\MerkleDepth \typecolon \Nat := \changed{29}$ + \item $\MerkleDepthSprout \typecolon \Nat := \changed{29}$ +\sapling{ + \item $\MerkleDepthSapling \typecolon \Nat := 29$ +} \item $\NOld \typecolon \Nat := 2$ \item $\NNew \typecolon \Nat := 2$ \item $\MerkleHashLengthSprout \typecolon \Nat := 256$ @@ -3494,11 +3626,12 @@ Define: \item $\AuthPrivateLength \typecolon \Nat := \changed{252}$ \sapling{ \item $\AuthPrivateSeedLength \typecolon \Nat := 256$ + \item $\DiversifierLength \typecolon \Nat := 88$ } \item $\changed{\NoteAddressPreRandLength \typecolon \Nat := 252}$ \item $\UncommittedSprout \typecolon \bitseq{\MerkleHashLengthSprout} := \zeros{\MerkleHashLengthSprout}$ \sapling{ - \item $\UncommittedSapling \typecolon \bitseq{\MerkleHashLengthSapling} := \zeros{\MerkleHashLengthSapling}$ + \item $\UncommittedSapling \typecolon \bitseq{\MerkleHashLengthSapling} := \ones{\MerkleHashLengthSapling}$ } \item $\MAXMONEY \typecolon \Nat := \changed{2.1 \smult 10^{15}}$ (\zatoshi) \item $\SlowStartInterval \typecolon \Nat := 20000$ @@ -3531,7 +3664,7 @@ SHA-256 is defined by \cite{NIST2015}. \Zcash uses the full \shaHashFunction to instantiate $\NoteCommitmentSprout$. \begin{formulae} - \item $\SHAFull \typecolon \byteseqs \rightarrow \bitseq{256}$ + \item $\SHAFull \typecolon \byteseqs \rightarrow \byteseq{32}$ \end{formulae} It also uses the \shaCompressFunction, $\SHACompress$. This operates @@ -3547,6 +3680,8 @@ $\MerkleCRHSprout$. \item $\SHACompress \typecolon \bitseq{512} \rightarrow \bitseq{256}$ \end{formulae} +\todo{Specify bit order.} + \nsubsubsubsection{\BlakeTwo{} \HashFunction} \label{concreteblake2} @@ -3564,10 +3699,10 @@ and $\KDFSprout$. \nuzero{From \NUZero onward, it is used to compute \sighashTxHashes.} \sapling{For \Sapling, it is also used to instantiate $\KDFSapling$ and $\PRGExpandSeed{}$, and in the $\EdJubjub$ \signatureScheme which -instantiates $\SpendAuthorizationSig$.} +instantiates $\SpendAuthSig$.} \begin{formulae} - \item $\BlakeTwob{\ell} \typecolon \byteseq{16} \times \byteseqs \rightarrow \bitseq{\ell}$ + \item $\BlakeTwob{\ell} \typecolon \byteseq{16} \times \byteseqs \rightarrow \byteseq{\ell/8}$ \end{formulae} \vspace{-3ex} @@ -3587,16 +3722,14 @@ $\BlakeTwosGeneric$ is used to instantiate $\PRFnr{}$, $\CRHivk$, and $\GroupJHash{}$. \begin{formulae} - \item $\BlakeTwos{\ell} \typecolon \byteseq{8} \times \byteseqs \rightarrow \bitseq{\ell}$ + \item $\BlakeTwos{\ell} \typecolon \byteseq{8} \times \byteseqs \rightarrow \byteseq{\ell/8}$ \end{formulae} } +\introsection \nsubsubsubsection{\MerkleTree{} \HashFunction} \label{merklecrh} -$\MerkleCRH$ is used to hash \incrementalMerkleTree \merkleHashes. -It is instantiated by $\SHACompress$ as specified in \crossref{concretesha256}. - \newsavebox{\merklebox} \begin{lrbox}{\merklebox} \begin{bytefield}[bitwidth=0.04em]{512} @@ -3605,20 +3738,72 @@ It is instantiated by $\SHACompress$ as specified in \crossref{concretesha256}. \end{bytefield} \end{lrbox} +\sprout{ +$\MerkleCRHSprout$ is used to hash \incrementalMerkleTree \merkleHashes. + +Let $\SHACompress$ be as specified in \crossref{concretesha256}. + +$\MerkleCRHSprout \typecolon \MerkleHashSprout \times \MerkleHashSprout \rightarrow \MerkleHashSprout$ +is defined as follows: + \begin{formulae} - \item $\MerkleCRH(\mathsf{left}, \mathsf{right}) := \SHACompressBox{\merklebox}$. + \item $\MerkleCRHSprout(\mathsf{left}, \mathsf{right}) := \SHACompressBox{\merklebox}$. \end{formulae} \pnote{ $\SHACompress$ is not the same as the $\SHAFull$ function, which hashes arbitrary-length byte sequences. } +} +\notsprout{ +$\MerkleCRHSprout$ and $\MerkleCRHSapling$ are used to hash +\incrementalMerkleTree \merkleHashes for \Sprout and \Sapling respectively. +\subsubsubsubsection{$\MerkleCRHSprout$ \HashFunction} \label{merklecrhsprout} + +Let $\SHACompress$ be as specified in \crossref{concretesha256}. + +$\MerkleCRHSprout \typecolon \MerkleLayerSprout \times \MerkleHashSprout \times \MerkleHashSprout +\rightarrow \MerkleHashSprout$ is defined as follows: + +\begin{formulae} + \item $\MerkleCRHSprout(\mathsf{layer}, \mathsf{left}, \mathsf{right}) := \SHACompressBox{\merklebox}$. +\end{formulae} + +\vspace{-4ex} +\begin{pnotes} + \item The $\mathsf{layer}$ argument does not affect the output. + \item $\SHACompress$ is not the same as the $\SHAFull$ function, which hashes arbitrary-length + byte sequences. +\end{pnotes} +} + +\vspace{-2ex} \securityrequirement{ $\SHACompress$ must be collision-resistant, and it must be infeasible to find a preimage $x$ such that $\SHACompress(x) = \zeros{256}$. } +\sapling{ +\subsubsubsubsection{$\MerkleCRHSapling$ \HashFunction} \label{merklecrhsapling} + +Let $\PedersenHash$ be as specified in \crossref{concretepedersenhash}. + +$\MerkleCRHSapling \typecolon \MerkleLayerSapling \times \MerkleHashSapling \times \MerkleHashSapling +\rightarrow \MerkleHashSapling$ is defined as follows: + +\begin{formulae} + \item $\MerkleCRHSapling(\mathsf{layer}, \mathsf{left}, \mathsf{right}) := \PedersenHash(\ascii{Zcash\_PH}, + \ItoLEBSP{6}(\mathsf{layer}) \bconcat \mathsf{left} \bconcat \mathsf{right})$. +\end{formulae} + +\vspace{-2ex} +\securityrequirement{ +$\PedersenHash$ must be collision-resistant. +} +} + + \introlist \nsubsubsubsection{\hSigText{} \HashFunction} \label{hsigcrh} @@ -3656,8 +3841,8 @@ $\BlakeTwob{256}(\ascii{ZcashComputehSig}, x)$ must be collision-resistant. \newsavebox{\crhivkbox} \begin{lrbox}{\crhivkbox} \begin{bytefield}[bitwidth=0.05em]{512} - \bitbox{256}{$256$-bit $\reprJ(\AuthSignPublic)$} & - \bitbox{256}{$256$-bit $\reprJ(\AuthProvePublic)$} + \bitbox{256}{$256$-bit $\reprJOf{\AuthSignPublic}$} & + \bitbox{256}{$256$-bit $\reprJOf{\AuthProvePublic}$} \end{bytefield} \end{lrbox} @@ -3674,7 +3859,8 @@ and for its use in the \spendStatement see \crossref{spendstatement}. It is defined as follows: \begin{formulae} - \item $\CRHivk(\AuthSignPublic, \AuthProvePublic) := \drop{5}(\BlakeTwos{256}(\ascii{Zcashivk},\; \crhInput))$ + \item $\CRHivk(\AuthSignPublic, \AuthProvePublic) := + \LEOStoIP{256}(\BlakeTwos{256}(\ascii{Zcashivk},\; \crhInput)) \bmod 2^{251}$ \end{formulae} where @@ -3687,17 +3873,9 @@ $\BlakeTwos{256}(p, x)$ refers to unkeyed $\BlakeTwos{256}$ \cite{ANWW2013} in sequential mode, with an output digest length of $32$ bytes, $8$-byte personalization string $p$, and input $x$. -The output of $\BlakeTwos{256}$ is treated as a bit string with the -most-significant bit first in each byte. $\drop{5}$ discards the first -$5$ bits and returns the remaining $251$ bits as the hash result. - -When the output of $\CRHivk$ is used to obtain $\InViewingKey$, -the $251$-bit string will be converted to an integer according to -big-endian bit order as specified in \crossref{saplingkeycomponents}. - \securityrequirement{ -$\drop{5}(\BlakeTwos{256}(\ascii{Zcashivk}, x))$ must be -collision-resistant on a $512$-bit input $x$. Note that this +$\LEOStoIP{256}(\BlakeTwos{256}(\ascii{Zcashivk}, x)) \bmod 2^{251}$ +must be collision-resistant on a $512$-bit input $x$. Note that this does not follow from collision-resistance 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 @@ -3719,15 +3897,17 @@ the same effect as using that feature. \nsubsubsubsection{\PedersenHashFunction} \label{concretepedersenhash} $\PedersenHash$ is an algebraic hash function with collision resistance -derived from assumed hardness of the Discrete Logarithm Problem on the -$\JubjubCurve$ curve. It is based on the work of \todo{add citations}, and of -Mihir Bellare, Oded Goldreich, and Shafi Goldwasser in \cite{BGG1995}, +(for fixed input length) derived from assumed hardness of the +Discrete Logarithm Problem on the $\JubjubCurve$ curve. +It is based on the work of Jurjen Bos, David Chaum, George Purdy, +Eugène van Heijst and Birgit Pfitzmann in \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 Daira Hopwood. $\PedersenHash$ is used in the \incrementalMerkleTree over \noteCommitments (\crossref{merkletree}) and in the definition of \xPedersenCommitments -(\crossref{concretepedersencommit}). +(\crossref{concretewindowedcommit}). Let $\GroupJ$ be as defined in \crossref{jubjub}. @@ -3746,37 +3926,125 @@ Let $c = 63$. \introlist \vspace{2ex} -Define $\PedersenBaseAlg, \PedersenGenAlg \typecolon \byteseq{8} \times \Nat \rightarrow \GroupJ$ by: +Define $\PedersenGenAlg \typecolon \byteseq{8} \times \Nat \rightarrow \GroupJ$ by: -\begin{tabular}{@{\hskip 2em}r@{\;}l} - $\PedersenBase{D}{i}$ &$:= \FindGroupJHash\left(D, \Justthebox{\gencountbox}\right)$ \\ - $\PedersenGen{D}{i}$ &$:= \scalarmult{4 \smult ((i\!-\!1) \bmod c)}{\PedersenBase{D}{i}}$ -\end{tabular} +\begin{formulae} + \item $\PedersenGen{D}{i} := \FindGroupJHashOf{D, \Justthebox{\gencountbox}}$. +\end{formulae} -\newcommand{\si}[1]{s^{\kern 0.02em i}_{#1}} +\newcommand{\sj}[1]{s^{\kern 0.02em j}_{#1}} \vspace{2ex} -\introlist -Define $\PedersenHash(D \typecolon \byteseq{8}, M \typecolon \bitseqs)$ as follows: +\introsection +Define $\PedersenHashToPoint(D \typecolon \byteseq{8}, M \typecolon \bitseq{\PosInt})$ as follows: \begin{formulae} \item Pad $M$ to a multiple of $3$ bits by appending zero bits, giving $M'$. - \item Let $n = \length(M')/3$. - \item Split $M'$ into $n$ \quotedterm{windows} $M_{\barerange{1}{n}}$ each of length $3$ bits, - so that $M' = \concatbits(M_{\barerange{1}{n}})$. - \item Write each $M_i$ as $[\si{0}, \si{1}, \si{2}]$, and let - $m_i = (1 - 2 \smult \si{2}) \mult (1 + \si{0} + 2 \smult \si{1})$. - \item Let $R = \vsum{i=1}{n} \scalarmult{m_i}{\PedersenGen{D}{i}}$. - \item Return $\ItoLEBSP{255}(\ExtractJ(R))$. + \item Let $n = \ceiling{\hfrac{\length(M')}{3 \mult c}}$. + \item Split $M'$ into $n$ \quotedterm{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 $\vsum{i=1}{n} \scalarmult{\PedersenEncode{M_i}}{\PedersenGen{D}{i}} \typecolon \GroupJ$. +\end{formulae} + +where +$\PedersenEncode{\paramdot} \typecolon \bitseq{3 \mult \range{1}{c}} \rightarrow + \rangenozero{-\hfrac{\ParamJ{r}-1}{2}}{\hfrac{\ParamJ{r}-1}{2}}$ is defined as: + +\begin{formulae} + \item Let $k_i = \length(M_i)/3$. + \item Split $M_i$ into $3$-bit \quotedterm{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})$. + \item Let $\PedersenEncode{M_i} = \vsum{j=1}{k_i} \enc(m_j) \mult 2^{4 \mult (j-1)}$. +\end{formulae} + +Finally, define $\PedersenHash \typecolon \byteseq{8} \times \bitseq{\PosInt} \rightarrow \bitseq{255}$ by: + +\begin{formulae} + \item $\PedersenHash(D, M) := \ItoLEBSP{255}(\ExtractJ(\PedersenHashToPoint(D, M)))$. \end{formulae} See \crossref{cctpedersenhash} for rationale and efficient circuit implementation -of this function. +of these functions. \securityrequirement{ -$\PedersenHash$ is required to be collision-resistant. No other security properties -commonly associated with \hashFunctions are needed. +$\PedersenHash$ and $\PedersenHashToPoint$ are required to be collision-resistant +between inputs of fixed length, for a given personalization input $D$. +No other security properties commonly associated with \hashFunctions are needed. } + +\vspace{2ex} +\begin{theorem} \label{thmpedersenencodeinjective} +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 $\rangenozero{-\hfrac{\ParamJ{r}-1}{2}}{\hfrac{\ParamJ{r}-1}{2}}$. +The range of this expression is a subset of +$\rangenozero{-\PedersenRangeOffset}{\PedersenRangeOffset}$ where +$\PedersenRangeOffset = 4 \mult \vsum{i=0}{c-1} 2^{4 \mult i} = 4 \mult \hfrac{2^{4 \mult c}}{15}$. + +When $c = 63$, we have + +\begin{tabular}{@{\hskip 2em}r@{\;}l} + $4 \mult \hfrac{2^{4 \mult c}}{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 $\vsum{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} = \vsum{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 collision-resistant under the same assumptions and security bounds. +Because $\ItoLEBSP{255}$ and $\ExtractJ$ are injective, it follows that +$\PedersenHash$ is equally collision-resistant. +} + + +\sapling{ +\nsubsubsubsection{Mixing Pedersen \HashFunction} \label{concretemixinghash} + +A mixing \xPedersenHash is used to compute $\NoteAddressRand$ from +$\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as +input a \xPedersenCommitment $P$, and hashes it with another input $x$. + +We define $\MixingPedersenHash{D} \typecolon \byteseq{8} \times \GroupJ \times \range{0}{\ParamJ{r}-1} +\rightarrow \GroupJ$ by: + +\begin{formulae} + \item $\MixingPedersenHash(D, P, x) := P + \scalarmult{x}{\FindGroupJHashOf(D, \ascii{})}$. +\end{formulae} + +\securityrequirement{ +Fix $D_1, D_2 \typecolon \byteseq{8}$ with $D_1 \neq D_2$, and consider the function +$\fun{(r, M, x) \typecolon \range{0}{\ParamJ{r}-1} \times \bitseq{\PosInt} \times +\range{0}{\ParamJ{r}-1}}{\MixingPedersenHash(D_2, x, \WindowedPedersenCommit{r}(D_1, M)) \typecolon \GroupJ}$. +This function must be collision-resistant on $(r, M, x)$. +} + +See \crossref{cctmixinghash} for rationale and efficient circuit implementation +of this function. } @@ -3918,7 +4186,7 @@ The first four bits --i.e.\ the most significant four bits of the first byte-- are used to distinguish different uses of $\SHACompress$, ensuring that the functions are independent. In addition to the inputs shown here, the bits $\mathtt{1011}$ in this position are used to distinguish uses of the full $\SHAFull$ hash -function --- see \crossref{concretecomm}. +function --- see \crossref{concretesproutcommit}. (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 @@ -3973,7 +4241,9 @@ 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$. } -\nsubsubsection{\SproutOrNothing \KeyAgreement} \label{concretesproutkeyagreement} +\nsubsubsection{\KeyAgreementAndDerivation} \label{concretekaandkdf} + +\nsubsubsubsection{\SproutOrNothing \KeyAgreement} \label{concretesproutkeyagreement} \changed{ The \keyAgreementScheme specified in \crossref{abstractkeyagreement} is @@ -3988,8 +4258,8 @@ multiplication of the Curve25519 public key represented by the byte sequence $\bytes{q}$ by the Curve25519 secret key represented by the byte sequence $\bytes{n}$, as defined in \cite[section 2]{Bern2006}. -Let $\CurveBase$ be the public byte sequence representing the Curve25519 -base point. +Let $\KASproutBase := \CurveBase$ be the public byte sequence representing +the Curve25519 base point. Let $\Clamp(\bytes{x})$ take a 32-byte sequence $\bytes{x}$ as input and return a byte sequence representing a Curve25519 private key, with @@ -4056,16 +4326,39 @@ as follows. Let $\KASaplingPublic$ and $\KASaplingSharedSecret$ be the type of compressed $\JubjubCurve$ points $\CompressedEdwardsJubjub$, and let $\KASaplingPrivate$ be the type of $\JubjubCurve$ secret keys. \todo{expand this} - -\nsubsubsubsection{\Sapling \KeyDerivation} \label{concretesaplingkdf} - -Let $\KDFSapling(\OutputUnique, \OutputIndex, \DHSecret{}, \EphemeralPublic) := - \BlakeTwob{256}(\ascii{Zcash\_SaplingKDF}, - \OutputUnique \bconcat \OutputIndex \bconcat \reprJ(\DHSecret{}) \bconcat \reprJ(\EphemeralPublic))$. } -\nsubsubsection{\JoinSplitSignature} \label{concretesig} +\newsavebox{\kdfsaplinginputbox} +\begin{lrbox}{\kdfsaplinginputbox} +\begin{bytefield}[bitwidth=0.06em]{544} + \bitbox{32}{$32$-bit $\OutputIndex$} & + \bitbox{256}{$256$-bit $\reprJ{\DHSecret{}}$} & + \bitbox{256}{$256$-bit $\reprJ{\EphemeralPublic}$} +\end{bytefield} +\end{lrbox} + +\sapling{ +\nsubsubsubsection{\Sapling \KeyDerivation} \label{concretesaplingkdf} + +The $\KDFSapling$ \keyDerivationFunction specified in \crossref{abstractkdf} +is instantiated using $\BlakeTwob{256}$ as follows: + +\begin{formulae} + \item $\KDFSapling(\OutputIndex, \DHSecret{}, \EphemeralPublic) := + \BlakeTwob{256}(\ascii{Zcash\_SaplingKDF}, \kdfinput)$. +\end{formulae} +\introlist +where: +\begin{formulae} + \item $\kdfinput := \Justthebox{\kdfsaplinginputbox}$. +\end{formulae} + +$\BlakeTwob{256}(p, x)$ is defined in \crossref{concreteblake2}. +} + + +\nsubsubsection{\JoinSplitSignature} \label{concretejssig} $\JoinSplitSig$ is specified in \crossref{abstractsig}. @@ -4083,6 +4376,11 @@ Note that it is \emph{not} required that the encoding of the $y$-coordinate in $\EdDSAR$ is less than $2^{255}-19$. $\JoinSplitSigSpecific$ is defined as using $\JoinSplitSigHashName$ internally. + +A valid $\JoinSplitSigSpecific$ public key is defined as a point of order $\ell$ +on the Ed25519 curve, in the encoding specified by \cite{BDLSY2012}. Again, it is +\emph{not} required that the encoding of the y-coordinate of the public key is +less than $2^{255}-19$. } \newsavebox{\sigbox} @@ -4109,15 +4407,17 @@ The encoding of a public key is as defined in \cite{BDLSY2012}. } \sapling{ -\nsubsubsection{\ShieldedOutputsSignature{} and \SpendAuthorizationSignature} \label{concretesaplingsig} +\nsubsubsection{\SpendAuthSignature} \label{concretespendauthsig} -$\ShieldedOutputsSig$ and $\SpendAuthorizationSig$ are specified in \crossref{abstractsig}. +$\SpendAuthSig$ is specified in \crossref{abstractsig}. -\todo{They are both instantiated as EdJubjub...} +\todo{It is instantiated as EdJubjub...} } \introlist -\nsubsubsection{Commitment} \label{concretecomm} +\nsubsubsection{Commitment schemes} \label{concretecommit} + +\nsubsubsubsection{\SproutOrNothing{} \NoteCommitments} \label{concretesproutcommit} \newsavebox{\cmbox} \begin{lrbox}{\cmbox} @@ -4138,7 +4438,7 @@ $\ShieldedOutputsSig$ and $\SpendAuthorizationSig$ are specified in \crossref{ab \end{bytefield} \end{lrbox} -The commitment scheme $\NoteCommitSprout{}$ specified in \crossref{abstractcomm} is +The commitment scheme $\NoteCommitSprout{}$ specified in \crossref{abstractcommit} is instantiated using $\SHAFull$ as follows: \begin{formulae}[leftmargin=1em] @@ -4158,6 +4458,80 @@ The leading byte of the $\SHAFull$ input is $\hexint{B0}$. \end{securityrequirements} +\sapling{ +\nsubsubsubsection{Windowed Pedersen commitments} \label{concretewindowedcommit} + +We construct \quotedterm{windowed} \xPedersenCommitments by reusing the \xPedersenHash +construction from \crossref{concretepedersenhash}, and adding a randomized point +on the $\JubjubCurve$ curve (see \crossref{jubjub}): + +\begin{formulae} + \item $\WindowedPedersenCommit{r}(D, s) := + \PedersenHashToPoint(D, s) + \scalarmult{r}{\FindGroupJHashOf{D, \ascii{}}}$. +\end{formulae} + +See \crossref{cctwindowedcommit} for rationale and efficient circuit implementation +of this function. + +The commitment scheme $\NoteCommitSprout{}$ specified in \crossref{abstractcommit} is +instantiated using $\WindowedPedersenCommitAlg$ as follows: + +\begin{formulae} + \item $\NoteCommitSapling{\NoteCommitRand}(\Diversifier, \DiversifiedTransmitPublic, \Value) := + \WindowedPedersenCommit{\NoteCommitRand}(\ascii{Zcash\_cm}, + \Diversifier \bconcat \DiversifiedTransmitPublic \bconcat \ItoLEBSP{64}(\Value))$. +\end{formulae} + +\begin{securityrequirements} + \item $\WindowedPedersenCommitAlg$ must be a computationally binding and at least + computationally hiding \commitmentScheme, for a given personalization input $D$. + \item $\NoteCommitSaplingAlg$ must be a computationally binding and at least + computationally hiding \commitmentScheme. +\end{securityrequirements} + +(They are in fact unconditionally hiding \commitmentSchemes.) +} + + +\sapling{ +\nsubsubsubsection{Raw Pedersen commitments} \label{concreterawcommit} + +The windowed Pedersen commitments defined in the preceding section are +highly efficient, but they do not support the homomorphic property we +need when instantiating $\ValueCommit{}$ (see \crossref{spendsandoutputs} +and \crossref{saplingbalance}). + +In order to support this property, we also define \quotedterm{raw} +\xPedersenCommitments as follows: + +\begin{formulae} + \item $\RawPedersenCommit{\ValueCommitRand}(D, \Value) = + \scalarmult{\Value}{\ValueCommitBase} + \scalarmult{\ValueCommitRand}{\FindGroupJHashOf{D, ascii{}}}$ +\end{formulae} + + +See \crossref{cctrawcommit} for rationale and efficient circuit implementation +of this function. + +The commitment scheme $\ValueCommit{}$ specified in \crossref{abstractcommit} is +instantiated using $\RawPedersenCommit{}$ as follows: + +\begin{formulae} + \item $\ValueCommit{\ValueCommitRand}(\Value) := + \RawPedersenCommit{\ValueCommitRand}(\ascii{Zcash\_cv}, \Value)$. +\end{formulae} + +\begin{securityrequirements} + \item $\RawPedersenCommitAlg$ must be a computationally binding and at least + computationally hiding \commitmentScheme, for a given personalization input $D$. + \item $\ValueCommitAlg$ must be a computationally binding and at least + computationally hiding \commitmentScheme. +\end{securityrequirements} + +(They are in fact unconditionally hiding \commitmentSchemes.) +} + + \introsection \nsubsubsection{\RepresentedGroupsAndPairings} \label{concretepairing} @@ -4220,7 +4594,7 @@ $\GenG{1}$ and $\GenG{2}$ are generators of $\GroupG{1}$ and $\GroupG{2}$ respec \bitbox{20}{$0$} & \bitbox{20}{$1$} & \bitbox{80}{$1$-bit $\tilde{y}$} & - \bitbox{256}{$256$-bit $\ItoOSP{32}(x)$} + \bitbox{256}{$256$-bit $\ItoBEBSP{256}(x)$} \end{bytefield} \end{lrbox} @@ -4236,13 +4610,12 @@ $\GenG{1}$ and $\GenG{2}$ are generators of $\GroupG{1}$ and $\GroupG{2}$ respec \bitbox{20}{$0$} & \bitbox{20}{$1$} & \bitbox{80}{$1$-bit $\tilde{y}$} & - \bitbox{512}{$512$-bit $\ItoOSP{64}(x)$} + \bitbox{512}{$512$-bit $\ItoBEBSP{512}(x)$} \end{bytefield} \end{lrbox} -Define $\ItoOSP{} \typecolon (k \typecolon \Nat) \times \range{0}{256^k\!-\!1} \rightarrow -\typeexp{\range{0}{255}}{k}$ such that $\ItoOSP{\ell}(n)$ is the sequence of $\ell$ bytes -representing $n$ in big-endian order. +Define $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \range{0}{2^\ell\!-\!1} \rightarrow +\bitseq{\ell}$ as in \crossref{endian}. \introlist For a point $P \typecolon \GroupGstar{1} = (\xP, \yP)$: @@ -4273,7 +4646,7 @@ For a point $P \typecolon \GroupGstar{2} = (\xP, \yP)$: \subparagraph{Non-normative notes:} \begin{itemize} - \item The use of big-endian byte order is different from the encoding + \item The use of big-endian order by $\ItoBEBSP{}$ is different from the encoding of most other integers in this protocol. The encodings for $\GroupGstar{1, 2}$ are consistent with the definition of $\ECtoOSP{}$ for compressed curve points in @@ -4305,7 +4678,7 @@ the square root exists, or that the encoding represents a point on the curve. \bitbox{20}{$1$} & \bitbox{20}{$0$} & \bitbox{80}{$1$-bit $\tilde{y}$} & - \bitbox{381}{$381$-bit $\ItoBSP{381}(x)$} + \bitbox{381}{$381$-bit $\ItoBEBSP{381}(x)$} \end{bytefield} \end{lrbox} @@ -4316,8 +4689,8 @@ the square root exists, or that the encoding represents a point on the curve. \bitbox{20}{$1$} & \bitbox{20}{$0$} & \bitbox{80}{$1$-bit $\tilde{y}$} & - \bitbox{381}{$381$-bit $\ItoBSP{381}(x_1)$} & - \bitbox{384}{$384$-bit $\ItoBSP{384}(x_2)$} + \bitbox{381}{$381$-bit $\ItoBEBSP{381}(x_1)$} & + \bitbox{384}{$384$-bit $\ItoBEBSP{384}(x_2)$} \end{bytefield} \end{lrbox} @@ -4373,6 +4746,9 @@ Let $\GenS{2} \typecolon \GroupSstar{2} =\;$ $\GenS{1}$ and $\GenS{2}$ are generators of $\GroupS{1}$ and $\GroupS{2}$ respectively. +Define $\ItoBEBSP{} \typecolon (\ell \typecolon \Nat) \times \range{0}{2^\ell\!-\!1} \rightarrow +\bitseq{\ell}$ as in \crossref{endian}. + \introlist For a point $P \typecolon \GroupSstar{1} = (\xP, \yP)$: @@ -4405,9 +4781,7 @@ For a point $P \typecolon \GroupSstar{2} = (\xP, \yP)$: \subparagraph{Non-normative notes:} \begin{itemize} - \item The use of big-endian byte order is different from the encoding - of most other integers in this protocol. - The encodings for $\GroupSstar{1, 2}$ are specific to \Zcash. + \item The encodings for $\GroupSstar{1, 2}$ are specific to \Zcash. \item The points at infinity $\ZeroS{1, 2}$ never occur in proofs and have no defined encodings in this protocol. \item Algorithms for decompressing points from the encodings of @@ -4449,11 +4823,10 @@ $\GroupJ$ has order $8 \smult \ParamJ{r}$. Let $\ellJ = 256$. Define $\ItoLEBSP{} \typecolon (\ell \typecolon \Nat) \times \range{0}{2^\ell\!-\!1} \rightarrow \bitseq{\ell}$ -such that $\ItoLEBSP{\ell}(x)$ is the sequence of $\ell$ bits representing $x$ in -little-endian order. +as in \crossref{endian}. Define $\reprJ \typecolon \GroupJ \rightarrow \bitseq{\ellJ}$ such -that $\reprJ(u, \varv) = \ItoLEBSP{256}(\varv + 2^{255} \smult \tilde{u})$, where +that $\reprJOf{u, \varv} = \ItoLEBSP{256}(\varv + 2^{255} \smult \tilde{u})$, where $\tilde{u} = u \bmod 2$. \todo{Representing this as a bit string is problematic because we normally encode @@ -4464,7 +4837,7 @@ the representation as an integer?} Let $\abstJ \typecolon \bitseq{\ellJ} \rightarrow \GroupJ \union \setof{\bot}$ be the left inverse of $\reprJ$ such that if $S$ is not in the range of -$\reprJ$, then $\abstJ(S) = \bot$. +$\reprJ$, then $\abstJOf{S} = \bot$. \introlist \subparagraph{Non-normative notes:} @@ -4546,13 +4919,15 @@ is injective on points in $G$. Let $\CRS$ be the $64$-byte \commonRandomString given by the $\SHAd$ hash (expressed as an ASCII lowercase hex string in RPC byte order \cite{Bitc-ByteOrder}) of the first \block in the eventual consensus \Bitcoin \blockchain having -timestamp at or after 2018-03-01 00:00:00 UTC. +timestamp at or after 2018-03-01 00:00:00 UTC. \todo{this will probably change +to use the MPC randomness beacon.} Let $\BlakeTwos{256}$ be as defined in \crossref{concreteblake2}. -Let $D$ be an $8$-byte domain separator. +Let $\abstJ$ be as defined in \crossref{jubjub}. -Let $T$ be the hash input. +Let $D \typecolon \byteseq{8}$ be an $8$-byte domain separator, and +let $M \typecolon \byteseqs$ be the hash input. The hash $\GroupJHash{\CRS}(D, M)$ is calculated as follows: @@ -4565,16 +4940,13 @@ The hash $\GroupJHash{\CRS}(D, M)$ is calculated as follows: \begin{formulae} \item $\Justthebox{\ghintbox} := \BlakeTwos{256}(D,\, \CRS \bconcat\, M))$ - \item $P := \abstJ(p)$ + \item $P := \abstJOf{p}$ \item If $P = \bot$ then return $\bot$. \item $Q := \scalarmult{8}{P}$ \item If $Q = \ZeroJ$ then return $\bot$, else return $Q$. \end{formulae} -Define $\ItoOSPvar \typecolon \Nat \rightarrow \byteseqs$ -so that $\ItoOSPvar(i)$ is the shortest little-endian encoding of $i$ -as a byte sequence, i.e. so that the encoding does not end in a zero -byte. ($\ItoOSPvar(0) = []$.) +Define $\ItoLEOSPvar \typecolon \Nat \rightarrow \byteseqs$ as in \crossref{endian}. Define $\first \typecolon (\Nat \rightarrow T \union \setof{\bot}) \rightarrow T$ so that $\first(f) = f(i)$ where $i$ is the least nonnegative integer @@ -4582,7 +4954,7 @@ such that $f(i) \neq \bot$. (For our use of $\first$, such an $i$ always exists.) Let $\FindGroupJHashOf{D, M} = -\first(\fun{i \typecolon \Nat}{\GroupJHash{\CRS}(D, M \bconcat \ItoOSPvar(i)) \typecolon \GroupJ})$. +\first(\fun{i \typecolon \Nat}{\GroupJHash{\CRS}(D, M \bconcat \ItoLEOSPvar(i)) \typecolon \GroupJ})$. \begin{pnotes} \item The $\BlakeTwos{256}$ chaining variable after processing $\CRS$ @@ -4731,17 +5103,18 @@ verifier \MUST check, for the encoding of each element, that: As explained in \crossref{noteptconcept}, transmitted \notes are stored on the \blockchain in encrypted form. +% FIXME duplication with {noteptconcept}. + The \notePlaintexts in a \joinSplitDescription are encrypted to the respective \transmissionKeys $\TransmitPublicNew{\allNew}$. Each \notsprout{\Sprout} \notePlaintext (denoted $\NotePlaintext{}$) consists of $(\Value, \NoteAddressRand, \NoteCommitRand\changed{, \Memo})$. -\saplingonly{ +\saplingonward{ The \notePlaintext in each \outputDescription is encrypted to the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$. Each \Sapling \notePlaintext (denoted $\NotePlaintext{}$) consists of -$(\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteAddressRand, -\NoteCommitRand, \Memo)$. +$(\Diversifier, \Value, \NoteCommitRand, \Memo)$. } \changed{$\Memo$ is a 512-byte \memo associated with this \note. @@ -4807,7 +5180,6 @@ The encoding of a \Sapling \notePlaintext consists of: \bitbox{192}{$8$-bit $\NotePlaintextLeadByteSapling$} \bitbox{224}{$88$-bit $\Diversifier$} \bitbox{192}{$64$-bit $\Value$} - \bitbox{256}{$256$-bit $\NoteAddressRand$} \bitbox{256}{$256$-bit $\NoteCommitRand$} \changed{\bitbox{800}{$\Memo$ ($512$ bytes)}} \end{bytefield} @@ -4818,7 +5190,6 @@ The encoding of a \Sapling \notePlaintext consists of: encoding of a \Sapling \notePlaintext. \item $11$ bytes specifying $\Diversifier$. \item $8$ bytes specifying $\Value$. - \item $32$ bytes specifying $\NoteAddressRand$. \item $32$ bytes specifying $\NoteCommitRand$. \item $512$ bytes specifying $\Memo$. \end{itemize} @@ -4964,7 +5335,7 @@ cause the first two characters of the Base58Check encoding to be fixed as \sapling{ \nsubsubsection{\Sapling \PaymentAddresses} \label{saplingpaymentaddrencoding} -A \Sapling \paymentAddress consists of $\Diversifier \typecolon \bitseq{\DiversifierLength}$ +A \Sapling \paymentAddress consists of $\Diversifier \typecolon \DiversifierType$ and $\DiversifiedTransmitPublic \typecolon \KASaplingPublic$. $\Diversifier$ is a bit sequence, encoded as 11 bytes. @@ -4978,7 +5349,7 @@ The raw encoding of a \Sapling \paymentAddress consists of: \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{344} \bitbox{88}{$88$-bit $\Diversifier$} - \bitbox{256}{$256$-bit $\reprJ(\DiversifiedTransmitPublic)$} + \bitbox{256}{$256$-bit $\reprJOf{\DiversifiedTransmitPublic}$} \end{bytefield} \end{equation*} @@ -5049,11 +5420,11 @@ cause the first four characters of the Base58Check encoding to be fixed as \sapling{ \nsubsubsection{\Sapling \IncomingViewingKeys} \label{saplinginviewingkeyencoding} -A \Sapling \incomingViewingKey consists of $\InViewingKey \typecolon \KASproutPrivate$. +A \Sapling \incomingViewingKey consists of $\InViewingKey \typecolon \KASproutPrivate$ +(see \crossref{concretesaplingkeyagreement}). -$\InViewingKey$ is a $\KASproutPrivate$ key (see \crossref{concretesaplingkeyagreement}), -for use with the encryption scheme defined in \crossref{inband}. -It is derived as described in \crossref{saplingkeycomponents}. +$\InViewingKey$ is a $\KASproutPrivate$ key for use with the encryption scheme +defined in \crossref{inband}. It is derived as described in \crossref{saplingkeycomponents}. \introlist The raw encoding of an \incomingViewingKey consists of: @@ -5091,8 +5462,8 @@ The raw encoding of a \fullViewingKey consists of: \vspace{2ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{512} - \bitbox{256}{$256$-bit $\reprJ(\AuthSignPublic)$} - \bitbox{256}{$256$-bit $\reprJ(\AuthProvePublic)$} + \bitbox{256}{$256$-bit $\reprJOf{\AuthSignPublic}$} + \bitbox{256}{$256$-bit $\reprJOf{\AuthProvePublic}$} \end{bytefield} \end{equation*} @@ -5288,6 +5659,8 @@ for use by \Sapling \transactions. \nsubsection{Encoding of \Transactions} \label{txnencoding} +\nuzero{\pnote{This section has not yet been updated for v3 transactions; see ZIP 202.}} + The \Zcash \transaction format is as follows: \begin{center} @@ -5334,16 +5707,18 @@ The encoding of $\joinSplitPubKey$ and the data to be signed are specified in \begin{consensusrules} \sproutonlyitem{The \transactionVersionNumber{} \MUST be greater than or equal to $1$.} - \saplingonlyitem{The \transactionVersionNumber{} \MUST be \todo{}.} +\notsprout{ + \sproutonlyitem{The $\fOverwintered$ flag \MUSTNOT be set.} +} + \nuzeroonlyitem{The \transactionVersionNumber{} \MUST be $3$. \todo{is this a consensus rule?}} + \saplingonwarditem{The \transactionVersionNumber{} \MUST be $3$ or $4$. \todo{is this a consensus rule?}} \item If $\versionField = 1$ or $\nJoinSplit = 0$, then \txInCount{} \MUSTNOT be $0$. \item A \transaction with one or more inputs from \coinbaseTransactions{} \MUST have no \transparent outputs (i.e.\ \txOutCount{} \MUST be $0$). \item If $\nJoinSplit > 0$, then \joinSplitSig{} \MUST represent a valid signature over $\dataToBeSigned$ as defined in \crossref{nonmalleability}. - \item If $\nJoinSplit > 0$, then \joinSplitPubKey{} \MUST represent a point of order $\ell$ - on the Ed25519 curve, in the encoding specified by \cite{BDLSY2012}. Note that it is - \emph{not} required that the encoding of the y-coordinate of the public key is - less than $2^{255}-19$. + \item If $\nJoinSplit > 0$, then \joinSplitPubKey{} \MUST represent a valid + $\JoinSplitSigSpecific$ public key encoding as specified in \crossref{concretejssig}. \sproutonlyitem{The encoded size of the \transaction{} \MUST be less than or equal to $100000$ bytes.} \item A \coinbaseTransaction{} \MUSTNOT have any @@ -5355,36 +5730,33 @@ The encoding of $\joinSplitPubKey$ and the data to be signed are specified in \end{consensusrules} \begin{pnotes} -\sprout{ - \item The semantics of \transactions with \transactionVersionNumber not equal to + \item The semantics of \transactions with \transactionVersionNumber not equal to\sprout{ either $1$ or $2$ is not currently defined. Miners \MUSTNOT create \blocks containing such \transactions. +}\notsprout{ + $1$, $2$, \nuzero{$3$,}\sapling{ or $4$} is not currently defined. + Miners \MUSTNOT create \blocks before the \NUZero \activationHeight + containing \transactions with version other than $1$ or $2$. +} \item The exclusion of \transactions with \transactionVersionNumber - \emph{greater than} $2$ is not a consensus rule. Such \transactions may - exist in the \blockchain and \MUST be treated identically to version $2$ - \transactions. -} -\sapling{ - \item The semantics of \transactions with \transactionVersionNumber not equal to - $1$, $2$, or \todo{} is not currently defined. Miners \MUSTNOT create \blocks - before the \Sapling fork height containing \transactions with version - other than $1$ or $2$, and \MUSTNOT create \blocks at or after the \Sapling - fork height containing \transactions with version other than \todo{}. - \item The exclusion of \transactions with \transactionVersionNumber greater than - $2$ for \Sprout, or in the range \todo{} for \Sapling, is not a - consensus rule. Such \transactions may exist in the \blockchain and \MUST - be treated identically to version $2$ \transactions before the \Sapling fork - height, or to version \todo{} \transactions at or after the \Sapling fork - height. -} + \emph{greater than} $2$ is not a consensus rule\notsprout{ before \NUZero activation}. + Such \transactions may exist in the \blockchain and \MUST be treated + identically to version $2$ \transactions. + \nuzeroonwarditem{Once \NUZero has activated, limits on the maximum + \transactionVersionNumber are consensus rules.} \item Note that a future hard fork might use \emph{any} \transactionVersionNumber. It is likely that a hard fork that changes the \transactionVersionNumber will also change the \transaction format, and software that parses \transactions{} \SHOULD take this into account. +\sprout{ \item The $\versionField$ field is a signed integer. (It was incorrectly specified as unsigned in a previous version of this specification.) A future hard fork might \sprout{use negative values for this field, or otherwise} change its - interpretation. \nuzero{TODO} + interpretation. +} +\nuzero{ + \item \todo{Describe interpretation of $\fOverwintered$ and $\versionField$.} +} \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 \Bitcoin v0.11.2 @@ -5475,7 +5847,7 @@ The \Zcash \blockHeader format is as follows: \begin{center} \hbadness=2500 -\begin{tabularx}{0.92\textwidth}{|c|l|p{10.7em}|X|} +\begin{tabularx}{0.92\textwidth}{|c|l|p{8.6em}|X|} \hline Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ \hhline{|=|=|=|=|} @@ -5492,7 +5864,12 @@ $32$ & $\hashMerkleRoot$ & \type{char[32]} & A $\SHAd$ hash in internal byte ord 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$ & $\hashReserved$ & \type{char[32]} & A reserved field which should be ignored. \\ \hline +$32$ & \sprout{$\hashReserved$} +\notsprout{\Longunderstack[l]{$\hashReserved$ /\\ \sapling{$\hashFinalSaplingRoot$}}} & +\type{char[32]} & +\sproutonly{A reserved field which should be ignored.} +\saplingonward{A \merkleRoot (\todo{specify bit sequence to byte sequence conversion}) of the \Sapling{} +\noteCommitmentTree corresponding to the final \Sapling{} \treestate of this \block.} \\ \hline $4$ & $\nTimeField$ & \type{uint32\_t} & The \blockTime is a Unix epoch time (UTC) when the miner started hashing the \header (according to the miner). \\ \hline @@ -5519,15 +5896,17 @@ Let $\ThresholdBits$ be as defined in \crossref{diffadjustment}, and let $\PoWMe be the constant defined in \crossref{constants}. \begin{consensusrules} - \sproutonlyitem{The \blockVersionNumber{} \MUST be greater than or equal to $4$.} - \saplingonlyitem{The \blockVersionNumber{} \MUST be \todo{}.} - \item For a \block at \blockHeight $\BlockHeight$, \nBitsField{} \MUST be equal to + \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 valid Equihash solution as defined in \crossref{equihash}. - \item \nTimeField{} \MUST be strictly greater than the median time of the previous + \item $\solution$ \MUST represent a valid Equihash solution as defined in \crossref{equihash}. + \item $\nTimeField$ \MUST be strictly greater than the median time of the previous $\PoWMedianBlockSpan$ \blocks. \item The size of a \block{} \MUST be less than or equal to $2000000$ bytes. + \saplingonwarditem{$\hashFinalSaplingRoot$ \MUST be the \merkleRoot of the + \Sapling{} \noteCommitmentTree for the final \Sapling{} \treestate + of this \block.} \item \todo{Other rules inherited from \Bitcoin.} \end{consensusrules} @@ -5562,6 +5941,14 @@ rejected by this rule at a given point in time may later be accepted. the median of the timestamps of the past $\PoWMedianBlockSpan$ \blocks. The Bitcoin Developer Reference \cite{Bitc-Block} was previously in error on this point, but has now been corrected. +\nuzero{ + \item There are no changes to the \blockVersionNumber or format for \NUZero. +} +\sapling{ + \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. +} \end{pnotes} \introlist @@ -5569,7 +5956,8 @@ The changes relative to \Bitcoin version $4$ blocks as described in \cite{Bitc-B \begin{itemize} \item \Blockversions less than $4$ are not supported. - \item The $\hashReserved$, $\solutionSize$, and $\solution$ fields have been added. + \item The $\hashReserved$\sapling{ (or $\hashFinalSaplingRoot$)}, $\solutionSize$, and + $\solution$ fields have been added. \item The type of the $\nNonce$ field has changed from \type{uint32\_t} to \type{char[32]}. \item The maximum \block size has been doubled to $2000000$ bytes. \end{itemize} @@ -5626,9 +6014,8 @@ For $i \in \range{1}{N}$, let $X_i = \EquihashGen{n, k}(\powheader, i)$. $\EquihashGen{}$ is instantiated in \crossref{equihashgen}. -Define $\ItoBSP{} \typecolon (u \typecolon \Nat) \times \range{0}{2^u\!-\!1} \rightarrow \bitseq{u}$ -such that $\ItoBSP{u}(x)$ is the sequence of $u$ bits representing $x$ in -big-endian order. +Define $\ItoBEBSP{} \typecolon (u \typecolon \Nat) \times \range{0}{2^u\!-\!1} \rightarrow \bitseq{u}$ +as in \crossref{endian}. A \validEquihashSolution is then a sequence $i \typecolon \range{1}{N}^{2^k}$ that satisfies the following conditions: @@ -5663,10 +6050,10 @@ field of a \blockHeader as follows: \newsavebox{\solutionbox} \begin{lrbox}{\solutionbox} \begin{bytefield}[bitwidth=0.45em]{105} - \bitbox{21}{$\ItoBSP{21}(i_1-1)$} & - \bitbox{21}{$\ItoBSP{21}(i_2-1)$} & + \bitbox{21}{$\ItoBEBSP{21}(i_1-1)$} & + \bitbox{21}{$\ItoBEBSP{21}(i_2-1)$} & \bitbox{42}{$\cdots$} & - \bitbox{21}{$\ItoBSP{21}(i_{512}-1)$} + \bitbox{21}{$\ItoBEBSP{21}(i_{512}-1)$} \end{bytefield} \end{lrbox} @@ -5675,9 +6062,9 @@ field of a \blockHeader as follows: \newsavebox{\eqexamplebox} \begin{lrbox}{\eqexamplebox} \begin{bytefield}[bitwidth=0.75em]{63} - \bitbox{21}{$\ItoBSP{21}(68)$} & - \bitbox{21}{$\ItoBSP{21}(41)$} & - \bitbox{21}{$\ItoBSP{21}(2^{21}-1)$} \\ + \bitbox{21}{$\ItoBEBSP{21}(68)$} & + \bitbox{21}{$\ItoBEBSP{21}(41)$} & + \bitbox{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 \\ @@ -5710,7 +6097,7 @@ and so the first $7$ bytes of $\solution$ would be $[0, 2, 32, 0, 10, 127, 255]$. \pnote{ -$\ItoBSP{}$ is big-endian, while integer field encodings in $\powheader$ +$\ItoBEBSP{}$ is big-endian, while integer field encodings in $\powheader$ and in the instantiation of $\EquihashGen{}$ are little-endian. The rationale for this is that little-endian serialization of \blockHeaders is consistent with \Bitcoin, but using little-endian @@ -6091,7 +6478,7 @@ 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. -\saplingonly{ +\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 @@ -6102,8 +6489,8 @@ 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 inputs and outputs -are still possible. +exact number of \shielded inputs and outputs, but dummy (zero-valued) +outputs are still possible. } \nsubsection{Faerie Gold attack and fix} \label{faeriegold} @@ -6228,27 +6615,20 @@ dummy), and so a roadblock attack cannot be performed by another party who does not know these keys. } -\saplingonly{ -In \Sapling, uniqueness of $\NoteAddressRand$ is ensured as follows: -The creator of a transaction generates a new $\EdJubjub$ (public, private) -key pair where the public key is $\OutputUnique$. The \outputUniquenessSet -is used to ensure $\OutputUnique$ values are not repeated. $\OutputUnique$ -is then used in a similar way to $\hSig$ in \Sprout; we use it as input -to a \xPedersenCommitment $\UniqueCommit{}$, together with a -unique-per-\transaction output index $\OutputIndex$ and a random key -$\NoteAddressPreRand$, to derive $\NoteAddressRand$ for each \shieldedOutput. -The correct construction of $\NoteAddressRand$ for each output \note is -enforced by the \outputStatement. -In the same way that collision-resistance of $\PRFrho{}$ on its inputs -and key ensures uniqueness of derived $\NoteAddressRand$ values in \Sprout, -collision-resistance of $\UniqueCommit{}$ on its inputs and key ensures -uniqueness of derived $\NoteAddressRand$ values in \Sapling, at least -for any two \outputDescriptions that get into a \validBlockchain. -(The collision-resistance proof for \xPedersenHashes extends to -\xPedersenCommitments.) The private key corresponding to $\OutputUnique$ -is used to sign the $\SIGHASHALL$ hash (\todo{check}) of the \transaction, -and so a roadblock attack cannot be performed by another party who does not -know this key. +\saplingonward{ +In \Sapling, uniqueness of $\NoteAddressRand$ is ensured by making it +dependent on the position of the \noteCommitment in the \Sapling{} +\noteCommitmentTree. Specifically, +$\NoteAddressRand = \cm + \scalarmult{\NotePosition}{\NotePositionBase}$, +where $\NotePositionBase$ is a generator independent of the generators +used in $\NoteCommitSaplingAlg$. Therefore, $\NoteAddressRand$ commits uniquely +to the \note and its position, and this commitment is collision-resistant +by the same argument used to prove collision resistance of \xPedersenHashes. +Note that it is possible for two distinct \Sapling \positionedNotes (having +different $\NoteAddressRand$ 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. } @@ -6300,7 +6680,7 @@ for this use at a 128-bit security level, the overhead of doing so within the \joinSplitStatement was not considered to justify the benefits. } -\saplingonly{ +\saplingonward{ In \Sapling, \xPedersenCommitments are used instead of $\SHACompress$. These commitments are statistically hiding, and so ``everlasting anonymity'' is supported for \Sapling notes under the same conditions as in \Zerocash @@ -6406,7 +6786,8 @@ The motivations for this change were as follows: performance, implementation complexity, and robustness advantages over most other available curve choices, as explained in \cite{Bern2006}. \sapling{For \Sapling, the $\JubjubCurve$ curve was designed according to a - similar design process following the ``Safe curves'' criteria \cite{BL-SafeCurves}. + similar design process following the ``Safe curves'' criteria + \cite{BL-SafeCurves} \cite{GitHub-jubjub}. This retains Curve25519's advantages while keeping \paymentAddress sizes short, because the same public key material supports both encryption and spend authentication.} @@ -6449,7 +6830,7 @@ The motivations for this change were as follows: with knowledge of $\AuthPrivateOld{\allOld}$, so an adversary cannot modify it in a ciphertext from someone else's transaction for use in a chosen-ciphertext attack without detection.} - \sapling{In \Sapling, $\OutputUnique$ plays a similar rôle as a public seed.} + \sapling{In \Sapling, there is no equivalent to $\hSig$. \todo{Explain why this is ok.}} \item \sproutonly{The scheme used by \SproutOrZcash includes an optimization that reuses the same ephemeral key (with different nonces) for the two ciphertexts encrypted in each \joinSplitDescription.} @@ -6567,7 +6948,8 @@ Mike Perry, Isis Lovecruft, Leif Ryge, Andrew Miller, Zooko Wilcox, Samantha Hulsey, Jack Grigg, Simon Liu, Ariel Gabizon, jl777, Ben Blaxill, Alex Balducci, Jake Tarren, Solar Designer, Ling Ren, Alison Stevenson, John Tromp, Paige Peterson, Maureen Walsh, Jay Graber, Jack Gavigan, -Filippo Valsorda, Zaki Manian, George Tankersley, and no doubt others. +Filippo Valsorda, Zaki Manian, George Tankersley, Tracy Hu, +and no doubt others. \Zcash has benefited from security audits performed by NCC Group and Coinspect. @@ -6594,6 +6976,21 @@ Daira Hopwood, Sean Bowe, and Jack Grigg. \begin{itemize} \item Split the descriptions of $\SHAFull$ and $\SHACompress$\sapling{, and of $\BlakeTwoGeneric$,} into their own sections. Specify $\SHACompress$ more precisely. + \item Add Tracy Hu to acknowledgements\sapling{ (for the idea of explicitly + encoding the root of the \Sapling \noteCommitmentTree in \blockHeaders)}. +\sapling{ + \item Refer to \NUZero and \Sapling just as ``upgrades'' in the abstract, not as + the next ``minor version'' and ``major version''. + \item $\PRFnr{}$ must be collision-resistant. + \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{thmdistinctxcriterion}) + to allow negative indices. +} \end{itemize} \introlist @@ -6745,7 +7142,7 @@ Daira Hopwood, Sean Bowe, and Jack Grigg. \begin{itemize} \item Clarify the consensus rule preventing double-spends. \item Clarify what a \noteCommitment opens to in \crossref{crprf}. - \item Correct the order of arguments to $\CommitAlg$ in \crossref{concretecomm}. + \item Correct the order of arguments to $\CommitAlg$ in \crossref{concretesproutcommit}. \item Correct a statement about indistinguishability of \joinSplitDescriptions. \item Change the \foundersReward addresses, for the test network only, to reflect the hard fork described in \cite{ZcashIssue-2113}. @@ -6767,7 +7164,7 @@ Daira Hopwood, Sean Bowe, and Jack Grigg. \begin{itemize} \item Specify the security requirements on the $\shaCompress$ function in order - for the scheme in \crossref{concretecomm} to be a secure commitment. + for the scheme in \crossref{concretesproutcommit} to be a secure commitment. \item Specify $\GroupG{2}$ more precisely. \item Explain the use of interstitial \treestates in chained \joinSplitTransfers. \end{itemize} @@ -7075,15 +7472,16 @@ Here $\times$ and $\mult$ both represent multiplication in the field $\GF{\Param but we use $\times$ for multiplications corresponding to gates of the circuit, and $\mult$ for multiplications by constants in the terms of a \linearCombination. -\nsubsection{Elliptic curve background} +\nsubsection{Elliptic curve background} \label{ecbackground} The circuit makes use of a twisted Edwards curve, $\JubjubCurve$, and also a Montgomery curve that is birationally equivalent to $\JubjubCurve$. -From here on we omit ``twisted'' when referring to twisted Edwards curves or -coordinates. By convention we use $(u, \varv)$ for affine coordinates on the Edwards -curve, and $(x, y)$ for affine coordinates on the Montgomery curve. +From here on we omit ``twisted'' when referring to the Edwards $\JubjubCurve$ +curve or coordinates. By convention we use $(u, \varv)$ for affine coordinates +on the Edwards curve, and $(x, y)$ for affine coordinates on the Montgomery curve. -The Montgomery curve has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = -40964$. +\introlist +The Montgomery curve has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$. We use an affine representation of this curve with the formula: \begin{formulae} @@ -7127,6 +7525,28 @@ 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 +Montgomery curves. + +\fact{$\ParamM{A}^2 - 4$ is a nonsquare in $\GF{\ParamJ{r}}$.} + +\begin{theorem} \label{thmmontynotzero} +Let $P = (x, y)$ be a point other than $(0, 0)$ on a Montgomery curve +over $\GF{r}$ with parameter $A$, such that $A^2 - 4$ is a nonsquare in $\GF{r}$. +Then $y \neq 0$. +\end{theorem} + +\begin{proof} +Substituting $y = 0$ into the Montgomery curve 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 @@ -7136,7 +7556,17 @@ 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 follow the convention that components +typically boolean-constrain their inputs when needed, but not their outputs. +Exceptions to this convention are explicitly noted. +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. + +\introlist \nsubsubsection{Boolean constraints} \label{cctboolean} A boolean constraint $b \in \bit$ can be implemented as: @@ -7156,6 +7586,80 @@ A selection constraint $b \bchoose x : y = z$, where $b \in \bit$, can be implem \end{formulae} +\introlist +\nsubsubsection{Nonzero constraints} \label{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, +$\ainv = a^{-1} \pmod{\ParamS{r}}$: + +\begin{formulae} + \item $\constraint{\ainv}{a}{1}$ +\end{formulae} + +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 to give $a = \vproduct{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. + + +\introsection +\nsubsubsection{Not-all-one constraints} \label{cctnotallone} + +Given a sequence $b_{\barerange{0}{n-1}}$ of variables that have already been +boolean-constrained, we can assert that they are not all one by letting +$a = -n + \vsum{i=0}{n-1} b_i$, and asserting $a \neq 0$ as in the previous +section: + +\begin{formulae} + \item $\constraint{\ainv}{-n + \vsum{i=0}{n-1} b_i}{1}$ +\end{formulae} + +(This assumes $n < \ParamS{r}$ which is in practice always the case.) + + +\introsection +\nsubsubsection{Unpacking} \label{cctunpack} + +A field element $a$ may need to be ``unpacked'' to a sequence of boolean +variables $b_{\barerange{0}{n-1}} \typecolon \bitseq{n}$, so that +$a = \vsum{i=0}{n-1} b_i \mult 2^i$. + +\introlist +This costs $n$ constraints to boolean-constrain $b_{\barerange{0}{n-1}}$ +as in \crossref{cctboolean}, and one constraint that equates the sum with +$a$: + +\begin{formulae} + \item $\constraint{\vsum{i=0}{n-1} b_i \mult 2^i}{1}{a}$ +\end{formulae} + +\pnote{ +Since the last constraint has only a trivial multiplication, it is +possible to eliminate it by expressing one of the output bits 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. +\todo{Do we want to use it internally to the BLAKE2s implementation where +modularity is not significantly affected?} +} + +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 $\ItoLEBSP{255}(a)$ and $\ItoLEBSP{255}(a + \ParamS{r})$. +This is a potential hazard, but it may or may not be necessary to force use +of the canonical representation $\ItoLEBSP{255}(a)$, depending on the context +in which the unpacking operation is used. We therefore do not consider this +to be part of the unpacking operation itself. + +\todo{Check where canonical $255$-bit unpackings are needed. They are not +needed for the Merkle path check.} + + +\introlist \nsubsubsection{Checking that affine Edwards coordinates are on the curve} \label{cctedvalidate} To check that $(u, \varv)$ is a point on the Edwards curve, use: @@ -7187,28 +7691,71 @@ Define $\EdwardsToMont \typecolon \AffineEdwardsJubjub \rightarrow \AffineMontJu as follows: \begin{formulae} - \item $\EdwardsToMont(u, \varv) = \left(\hfrac{1 + \varv}{1 - \varv}, \hfrac{1 + \varv}{(1 - \varv) \mult u}\right)$ + \item $\EdwardsToMont(u, \varv) = \left(\hfrac{1 + \varv}{1 - \varv}, + \scalebox{0.8}{$\ssqrt{-40964}$} \mult \hfrac{1 + \varv}{(1 - \varv) \mult u}\right) + \sidecondition{1 - \varv \neq 0 \tand u \neq 0}$ \end{formulae} +\introlist Define $\MontToEdwards \typecolon \AffineMontJubjub \rightarrow \AffineEdwardsJubjub$ as follows: \begin{formulae} - \item $\MontToEdwards(x, y) = \left(\hfrac{x}{y}, \hfrac{x - 1}{x + 1}\right)$ + \item $\MontToEdwards(x, y) = \left(\scalebox{0.8}{$\ssqrt{-40964}$} \mult \hfrac{x}{y}, + \hfrac{x - 1}{x + 1}\right) + \sidecondition{x + 1 \neq 0 \tand y \neq 0}$ \end{formulae} +\introlist Either of these conversions can be implemented by the same \quadraticArithmeticProgram: \begin{formulae} - \item $\constraint{1 - \varv}{x}{1 + \varv}$ - \item $\constraint{u}{y}{x}$ -\end{formulae} - -\begin{formulae} - \item $\constraint{y}{u}{x}$ + \item $\constraint{y}{u}{\ssqrt{-40964} \mult x}$ \item $\constraint{x + 1}{\varv}{x - 1}$ \end{formulae} +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{1ex} +\begin{theorem} \label{thmconversiontomontnoexcept} +Let $(u, \varv)$ be an affine point on a complete twisted Edwards curve. +Then the only points with $u \neq 0$ or $\varv \neq 0$ +are $(0, 1) = \ZeroJ$; $(0, -1)$ of order $2$; and +$\left(\pm\, 1/\!\ssqrt{\ParamJ{a}}, 0\right)$ of order $4$. +\end{theorem} + +\begin{proof} +Straightforward from the curve equation. (The fact that the points +$\left(\pm\, 1/\!\ssqrt{\ParamJ{a}}, 0\right)$ are of order $4$ +can be inferred by applying the doubling formula.) +\end{proof} + +\vspace{0.5ex} +\begin{theorem} \label{thmconversiontoedwardsnoexcept} +Let $(x, y)$ be an affine point on a Montgomery curve over $\GF{r}$ +with parameter $A$ such that $A^2 - 4$ is a nonsquare in $\GF{r}$, +that is birationally equivalent to a complete twisted Edwards curve. +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 Montgomery curve equation gives +$\ParamM{B} \mult y^2 = x^3 + \ParamM{A}.x^2 + x = \ParamM{A} - 2$. +So in that case $y^2 = (\ParamM{A} - 2)/\ParamM{B}$. The right-hand-side is equal +to the parameter $d$ of a particular complete twisted Edwards curve birationally +equivalent to the Montgomery curve (see \cite[section 4.3.5]{BL2017}). +For all complete twisted Edwards curves, $d$ is nonsquare, so this equation +has no solutions for $y$, hence $x + 1 \neq 0$. +\end{proof} + +(The complete twisted Edwards curve referred to in the proof is an +isomorphic $y$-coordinate rescaling of the $\JubjubCurve$ curve.) + \introsection \nsubsubsection{Affine-Montgomery arithmetic} \label{cctmontarithmetic} @@ -7278,9 +7825,14 @@ Affine-Montgomery doubling can be implemented as: \item $\constraint{x - x_3}{\lambda}{y_3 + y}$ \end{formulae} -\nsubsubsection{Affine-Edwards arithmetic} \label{cctedarithmetic} +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 +\nsubsubsection{Affine-Edwards arithmetic} \label{cctedarithmetic} + Formulae for affine-Edwards 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: @@ -7351,15 +7903,11 @@ the resulting point is not $\ZeroJ$) by asserting that $u \neq 0$. On a twisted Edwards curve, only the zero point $\ZeroJ$, and the unique point of order $2$ at $(0, -1)$ have zero $u$-coordinate. -Since only non-zero elements of $\GF{\ParamS{r}}$ have a multiplicative inverse, the -assertion $u \neq 0$ can be implemented by witnessing the inverse, $\uinv$: +The assertion $u \neq 0$ can be implemented in a single constraint as described +in \crossref{cctnonzero}. -\begin{formulae} - \item $\constraint{\uinv}{u}{1}$ -\end{formulae} - -This costs $3 \mult 5$ constraints for the doublings and $1$ constraint for the check -on $u$, for a total of $16$ constraints. +The cost is therefore $3 \mult 5$ constraints for the doublings and $1$ constraint for +the check on $u$, for a total of $16$ constraints. In the case where we \emph{only} need to reject points of small order (less than $\ParamJ{r}$) and the result of cofactor multiplication is not needed, it is sufficient to double twice @@ -7440,17 +7988,19 @@ and one in the \outputCircuit, so the additional complexity was not considered justified for \Sapling. } -\nsubsubsection{Pedersen hashes} \label{cctpedersenhash} +\nsubsubsection{Pedersen hash} \label{cctpedersenhash} The specification of the \xPedersenHashes used in \Sapling is given in -\crossref{concretepedersenhash}. It is based on the scheme from \cite{BGG1995}, -but tailored to allow several optimizations in the circuit implementation. +\crossref{concretepedersenhash}. It is based on the scheme from +\cite[section 5.2]{CvHP1991} --for which a tighter security reduction to +the Discrete Logarithm Problem 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. $\MerkleDepthSapling$ \xPedersenHash instances are used in the \spendCircuit to check a Merkle path to the \noteCommitment of the \note being spent. We also reuse the \xPedersenHash implementation to -construct the commitments $\NoteCommitSaplingAlg$ and $\UniqueCommitAlg$. +construct the \commitmentScheme $\NoteCommitSaplingAlg$. This motivates considerable attention to optimizing this circuit implementation of this primitive, even at the cost of complexity. @@ -7474,106 +8024,89 @@ 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 Edwards curve and summing the intermediate results using Edwards addition. -If the resulting point is $R$, this calculation can be written as: +If the resulting point is $R$, then (abstracting away the changes of curve) +this calculation can be written as: \begin{formulae} - \item $R = \vsum{j=1}{N} \scalarmult{\PedersenEncode{M_j}}{\PedersenBase{D}{j}}$. + \item $\PedersenHashToPoint(D, M) = \vsum{j=1}{N} \scalarmult{\PedersenEncode{M_j}}{\PedersenGen{D}{j}}$ \end{formulae} -For simplicity the definition in \crossref{concretepedersenhash} was given -as a sum over the contribution of windows rather than segments. However, -with a suitable definition of $\PedersenEncode{\cdot}$, the above expression -matches the calculation of $R$ given in that section. +where $\PedersenEncode{\paramdot}$ and $\PedersenGen{D}{j}$ +are defined as in \crossref{concretepedersenhash}. -Pad the input to a multiple of $3$ bits, then split it into segments $M_{\barerange{1}{N}}$ -of length $3 \smult c$ bits for $c = 63$ (the last segment may be shorter). -Split each $M_j$ into $3$-bit chunks $M^{\barerange{1}{L_j}}_j$ where -$L_j = \length(M_j)/3$. Define: +We have to prove that: +\begin{itemize} + \item the \distinctXCriterion is met for all Montgomery additions within + a segment; + \item the Montgomery-to-Edwards conversions can be implemented without + exceptional cases. +\end{itemize} + +The proof of \theoremref{thmpedersenencodeinjective} showed that +all indices of addition inputs are in the range +$\rangenozero{-\hfrac{\ParamJ{r}-1}{2}}{\hfrac{\ParamJ{r}-1}{2}}$. + +Because the $\PedersenGen{D}{j}$ (which are outputs of $\GroupJHash{}$) +are all of prime order, and $\PedersenEncode{M_j} \neq 0 \pmod{\ParamJ{r}}$, +it is guaranteed that all of the terms +$\scalarmult{\PedersenEncode{M_j}}{\PedersenGen{D}{j}}$ +to be converted to Edwards form are of prime order. +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. + +\begin{theorem} \label{thmpedersendistinctabsindices} +For all disjoint nonempty subsets $S$ and $S'$ of $\range{1}{c}$, and for all +$m \in \typeexp{\bitseq{3}}{c}$, \begin{formulae} - \item $\PedersenEncode{M_j} = \vsum{i=1}{L_j} \enc(M^i_j) \mult 2^{(w+1) \mult (i-1)}$ + \item $\vsum{j \in S\vphantom{S'}}{} \enc(m_j) \mult 2^{4 \mult (j-1)} + \neq \pm\!\!\vsum{j' \in S'}{} \enc(m_{\kern -0.1em j'}) \mult 2^{4 \mult (j'-1)}$ \end{formulae} - -where $\enc \typecolon \bitseq{3} \rightarrow \Digits$ implements the encoding -of chunks as signed digits: - -\begin{formulae} - \item $\enc([s_0, s_1, s_2]) = (1 - 2 \smult s_2) \mult (1 + s_0 + 2 \smult s_1)$. -\end{formulae} - -\begin{theorem} -The encoding function -$\fun{M_j \typecolon \bitseq{3 \mult c}}{\PedersenEncode{M_j} \typecolon -\rangenozero{-\hfrac{\ParamJ{r}-1}{2}}{\hfrac{\ParamJ{r}-1}{2}}}$ -is injective. \end{theorem} \begin{proof} -We first need to check that the range of -$\vsum{i=1}{L_j} \enc(M^i_j) \mult 2^{(w+1) \mult (i-1)}$ is a subset of -the allowable range $\rangenozero{-\hfrac{\ParamJ{r}-1}{2}}{\hfrac{\ParamJ{r}-1}{2}}}$. -The range of this expression is obviously a subset of -$\rangenozero{-L}{L}$ where $L = 4 \mult \vsum{i=0}{c-1} 2^{4 \mult i} = 4 \mult \hfrac{2^{4 \mult c}}{15}$. +\todo{...} +%Since $\PedersenEncode{\paramdot}$ is injective, the given condition is +%equivalent to: -When $c = 63$, we have +%\begin{formulae} +% \item for all disjoint subsets $S$ and $S'$ of $\range{1}{c}$, and for all +% $M \in \bitseq{3 \mult c},\; \PedersenEncodeSub{S}{M} \neq \pm \PedersenEncodeSub{S'}{M}$ +%\end{formulae} -\begin{tabular}{@{\hskip 2em}r@{\;}l} - $4 \mult \hfrac{2^{4 \mult c}}{15}$ &$= \hexint{444444444444444444444444444444444444444444444444444444444444444}$ \\ - & \\[-2ex] - $\hfrac{\ParamJ{r}-1}{2}$ &$= \hexint{73EDA753299D7D483339D80809A1D8053341049E6640841684B872F6B7B965B}$ -\end{tabular} +%where $\PedersenEncodeSub{S}{M} = \vsum{j \in S}{} \enc(m_j) \mult 2^{4 \mult (j-1)}$. -so the required condition is met. +%This is in turn equivalent to: + +%\begin{formulae} +% \item for all disjoint subsets $S$ and $S'$ of $\range{1}{c}$, and for all +% $M \in \bitseq{3 \mult c},\; +% \PedersenEncodeSub{S}{M \band \Mask} \neq \PedersenEncodeSub{S'}{M \band \Mask}$ +%\end{formulae} + +%where $\Mask = \vsum{j=1}{c} 3 \mult 2^{4 \mult (j-1)}$. + +%(This masks off the bit controlling the sign of each digit, which effectively +%takes the absolute value of each digit.) + +%Since $S$ and $S'$ are disjoint and each term of the RHS is separated, +%it follows that $\Mask_S \band \Mask_{S'} = 0$ and so ... + +%Suppose this were not +%the case, then there would exist disjoint subsets of windows $S$ and $S'$ +%such that ..., the space of indices spanned by ... +%does not overlap the space spanned by $S'$. + +%is met because all of the terms in the Montgomery addition, as well as any +%intermediate result formed from adding a subset of terms, have distinct indices + +%(this bound makes no assumption about the order of additions; the actual +%maximum will be smaller). \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 this construction. - - -Now, we need to show that the indices of inputs to addition are -all distinct disregarding sign. - -\begin{theorem} -Let $S$ and $S'$ be disjoint subsets of $\range{0}{c-1}$. - -Let $\abs_s(x) = \begin{cases} - x, &\caseif x \bmod s < (-x) \bmod s\\ - -x, &\caseotherwise. - \end{cases}$ - -Then -$\setof{\abs\left(\vsum{i \in S }{} d_i \mult 2^{4 \mult i}\right) \suchthat d \in \typeexp{\Digits}{c}} \intersection - \setof{\abs\left(\vsum{i \in S'}{} d_i \mult 2^{4 \mult i}\right) \suchthat d \in \typeexp{\Digits}{c}}$ -\end{theorem} - -The motivation for this approach is to allow the use of Montgomery arithmetic -within each segment: the \distinctXCriterion is met because all of the terms -in the Montgomery addition, as well as any intermediate result formed from -adding a subset of terms, have distinct indices in $\range{1}{(\ParamJ{r}-1)/2}$. - -Then, the sums from each segment are converted to Edwards form and added using -the complete addition method from \crossref{cctedarithmetic}. - -%Let $\split(...)$ = ... - -%\begin{pnotes} -% \item $\PedersenEncode{M_i}$ is an injective encoding of $M_i$ into $\range{-3}{-1} \union \range{1}{3}$. -% The security proof in \cite[Appendix A]{BGG1995} (adapted to an additively-written group) -% only requires $\fun{M_i \typecolon \bitseq{3}}{\PedersenEncode{M_i} \typecolon \GF{\ParamJ{r}}}$ -% to be injective and never zero, and so this proof applies. -%\end{pnotes} - - -\begin{formulae} - \item $\PedersenHashSegment \typecolon \bitseq{249} \rightarrow \AffineEdwardsJubjub$ - - \item $\PedersenHashSegment(...) = \MontToEdwards(...)$ - - \item $\PedersenHashPoint(segment_{\range{1}{n}}) = \vsum{}{} \PedersenHashSegment(...)$ - \item $\PedersenHash(segment_{\range{1}{n}}) = \Selectu(\PedersenHashPoint(segment_{\range{1}{n}}))$ -\end{formulae} - When these hashes are used in the circuit, the first two windows of the input are fixed and can be optimized (for example, in the Merkle tree hashes they represent the layer number). @@ -7587,25 +8120,67 @@ $\ell$ bits, with the first 6 bits fixed, is ... constraints. In particular, for the Merkle tree hashes $\ell = 516$, so the cost is ... constraints. +\nsubsubsection{Mixing Pedersen hash} \label{cctmixinghash} + +A mixing \xPedersenHash is used to compute $\NoteAddressRand$ from +$\cm$ and $\NotePosition$ in \crossref{commitmentsandnullifiers}. It takes as +input a \xPedersenCommitment $P$, and hashes it with another input $x$. + +We define $\MixingPedersenHash{D} \typecolon \byteseq{8} \times \range{0}{\ParamJ{r}-1} +\times \GroupJ \rightarrow \GroupJ$ by: + +\begin{formulae} + \item $\MixingPedersenHash(D, P, x) := P + \scalarmult{x}{\FindGroupJHashOf{D, \ascii{}}}$. +\end{formulae} + +This costs \todo{...} for the scalar multiplication, and $6$ constraints for the +Edwards addition, for a total of \todo{...} constraints. + + \nsubsubsection{Merkle path check} \label{cctmerklepath} Checking a Merkle authentication path, as described in \crossref{merklepath}, -requires boolean-constraining the previous-layer and sibling hashes in -addition to the cost of computing the Merkle hash. +requires to: -Therefore, the cost of each layer is $2 \smult 255 + ... = ...$ constraints. +\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 previous-layer and sibling hashes to $255$-bit sequences; + \item compute the Merkle hash. +\end{itemize} -Note that it is \emph{not} necessary to ensure that the previous-layer or sibling -inputs represent integers in $\range{0}{\ParamS{r}}$. +The unpacking need not be canonical in the sense discussed in \crossref{cctunpack}; +that is, it is \emph{not} necessary to ensure that the previous-layer or sibling +bit-sequence inputs 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 collision-resistant +on arbitrary bit-sequence inputs, an attempt by an adversarial prover to use a +non-canonical input would result in the wrong root being calculated, and the +overall path check would fail. + +Note that the leaf node input of the authentication path is given as a bit sequence, +not as a field element. + +For each layer, the cost is $1 + 2 \smult 255$ boolean constraints, +$2$ constraints for the conditional swap (implemented as two selection +constraints), and todo{...} for the Merkle hash, for a total of \todo{...} +constraints. + +\pnote{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.} -\nsubsubsection{Windowed Pedersen commitments} \label{cctwindowedpedersencommit} +\nsubsubsection{Windowed Pedersen commitment} \label{cctwindowedcommit} We construct ``windowed'' Pedersen commitments by reusing the Pedersen hash implementation, and adding a randomized point: \begin{formulae} - \item $\WindowedPedersenCommit{r}(s) = \Selectu(\PedersenHashPoint(s) + \scalarmult{r}{\TrapdoorBase})$ + \item $\WindowedPedersenCommit{r}(D, s) = + \PedersenHashToPoint(D, s) + \scalarmult{r}{\FindGroupJHashOf{D, \ascii{}}}$ \end{formulae} This can be implemented in: @@ -7613,26 +8188,30 @@ This can be implemented in: \item $... \smult \ell + ...$ constraints for the Pedersen hash on $\ell = \length(s)$ bits (again assuming that the first $6$ bits are fixed); \item $750$ constraints for the fixed-base scalar multiplication; - \item $5$ constraints for the final Edwards addition (saving a - constraint because the $\varv$-coordinate is not needed) + \item $6$ constraints for the final Edwards addition \end{itemize} -for a total of $... \smult \ell + 755$ constraints. +for a total of $... \smult \ell + 756$ constraints. -\nsubsubsection{Raw Pedersen commitments} \label{cctrawpedersencommit} + +\nsubsubsection{Raw Pedersen commitments} \label{cctrawcommit} The windowed Pedersen commitments defined in the preceding section are -highly efficient, but they do not support the homomorphic property, which we -need when instantiating $\ValueCommit{}$ from \crossref{valuecommit}. +highly efficient, but they do not support the homomorphic property we +need when instantiating $\ValueCommit{}$ (see \crossref{spendsandoutputs} +and \crossref{saplingbalance}). In order to support this property, we also define ``raw'' Pedersen commitments as follows: -$\RawPedersenCommit{r}(\Value) = \Selectu(\MontToEdwards(\scalarmult{Value}{\ValueCommitBase})) -+ \MontToEdwards(\scalarmult{r}{\TrapdoorBase})))$ +\begin{formulae} + \item $\RawPedersenCommit{\ValueCommitRand}(D, \Value) = + \scalarmult{\Value}{\ValueCommitBase} + \scalarmult{\ValueCommitRand}{\FindGroupJHashOf{D, ascii{}}}$ +\end{formulae} -In the case that we need for $\ValueCommit{}$, $\varv \typecolon $ has at most 51 bits. -This can be straightforwardly implemented in ... constraints. (The outer Edwards -addition saves a constraint because the $\varv$-coordinate is not needed.) +In the case that we need for $\ValueCommit{}$, +%$\Value \typecolon \range{-\MAXMONEY}{\MAXMONEY}$ has at most $51$ bits. +$\Value$ has at most $63$ bits. +This can be straightforwardly implemented in ... constraints. \nsubsubsection{BLAKE2s hashes} \label{cctblake2s} @@ -7674,9 +8253,9 @@ output bits, but not the input bits. \pnote{ 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 --- but no better -alternative is available. Pedersen hashes do not have the necessary cryptographic -properties for the two cases where the SaplingSpend circuit uses $\BlakeTwosGeneric$. +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. diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 78104f9c..fd1516c7 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -222,8 +222,8 @@ Received \mbox{March 20,} 2012.} month={August}, year={2015}, doi={10.6028/NIST.FIPS.180-4}, - url={http://csrc.nist.gov/publications/PubsFIPS.html#180-4}, - urldate={2016-08-14} + url={https://csrc.nist.gov/publications/detail/fips/180/4/final}, + urldate={2018-02-14} } @misc{RIPEMD160, @@ -582,6 +582,16 @@ Received \mbox{April 13,} 2011.} urldate={2017-01-06} } +@misc{GitHub-jubjub, + presort={Github-jubjub}, + author={Daira Hopwood}, + title={GitHub repository `\hairspace daira/jubjub'\hairspace: +{S}upporting evidence for security of the {J}ubjub curve to be used in {Z}cash}, + url={https://github.com/daira/jubjub}, + urldate={2018-02-18}, + addendum={Based on code written for SafeCurves \cite{BL-SafeCurves} by Daniel Bernstein and Tanja Lange.} +} + @misc{ZcashIssue-2113, presort={ZcashIssue-2113}, author={Simon Liu}, @@ -748,8 +758,8 @@ IEEE Computer Society Press, 1997; ISBN 0-8186-8197-7.} @inproceedings{BGG1995, presort={BGG1995}, - title={Incremental {C}ryptography: {T}he {C}ase of {H}ashing and {S}igning}, author={Mihir Bellare and Oded Goldreich and Shafi Goldwasser}, + title={Incremental {C}ryptography: {T}he {C}ase of {H}ashing and {S}igning}, date={1995-10-20}, booktitle={Advances in Cryptology - CRYPTO '94. Proceedings of the 14th Annual International Cryptology Conference @@ -766,3 +776,29 @@ Proceedings of the 14th Annual International Cryptology Conference % url={https://groups.csail.mit.edu/cis/pubs/shafi/1994-lncs.pdf}, urldate={2018-02-09} } + +@misc{CvHP1991, + presort={CvHP1991}, + author={David Chaum and Eugène van Heijst and Birgit Pfitzmann}, + title={Cryptographically {S}trong {U}ndeniable {S}ignatures, {U}nconditionally {S}ecure for the {S}igner}, + date={1991-02}, + publisher={Universität Karlsruhe Fakultät für Informatik}, +% doi={10.1.1.34.8570}, + url={http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.8570}, + urldate={2018-02-17}, + addendum={DOI: \texttt{10.1.1.34.8570}. +An extended abstract appeared in +\textsl{Advances in Cryptology - CRYPTO '91: +Proceedings of the 11th Annual International Cryptology Conference +(Santa Barbara, California, USA, August 11--15, 1991)}; Ed. by Joan Feigenbaum; +Vol. 576, Lecture Notes in Computer Science, pages 470--484; +Springer, 1992; ISBN 978-3-540-55188-1.} +} + +@unpublished{BCP1988, + presort={BCP1988}, + author={Jurgen Bos and David Chaum and George Purdy}, + title={A {V}oting {S}cheme}, + note={Unpublished. Presented at the rump session of CRYPTO '88 +(Santa Barbara, California, USA, August 21--25, 1988); does not appear in the proceedings.} +}