diff --git a/protocol/protocol.tex b/protocol/protocol.tex index 28854876..df114858 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -692,9 +692,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ZerocashText}{\textbf{Zerocash}} \newcommand{\Sprout}{\termbf{Sprout}} \newcommand{\SproutText}{\textbf{Sprout}} -\newcommand{\SproutOrZcash}{\notsprout{\Sprout{}}\sprout{\Zcash{}}\xspace} -\newcommand{\SproutOrNothing}{\notsprout{\Sprout{}}\xspace} -\newcommand{\SproutOrNothingText}{\notsprout{\SproutText}} \newcommand{\pSproutOrNothing}{\notsprout{ (\Sprout)}\xspace} \newcommand{\pSproutOrNothingText}{\notsprout{ (\SproutText)}} \newcommand{\Overwinter}{\termbf{Overwinter}} @@ -877,6 +874,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\BCTV}{\termsf{BCTV14}} \newcommand{\Groth}{\termsf{Groth16}} \newcommand{\HaloTwo}{\termandindexx{$\mathsf{Halo}\;\mathsf{2}$}{Halo 2}} +\newcommand{\halotwo}{\termandindexx{$\mathsf{halo2}$}{halo2 (library)}} \newcommand{\PLONK}{\termsf{PLONK}} \newcommand{\BCTVText}{\texorpdfstring{$\mathsf{BCTV14}$}{BCTV14}} \newcommand{\GrothText}{\texorpdfstring{$\mathsf{Groth16}$}{Groth16}} @@ -1029,6 +1027,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\diversifiedBases}{\terms{diversified base}} \newcommand{\diversifier}{\term{diversifier}} \newcommand{\diversifiers}{\terms{diversifier}} +\newcommand{\diversifierKey}{\term{diversifier key}} \newcommand{\incomingViewingKey}{\term{incoming viewing key}} \newcommand{\incomingViewingKeys}{\terms{incoming viewing key}} \newcommand{\outgoingViewingKey}{\term{outgoing viewing key}} @@ -1060,7 +1059,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\authNullifierKeys}{\terms{nullifier private key}} \newcommand{\nullifierDerivingKey}{\term{nullifier deriving key}} \newcommand{\nullifierDerivingKeys}{\terms{nullifier deriving key}} -\newcommand{\nullifierRandomness}{\term{nullifier randomness}} +\newcommand{\commitIvkRandomness}{\termandindexx{$\CommitIvk{}$ randomness}{Commit^ivk randomness}} \newcommand{\rawEncoding}{\term{raw encoding}} \newcommand{\hdWallet}{\term{Hierarchical Deterministic Wallet}} \newcommand{\humanReadablePart}{\term{Human-Readable Part}} @@ -1203,7 +1202,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\mantissa}{\mathsf{mantissa}} \newcommand{\ToCompact}{\mathsf{ToCompact}} \newcommand{\ToTarget}{\mathsf{ToTarget}} -\newcommand{\ToScalar}[1]{\mathsf{ToScalar^{#1\!}}} +\newcommand{\ToScalar}[1]{\mathsf{ToScalar^{#1\kern-0.1em}}} +\newcommand{\ToBase}[1]{\mathsf{ToBase^{#1\kern-0.1em}}} \newcommand{\hexint}[1]{\mathtt{0x{#1}}} \newcommand{\dontcare}{\kern -0.06em\raisebox{0.1ex}{\footnotesize{$\times$}}} \newcommand{\ascii}[1]{\textbf{``\texttt{#1}''}} @@ -1313,9 +1313,13 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\CRHivkText}{\texorpdfstring{$\CRHivk$}{CRHivk}} \newcommand{\CRHivkOutput}{\CRHivk\mathsf{.Output}} \newcommand{\CRHivkBox}[1]{\CRHivk\!\left(\Justthebox{#1}\right)} -\newcommand{\CRHovk}{\mathsf{CRH^{\InViewingKey}}} +\newcommand{\CRHovk}{\mathsf{CRH^{\OutViewingKey}}} \newcommand{\CRHovkText}{\texorpdfstring{$\CRHovk$}{CRHovk}} -\newcommand{\DiversifyHash}[1]{\mathsf{DiversifyHash}^\mathsf{#1\!}} +\newcommand{\Poseidon}{\mathsf{Poseidon}} +\newcommand{\PoseidonText}{\texorpdfstring{$\Poseidon$}{Poseidon}} +\newcommand{\PoseidonHash}{\mathsf{PoseidonHash}} +\newcommand{\PoseidonHashText}{\texorpdfstring{$\PoseidonHash$}{PoseidonHash}} +\newcommand{\DiversifyHash}[1]{\mathsf{DiversifyHash}^\mathsf{#1\kern-0.1em}} \newcommand{\DiversifyHashText}[1]{\texorpdfstring{$\DiversifyHash{#1}$}{DiversifyHash{#1}}} \newcommand{\DefaultDiversifier}{\mathsf{DefaultDiversifier}} \newcommand{\CheckDiversifier}{\mathsf{CheckDiversifier}} @@ -1337,9 +1341,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\PaymentAddressLeadByte}{\hexint{16}} \newcommand{\PaymentAddressSecondByte}{\hexint{9A}} \newcommand{\InViewingKey}{\mathsf{ivk}} -\newcommand{\InViewingKeyRandom}{\mathsf{rivk}} \newcommand{\InViewingKeyLength}[1]{\ell^\mathsf{#1\vphantom{p}}_{\InViewingKey}\!} -\newcommand{\InViewingKeyType}[1]{\binaryrange{\InViewingKeyLength{#1}}} +\newcommand{\InViewingKeyTypeSapling}{\binaryrange{\InViewingKeyLength{Sapling}}} +\newcommand{\InViewingKeyTypeOrchard}{\range{0}{\ParamP{q}-1}} \newcommand{\InViewingKeyRepr}{{\InViewingKey\Repr}} \newcommand{\InViewingKeyLeadByte}{\hexint{A8}} \newcommand{\InViewingKeySecondByte}{\hexint{AB}} @@ -1376,6 +1380,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\AuthPrivateNew}[1]{\mathsf{a^{new}_{sk,\mathnormal{#1}}}} \newcommand{\AddressPublicNew}[1]{\mathsf{addr^{new}_{pk,\mathnormal{#1}}}} \newcommand{\ScalarLength}[1]{\ell^\mathsf{#1\vphantom{p}}_{\mathsf{scalar}}} +\newcommand{\CompactLengthOrchard}{\mathsf{\ell^{Orchard\vphantom{p}}_{compact\vphantom{d}}}} \newcommand{\enc}{\mathsf{enc}} \newcommand{\DHSecret}[1]{\mathsf{sharedSecret}_{#1}} \newcommand{\EphemeralPublic}{\mathsf{epk}} @@ -1404,7 +1409,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\AuthSignPublic}{\mathsf{ak}} \newcommand{\AuthSignPublicX}{\mathsf{ak}_x} \newcommand{\AuthSignPublicRepr}{{\AuthSignPublic\Repr}} -\newcommand{\AuthSignPublicXRepr}{\mathsf{ak}_x\Repr} \newcommand{\AuthSignRandomizedPublic}{\mathsf{rk}} \newcommand{\AuthSignRandomizedPublicRepr}{{\AuthSignRandomizedPublic\Repr}} \newcommand{\AuthSignRandomizedPrivate}{\mathsf{rsk}} @@ -1415,7 +1419,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\AuthProveBaseSapling}{\mathcal{H}^\mathsf{Sapling}} \newcommand{\NullifierKey}{\mathsf{nk}} \newcommand{\NullifierKeyRepr}{{\NullifierKey\Repr}} -\newcommand{\NullifierKeyType}{\GF{\ParamP{q}}} +\newcommand{\NullifierKeyTypeOrchard}{\GF{\ParamP{q}}} \newcommand{\NullifierBaseOrchard}{\mathcal{K}^\mathsf{Orchard}} \newcommand{\OutViewingKey}{\mathsf{ovk}} \newcommand{\OutViewingKeyLength}{\mathsf{\ell_{\OutViewingKey}}} @@ -1428,6 +1432,9 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\Diversifier}{\mathsf{d}} \newcommand{\DiversifierLength}{\mathsf{\ell_{\Diversifier}}} \newcommand{\DiversifierType}{\bitseq{\DiversifierLength}} +\newcommand{\DiversifierKey}{\mathsf{dk}} +\newcommand{\DiversifierKeyLength}{\mathsf{\ell_{\DiversifierKey}}} +\newcommand{\CommitIvkRandom}{\mathsf{rivk}} \newcommand{\DiversifiedTransmitBase}{\mathsf{g_d}} \newcommand{\DiversifiedTransmitBaseRepr}{\mathsf{g\Repr_d}} \newcommand{\DiversifiedTransmitBaseOld}{\mathsf{g^{old}_d}} @@ -1452,7 +1459,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\PRFsn}[1]{\PRF{#1}{sn}} \newcommand{\PRFpk}[1]{\PRF{#1}{pk}} \newcommand{\PRFrho}[1]{\PRF{#1}{\NoteUniqueRand}} -\newcommand{\PRFOutputLengthSprout}{\mathsf{\ell_{PRF\notsprout{Sprout}}}} +\newcommand{\PRFOutputLengthSprout}{\mathsf{\ell^{Sprout}_{PRF}}} \newcommand{\PRFOutputSprout}{\bitseq{\PRFOutputLengthSprout}} \newcommand{\PRFOutputLengthNfSapling}{\mathsf{\ell_{PRFnfSapling}}} \newcommand{\PRFOutputNfSapling}{\byteseq{\PRFOutputLengthNfSapling/8}} @@ -1463,8 +1470,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % Commitments -\newcommand{\Uncommitted}[1]{\mathsf{Uncommitted}^\mathsf{#1\!}} -\newcommand{\NoteCommitment}[1]{\mathsf{NoteCommitment}^\mathsf{#1\!}} +\newcommand{\Uncommitted}[1]{\mathsf{Uncommitted}^\mathsf{#1\kern-0.1em}} +\newcommand{\NoteCommitment}[1]{\mathsf{NoteCommitment}^\mathsf{#1\kern-0.1em}} \newcommand{\CommitAlg}{\mathsf{COMM}} \newcommand{\Commit}[1]{\CommitAlg_{#1}} @@ -1472,21 +1479,21 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\CommitGenTrapdoor}{\CommitAlg\mathsf{.GenTrapdoor}} \newcommand{\CommitInput}{\CommitAlg\mathsf{.Input}} \newcommand{\CommitOutput}{\CommitAlg\mathsf{.Output}} -\newcommand{\NoteCommitAlg}[1]{\mathsf{NoteCommit}^\mathsf{#1\!}} +\newcommand{\NoteCommitAlg}[1]{\mathsf{NoteCommit}^\mathsf{#1\kern-0.1em}} \newcommand{\NoteCommit}[2]{\NoteCommitAlg{#1}_{\vphantom{l}#2}} \newcommand{\NoteCommitTrapdoor}[1]{\NoteCommitAlg{#1}\mathsf{.Trapdoor}} \newcommand{\NoteCommitTrapdoorBytes}{\byteseq{32}} \newcommand{\NoteCommitGenTrapdoor}[1]{\NoteCommitAlg{#1}\mathsf{.GenTrapdoor}} \newcommand{\NoteCommitInput}[1]{\NoteCommitAlg{#1}\mathsf{.Input}} \newcommand{\NoteCommitOutput}[1]{\NoteCommitAlg{#1}\mathsf{.Output}} -\newcommand{\ValueCommitAlg}[1]{\mathsf{ValueCommit}^\mathsf{#1\!}} +\newcommand{\ValueCommitAlg}[1]{\mathsf{ValueCommit}^\mathsf{#1\kern-0.1em}} \newcommand{\ValueCommit}[2]{\ValueCommitAlg{#1}_{#2}} \newcommand{\ValueCommitTrapdoor}[1]{\ValueCommitAlg{#1}\mathsf{.Trapdoor}} \newcommand{\ValueCommitGenTrapdoor}[1]{\ValueCommitAlg{#1}\mathsf{.GenTrapdoor}} \newcommand{\ValueCommitInput}[1]{\ValueCommitAlg{#1}\mathsf{.Input}} \newcommand{\ValueCommitOutput}[1]{\ValueCommitAlg{#1}\mathsf{.Output}} -\newcommand{\ValueCommitValueBase}[1]{\mathcal{V}^\mathsf{#1\!}} -\newcommand{\ValueCommitRandBase}[1]{\mathcal{R}^\mathsf{#1\!}} +\newcommand{\ValueCommitValueBase}[1]{\mathcal{V}^\mathsf{#1\kern-0.1em}} +\newcommand{\ValueCommitRandBase}[1]{\mathcal{R}^\mathsf{#1\kern-0.1em}} \newcommand{\CommitIvkAlg}{\mathsf{Commit}^{\InViewingKey}} \newcommand{\CommitIvk}[1]{\CommitIvkAlg_{#1}} \newcommand{\CommitIvkTrapdoor}{\CommitIvkAlg\mathsf{.Trapdoor}} @@ -1519,7 +1526,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % Key agreement -\newcommand{\KA}[1]{\mathsf{KA}^\mathsf{#1\!}} +\newcommand{\KA}[1]{\mathsf{KA}^\mathsf{#1\kern-0.1em}} \newcommand{\KAPublic}[1]{\KA{#1}\mathsf{.Public}} \newcommand{\KAPublicPrimeSubgroup}[1]{\KA{#1}\mathsf{.PublicPrimeSubgroup}} \newcommand{\KAPrivate}[1]{\KA{#1}\mathsf{.Private}} @@ -1536,7 +1543,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % KDF -\newcommand{\KDF}[1]{\mathsf{KDF}^\mathsf{#1\!}} +\newcommand{\KDF}[1]{\mathsf{KDF}^\mathsf{#1\kern-0.1em}} \newcommand{\kdftag}{\mathsf{kdftag}} \newcommand{\kdfinput}{\mathsf{kdfinput}} @@ -1558,7 +1565,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\ValueCommitRandNew}[1]{\ValueCommitRand^\mathsf{new}_{#1}} \newcommand{\ValueCommitRandNet}[1]{\ValueCommitRand^\mathsf{net}_{#1}} \newcommand{\NoteTuple}[1]{\mathbf{n}_{#1}} -\newcommand{\NoteType}[1]{\mathsf{Note}^\mathsf{#1\!}} +\newcommand{\NoteType}[1]{\mathsf{Note}^\mathsf{#1\kern-0.1em}} \newcommand{\NotePlaintext}[1]{\mathbf{np}_{#1}} \newcommand{\OutPlaintext}{\mathbf{op}} \newcommand{\NoteSeedBytes}{\mathsf{rseed}} @@ -1577,7 +1584,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\NoteUniqueRandOld}[1]{\NoteUniqueRand^\mathsf{old}_{#1}} \newcommand{\NoteUniqueRandNew}[1]{\NoteUniqueRand^\mathsf{new}_{#1}} \newcommand{\NoteUniquePreRand}{\mathsf{\upvarphi}} -\newcommand{\NoteUniquePreRandLength}{\mathsf{\ell_{\NoteUniquePreRand}}} +\newcommand{\NoteUniquePreRandLength}{\mathsf{\ell^{Sprout}_{\NoteUniquePreRand}}} \newcommand{\NoteNullifierRand}{\mathsf{\uppsi}} \newcommand{\NoteNullifierRandType}{\GF{\ParamP{q}}} \newcommand{\NoteCommitS}{\mathsf{s}} @@ -1774,7 +1781,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\JoinSplitSigSign}[1]{\JoinSplitSig\mathsf{.Sign}_{#1}} \newcommand{\JoinSplitSigValidate}[1]{\JoinSplitSig\mathsf{.Validate}_{#1}} -\newcommand{\SpendAuthSig}[1]{\mathsf{SpendAuthSig}^\mathsf{#1\!}} +\newcommand{\SpendAuthSig}[1]{\mathsf{SpendAuthSig}^\mathsf{#1\kern-0.1em}} \newcommand{\SpendAuthSigPublic}[1]{\SpendAuthSig{#1}\mathsf{.Public}} \newcommand{\SpendAuthSigPrivate}[1]{\SpendAuthSig{#1}\mathsf{.Private}} \newcommand{\SpendAuthSigMessage}[1]{\SpendAuthSig{#1}\mathsf{.Message}} @@ -1790,7 +1797,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\SpendAuthSigRandomizerId}[1]{\SpendAuthSig{#1}\mathsf{.Id}} \newcommand{\SpendAuthSigRandomizer}{\alpha} -\newcommand{\BindingSig}[1]{\mathsf{BindingSig}^\mathsf{#1\!}} +\newcommand{\BindingSig}[1]{\mathsf{BindingSig}^\mathsf{#1\kern-0.1em}} \newcommand{\BindingSigPublic}[1]{\BindingSig{#1}\mathsf{.Public}} \newcommand{\BindingSigPrivate}[1]{\BindingSig{#1}\mathsf{.Private}} \newcommand{\BindingSigMessage}[1]{\BindingSig{#1}\mathsf{.Message}} @@ -1818,10 +1825,10 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg % Merkle tree -\newcommand{\MerkleDepth}[1]{\mathsf{MerkleDepth}^\mathsf{#1\!}} +\newcommand{\MerkleDepth}[1]{\mathsf{MerkleDepth}^\mathsf{#1\kern-0.1em}} \newcommand{\MerkleNode}[2]{\mathsf{M}^\mathsf{#1}_{#2}} \newcommand{\MerkleSibling}{\mathsf{sibling}} -\newcommand{\MerkleCRH}[1]{\mathsf{MerkleCRH}^\mathsf{#1\!}} +\newcommand{\MerkleCRH}[1]{\mathsf{MerkleCRH}^\mathsf{#1\kern-0.1em}} \newcommand{\MerkleHashLength}[1]{\mathsf{\ell}^\mathsf{#1\vphantom{p}}_\mathsf{Merkle}} \newcommand{\MerkleHash}[1]{\bitseq{\MerkleHashLength{#1}}} \newcommand{\MerkleLayer}[1]{\range{0}{\MerkleDepth{#1}-1}} @@ -1839,15 +1846,25 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\txOut}{\mathtt{tx\_out}} \newcommand{\lockTime}{\mathtt{lock\_time}} \newcommand{\nExpiryHeight}{\mathtt{nExpiryHeight}} +\newcommand{\nJoinSplit}{\mathtt{nJoinSplit}} +\newcommand{\vJoinSplit}{\mathtt{vJoinSplit}} \newcommand{\valueBalance}[1]{\mathtt{valueBalance#1}} \newcommand{\nShieldedSpend}{\mathtt{nShieldedSpend}} \newcommand{\vShieldedSpend}{\mathtt{vShieldedSpend}} \newcommand{\nShieldedOutput}{\mathtt{nShieldedOutput}} \newcommand{\vShieldedOutput}{\mathtt{vShieldedOutput}} -\newcommand{\nShieldedAction}{\mathtt{nShieldedAction}} -\newcommand{\vShieldedAction}{\mathtt{vShieldedAction}} -\newcommand{\nJoinSplit}{\mathtt{nJoinSplit}} -\newcommand{\vJoinSplit}{\mathtt{vJoinSplit}} +\newcommand{\nSpendsSapling}{\mathtt{nSpendsSapling}} +\newcommand{\vSpendsSapling}{\mathtt{vSpendsSapling}} +\newcommand{\nOutputsSapling}{\mathtt{nOutputsSapling}} +\newcommand{\vOutputsSapling}{\mathtt{vOutputsSapling}} +\newcommand{\vSpendProofsSapling}{\mathtt{vSpendProofsSapling}} +\newcommand{\vSpendAuthSigsSapling}{\mathtt{vSpendAuthSigsSapling}} +\newcommand{\vOutputProofsSapling}{\mathtt{vOutputProofsSapling}} +\newcommand{\nActionsOrchard}{\mathtt{nActionsOrchard}} +\newcommand{\vActionsOrchard}{\mathtt{vActionsOrchard}} +\newcommand{\sizeProofsOrchard}{\mathtt{sizeProofsOrchard}} +\newcommand{\proofsOrchard}{\mathtt{proofsOrchard}} +\newcommand{\vSpendAuthSigsOrchard}{\mathtt{vSpendAuthSigsOrchard}} \newcommand{\vpubOldField}{\mathtt{vpub\_old}} \newcommand{\vpubNewField}{\mathtt{vpub\_new}} \newcommand{\anchorField}[1]{\mathtt{anchor#1}} @@ -2244,6 +2261,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg \newcommand{\SinsemillaHashToPoint}{\mathsf{SinsemillaHashToPoint}} \newcommand{\SinsemillaCommitAlg}{\mathsf{SinsemillaCommit}} \newcommand{\SinsemillaCommit}[1]{\SinsemillaCommitAlg_{#1}} +\newcommand{\SinsemillaShortCommitAlg}{\mathsf{SinsemillaShortCommit}} +\newcommand{\SinsemillaShortCommit}[1]{\SinsemillaShortCommitAlg_{#1}} % Consensus rules @@ -2459,8 +2478,8 @@ This specification is structured as follows: \item Differences from the \Zerocash protocol — a summary of changes from the protocol in \cite{BCGGMTV2014}. \notsprout{ - \item Appendix: Circuit Design — details of how the \Sapling\orchard{ and \Orchard} - circuits are defined as \quadraticConstraintPrograms. + \item Appendix: Circuit Design — details of how the \Sapling circuits are + defined as \quadraticConstraintPrograms. \item Appendix: Batching Optimizations — improvements to the efficiency of validating multiple signatures and verifying multiple proofs. } @@ -2576,8 +2595,10 @@ For each \shieldedInput, \item the \nullifier and \noteCommitment are computed correctly. \end{itemize} +\vspace{-1.5ex} and for each \shieldedOutput, +\vspace{0.5ex} \begin{itemize} \item \saplingonward{there is a revealed \valueCommitment to the same value as the output \note;\orchard{\footnoteref{orchardvaluecommitments}}} @@ -2843,12 +2864,12 @@ decryption or validity check. The following integer constants will be instantiated in \crossref{constants}: \begin{formulae} \item \begin{flushleft} - $\MerkleDepth{Sprout}$,\sapling{ $\MerkleDepth{Sapling}$,}\orchard{ $\MerkleDepth{Orchard}$,} $\NOld$, $\NNew$, - $\ValueLength$, $\MerkleHashLength{Sprout}$,\sapling{ $\MerkleHashLength{Sapling}$,}\orchard{ $\MerkleHashLength{Orchard}$,} - $\hSigLength$, $\PRFOutputLengthSprout$,\sapling{ $\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,} - $\NoteCommitRandLength$, \changed{$\RandomSeedLength$,} $\AuthPrivateLength$, - \changed{$\NoteUniquePreRandLength$,}\sapling{ $\SpendingKeyLength$, $\DiversifierLength$, - $\InViewingKeyLength{Sapling}$, $\OutViewingKeyLength$, $\ScalarLength{Sapling}$,\orchard{ $\ScalarLength{Orchard}$,}} + $\MerkleDepth{Sprout}$,\sapling{ $\MerkleDepth{Sapling}$,}\orchard{ $\MerkleDepth{Orchard}$,} + $\MerkleHashLength{Sprout}$,\sapling{ $\MerkleHashLength{Sapling}$,}\orchard{ $\MerkleHashLength{Orchard}$,} + $\NOld$, $\NNew$, $\ValueLength$, $\hSigLength$, $\PRFOutputLengthSprout$,\sapling{ $\PRFOutputLengthExpand$, + $\PRFOutputLengthNfSapling$,} $\NoteCommitRandLength$, \changed{$\RandomSeedLength$,} $\AuthPrivateLength$, + \changed{$\NoteUniquePreRandLength$,}\sapling{ $\SpendingKeyLength$, $\DiversifierLength$,\orchard{ $\DiversifierKeyLength$,} + $\InViewingKeyLength{Sapling}$, $\OutViewingKeyLength$, $\ScalarLength{Sapling}$,\orchard{ $\ScalarLength{Orchard}$, $\CompactLengthOrchard$},} $\MAXMONEY$,\blossom{ $\BlossomActivationHeight$,}\strut\canopy{ $\CanopyActivationHeight$, $\ZIPTwoOneTwoGracePeriod$,} $\SlowStartInterval$, $\PreBlossomHalvingInterval$, $\MaxBlockSubsidy$, $\NumFounderAddresses$, $\PoWLimit$, $\PoWAveragingWindow$, $\PoWMedianBlockSpan$, $\PoWDampingFactor$, @@ -2856,14 +2877,18 @@ The following integer constants will be instantiated in \crossref{constants}: \end{flushleft} \end{formulae} -\sprout{The bit sequence constant $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}}$,} -\notsprout{The bit sequence constants $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}}$, +\sprout{ +The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$, and +the bit sequence constant $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}}$, +will also be defined in that section. +} %sprout +\notsprout{ +The rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and $\PoWMaxAdjustUp$, and +the bit sequence constants $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}}$, \sapling{$\Uncommitted{Sapling} \typecolon \bitseq{\MerkleHashLength{Sapling}}$,} \orchard{and $\Uncommitted{Orchard} \typecolon$ $\bitseq{\MerkleHashLength{Orchard}}$,} -and the rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and -$\PoWMaxAdjustUp$ will also be defined in that section. +will also be defined in that section. -\notsprout{ We use the abbreviation ``\defining{\xCtEdwards}'' to refer to \completeTwistedEdwardsEllipticCurves and coordinates (see \crossref{jubjub}). } @@ -2887,7 +2912,7 @@ abstractions. \begin{center} \sprout{\includegraphics[scale=.7]{key_components}} \sapling{\notorchard{\includegraphics[scale=.5]{key_components_sapling}}} -\orchard{\includegraphics[scale=.39]{key_components_orchard}} +\orchard{\includegraphics[scale=.385]{key_components_orchard}} \end{center} \sproutspecific{ @@ -2921,11 +2946,11 @@ Two methods of doing so are defined: \orchardonward{ An \Orchard \spendingKey $\SpendingKey$ is used to derive a \authSigningKey $\AuthSignPrivate$, and a \fullViewingKey $(\AuthSignPublic, \NullifierKey, \CommitIvkRand)$. From the \fullViewingKey -we can also derive an \incomingViewingKey $\InViewingKey$, an \outgoingViewingKey $\OutViewingKey$, and -a set of \diversifiedPaymentAddresses $\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$, -as described in \crossref{orchardkeycomponents}. +we can also derive a \diversifierKey $\DiversifierKey$, an \incomingViewingKey $\InViewingKey$, +an \outgoingViewingKey $\OutViewingKey$, and a set of \diversifiedPaymentAddresses +$\DiversifiedPaymentAddress = (\Diversifier, \DiversifiedTransmitPublic)$, as described in +\crossref{orchardkeycomponents}. } %orchardonward -} %saplingonward \vspace{-2ex} \sapling{\nnote{In \zcashd, all \SaplingAndOrchard keys and addresses are derived according to \cite{ZIP-32}.}} @@ -2971,7 +2996,6 @@ in order to exploit a hypothetical weakness in that cryptosystem. } \introsection -\vspace{-1ex} \lsubsection{Notes}{notes} \sprout{ @@ -2981,12 +3005,13 @@ spendable by the recipient who holds the \spendingKey $\AuthPrivate$ correspondi to $\AuthPublic$, as described in the previous section. } %sprout \notsprout{ -A \defining{\note} (denoted $\NoteTuple{}$) can be a \Sprout{} \note\sapling{ or a -\Sapling{} \note}\orchard{ or an \Orchard{} \note}. In each case it represents that +A \defining{\note} (denoted $\NoteTuple{}$) can be a \Sprout \note\sapling{ or a +\Sapling \note}\orchard{ or an \Orchard \note}. In each case it represents that a value $\Value$ is spendable by the recipient who holds the \spendingKey corresponding to a given \paymentAddress. } %notsprout +\vspace{1ex} Let \sprout{$\MAXMONEY$ and $\PRFOutputLengthSprout$} \notsprout{$\MAXMONEY$, $\PRFOutputLengthSprout$\sapling{, $\PRFOutputLengthNfSapling$, and $\DiversifierLength$}} be as defined in \crossref{constants}. @@ -3007,7 +3032,7 @@ Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}. \vspace{2ex} \introlist -A \SproutOrNothing{} \note is a tuple $\changed{(\AuthPublic, +A \Sprout \note is a tuple $\changed{(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)}$, where: \begin{itemize} \item $\AuthPublic \typecolon \PRFOutputSprout$ is the \defining{\payingKey} of the @@ -3023,7 +3048,7 @@ A \SproutOrNothing{} \note is a tuple $\changed{(\AuthPublic, \end{itemize} \introlist -Let $\NoteType{Sprout}$ be the type of a \SproutOrNothing{} \note, i.e. +Let $\NoteType{Sprout}$ be the type of a \Sprout \note, i.e. \begin{formulae} \item $\NoteType{Sprout} := \changed{\PRFOutputSprout \times \range{0}{\MAXMONEY} \times \PRFOutputSprout \times \NoteCommitTrapdoor{Sprout}}$. @@ -3031,8 +3056,8 @@ Let $\NoteType{Sprout}$ be the type of a \SproutOrNothing{} \note, i.e. \sapling{ \vspace{1ex} -\introlist -A \Sapling{} \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, +\introsection +A \Sapling \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRand)$, where: \begin{itemize} \item $\Diversifier \typecolon \DiversifierType$ @@ -3046,7 +3071,7 @@ A \Sapling{} \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, \end{itemize} \introlist -Let $\NoteType{Sapling}$ be the type of a \Sapling{} \note, i.e. +Let $\NoteType{Sapling}$ be the type of a \Sapling \note, i.e. \begin{formulae} \item $\NoteType{Sapling} := \DiversifierType \times \KAPublicPrimeSubgroup{Sapling} \times \range{0}{\MAXMONEY} \times \NoteCommitTrapdoor{Sapling}$. @@ -3056,7 +3081,7 @@ Let $\NoteType{Sapling}$ be the type of a \Sapling{} \note, i.e. \orchard{ \vspace{1ex} \introlist -An \Orchard{} \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, +An \Orchard \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRand, \NoteNullifierRand, \NoteCommitRand)$, where: \begin{itemize} \item $\Diversifier \typecolon \DiversifierType$ @@ -3078,7 +3103,7 @@ An \Orchard{} \note is a tuple $(\Diversifier, \DiversifiedTransmitPublic, \end{itemize} \introlist -Let $\NoteType{Orchard}$ be the type of an \Orchard{} \note, i.e. +Let $\NoteType{Orchard}$ be the type of an \Orchard \note, i.e. \begin{formulae} \item $\NoteType{Orchard} := \DiversifierType \times \KAPublic{Orchard} \times \range{0}{\MAXMONEY} \times \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType \times \NoteCommitTrapdoor{Orchard}$. @@ -3094,7 +3119,7 @@ on the \blockChain. \vspace{1ex} \introlist -A \SproutOrNothing{} \defining{\noteCommitment} on a \note +A \Sprout{} \defining{\noteCommitment} on a \note $\NoteTuple{} = \changed{(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)}$ is computed as \vspace{-1ex} @@ -3127,9 +3152,9 @@ $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteCommitRa \vspace{-2.5ex} where $\NoteCommitAlg{Sapling}$ is instantiated in \crossref{concretewindowedcommit}. -Notice that the above definition of a \Sapling{} \note does not have a +Notice that the above definition of a \Sapling \note does not have a $\NoteUniqueRand$ field. There is in fact a $\NoteUniqueRand$ value associated -with each \Sapling{} \note, but this can only be computed once its position in the +with each \Sapling \note, but this can only be computed once its position in the \noteCommitmentTree is known (see \crossref{transactions} and \crossref{merkletree}). We refer to the combination of a \note and its \notePosition $\NotePosition$, as a \positionedNote. @@ -3159,7 +3184,7 @@ $\NoteTuple{} = (\Diversifier, \DiversifiedTransmitPublic, \Value, \NoteUniqueRa \vspace{-2.5ex} where $\NoteCommitAlg{Orchard}$ is instantiated in \crossref{concretesinsemillacommit}. -Unlike in \Sapling, the definition of an \Orchard{} \note includes the +Unlike in \Sapling, the definition of an \Orchard \note includes the $\NoteUniqueRand$ field; the \note's position in the \noteCommitmentTree does not need to be known in order to compute this value. } %orchard @@ -3203,7 +3228,7 @@ The \notePlaintexts in each \joinSplitDescription are encrypted to the respective \transmissionKeys $\TransmitPublicNew{\allNew}$. \introlist -Each \SproutOrNothing{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists of +Each \Sprout{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) consists of \vspace{-1ex} \begin{formulae} @@ -3213,7 +3238,7 @@ Each \SproutOrNothing{} \defining{\notePlaintext} (denoted $\NotePlaintext{}$) c \end{formulae} \saplingonward{ -The \notePlaintext in each \outputDescription is encrypted to the +The \notePlaintext in each \outputDescription\orchard{ or \actionDescription} is encrypted to the \diversifiedPaymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$. \introlist @@ -3279,7 +3304,7 @@ As in \Bitcoin, the remaining value in the pool is available to miners as a fee. \vspace{-3ex} \consensusrule{ -The remaining value in the \transparentTxValuePool{} \MUST be nonnegative. +The remaining value in the \transparentTxValuePool \MUST be nonnegative. } \vspace{2ex} @@ -3346,7 +3371,7 @@ The \changed{total $\vpubNew$ value adds to, and the total} $\vpubOld$ value subtracts from the \transparentTxValuePool of the containing \transaction. The \anchor of each \joinSplitDescription in a \transaction{} refers to a -\SproutOrNothing{} \treestate. +\Sprout \treestate. For each of the $\NOld$ \shieldedInputs, a \nullifier is revealed. This allows detection of double-spends as described in \crossref{nullifierset}. @@ -3367,15 +3392,15 @@ it is not known where it will eventually appear in a mined \block. Therefore the \vspace{-3ex} \begin{consensusrules} - \item The input and output values of each \joinSplitTransfer{} \MUST balance + \item The input and output values of each \joinSplitTransfer \MUST balance exactly. \vspace{-0.5ex} - \item For the first \joinSplitDescription of a \transaction, the \anchor{} \MUST - be the output \SproutOrNothing{} \treestate of a previous \block. + \item For the first \joinSplitDescription of a \transaction, the \anchor \MUST + be the output \Sprout \treestate of a previous \block. \changed{ \vspace{-0.5ex} - \item The \anchor of each \joinSplitDescription in a \transaction{} \MUST refer - to either some earlier \block's final \SproutOrNothing{} \treestate, or to + \item The \anchor of each \joinSplitDescription in a \transaction \MUST refer + to either some earlier \block's final \Sprout \treestate, or to the interstitial output \treestate of any prior \joinSplitDescription in the same \transaction. } @@ -3387,7 +3412,7 @@ it is not known where it will eventually appear in a mined \block. Therefore the \lsubsection{Spend Transfers, Output Transfers, and their Descriptions}{spendsandoutputs} \vspace{-1ex} -\joinSplitTransfers are not used for \Sapling{} \notes. \defining{Instead, there is a +\joinSplitTransfers are not used for \Sapling \notes. \defining{Instead, there is a separate \spendTransfer for each \shieldedInput, and a separate \outputTransfer for each \shieldedOutput.} @@ -3420,7 +3445,7 @@ that the result commits to a value consistent with the net \transparent value ch This approach allows all of the \zkSNARK \statements to be independent of each other, potentially increasing opportunities for precomputation. -A \spendDescription specifies an \anchor, which refers to the output \Sapling{} \treestate +A \spendDescription specifies an \anchor, which refers to the output \Sapling \treestate of a previous \block. It also reveals a \nullifier, which allows detection of double-spends as described in \crossref{nullifierset}. @@ -3436,8 +3461,8 @@ for the whole \transaction to balance. \begin{consensusrules} \item The \spendTransfers and \actionTransfers of a \transaction \MUST be consistent with its $\vBalance{Sapling}$ value as specified in \crossref{saplingbalance}. - \item The \anchor of each \spendDescription{} \MUST refer to some earlier \block's final - \Sapling{} \treestate. \orchard{The \anchor is encoded separately in each \spendDescription + \item The \anchor of each \spendDescription \MUST refer to some earlier \block's final + \Sapling \treestate. \orchard{The \anchor is encoded separately in each \spendDescription for v4 \transactions, or encoded once and shared between all \spendDescriptions in a v5 \transaction.} \end{consensusrules} @@ -3535,7 +3560,7 @@ revealed in \joinSplitDescriptions\sapling{ and \spendDescriptions}\orchard{ and double-spends. \consensusrule{ -A \nullifier{} \MUSTNOT repeat either within a \transaction, or across \transactions +A \nullifier \MUSTNOT repeat either within a \transaction, or across \transactions in a \validBlockChain. \sapling{\Sprout and \SaplingAndOrchard \nullifiers are considered disjoint, even if they have the same bit pattern.} } @@ -3564,16 +3589,16 @@ The first (and only the first) \transaction in a block is a \defining{\coinbaseT which collects and spends any \minerSubsidy and \transactionFees paid by \transactions included in this \block. -\precanopy{The \coinbaseTransaction{} \MUST also pay the \foundersReward as described in \\ -\crossref{foundersreward}.} +\precanopy{As described in \crossref{foundersreward}, the \coinbaseTransaction \MUST also pay +the \foundersReward.} -\canopyonward{The \coinbaseTransaction \MUST also pay the \fundingStreams as described in \\ -\crossref{fundingstreams}.} +\canopyonward{As described in \crossref{fundingstreams}, the \coinbaseTransaction \MUST also pay +the \fundingStreams.} \lsubsection{Mainnet and Testnet}{networks} -The production \Zcash \defining{\network}, which supports the \ZEC token, is called \Mainnet. Governance of its +The production \Zcash{} \defining{\network}, which supports the \ZEC token, is called \Mainnet. Governance of its protocol is by agreement between the Electric Coin Company and the Zcash Foundation \cite{ECCZF2019}. Subject to errors and omissions, each version of this document intends to describe some version (or planned version) of that agreed protocol. @@ -3610,19 +3635,26 @@ Other \networks using variants of the \Zcash protocol may exist, but are not des \lsubsubsection{Hash Functions}{abstracthashes} Let $\MerkleDepth{Sprout}$, $\MerkleHashLength{Sprout}$, -\sapling{$\MerkleDepth{Sapling}$, $\MerkleHashLength{Sapling}$, $\InViewingKeyLength{Sapling}$, $\DiversifierLength$,} +\sapling{$\MerkleDepth{Sapling}$, $\MerkleHashLength{Sapling}$,} +\orchard{$\MerkleDepth{Orchard}$, $\MerkleHashLength{Orchard}$,} +\sapling{$\InViewingKeyLength{Sapling}$, $\DiversifierLength$,} $\RandomSeedLength$, $\PRFOutputLengthSprout$, $\hSigLength$, and $\NOld$ be as defined in \crossref{constants}. \sapling{ Let $\GroupJ$, $\SubgroupJ$, $\SubgroupJstar$, $\ParamJ{r}$, and $\ellJ$ be as defined in \crossref{jubjub}. } %sapling +\orchard{ +Let $\GroupP$ be as defined in \crossref{pallasandvesta}. +} %orchard + \sprout{ $\MerkleCRH \typecolon \MerkleHash{Sprout} \times \MerkleHash{Sprout} \rightarrow \MerkleHash{Sprout}$ is a \collisionResistant \hashFunction used in \crossref{merklepath}. It is instantiated in \crossref{merklecrh}. } %sprout \notsprout{ +\introlist The following \hashFunctions are used in \crossref{merklepath}: \begin{tabular}{@{\hskip 2em}l@{\;}l@{\;}l@{\;}l@{\;}l} @@ -3651,22 +3683,22 @@ It is instantiated in \crossref{equihashgen}. } \sapling{ -$\CRHivk \typecolon \ReprJ \times \ReprJ \rightarrow \InViewingKeyType{Sapling}$ +$\CRHivk \typecolon \ReprJ \times \ReprJ \rightarrow \InViewingKeyTypeSapling$ is a \collisionResistant \hashFunction used in \crossref{saplingkeycomponents} -to derive an \incomingViewingKey for a \Sapling{} \paymentAddress. It is also used +to derive an \incomingViewingKey for a \Sapling \paymentAddress. It is also used in the \spendStatement (\crossref{spendstatement}) to confirm use of the correct keys for the \note being spent. It is instantiated in \crossref{concretecrhivk}. $\MixingPedersenHash \typecolon \GroupJ \times \range{0}{\ParamJ{r}-1} \rightarrow \GroupJ$ is a \hashFunction used in \crossref{commitmentsandnullifiers} -to derive the unique $\NoteUniqueRand$ value for a \Sapling{} \note. It is also used +to derive the unique $\NoteUniqueRand$ value for a \Sapling \note. It is also used in the \spendStatement to confirm use of the correct $\NoteUniqueRand$ value as an input to \nullifier derivation. It is instantiated in \crossref{concretemixinghash}. $\DiversifyHash{Sapling} \typecolon \DiversifierType \rightarrow \SubgroupJstar$\orchard{ and $\DiversifyHash{Orchard} \typecolon \DiversifierType \rightarrow \GroupP$}\notorchard{ is a \hashFunction}\orchard{ are \hashFunctions} instantiated in \crossref{concretediversifyhash}, -and satisfying the Unlinkability security property described in that section. \notorchard{It is}\orchard{They are} +satisfying the Unlinkability security property described in that section. \notorchard{It is}\orchard{They are} used to derive a \diversifiedBase from a \diversifier, which is specified in \crossref{saplingkeycomponents}\orchard{ and in \crossref{orchardkeycomponents}}. } %sapling @@ -3675,66 +3707,78 @@ used to derive a \diversifiedBase from a \diversifier, which is specified in \introsection \lsubsubsection{Pseudo Random Functions}{abstractprfs} -$\PRF{x}{}$ is a \defining{\pseudoRandomFunction} keyed by $x$. +$\PRF{x}{}$ denotes a \defining{\pseudoRandomFunction} keyed by $x$. -Let $\AuthPrivateLength$, \changed{$\NoteUniquePreRandLength$,} $\hSigLength$, -$\PRFOutputLengthSprout$, \sapling{$\SpendingKeyLength$, $\OutViewingKeyLength$, -$\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,} +Let $\AuthPrivateLength$, $\hSigLength$, $\PRFOutputLengthSprout$, \changed{$\NoteUniquePreRandLength$,} +\sapling{$\SpendingKeyLength$, $\OutViewingKeyLength$, $\PRFOutputLengthExpand$, $\PRFOutputLengthNfSapling$,} $\NOld$, and $\NNew$ be as defined in \crossref{constants}. \sapling{ -Let $\ellJ$ and $\SubgroupReprJ$ be as defined in \crossref{jubjub}. - Let $\Sym$ be as defined in \crossref{concretesym}. } %sapling +\sapling{ +\vspace{-0.5ex} +Let $\ellJ$ and $\SubgroupReprJ$ be as defined in \crossref{jubjub}. +} %sapling + +\orchard{ +Let $\ellP$ and $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. +} %orchard + \vspace{1ex} \sprout{\changed{Four} \emph{independent} $\PRF{x}{}$ are needed in our protocol:} \notsprout{For \Sprout, \changed{four} \emph{independent} $\PRF{x}{}$ are needed:} -\begin{tabular}{@{\hskip 2em}l@{\notsprout{\hskip 1.88em}}l@{\;}l@{\;}l@{\,\notsprout{\hskip 5em}}l} -$\PRFaddr{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \byte $& &$\rightarrow \PRFOutputSprout$ \\ -$\PRFpk{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \setofOld $&$\times\; \hSigType $&$\rightarrow \PRFOutputSprout$ \\ +\begin{tabular}{@{\hskip 2em}l@{\;\notorchard{\hskip 0.86em}}l@{\;\notorchard{\hskip 0.54em}}l@{\;}l@{\,\notorchard{\notsprout{\hskip 4em}}}l} +$\PRFaddr{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \byte $& &$\rightarrow \PRFOutputSprout$ \\ +$\PRFpk{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \setofOld $&$\times\; \hSigType $&$\rightarrow \PRFOutputSprout$ \\ $\setchanged\PRFrho{} $&$\setchanged\typecolon\; \bitseq{\NoteUniquePreRandLength} $&$\setchanged\times\; \setofNew $&$\setchanged\times\; \hSigType $&$\setchanged\rightarrow \PRFOutputSprout$ \\ -$\PRFnf{Sprout}{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \PRFOutputSprout $& &$\rightarrow \PRFOutputSprout$ +$\PRFnf{Sprout}{} $&$\typecolon\; \bitseq{\AuthPrivateLength} $&$\times\; \PRFOutputSprout $& &$\rightarrow \PRFOutputSprout$ \end{tabular} These are used in \crossref{joinsplitstatement}; $\PRFaddr{}$ is also used to derive a \paymentAddress from a \spendingKey in \crossref{sproutkeycomponents}. -%\sapling{ +\sapling{ +\vspace{0.5ex} +\introlist For \Sapling, three additional $\PRF{x}{}$ are needed: -\begin{tabular}{@{\hskip 2em}l@{\;}l@{\;}l@{\;}l@{\,}l} -$\PRFexpand{} $&$\typecolon\; \SpendingKeyType $&$\times\; \PRFInputExpand $& &$\rightarrow \PRFOutputExpand$ \\ -$\PRFock{Sapling}{} $&$\typecolon\; \OutViewingKeyType $&$\times\; \ReprJBytes \times \ReprJBytes \times \ReprJBytes $& &$\rightarrow \Keyspace$ \\ -$\PRFnf{Sapling}{} $&$\typecolon\; \SubgroupReprJ $&$\times\; \ReprJ $& &$\rightarrow \PRFOutputNfSapling$ +\begin{tabular}{@{\hskip 2em}l@{\hskip 0.5em}l@{\;}l@{\;}l@{\hskip 0.33em}l} +$\PRFexpand{} $&$\typecolon\; \SpendingKeyType $&$\times\; \PRFInputExpand $& &$\rightarrow \PRFOutputExpand$ \\ +$\PRFock{Sapling}{} $&$\typecolon\; \OutViewingKeyType $&$\times\; \ReprJBytes \times \ReprJBytes \times \ReprJBytes $& &$\rightarrow \Keyspace$ \\ +$\PRFnf{Sapling}{} $&$\typecolon\; \SubgroupReprJ $&$\times\; \ReprJ $& &$\rightarrow \PRFOutputNfSapling$ \end{tabular} +} %sapling -%\orchard{ +\orchard{ +\introlist For \Orchard, we need $\PRFexpand{}$, and also: \begin{tabular}{@{\hskip 2em}l@{\;}l@{\;}l@{\;}l@{\,}l} -$\PRFock{Orchard}{} $&$\typecolon\; \OutViewingKeyType $&$\times\; \ReprJBytes \times \ReprJBytes \times \ReprJBytes $& &$\rightarrow \Keyspace$ \\ -$\PRFnf{Orchard}{} $&$\typecolon\; \NullifierKeyType $&$\times\; \NoteUniqueRandTypeOrchard $& &$\rightarrow \PRFOutputNfOrchard$ +$\PRFock{Orchard}{} $&$\typecolon\; \OutViewingKeyType $&$\times\; \ReprPBytes \times \ReprPBytes \times \ReprPBytes $& &$\rightarrow \Keyspace$ \\ +$\PRFnf{Orchard}{} $&$\typecolon\; \NullifierKeyTypeOrchard $&$\times\; \NoteUniqueRandTypeOrchard $& &$\rightarrow \PRFOutputNfOrchard$ \end{tabular} -%} %orchard +} %orchard +\sapling{ $\PRFexpand{}$ is used in the following places: \begin{itemize} \item \crossref{saplingkeycomponents}, with inputs $[0]$, $[1]$, $[2]$, and $[3, i \typecolon \byte]$; \orchardonwarditem{in \crossref{orchardkeycomponents}, with inputs $[6]$, $[7]$, and $[8]$;} - \item in the processes of sending and receiving \SaplingOrOrchard \notes - (see \crossref{saplingandorchardsend} and \crossref{saplingandorchardinband}), with inputs $[4]$ and $[5]$; + \item when sending and receiving \SaplingOrOrchard \notes + in \crossref{saplingandorchardsend} and \crossref{saplingandorchardinband}, with inputs $[4]$ and $[5]$; \item in \cite{ZIP-32}, with inputs $[0]$, $[1]$, $[2]$ (intentionally matching \shortcrossref{saplingkeycomponents}), - and $[t \typecolon \range{16}{22}]$. + and $[t \typecolon \range{16}{22}]$\notorchard{.}\notbeforeorchard{;} + \orchardonwarditem{in \cite{ZIP-32}, with inputs $\hexint{81}$ and $\hexint{82}$.} \end{itemize} -$\PRFock{Sapling}{}$\notorchard{ is}\orchard{ and $\PRFock{Orchard}{}$ are} used in \crossref{inband}. +$\PRFock{Sapling}{}$\notorchard{ is}\orchard{ and $\PRFock{Orchard}{}$ are} used in \crossref{saplingandorchardinband}. $\PRFnf{Sapling}{}$ is used in \crossref{spendstatement}. -%} %sapling +} %sapling \orchard{ $\PRFnf{Orchard}{}$ is used in \crossref{actionstatement}. @@ -3863,8 +3907,8 @@ This is not considered to be a significant security weakness.} \notsprout{ \introlist -The inputs to the \keyDerivationFunction differ between the \Sprout and -\Sapling KDFs: +\sapling{The inputs to the \keyDerivationFunction differ between the \Sprout and +\SaplingAndOrchard KDFs:} $\KDF{Sprout}$ takes as input an output index in $\setofNew$, the value $\hSig$, the shared Diffie--Hellman secret $\DHSecret{}$, @@ -4004,9 +4048,11 @@ pair without access to the \signingKey. \sapling{ +\vspace{-2ex} \introsection \lsubsubsubsection{Signature with Re-Randomizable Keys}{abstractsigrerand} +\vspace{-1ex} A \defining{\rerandomizableSignatureScheme} $\Sig$ is a \signatureScheme that additionally defines: @@ -4018,9 +4064,9 @@ additionally defines: \item a distinguished ``identity'' \randomizer $\SigRandomizerId \typecolon \SigRandom$ \end{itemize} -\vspace{-1.2ex} +\vspace{-1.5ex} such that: -\vspace{0.8ex} +\vspace{1ex} \begin{itemize} \item for any $\SigRandomizer \typecolon \SigRandom$, @@ -4032,7 +4078,7 @@ such that: \item $\SigRandomizePrivate(\SigRandomizer, \sk) : \SigRandomizer \leftarrowR \SigGenRandom()$ \end{formulae} \vspace{-1.5ex} is identically distributed to $\SigGenPrivate()$. - \vspace{1ex} + \vspace{0.5ex} \item for any $\sk \typecolon \SigPrivate$ and $\SigRandomizer \typecolon \SigRandom$, \begin{formulae} \item $\SigRandomizePublic(\SigRandomizer, \SigDerivePublic(\sk)) = @@ -4040,6 +4086,7 @@ such that: \end{formulae} \end{itemize} +\vspace{-1ex} The following security requirement for such \signatureSchemes is based on that given in \cite[section 3]{FKMSSS2016}. Note that we require Strong Unforgeability with Re-randomized Keys, not Existential Unforgeability with Re-randomized Keys @@ -4050,7 +4097,7 @@ a given key. (Although each \note uses a different re-randomized key pair, the s original key pair can be re-randomized for multiple \notes, and also it can happen that multiple \transactions spending the same \note are revealed to an adversary.) -\introsection +\introlist \securityrequirement{\textbf{Strong Unforgeability with Re-randomized Keys under adaptive Chosen Message Attack (SURK-CMA)} For any $\sk \typecolon \SigPrivate$, let @@ -4140,7 +4187,7 @@ With a change of notation from $\mu$ to $\SigDerivePublic$, $+$ to $\grpplus$, a this is similar to the definition of a \quotedtermnoindex{Signature with Secret Key to Public Key Homomorphism} in \cite[Definition 13]{DS2016}, except for an additional requirement for the homomorphism to be injective. -\introsection +\introlist \securityrequirement{ For any $\sk_1 \typecolon \SigPrivate$, and an unknown $\sk_2 \leftarrowR \SigGenPrivate()$ chosen independently of $\sk_1$, the distribution of $\sk_1 \grpplus \sk_2$ is @@ -4215,7 +4262,7 @@ and $\ValueLength$ be as defined in \crossref{constants}. Define $\NoteCommitTrapdoor{Sprout} := \bitseq{\NoteCommitRandLength}$ and $\NoteCommitOutput{Sprout} := \bitseq{\MerkleHashLength{Sprout}}$. -\SproutOrZcash uses a \note{} \commitmentScheme +\Sprout uses a \note \commitmentScheme \begin{tabular}{@{\hskip 1.5em}r@{\;}l} $\NoteCommit{Sprout}{} $&$\typecolon\; \NoteCommitTrapdoor{Sprout} \times \PRFOutputSprout @@ -4281,7 +4328,7 @@ Define: $\NoteCommitAlg{Orchard} $&$\typecolon\; \NoteCommitTrapdoor{Orchard} \times \ReprP \times \ReprP \times \ValueType$ \\[-1ex] &\hspace{21.2em}$\times\; \NoteUniqueRandTypeOrchard \times \NoteNullifierRandType $&$\rightarrow \NoteCommitOutput{Orchard}$ \\ $\ValueCommitAlg{Orchard} $&$\typecolon\; \ValueCommitTrapdoor{Orchard} \times \ValueCommitTypeOrchard $&$\rightarrow \ValueCommitOutput{Orchard}$ \\ - $\CommitIvkAlg $&$\typecolon\; \CommitIvkTrapdoor \times \GF{\ParamP{q}} \times \NullifierKeyType $&$\rightarrow \CommitIvkOutput$ + $\CommitIvkAlg $&$\typecolon\; \CommitIvkTrapdoor \times \GF{\ParamP{q}} \times \NullifierKeyTypeOrchard $&$\rightarrow \CommitIvkOutput$ \end{tabular} $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$ are instantiated in \crossref{concreteorchardnotecommit}. @@ -4583,9 +4630,10 @@ them to be the relevant \Groth \provingKeys and \verifyingKeys defined in \crossref{grothparameters}. \orchard{ -We also omit subscripts on $\ActionProve$ and $\ActionVerify$, -taking them to be the relevant \HaloTwo \provingKeys and -\verifyingKeys defined in \crossref{halo2parameters}. +We also omit subscripts on $\ActionProve$ and $\ActionVerify$. +For \HaloTwo, parameters for a given circuit implementation are +generated on the fly by the \halotwo library, and do not require +parameter files. } %orchard } %sapling @@ -4601,7 +4649,7 @@ Let $\PRFaddr{}$ be a \pseudoRandomFunction, instantiated in \crossref{concretep Let $\KA{Sprout}$ be a \keyAgreementScheme, instantiated in \crossref{concretesproutkeyagreement}. \vspace{0.5ex} -A new \SproutOrNothing{} \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence +A new \Sprout \spendingKey $\AuthPrivate$ is generated by choosing a bit sequence uniformly at random from $\bitseq{\AuthPrivateLength}$. \introlist @@ -4650,7 +4698,7 @@ Define $\AuthProveBaseSapling := \FindGroupJHash\Of{\ascii{Zcash\_H\_}, \ascii{} Define $\ToScalar{Sapling}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamJ{r}}$. \introlist -A new \Sapling{} \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Sapling \spendingKey $\SpendingKey$ is generated by choosing a bit sequence uniformly at random from $\SpendingKeyType$. From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamJ{r}}$, @@ -4668,7 +4716,7 @@ If $\AuthSignPrivate = 0$, discard this key and repeat with a new $\SpendingKey$ \vspace{1ex} $\AuthSignPublic \typecolon \SubgroupJstar$, $\NullifierKey \typecolon \SubgroupJ$, and -the \incomingViewingKey $\InViewingKey \typecolon \InViewingKeyType{Sapling}$ are then derived as: +the \incomingViewingKey $\InViewingKey \typecolon \InViewingKeyTypeSapling$ are then derived as: \vspace{-0.5ex} \begin{tabular}{@{\hskip 1.7em}r@{\;}l} @@ -4686,13 +4734,12 @@ authority. A group of such addresses shares the same \fullViewingKey and \introlist To create a new \diversifiedPaymentAddress given an \incomingViewingKey -$\InViewingKey$, repeatedly pick a \defining{\diversifier} $\Diversifier$ uniformly at -random from $\DiversifierType$ until the \defining{\diversifiedBase} -$\DiversifiedTransmitBase = \DiversifyHash{Sapling}(\Diversifier)$ is not $\bot$. +$\InViewingKey$, pick a \defining{\diversifier} $\Diversifier$ uniformly at +random from $\DiversifierType$. Then calculate the \defining{\diversifiedTransmissionKey} $\DiversifiedTransmitPublic$: \begin{formulae} - \item $\DiversifiedTransmitPublic := \KADerivePublic{Sapling}(\InViewingKey, \DiversifiedTransmitBase)$. + \item $\DiversifiedTransmitPublic := \KADerivePublic{Orchard}(\InViewingKey, \DiversifiedTransmitBase)$. \end{formulae} \vspace{-1ex} @@ -4746,19 +4793,19 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. Define $f \typecolon \SpendingKeyType \times \PRFInputExpand \rightarrow \GF{\ParamJ{r}}$ by $f_{\sk}(t) := \ToScalar{Sapling}(\PRFexpand{\SpendingKey}(t))$. - Then $f$ is also a \xPRF, since + $f$ is also a \xPRF since $\LEOStoIP{\PRFOutputLengthExpand} \typecolon \PRFOutputExpand \rightarrow \binaryrange{\PRFOutputLengthExpand}$ is injective; the bias introduced by reduction modulo $\ParamJ{r}$ is small because \crossref{constants} defines $\PRFOutputLengthExpand$ as $512$, while $\ParamJ{r}$ has length $252$ bits. It follows that the distribution of $\AuthSignPrivate$, i.e.\ $\PRFexpand{\SpendingKey}([0]) : \SpendingKey \leftarrowR \SpendingKeyType$, - is computationally indistinguishable from that of $\SpendAuthSigGenPrivate{Sapling}()$ defined + is computationally indistinguishable from $\SpendAuthSigGenPrivate{Sapling}()$ defined in \crossref{concretespendauthsig}. \item Similarly, the distribution of $\AuthProvePrivate$, i.e.\ $\ToScalar{Sapling}(\PRFexpand{\SpendingKey}([1])) : \SpendingKey \leftarrowR \SpendingKeyType$, is computationally indistinguishable from the uniform distribution on $\GF{\ParamJ{r}}$. Since $\fun{\AuthProvePrivate \typecolon \GF{\ParamJ{r}}^{\vphantom{X}}} - {\reprJ\Of{\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}} \typecolon \SubgroupReprJ}$ + {\reprJ\big(\scalarmult{\AuthProvePrivate}{\AuthProveBaseSapling}} \typecolon \SubgroupReprJ\big)$ is bijective, the distribution of $\reprJ\Of{\NullifierKey}$ will be computationally indistinguishable from uniform on $\SubgroupReprJ$ (which is the keyspace of $\PRFnf{Sapling}{}$). \item The \zcashd wallet picks \diversifiers as in \cite{ZIP-32}, rather than using the default @@ -4768,11 +4815,12 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. } %sapling -\orchard{ +%\orchard{ +\introsection \lsubsubsection{\OrchardText{} Key Components}{orchardkeycomponents} -Let $\PRFOutputLengthExpand$, $\SpendingKeyLength$, $\OutViewingKeyLength$, and $\DiversifierLength$ -be as defined in \crossref{constants}. +Let $\PRFOutputLengthExpand$, $\SpendingKeyLength$, $\OutViewingKeyLength$, $\DiversifierLength$, +and $\DiversifierKeyLength$ be as defined in \crossref{constants}. Let $\PRFexpand{}$ and $\PRFock{Orchard}{}$, instantiated in \crossref{concreteprfs}, be \pseudoRandomFunctions. @@ -4780,7 +4828,8 @@ be \pseudoRandomFunctions. Let $\KA{Orchard}$, instantiated in \crossref{concreteorchardkeyagreement}, be a \keyAgreementScheme. -Let $\CommitIvk{}$, instantiated in \crossref{concretecommitivk}, be a \commitmentScheme. +Let $\CommitIvk{}$, instantiated in \crossref{concretesinsemillacommit}, +be a \commitmentScheme. Let $\DiversifyHash{Orchard}$, instantiated in \crossref{concretediversifyhash}, be a \hashFunction. @@ -4788,40 +4837,45 @@ be a \hashFunction. Let $\SpendAuthSig{Orchard}$ instantiated in \crossref{concretespendauthsig} be a \rerandomizableSignatureScheme. -Let $\reprP$, $\GroupP$, $\GroupPstar$, and $\ReprP$ be as defined in \crossref{pallasandvesta}. +Let $\reprP$, $\GroupP$, $\ParamP{r}$, and $\ReprP$ be as defined in \crossref{pallasandvesta}. and let $\GroupPHash$ be as defined in \crossref{concretegrouphashpallasandvesta}. Let $\LEBStoOSP{} \typecolon (\ell \typecolon \Nat) \times \bitseq{\ell} \rightarrow \byteseq{\sceiling{\ell/8}}$ and $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \times \byteseq{\ell/8} \rightarrow \binaryrange{\ell}$ be as defined in \crossref{endian}. +Define $\ToScalar{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{r}}$. + +Define $\ToBase{Orchard}(x \typecolon \PRFOutputExpand) := \LEOStoIPOf{\PRFOutputLengthExpand}{x} \pmod{\ParamP{q}}$. + \introlist -A new \Orchard{} \spendingKey $\SpendingKey$ is generated by choosing a bit sequence +A new \Orchard \spendingKey $\SpendingKey$ is generated by choosing a bit sequence uniformly at random from $\SpendingKeyType$. From this \spendingKey, the \authSigningKey $\AuthSignPrivate \typecolon \GFstar{\ParamP{r}}$, -the \nullifierDerivingKey $\NullifierKey \typecolon \NullifierKeyType$, and the -\nullifierRandomness $\CommitIvkRand \typecolon \CommitIvkRandType$ are derived as follows: +the \nullifierDerivingKey $\NullifierKey \typecolon \NullifierKeyTypeOrchard$, and the +\commitIvkRandomness $\CommitIvkRand \typecolon \CommitIvkRandType$ are derived as follows: \vspace{-0.5ex} +\todo{check field sizes.} \begin{tabular}{@{\hskip 1.7em}r@{\;}l} - $\AuthSignPrivate$ &$:= \truncate{\ScalarLength{Orchard}}(\PRFexpand{\SpendingKey}([6]))$ \\ - $\NullifierKey$ &$:= \truncate{\ScalarLength{Orchard}}(\PRFexpand{\SpendingKey}([7]))$ \\ - $\OutViewingKey$ &$:= \truncate{(\OutViewingKeyLength/8)}(\PRFexpand{\SpendingKey}([8]))$ + $\AuthSignPrivate$ &$:= \ToScalar{Orchard}(\PRFexpand{\SpendingKey}([6]))$ \\ + $\NullifierKey$ &$:= \ToBase{Orchard}(\PRFexpand{\SpendingKey}([7]))$ \\ + $\CommitIvkRand$ &$:= \ToScalar{Orchard}(\PRFexpand{\SpendingKey}([8]))$ \end{tabular} If $\AuthSignPrivate = 0$, discard this key and repeat with a new $\SpendingKey$. \vspace{1ex} $\AuthSignPublic \typecolon \GroupP$, the \incomingViewingKey -$\InViewingKey \typecolon \InViewingKeyType{Orchard}$, and the \outgoingViewingKey -$\OutViewingKey \typecolon \OutViewingKeyType{Orchard}$ are then derived as: +$\InViewingKey \typecolon \InViewingKeyTypeOrchard$, and the \outgoingViewingKey +$\OutViewingKey \typecolon \OutViewingKeyType$ are then derived as: \vspace{-0.5ex} \begin{tabular}{@{\hskip 1.7em}r@{\;}l} $\AuthSignPublic$ &$:= \SpendAuthSigDerivePublic{Orchard}(\AuthSignPrivate)$ \\ - $\InViewingKey$ &$:= \CommitIvk{\CommitIvkRand}\big(\reprP\Of{\ExtractP{\AuthSignPublic}}, \reprP\Of{\NullifierKey}\kern-0.08em\big)$ \\ - $\OutViewingKey$ &$:= \CRHovk\big(\CommitIvkRand, \reprP\Of{\ExtractP{\AuthSignPublic}}, \reprP\Of{\NullifierKey}\kern-0.08em\big)$. + $\InViewingKey$ &$:= \CommitIvk{\CommitIvkRand}\big(\ExtractP(\AuthSignPublic), \NullifierKey\big)$ \\ + $\OutViewingKey$ &$:= \CRHovk\big(\CommitIvkRand, \ExtractP(\AuthSignPublic), \NullifierKey\big)$. \end{tabular} As explained in \crossref{addressesandkeys}, \Orchard allows the efficient @@ -4829,6 +4883,8 @@ creation of multiple \diversifiedPaymentAddresses with the same spending authority. A group of such addresses shares the same \fullViewingKey, \incomingViewingKey, and \outgoingViewingKey. +$\DiversifierKey$ is derived as specified in \cite{ZIP-32}. + \introlist To create a new \diversifiedPaymentAddress given an \incomingViewingKey $\InViewingKey$, repeatedly pick a \defining{\diversifier} $\Diversifier$ uniformly at @@ -4904,7 +4960,7 @@ if this happens, discard the key and repeat with a different $\SpendingKey$. \item The \zcashd wallet picks \diversifiers as in \cite{ZIP-32}, rather than using the default \diversifier specified above. \end{nnotes} -} %orchard +%} %orchard \lsubsection{JoinSplit Descriptions}{joinsplitdesc} @@ -4978,7 +5034,7 @@ $\joinSplitPubKey$ of the containing \transaction: \end{formulae} \begin{consensusrules} - \item Elements of a \joinSplitDescription{} \MUST have the types given + \item Elements of a \joinSplitDescription \MUST have the types given above (for example: $0 \leq \vpubOld \leq \MAXMONEY$ and $0 \leq \vpubNew \leq \MAXMONEY$). \item The proof $\Proof{\JoinSplit}$ \MUST be valid given a \primaryInput formed from the relevant other fields and $\hSig$ --- i.e.\ $\JoinSplitVerify{}\big(\kern-0.1em(\rt{Sprout}, \nfOld{\allOld}, @@ -5007,6 +5063,7 @@ Let $\SpendAuthSig{Sapling}$ be as defined in \crossref{spendauthsig}. Let $\Spend$ be as defined in \crossref{abstractzk}. \vspace{1ex} +\introlist A \spendDescription consists of $(\cv, \rt{Sapling}, \nf, \AuthSignRandomizedPublic, \ProofSpend, \spendAuthSig)$ where \vspace{1ex} @@ -5024,7 +5081,10 @@ where \end{itemize} \begin{consensusrules} - \item Elements of a \spendDescription{} \MUST be canonical encodings of the types given above. + \item Elements of a \spendDescription \MUST be valid encodings of the types given above. + \orchardonwarditem{As required by \cite{ZIP-216}, $\cv$ and $\AuthSignRandomizedPublic$ + \MUST be canonically encoded, i.e.\ $\reprJ\Of{\abstJ\Of{\cv}} = \cv$ and + $\reprJ\Of{\abstJ\Of{\AuthSignRandomizedPublic}} = \AuthSignRandomizedPublic$.} \item $\cv$ and $\AuthSignRandomizedPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\AuthSignRandomizedPublic}$ \MUSTNOT be $\ZeroJ$. \item The proof $\Proof{\Spend}$ \MUST be valid given a \primaryInput formed @@ -5033,9 +5093,11 @@ where \item Let $\SigHash$ be the \sighashTxHash of this \transaction, not associated with an input, as defined in \crossref{sighash} using $\SIGHASHALL$. - The \spendAuthSignature{} \MUST be a valid $\SpendAuthSig{Sapling}$ signature over $\SigHash$ + The \spendAuthSignature \MUST be a valid $\SpendAuthSig{Sapling}$ signature over $\SigHash$ using $\AuthSignRandomizedPublic$ as the \validatingKey --- i.e.\ $\SpendAuthSigValidate{Sapling}{\AuthSignRandomizedPublic}(\SigHash, \spendAuthSig) = 1$. + \orchardonward{As specified in \crossref{concretereddsa}, the validation of the $\RedDSAReprR{}$ + component of the signature changes to prohibit \nonCanonicalPoint encodings.} \end{consensusrules} \vspace{-1ex} @@ -5085,7 +5147,10 @@ where \end{itemize} \begin{consensusrules} - \item Elements of an \outputDescription{} \MUST be canonical encodings of the types given above. + \item Elements of an \outputDescription \MUST be valid encodings of the types given above. + \orchardonwarditem{As required by \cite{ZIP-216}, $\cv$ and $\EphemeralPublic$ + \MUST be canonically encoded, i.e.\ $\reprJ\Of{\abstJ\Of{\cv}} = \cv$ and + $\reprJ\Of{\abstJ\Of{\EphemeralPublic}} = \EphemeralPublic$.} \item $\cv$ and $\EphemeralPublic$ \MUSTNOT be of small order, i.e.\ $\scalarmult{\ParamJ{h}}{\cv}$ \MUSTNOT be $\ZeroJ$ and $\scalarmult{\ParamJ{h}}{\EphemeralPublic}$ \MUSTNOT be $\ZeroJ$. \item The proof $\Proof{\Output}$ \MUST be valid given a \primaryInput formed @@ -5150,13 +5215,15 @@ where \end{itemize} \begin{consensusrules} - \item Elements of an \actionDescription{} \MUST be canonical encodings of the types given above. + \item Elements of an \actionDescription \MUST be canonical encodings of the types given above. \item Let $\SigHash$ be the \sighashTxHash of this \transaction, not associated with an input, as defined in \crossref{sighash} using $\SIGHASHALL$. - The \spendAuthSignature{} \MUST be a valid $\SpendAuthSig{Orchard}$ signature over $\SigHash$ + The \spendAuthSignature \MUST be a valid $\SpendAuthSig{Orchard}$ signature over $\SigHash$ using $\AuthSignRandomizedPublic$ as the \validatingKey --- i.e.\ $\SpendAuthSigValidate{Orchard}{\AuthSignRandomizedPublic}(\SigHash, \spendAuthSig) = 1$. + As specified in \crossref{concretereddsa}, validation of the $\RedDSAReprR{}$ component + of the signature prohibits \nonCanonicalPoint encodings. \item The proof $\Proof{\Action}$ \MUST be valid given a \primaryInput formed from $(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \EphemeralPublic)$ --- i.e.\ $\ActionVerify\big(\kern-0.1em(\cv, \rt{Orchard}, \nf, \AuthSignRandomizedPublic, \cmX, \EphemeralPublic), \Proof{\Action}\big) = 1$. @@ -5171,7 +5238,7 @@ where \notsprout{\lsubsubsection{Sending Notes (\SproutText)}{sproutsend}} -In order to send \SproutOrNothing{} \shielded value, the sender constructs a +In order to send \Sprout \shielded value, the sender constructs a \transaction containing one or more \joinSplitDescriptions. Let $\JoinSplitSig$ be as specified in \crossref{abstractsig}. @@ -5263,7 +5330,7 @@ Let $\reprJ$ and $\ParamJ{r}$ be as defined in \crossref{jubjub}. \orchard{ Let $\reprP$ and $\ParamP{r}$ be as defined in \crossref{pallasandvesta}. -Let $\repr$ be $\reprJ$ for a \Sapling{} \note, or $\reprP$ for an \Orchard{} \note. +Let $\repr$ be $\reprJ$ for a \Sapling \note, or $\reprP$ for an \Orchard \note. } %orchard \vspace{1ex} @@ -5283,7 +5350,6 @@ that is intended to be able to decrypt this payment. This may be one of: forward secrecy of the payment information with respect to compromise of its own secrets.} \canopy{ -\vspace{1ex} Let $\CanopyActivationHeight$ be as defined in \crossref{constants}. Let $\NotePlaintextLeadByte$ be the \notePlaintextLeadByte. This \MUST be $\hexint{01}$ @@ -5292,7 +5358,6 @@ if $\BlockHeight \geq \CanopyActivationHeight$. } \introlist -\vspace{1ex} For each \outputDescription, the sender selects a value $\Value \typecolon \range{0}{\MAXMONEY}$ and a destination \SaplingOrOrchard \paymentAddress $(\Diversifier, \DiversifiedTransmitPublic)$, and then performs the following steps: @@ -5343,10 +5408,10 @@ and then performs the following steps: $\cvField$ and $\cmuField$ to derive $\OutCipherKey$, and takes $\EphemeralPrivate$ as input. - \item For a \Sapling{} \note, generate a proof $\ProofOutput$ for the \outputStatement in \crossref{outputstatement}. + \item \notbeforeorchard{For a \Sapling \note, generate}\notorchard{Generate} a proof $\ProofOutput$ for the \outputStatement in \crossref{outputstatement}. \orchard{ - \item For an \Orchard{} \note, generate a proof $\ProofAction$ for the \actionStatement in \crossref{actionstatement}. + \item For an \Orchard \note, generate a proof $\ProofAction$ for the \actionStatement in \crossref{actionstatement}. } %orchard \item Return $(\cv, \cm, \EphemeralPublic, \TransmitCiphertext{}, \OutCiphertext, \ProofOutput\orchard{\text{ or }\ProofAction})$. @@ -5378,7 +5443,7 @@ Let $\NoteCommitAlg{Sprout}$ be as defined in \crossref{abstractcommit}. \introlist \vspace{0.5ex} \changed{ -A \dummy{} \SproutOrNothing input \note, with index $i$ in the \joinSplitDescription, +A \dummy \Sprout input \note, with index $i$ in the \joinSplitDescription, is constructed as follows: \vspace{-0.5ex} \begin{itemize} @@ -5394,7 +5459,7 @@ is constructed as follows: \end{itemize} } -A \dummy{} \SproutOrNothing output \note is constructed as normal but with +A \dummy \Sprout output \note is constructed as normal but with zero value, and sent to a random \paymentAddress. @@ -5405,7 +5470,7 @@ zero value, and sent to a random \paymentAddress. In \SaplingAndOrchard there is no need to use \dummyNotes simply in order to fill otherwise unused inputs as in the case of a \joinSplitDescription; nevertheless it may be useful for privacy to obscure the number of real \shieldedInputs from -\Sapling{} \notes\orchard{ and from \Orchard{} \notes}. +\Sapling \notes\orchard{ and from \Orchard \notes}. \todo{generalize for \Orchard} @@ -5422,7 +5487,7 @@ Let $\NoteCommitAlg{Sapling}$ be as defined in \crossref{abstractcommit}. \introlist \vspace{0.5ex} -A \dummy{} \Sapling input \note is constructed as follows: +A \dummy \Sapling input \note is constructed as follows: \vspace{-0.5ex} \begin{itemize} \item Choose uniformly random $\SpendingKey \leftarrowR \SpendingKeyType$. @@ -5442,7 +5507,7 @@ A \dummy{} \Sapling input \note is constructed as follows: \auxiliaryInput to the \spendStatement (this will not be checked, because $\vOld{} = 0$). \end{itemize} -As in \Sprout, a \dummy{} \Sapling output \note is constructed as normal but with +As in \Sprout, a \dummy \Sapling output \note is constructed as normal but with zero value, and sent to a random \paymentAddress. } %sapling @@ -5454,9 +5519,9 @@ zero value, and sent to a random \paymentAddress. The depth of the \noteCommitmentTree is $\MerkleDepth{}$ (defined in \crossref{constants}). } %sprout \notsprout{ -Let $\MerkleDepth{}$ be $\MerkleDepth{Sprout}$ for the \Sprout{} \noteCommitmentTree\sapling{, -or $\MerkleDepth{Sapling}$ for the \Sapling{} \noteCommitmentTree}\orchard{, -or $\MerkleDepth{Orchard}$ for the \Orchard{} \noteCommitmentTree}. +Let $\MerkleDepth{}$ be $\MerkleDepth{Sprout}$ for the \Sprout \noteCommitmentTree\sapling{, +or $\MerkleDepth{Sapling}$ for the \Sapling \noteCommitmentTree}\orchard{, +or $\MerkleDepth{Orchard}$ for the \Orchard \noteCommitmentTree}. These constants are defined in \crossref{constants}. Similarly, let $\MerkleCRH{}$ be $\MerkleCRH{Sprout}$ for \Sprout\sapling{, @@ -5524,9 +5589,9 @@ them to the \transaction for which they are intended. This is done by hashing in about the \transaction and (where applicable) the specific input, to give a \defining{\sighashTxHash} which is then used for the Spend authorization. The means of authorization differs between -\sprout{\transparentInputs and inputs to \Sprout{} \joinSplitTransfers,} -\notsprout{\transparentInputs, inputs to \Sprout{} \joinSplitTransfers,\sapling{ and -\Sapling{} \spendTransfers\orchard{ or \Orchard{} \actionTransfers,}}} +\sprout{\transparentInputs and inputs to \Sprout \joinSplitTransfers,} +\notsprout{\transparentInputs, inputs to \Sprout \joinSplitTransfers,\sapling{ and +\Sapling \spendTransfers\orchard{ or \Orchard \actionTransfers,}}} but for a given \transactionVersion the same \sighashTxHash algorithm is used. In the case of \Zcash, the @@ -5577,15 +5642,15 @@ activation, i.e.\ for version 3 \transactions, is defined in \cite{ZIP-143}.} version 4 \transactions, is defined in \cite{ZIP-243}.} \blossomonward{The \sighashAlgorithm used after \Blossom activation is the same as -for \Sapling, but using the \Blossom{} \consensusBranchID \hexint{2BB40E60} as defined in +for \Sapling, but using the \Blossom \consensusBranchID \hexint{2BB40E60} as defined in \cite{ZIP-206}.} \heartwoodonward{The \sighashAlgorithm used after \Heartwood activation is the same as -for \Sapling, but using the \Heartwood{} \consensusBranchID \hexint{F5B9230B} as defined in +for \Sapling, but using the \Heartwood \consensusBranchID \hexint{F5B9230B} as defined in \cite{ZIP-250}.} \canopyonward{The \sighashAlgorithm used after \Canopy activation is the same as -for \Sapling, but using the \Canopy{} \consensusBranchID \hexint{E9FF75A6} as defined in +for \Sapling, but using the \Canopy \consensusBranchID \hexint{E9FF75A6} as defined in \cite{ZIP-251}.} \orchardonward{The \sighashAlgorithm used after activation of the \networkUpgrade that @@ -5638,7 +5703,7 @@ The total value of \transparentOutputs{} must not exceed the total value of is transferred to the miner of the \block containing the \transaction; it is added to the \minerSubsidy in the \coinbaseTransaction of the \block. -\Zcash{} \SproutOrNothing extends this by adding \joinSplitTransfers. +\Zcash \Sprout extends this by adding \joinSplitTransfers. Each \joinSplitTransfer can be seen, from the perspective of the \transparentTxValuePool, as an input \changed{and an output simultaneously}. @@ -5851,12 +5916,12 @@ Thus checking the \saplingBindingSignature ensures that the \spendTransfers and in the \transaction balance, without their individual values being revealed. In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em-sum of the -\Sapling{} \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash +\Sapling \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash by signing $\SigHash$. \vspace{1ex} \pnote{ -The spender \MAY reveal any strict subset of the \Sapling{} \valueCommitment randomnesses +The spender \MAY reveal any strict subset of the \Sapling \valueCommitment randomnesses to other parties that are cooperating to create the \transaction. If all of the \valueCommitment randomnesses are revealed, that could allow replaying the \outputDescriptions of the \transaction. @@ -6035,12 +6100,12 @@ Thus checking the \orchardBindingSignature ensures that the \actionTransfers in balance, without their individual net values being revealed. In addition this proves that the signer, knowing the $\biggrpplus$\kern-0.015em-sum of the -\Orchard{} \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash +\Orchard \valueCommitment randomnesses, authorized a \transaction with the given \sighashTxHash by signing $\SigHash$. \vspace{1ex} \pnote{ -The spender \MAY reveal any strict subset of the \Orchard{} \valueCommitment randomnesses to +The spender \MAY reveal any strict subset of the \Orchard \valueCommitment randomnesses to other parties that are cooperating to create the \transaction. } %pnote } %orchard @@ -6356,7 +6421,7 @@ $\DiversifiedTransmitPublic = \scalarmult{\InViewingKey}{\DiversifiedTransmitBas For details of the form and encoding of \spendStatement proofs, see \crossref{groth}. \begin{pnotes} - \item Public and \auxiliaryInputs{} \MUST be constrained to have the types specified. In particular, + \item Public and \auxiliaryInputs \MUST be constrained to have the types specified. In particular, see \crossref{ccteddecompressvalidate}, for required validity checks on compressed representations of \jubjubCurve points. @@ -6434,7 +6499,7 @@ $\EphemeralPublic = \scalarmult{\EphemeralPrivate}{\DiversifiedTransmitBase}$. For details of the form and encoding of \outputStatement proofs, see \crossref{groth}. \begin{pnotes} - \item Public and \auxiliaryInputs{} \MUST be constrained to have the types specified. In particular, + \item Public and \auxiliaryInputs \MUST be constrained to have the types specified. In particular, see \crossref{ccteddecompressvalidate}, for required validity checks on compressed representations of \jubjubCurve points. @@ -6445,7 +6510,7 @@ For details of the form and encoding of \outputStatement proofs, see \crossref{g } %sapling -\orchard{ +%\orchard{ \lsubsubsection{Action Statement (\OrchardText)}{actionstatement} \vspace{-1ex} @@ -6495,7 +6560,7 @@ the prover knows an \auxiliaryInput: \hparen\DiversifiedTransmitPublicNewRepr \typecolon \ReprP,\\ \hparen\vNew{} \typecolon \ValueType,\\ \hparen\NoteCommitRandNew{} \typecolon \binaryrange{\ScalarLength{Orchard}},\\ - \hparen\EphemeralPrivate \typecolon \binaryrange{\ScalarLength{Orchard}},\\ + \hparen\EphemeralPrivate \typecolon \binaryrange{\CompactLengthOrchard},\\ \hparen\ValueCommitRand{} \typecolon \binaryrange{\ScalarLength{Orchard}}\cparen$ \end{formulae} \vspace{-1.5ex} @@ -6530,7 +6595,7 @@ $\AuthSignRandomizedPublic = \SpendAuthSigRandomizePublic(\AuthSignRandomizer, \ $\DiversifiedTransmitPublic = \scalarmult{\InViewingKey}{\DiversifiedTransmitBase}$ where \vspace{-1ex} \begin{formulae} - \item $\InViewingKey = \CommitIvk{\InViewingKeyRandom}(\AuthSignPublicRepr, \NullifierKeyRepr)$ + \item $\InViewingKey = \CommitIvk{\CommitIvkRandom}(\AuthSignPublicRepr, \NullifierKeyRepr)$ \vspace{-1ex} \item $\AuthSignPublicRepr = \reprJ\Of{\AuthSignPublic}$\,. \end{formulae} @@ -6558,7 +6623,7 @@ $\vNew{} = 0$ or $\enableOutput = 1$. For details of the form and encoding of \actionStatement proofs, see \crossref{halo2}. \begin{pnotes} - \item Public and \auxiliaryInputs{} \MUST be constrained to have the types specified. In particular, + \item Public and \auxiliaryInputs \MUST be constrained to have the types specified. In particular, see \crossref{cctswdecompressvalidate}, for required validity checks on compressed representations of \pallasCurve points. @@ -6575,7 +6640,7 @@ For details of the form and encoding of \actionStatement proofs, see \crossref{h ($\AuthSignBase{Orchard}$ is as defined in \crossref{concretespendauthsig}.) \item The validity of $\DiversifiedTransmitPublicRepr$ is \emph{not} checked in this circuit. \end{pnotes} -} %orchard +%} %orchard \lsubsection{In-band secret distribution\pSproutOrNothingText}{sproutinband} @@ -6614,7 +6679,7 @@ Let $\KA{Sprout}$ be the \keyAgreementScheme instantiated in \crossref{concretes Let $\TransmitPublicSub{\allNew}$ be the \transmissionKeys for the intended recipient addresses of each new \note. -Let $\NotePlaintext{\allNew}$ be \SproutOrNothing{} \notePlaintexts +Let $\NotePlaintext{\allNew}$ be \Sprout \notePlaintexts defined in \crossref{notept}. \introlist @@ -6649,7 +6714,7 @@ with a random (and undecryptable) dummy ciphertext, relying instead on out-of-ba transmission of the \note to the recipient. In this case the ephemeral key \MUST still be generated as a random \publicKey (rather than a random bit sequence) to ensure indistinguishability from other \joinSplitDescriptions. This mode of operation raises -further security considerations, for example of how to validate a \SproutOrNothing{} +further security considerations, for example of how to validate a \Sprout{} \note received out-of-band, which are not addressed in this document. } @@ -6729,7 +6794,7 @@ $\DiversifiedTransmitPublic$ is used to encrypt them. The recipient's possession of the associated \incomingViewingKey $\InViewingKey$ is used to reconstruct the original \note and \memo. -Unlike in a \Sprout{} \joinSplitDescription, each \SaplingOrOrchard \shieldedOutput +Unlike in a \Sprout \joinSplitDescription, each \SaplingOrOrchard \shieldedOutput is encrypted by a fresh \ephemeralPublicKey. \vspace{0.5ex} @@ -6755,7 +6820,7 @@ For both encryption and decryption, \todo{generalize} Let $\DiversifiedTransmitPublic \typecolon \KAPublicPrimeSubgroup{Sapling}$ be the -\diversifiedTransmissionKey for the intended recipient address of a new \Sapling{} \note, +\diversifiedTransmissionKey for the intended recipient address of a new \Sapling \note, and let $\DiversifiedTransmitBase \typecolon \KAPublicPrimeSubgroup{Sapling}$ be the corresponding \diversifiedBase computed as $\DiversifyHash{Sapling}(\Diversifier)$. @@ -6768,7 +6833,7 @@ i.e.\ the \outgoingViewingKey of the \paymentAddress from which the \note is bei \outgoingViewingKey associated with a \cite{ZIP-32} account, or $\bot$. Let $\NotePlaintext{} = (\NotePlaintextLeadByte, \Diversifier, \Value, \NoteCommitRandBytesOrSeedBytes, \Memo)$ -be the \Sapling{} \notePlaintext. +be the \Sapling \notePlaintext. $\NotePlaintext{}$ is encoded as defined in \crossref{notept}. @@ -6810,7 +6875,7 @@ with a random (and undecryptable) dummy ciphertext, relying instead on out-of-ba transmission of the \note to the recipient. In this case the ephemeral key \MUST still be generated as a random \publicKey (rather than a random bit sequence) to ensure indistinguishability from other \outputDescriptions. This mode of operation raises -further security considerations, for example of how to validate a \Sapling{} \note +further security considerations, for example of how to validate a \Sapling \note received out-of-band, which are not addressed in this document. } %pnote } %sapling @@ -6821,7 +6886,7 @@ received out-of-band, which are not addressed in this document. \todo{generalize} -Let $\InViewingKey \typecolon \InViewingKeyType{Sapling}$ be the recipient's \incomingViewingKey, +Let $\InViewingKey \typecolon \InViewingKeyTypeSapling$ be the recipient's \incomingViewingKey, as specified in \crossref{saplingkeycomponents}. Let $(\ephemeralKey, \TransmitCiphertext{}, \OutCiphertext)$ be the \noteCiphertextSapling from the @@ -6883,9 +6948,9 @@ from $\TransmitPlaintext{}$ $\NotePlaintextLeadByte \neq \hexint{01}$) in the comparison against $\reprJ\big(\KADerivePublic{Sapling}(\EphemeralPrivate, \DiversifiedTransmitBase)\kern-0.12em\big)$}. \item Normally only \noteCiphertextsSapling of \transactions in \blocks need to be decrypted. In that case, - any received \Sapling{} \note is necessarily a \positionedNote, and so its $\NoteUniqueRand$ + any received \Sapling \note is necessarily a \positionedNote, and so its $\NoteUniqueRand$ value can immediately be calculated as described in \crossref{commitmentsandnullifiers}. - To test whether a \Sapling{} \note is unspent in a particular \blockChain also requires + To test whether a \Sapling \note is unspent in a particular \blockChain also requires the \nullifierDerivingKey $\NullifierKeyRepr$; the coin is unspent if and only if $\nf = \PRFnf{Sapling}{\NullifierKeyRepr}\big(\reprJ(\NoteUniqueRand)\kern-0.15em\big)$ is not in the \nullifierSet for that \blockChain. @@ -6985,9 +7050,10 @@ from $\TransmitPlaintext{}$ \orchardonwarditem{This procedure returns $\bot$ if $\DiversifiedTransmitPublicRepr$ is \nonCanonicalPoint, as specified in \cite{ZIP-216}.} \item A previous version of this specification did not have the requirement for the decoded point - $\DiversifiedTransmitPublic$ to be in the subgroup $\SubgroupJ$. That did not match the implementation - in \zcashd, which does require $\DiversifiedTransmitPublic$ to be in the subgroup. The specification - has been changed to match \zcashd. + $\DiversifiedTransmitPublic$ to be in the subgroup $\SubgroupJ$ (i.e.\ the line + ``if $\DiversifiedTransmitBase \not\in \SubgroupJ$, return $\bot$``). That did not match the + implementation in \zcashd, which does require $\DiversifiedTransmitPublic$ to be in the subgroup. + The specification has been changed to match \zcashd. \item The comments in \crossref{decryptivk} concerning calculation of $\NoteUniqueRand$, detection of spent \notes, and decryption of \noteCiphertextsSapling for \transactions in the \mempool also apply to \notes decrypted by this procedure. @@ -7025,7 +7091,7 @@ Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}. \vspace{1ex} \introsection The following algorithm can be used, given the \blockChain and a -\SproutOrNothing{} \spendingKey $\AuthPrivate$, to obtain each \note sent +\Sprout \spendingKey $\AuthPrivate$, to obtain each \note sent to the corresponding \paymentAddress, its \memo field, and its final status (spent or unspent). @@ -7087,7 +7153,7 @@ Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}. \introsection \vspace{1ex} The following algorithm can be used, given the \blockChain and -$(\NullifierKey \typecolon \SubgroupJ, \InViewingKey \typecolon \InViewingKeyType{Sapling})$, +$(\NullifierKey \typecolon \SubgroupJ, \InViewingKey \typecolon \InViewingKeyTypeSapling)$, to obtain each \note sent to the corresponding \paymentAddress, its \memo field, and its final status (spent or unspent). @@ -7210,9 +7276,9 @@ Define: \sapling{ \item $\MerkleDepth{Sapling} \typecolon \Nat := 32$ } %sapling - \item $\NOld \typecolon \Nat := 2$ - \item $\NNew \typecolon \Nat := 2$ - \item $\ValueLength \typecolon \Nat := 64$ +\orchard{ + \item $\MerkleDepth{Orchard} \typecolon \Nat := 32$ +} %orchard \item $\MerkleHashLength{Sprout} \typecolon \Nat := 256$ \sapling{ \item $\MerkleHashLength{Sapling} \typecolon \Nat := 255$ @@ -7220,6 +7286,9 @@ Define: \orchard{ \item $\MerkleHashLength{Orchard} \typecolon \Nat := 255$ } %orchard + \item $\NOld \typecolon \Nat := 2$ + \item $\NNew \typecolon \Nat := 2$ + \item $\ValueLength \typecolon \Nat := 64$ \item $\hSigLength \typecolon \Nat := 256$ \item $\PRFOutputLengthSprout \typecolon \Nat := 256$ \sapling{ @@ -7233,18 +7302,23 @@ Define: \sapling{ \item $\SpendingKeyLength \typecolon \Nat := 256$ \item $\DiversifierLength \typecolon \Nat := 88$ +\orchard{ + \item $\DiversifierKeyLength \typecolon \Nat := 256$ +} %orchard \item $\InViewingKeyLength{Sapling} \typecolon \Nat := 251$ \item $\OutViewingKeyLength \typecolon \Nat := 256$ \item $\ScalarLength{Sapling} \typecolon \Nat := 252$ } %sapling \orchard{ - \item $\ScalarLength{Orchard} \typecolon \Nat := 254$ + \item $\ScalarLength{Orchard} \typecolon \Nat := 255$ + \item $\CompactLengthOrchard \typecolon \Nat := 254$ } %orchard \item $\Uncommitted{Sprout} \typecolon \bitseq{\MerkleHashLength{Sprout}} := \zeros{\MerkleHashLength{Sprout}}$ \sapling{ \item $\Uncommitted{Sapling} \typecolon \bitseq{\MerkleHashLength{Sapling}} := \ItoLEBSPOf{\MerkleHashLength{Sapling}}{1}$ } %sapling \orchard{ + \vspace{-1ex} \item $\Uncommitted{Orchard} \typecolon \bitseq{\MerkleHashLength{Orchard}} := \ItoLEBSPOf{\MerkleHashLength{Orchard}}{2}$ } %orchard \item $\MAXMONEY \typecolon \Nat := \changed{2.1 \smult 10^{15}}$ (\zatoshi) @@ -7530,7 +7604,7 @@ $\BlakeTwobOf{256}{\ascii{ZcashComputehSig}, x}$ must be \collisionResistant on \vspace{-2ex} $\CRHivk$ is used to derive the \incomingViewingKey $\InViewingKey$ -for a \Sapling{} \paymentAddress. +for a \Sapling \paymentAddress. For its use when generating an address see \crossref{saplingkeycomponents}, and for its use in the \spendStatement see \crossref{spendstatement}. @@ -7618,7 +7692,7 @@ the third address was derived from. %Consider the following experiment: %\begin{itemize} % \item Choose two \incomingViewingKeys -% $\InViewingKey_{1,2} \leftarrowR \InViewingKeyType{Sapling}$. +% $\InViewingKey_{1,2} \leftarrowR \InViewingKeyTypeSapling$. % \item An adversary chooses two (not necessarily distinct) \diversifiers % $\Diversifier_{1,2} \typecolon \DiversifierType$. % \item Define $\OracleNewAddress_i(\Diversifier' \typecolon \DiversifierType) := \begin{cases} @@ -7740,7 +7814,7 @@ by Sean Bowe and Daira Hopwood. $\PedersenHash$ is used in the definitions of \xPedersenCommitments (\crossref{concretewindowedcommit}), and of the \defining{\xPedersenHash} for the -\Sapling{} \incrementalMerkleTree (\crossref{saplingmerklecrh}). +\Sapling \incrementalMerkleTree (\crossref{saplingmerklecrh}). Let $\GroupJ$, $\SubgroupJ$, $\ZeroJ$, $\ParamJ{q}$, $\ParamJ{r}$, $\ParamJ{a}$, and $\ParamJ{d}$ be as defined in \crossref{jubjub}. @@ -7932,7 +8006,7 @@ using $\PedersenHash$) is to make efficient use of the lookups available in rece proof systems including \HaloTwo. $\SinsemillaHash$ is used in the definition of $\SinsemillaCommit{}$ -(\crossref{concretesinsemillacommit}), and for the \Orchard{} \incrementalMerkleTree +(\crossref{concretesinsemillacommit}), and for the \Orchard \incrementalMerkleTree (\crossref{orchardmerklecrh}). Let $\GroupP$, $\ZeroP$, $\ParamP{q}$, $\ParamP{r}$, and $\ParamP{b}$ be as defined in @@ -7950,7 +8024,7 @@ and $\LEOStoIP{} \typecolon (\ell \typecolon \Nat \suchthat \ell \bmod 8 = 0) \t be as defined in \crossref{endian}. \vspace{1ex} -Let $k = 11$. +Let $k := 10$. Let $c$ be the largest integer such that $2^n \leq \hfrac{\ParamP{r}-1}{2}$, i.e.\ $c := 253$. @@ -7972,7 +8046,7 @@ Define $\SinsemillaHashToPoint(D \typecolon \byteseqs, M \typecolon \bitseq{\ran each of length $k$ bits, so that $M' = \concatbits(M_\barerange{1}{n})$. \item let mutable $\Acc := \SinsemillaGenInit(D)$ \item for $i$ from $1$ up to $n$: - \item \tab set $\Acc := \scalarmult{2}{\Acc} + \SinsemillaGenBase(M_i)$ + \item \tab set $\Acc := \scalarmult{2}{\Acc} + \SinsemillaGenBase(\LEBStoIP{k}(M_i))$ \item \blank \item return $\Acc$. \end{algorithm} @@ -8026,6 +8100,74 @@ $\SinsemillaHashToPoint$ could return $\ZeroP$.} } %orchard +%\orchard{ +\introlist +\lsubsubsubsection{\PoseidonHashText{} Function}{poseidonhash} + +$\Poseidon$ is a cryptographic permutation described in \cite{GKRRS2019}. It operates +over a sequence of finite field elements, which we instantiate as $\typeexp{\GF{\ParamP{q}}}{3}$. + +The S-box function is $x \mapsto x^5$. The number of outer rounds $R_P$ is $.$, +and the number of inner rounds $R_.$ is $.$. + +We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise addition in +$\GF{\ParamP{q}}$ replacing exclusive-or of bit strings\footnote{\orchard{The sponge construction +was originally proposed as operating on an arbitrary group. \cite{BDPA2007}}}) to construct +a \hashFunction. The sponge capacity is one field element, the rate is two field elements, and +the output is one field element. We do not append any padding to the input message; this does +not affect security because the input length is fixed. + +That is, if $f \typecolon \typeexp{\GF{\ParamP{q}}}{3} \rightarrow \typeexp{\GF{\ParamP{q}}}{3}$ +is the $\Poseidon$ permutation, then the \hashFunction +$\PoseidonHash \typecolon \GF{\ParamP{q}} \times \GF{\ParamP{q}} \rightarrow \GF{\ParamP{q}}$ +is specified as: + +\begin{formulae} + \item $\PoseidonHash(x, y) = f([x, y, 0])_1$ (using $1$-based indexing). +\end{formulae} + +\todo{Specify the MDS matrix and number of rounds.} + +\begin{nnotes} + \item The choice of MDS matrix and the number of rounds take into account cryptanalytic + results in \cite{KR2020} and \cite{BCD+2020}. \todo{check.} + \item \cite{BCD+2020} says that ``... finite fields $\mathbb{F}_q$ with + a limited number of multiplicative subgroups might be preferable, i.e.\ one + might want to avoid $q-1$ being smooth. This implies that the fields which are + suitable for implementing FFT may be more vulnerable to integral attacks.'' + $\GF{\ParamP{q}}$ is such a field; the factorization of $\ParamP{q}-1$ is + $2^{32} \mult 3 \mult 463 \mult 539204044132271846773 \mult 8999194758858563409123804352480028797519453$. + + Furthermore, cryptanalysis of $\Poseidon$ has focussed mainly on the case of S-box + $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because + $x \mapsto x^3$ would not be a permutation. $\alpha = 5$ is the smallest + integer for which $x \mapsto x^\alpha$ is a permutation in $\GF{\ParamP{q}}$. + + On the other hand, the number of rounds chosen includes a significant security margin, + even taking into account these considerations. For small $t$, such as $t = 3$ as used + here, the results of \cite{KR2020} are positive for security since they indicate that + the number of active S-boxes through the middle rounds is larger than originally + estimated by the $\Poseidon$ designers (and the number of rounds is based on this + original conservative estimate). + + Also note that the use of $\Poseidon$ in \Orchard is very conservative. First, the + sponge mode limits an adversary to only being able to influence part of the $\Poseidon$ + permutation input, and we use it only to construct a PRF ($\PRFnf{Orchard}{}$ as described in + \crossref{concreteprfs}). Half of the sponge input is a random key $\NullifierKey$, + known only to holders of a \fullViewingKey, and the remaining half $\NoteUniqueRandRepr$ + is also chosen randomly by the \note creator (both are derived using $\PRFexpand{}$, + from $\SpendingKey$ and $\NoteSeedBytes$ respectively). Then the PRF is used to enhance + the security of a discrete-log-based nullifier construction (described in \crossref{...}) + against a potential discrete-log-breaking adversary. Given the weak assumption + that the $\PoseidonHash$ sponge produces output that preserves sufficient entropy + from the inputs $\NullifierKey$ and $\NoteUniqueRandRepr$, this nullifier + construction would still be secure under a decisional Diffie--Hellman assumption + on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from + an ideal PRF. +\end{nnotes} +%} %orchard + + \introlist \lsubsubsubsection{Equihash Generator}{equihashgen} @@ -8180,8 +8322,8 @@ be necessary.}) } -\newsavebox{\ockbox} -\begin{lrbox}{\ockbox} +\newsavebox{\saplingockbox} +\begin{lrbox}{\saplingockbox} \setsapling \begin{bytefield}[bitwidth=0.038em]{512} \sbitbox{256}{$\LEBStoOSPOf{256}{\OutViewingKey}$} & @@ -8231,7 +8373,7 @@ It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in \begin{formulae} \item $\PRFock{Sapling}{\OutViewingKey}(\cvField, \cmuField, \ephemeralKey) := \BlakeTwobOf{256}{\ascii{Zcash\_Derive\_ock}, \ockInput}$ - \item where $\ockInput = \Justthebox{\ockbox}$. + \item where $\ockInput = \Justthebox{\saplingockbox}$. \end{formulae} \vspace{-2ex} @@ -8243,7 +8385,7 @@ to $\OutViewingKey$, with input in the bits corresponding to $\cvField$, $\cmuFi \vspace{2ex} \introlist -$\PRFnf{Sapling}{}$ is used to derive the \nullifier for a \Sapling{} \note. +$\PRFnf{Sapling}{}$ is used to derive the \nullifier for a \Sapling \note. It is instantiated using the $\BlakeTwosGeneric$ \hashFunction defined in \crossref{concreteblake2}: \begin{formulae} @@ -8264,6 +8406,67 @@ $\SubgroupReprJ$ is defined in \crossref{jubjub}. } %sapling +\newsavebox{\orchardockbox} +\begin{lrbox}{\orchardockbox} +\setsapling +\begin{bytefield}[bitwidth=0.038em]{512} + \sbitbox{256}{$\LEBStoOSPOf{256}{\OutViewingKey}$} & + \sbitbox{256}{$32$-byte $\cvField$} + \sbitbox{256}{$32$-byte $\cmxField$} & + \sbitbox{264}{$32$-byte $\ephemeralKey$} +\end{bytefield} +\end{lrbox} + +\orchard{ +\introlist +\vspace{2ex} +$\PRFock{Orchard}{}$ is used in \crossref{orchardencrypt} to derive the +\outgoingCipherKey $\OutCipherKey$ used to encrypt an \outputCiphertext. + +It is instantiated using the $\BlakeTwobGeneric$ \hashFunction defined in +\crossref{concreteblake2}: + +\begin{formulae} + \item $\PRFock{Orchard}{\OutViewingKey}(\cvField, \cmxField, \ephemeralKey) := \BlakeTwobOf{256}{\ascii{Zcash\_Orchardock}, \ockInput}$ + \item where $\ockInput = \Justthebox{\orchardockbox}$. +\end{formulae} + +\vspace{-2ex} +\securityrequirement{ +$\BlakeTwobOf{512}{\ascii{Zcash\_Orchardock}, \ockInput}$ must be a +PRF for output range $\Keyspace$ (defined in \crossref{concretesym}) when keyed by the bits corresponding +to $\OutViewingKey$, with input in the bits corresponding to $\cvField$, $\cmxField$, and $\ephemeralKey$. +} %securityrequirement + +\vspace{2ex} +\introlist +Let $\ParamP{q}$ be as defined in \crossref{pallasandvesta}. + +$\PRFnf{Orchard}{} \typecolon \GF{\ParamP{q}} \times \GF{\ParamP{q}} \rightarrow \GF{\ParamP{q}}$ is used as +part of deriving the \nullifier for an \Orchard \note. + +It is instantiated using the $\PoseidonHash$ \hashFunction \cite{GKRRS2019} defined in \crossref{poseidonhash}: + +\begin{formulae} + \item $\PRFnf{Orchard}{\NullifierKeyRepr}(\NoteUniqueRandRepr) := \Poseidon(\NullifierKeyRepr, \NoteUniqueRandRepr)$. +\end{formulae} + +\vspace{-2ex} +\securityrequirement{ +$\Poseidon \typecolon \GF{\ParamP{q}} \times \GF{\ParamP{q}} \rightarrow \GF{\ParamP{q}}$ must be a +PRF when keyed by its first argument, with its second argument as input. +} %securityrequirement + +\begin{nnotes} + \item This construction of a PRF from a sponge is described in \cite[section 3.12]{BDPA2011}. + It is called ``outer-keyed sponge'' in \cite{ADMA2015}, or ``black-box keying'' in \cite{GPT2015}. + The results of these papers do not directly apply because the key is smaller than the rate. + However, the result of \cite{GG2015} does apply. + \item See \crossref{poseidonhash} for further security discussion of how \Orchard uses $\Poseidon$. +\end{nnotes} +} %orchard + + \introsection \lsubsubsection{Symmetric Encryption}{concretesym} @@ -8290,7 +8493,7 @@ block count and $64$-bit nonce as in the original definition of $\SymCipher$. \lsubsubsection{Key Agreement And Derivation}{concretekaandkdf} -\lsubsubsubsection{\SproutOrNothingText{} Key Agreement}{concretesproutkeyagreement} +\lsubsubsubsection{\SproutText{} Key Agreement}{concretesproutkeyagreement} \changed{ $\KA{Sprout}$ is a \keyAgreementScheme as specified in \crossref{abstractkeyagreement}. @@ -8325,7 +8528,7 @@ Define $\KAAgree{Sprout}(n, q) := \KASproutCurveMultiply(n, q)$. } \introsection -\lsubsubsubsection{\SproutOrNothingText{} Key Derivation}{concretesproutkdf} +\lsubsubsubsection{\SproutText{} Key Derivation}{concretesproutkdf} \newsavebox{\kdftagbox} \begin{lrbox}{\kdftagbox} @@ -8627,14 +8830,21 @@ EdDSA \cite{BJLSY2015}. $\RedJubjub$ is a specialization of $\RedDSA$ to the \jubjubCurve (\crossref{jubjub}), using the $\BlakeTwob{512}$ hash function. -The \spendAuthSignatureScheme $\SpendAuthSig{Sapling}$ defined in \crossref{concretespendauthsig} -is instantiated by $\RedJubjub$. The \bindingSignatureScheme $\BindingSig{Sapling}$ defined in -\crossref{concretebindingsig} is instantiated by $\RedJubjub$ without use of key re-randomization. +The \spendAuthSignatureScheme $\SpendAuthSig{Sapling}$ is instantiated by $\RedJubjub$, using +parameters defined in \crossref{concretespendauthsig}. + +The \bindingSignatureScheme $\BindingSig{Sapling}$ is instantiated by $\RedJubjub$ without +key re-randomization, using parameters defined in \crossref{concretebindingsig}. \orchard{ -The \spendAuthSignatureScheme $\SpendAuthSig{Orchard}$ defined in \crossref{concretespendauthsig} -is instantiated by $\RedPallas$. The \bindingSignatureScheme $\BindingSig{Orchard}$ defined in -\crossref{concretebindingsig} is instantiated by $\RedPallas$ without use of key re-randomization. +$\RedPallas$ is a specialization of $\RedDSA$ to the \pallasCurve (\crossref{pallasandvesta}), +using the $\BlakeTwob{512}$ hash function. + +The \spendAuthSignatureScheme $\SpendAuthSig{Orchard}$ is instantiated by $\RedPallas$, using +parameters defined in \crossref{concretespendauthsig}. + +The \bindingSignatureScheme $\BindingSig{Orchard}$ is instantiated by $\RedPallas$ without +key re-randomization, using parameters defined in \crossref{concretebindingsig}. } %orchard \introlist @@ -8732,6 +8942,7 @@ Define $\RedDSAValidate{} \typecolon (\vk \typecolon \RedDSAPublic) \times (M \t \vspace{-0.5ex} \item Let $\RedDSASigc{} = \RedDSAHashToScalar(\RedDSAReprR{} \bconcat \vkBytes{} \bconcat M)$. \vspace{0.5ex} + \orchardonwarditem{If $\reprG{}\Of{\RedDSASigR{}} \neq \RedDSAReprR{}$, return $0$.} \item Return $1$ if $\RedDSASigR{} \neq \bot$ and $\RedDSASigS{} < \ParamG{r}$ and $\scalarmult{\ParamG{h}}{\big(\!\!-\!\scalarmult{\RedDSASigS{}}{\GenG{}} + \RedDSASigR{} + \scalarmult{\RedDSASigc{}}{\vk}\big)} = \ZeroG{}$, otherwise $0$. \end{algorithm} @@ -8740,6 +8951,10 @@ Define $\RedDSAValidate{} \typecolon (\vk \typecolon \RedDSAPublic) \times (M \t \begin{pnotes} \item The validation algorithm \emph{does not} check that $\RedDSASigR{}$ is a point of order at least $\ParamG{r}$. +\orchard{ + \item After activation of \cite{ZIP-216}, validation returns $0$ if $\RedDSAReprR{}$ is a + \nonCanonicalPoint compressed point encoding. +} \item The value $\RedDSAReprR{}$ used as part of the input to $\RedDSAHashToScalar$ \MUST be exactly as encoded in the signature. \item Appendix \crossref{reddsabatchvalidate} describes an optimization that \MAY be used to speed up @@ -8747,15 +8962,19 @@ at least $\ParamG{r}$. \end{pnotes} \vspace{-2ex} -\nnote{The randomization used in $\RedDSARandomizePrivate$ and $\RedDSARandomizePublic$ -may interact with other uses of additive properties of keys for Schnorr-based signature schemes. -In the \Zcash protocol, such properties are used for \bindingSignatures but not at the same time -as key randomization. They are also used in \cite{ZIP-32} when deriving child extended keys, -but this does not result in any practical security weakness as long as the security recommendations -of ZIP-32 are followed. If $\RedDSA$ is reused in other protocols making use of these additive -properties, careful analysis of potential interactions is required.} +\begin{nnotes} + \item The randomization used in $\RedDSARandomizePrivate$ and $\RedDSARandomizePublic$ + may interact with other uses of additive properties of keys for Schnorr-based signature schemes. + In the \Zcash protocol, such properties are used for \bindingSignatures but not at the same time + as key randomization. They are also used in \cite{ZIP-32} when deriving child extended keys, + but this does not result in any practical security weakness as long as the security recommendations + of ZIP-32 are followed. If $\RedDSA$ is reused in other protocols making use of these additive + properties, careful analysis of potential interactions is required. + \item It is \RECOMMENDED that, for deployments of $\RedDSA$ in other protocols than \Zcash, the + requirement for $\RedDSAReprR{}$ to be canonically encoded is always enforced (which was the + original intent of the design). +\end{nnotes} -\vspace{1ex} \introlist The two abelian groups specified in \crossref{abstractsigmono} are instantiated for $\RedDSA$ as follows: @@ -8843,26 +9062,18 @@ as defined in \crossref{abstractsigrerand}. \lsubsubsubsection{Binding Signature (\SaplingAndOrchardText)}{concretebindingsig} \vspace{-1ex} -Let $\RedJubjub$ be as defined in \crossref{concreteredjubjub}. +Let $\RedJubjub$\orchard{ and $\RedPallas$} be as defined in \crossref{concreteredjubjub}. -Let $\ValueCommitRandBase{Sapling}$ be the randomness base defined in \crossref{concretevaluecommit}. - -The \defining{\bindingSignatureScheme}, $\BindingSig{Sapling}$, is instantiated as $\RedJubjub$ without -use of key re-randomization, and with generator $\GenG{} = \ValueCommitRandBase{Sapling}$. +The \Sapling{} \defining{\bindingSignatureScheme}, $\BindingSig{Sapling}$, is instantiated as $\RedJubjub$ +without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Sapling}$ defined in +\crossref{concretevaluecommit}. See \crossref{saplingbalance} for details on the use of this \signatureScheme. \orchard{ -Let $\RedPallas$ be as defined in \crossref{concreteredjubjub}. - -Let $\ValueCommitRandBase{Orchard}$ be the randomness base defined in \crossref{concretevaluecommit}. - -The \defining{\bindingSignatureScheme}, $\BindingSig{Orchard}$, is instantiated as $\RedPallas$ without -use of key re-randomization, and with generator $\GenG{} = \ValueCommitRandBase{Orchard}$. +The \Orchard{} \defining{\bindingSignatureScheme}, $\BindingSig{Orchard}$, is instantiated as $\RedPallas$ +without key re-randomization, using generator $\GenG{} = \ValueCommitRandBase{Orchard}$ defined in +\crossref{concretevaluecommit}. See \crossref{orchardbalance} for details on the use of this \signatureScheme. } %orchard -\vspace{0.5ex} -See \crossref{bindingsig} for details on the use of this \signatureScheme. - -\vspace{-1ex} \securityrequirement{ \orchard{Each instantiation of} $\BindingSig{}$ must be a SUF-CMA secure \keyMonomorphicSignatureScheme as defined in \crossref{abstractsigmono}. A signature must prove knowledge of the discrete logarithm of @@ -8877,7 +9088,7 @@ $\ValueCommitRandBase{Orchard}$}. \lsubsubsection{Commitment schemes}{concretecommit} \vspace{-1ex} -\lsubsubsubsection{\SproutOrNothingText{} Note Commitments}{concretesproutnotecommit} +\lsubsubsubsection{\SproutText{} Note Commitments}{concretesproutnotecommit} \newsavebox{\cmbox} \begin{lrbox}{\cmbox} @@ -9058,6 +9269,8 @@ which is equivalent to: \introsection \extralabel{concreteorchardnotecommit}{\lsubsubsubsection{Sinsemilla commitments}{concretesinsemillacommit}} +Let $\ExtractP$ be as defined in \crossref{concreteextractorpallas}. + \crossref{concretesinsemillahash} defines a \xSinsemillaHash construction. We construct \defining{\xSinsemillaCommitments} by reusing that construction, and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta}): @@ -9065,6 +9278,8 @@ and adding a randomized point on the \pallasCurve (see \crossref{pallasandvesta} \begin{formulae} \item $\SinsemillaCommit{r}(D, M) := \SinsemillaHashToPoint(D \bconcat \ascii{-M}, M) + \scalarmult{r}{\GroupPHash\Of{D \bconcat \ascii{-r}, \ascii{}}}$ + \item $\SinsemillaShortCommit{r}(D, M) := + \ExtractP\Of{\SinsemillaCommit{r}(D, M)}$ \end{formulae} See \todo{...} for rationale and efficient circuit implementation of this function. @@ -9074,8 +9289,8 @@ instantiated as follows using $\SinsemillaCommitAlg$: \begin{formulae} \item $\NoteCommit{Orchard}{\NoteCommitRand}(\DiversifiedTransmitBaseRepr, \DiversifiedTransmitPublicRepr, \Value) := - \SinsemillaCommit{\NoteCommitRand}\left(\ascii{z.cash:Orchard-NoteCommit}, - \DiversifiedTransmitBaseRepr \bconcat \DiversifiedTransmitPublicRepr \bconcat \ItoLEBSPOf{64}{\Value}\right)$ + \SinsemillaCommit{\NoteCommitRand}\!\big(\ascii{z.cash:Orchard-NoteCommit}, + \DiversifiedTransmitBaseRepr \bconcat \DiversifiedTransmitPublicRepr \bconcat \ItoLEBSP{64}(\Value)\kern-0.15em\big)$ \item $\NoteCommitGenTrapdoor{Orchard}()$ generates the uniform distribution on $\GF{\ParamP{r}}$. \end{formulae} @@ -9084,15 +9299,16 @@ instantiated as follows using $\SinsemillaCommitAlg$: \begin{formulae} \item $\CommitIvk{\CommitIvkRand}(\AuthSignPublicX, \NullifierKey) := - \SinsemillaCommit{\NoteCommitRand}\left(\ascii{z.cash:Orchard-CommitIvk}, - \AuthSignPublicXRepr \bconcat \NullifierKeyRepr\right)$ + \SinsemillaShortCommit{\NoteCommitRand}\left(\ascii{z.cash:Orchard-CommitIvk}, + \ItoLEBSP{\ScalarLength{Orchard}}(\AuthSignPublicRepr) \bconcat \ItoLEBSP{\ScalarLength{Orchard}}\NullifierKeyRepr\right)$ \item $\CommitIvkGenTrapdoor()$ generates the uniform distribution on $\GF{\ParamP{r}}$. \end{formulae} \vspace{-1ex} \begin{securityrequirements} - \item $\SinsemillaCommitAlg$, and hence $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$, must be - computationally binding and at least computationally hiding \commitmentSchemes. + \item $\SinsemillaCommitAlg$ and $\SinsemillaShortCommitAlg$, and hence + $\NoteCommitAlg{Orchard}$ and $\CommitIvkAlg$, must be computationally binding + and at least computationally hiding \commitmentSchemes. \end{securityrequirements} \vspace{-1ex} @@ -9823,7 +10039,7 @@ $]$. Let $\IsoMapG \typecolon \GroupIsoG \rightarrow \GroupG{}$ be the isogeny map given by: \begin{tabular}{@{\hskip 1.5em}r@{\;}l} - $\IsoMapG\big(\ZeroIsoG\big)$ &$= \ZeroP$ \\ + $\IsoMapG\big(\ZeroIsoG\big)$ &$= \ZeroG{}$ \\ $\IsoMapG\big((x, y)\big)$ &$= \left(\hfrac{\IsoConstG{1} \mult x^3 + \IsoConstG{2} \mult x^2 + \IsoConstG{3} \mult x + \IsoConstG{4}} {x^2 + \IsoConstG{5} \mult x + \IsoConstG{6}}, \hfrac{\big(\IsoConstG{7} \mult x^3 + \IsoConstG{8} \mult x^2 + \IsoConstG{9} \mult x + \IsoConstG{10}\big) \mult y} @@ -10007,7 +10223,7 @@ is believed to have been fully mitigated by activation of \Sapling. The use of \ in \Zcash is now limited to verifying proofs that were made prior to the \Sapling \networkUpgrade. -Due to this issue, new forks of \Zcash{} \MUSTNOT use \BCTV, and any other users of +Due to this issue, new forks of \Zcash \MUSTNOT use \BCTV, and any other users of the \Zcash protocol \SHOULD discontinue use of \BCTV as soon as possible. The vulnerability does not affect the Zero Knowledge property of the scheme (as @@ -10082,7 +10298,7 @@ After \Sapling activation, \Zcash uses \zkSNARKs with the \defining{\Groth} \pro security proof of this system and its setup is given in \cite{Maller2018}. \Groth \zkSNARKProofs are used in \transactionVersion 4 and later (\crossref{txnencoding}), -both in \Sprout \joinSplitDescriptions and in \Sapling{} \spendDescriptions and \outputDescriptions. +both in \Sprout \joinSplitDescriptions and in \Sapling \spendDescriptions and \outputDescriptions. They are generated by the \defining{\bellman} library \cite{Bowe-bellman}. A \Groth proof consists of @@ -10137,7 +10353,7 @@ verifier \MUST check, for the encoding of each element, that: \orchard{ \lsubsubsubsection{\HaloTwoText}{halo2} -For \Orchard{} \actionDescriptions in version 5 \transactions, \Zcash uses \zkSNARKs with the +For \Orchard \actionDescriptions in version 5 \transactions, \Zcash uses \zkSNARKs with the \defining{\HaloTwo} \provingSystem described in \todo{}. \introlist @@ -10167,7 +10383,7 @@ Each \notsprout{\Sprout} \notePlaintext (denoted $\NotePlaintext{}$) consists of \saplingonward{ The \notePlaintext in each \outputDescription is encrypted to the \diversifiedTransmissionKey $\DiversifiedTransmitPublic$. -Each \Sapling{} \notePlaintext (denoted $\NotePlaintext{}$) consists of: +Each \Sapling \notePlaintext (denoted $\NotePlaintext{}$) consists of: \begin{formulae} \item $(\NotePlaintextLeadByte \typecolon \byte, \Diversifier \typecolon \DiversifierType, \Value \typecolon \ValueType, @@ -10179,7 +10395,7 @@ Each \Sapling{} \notePlaintext (denoted $\NotePlaintext{}$) consists of: \introlist The usage of the \memo is by agreement between the sender and recipient of the -\note. The \memo{} \SHOULD be encoded as one of: +\note. The \memo \SHOULD be encoded as one of: \begin{itemize} \item a UTF-8 human-readable string \cite{Unicode}, padded by appending zero bytes; or @@ -10193,7 +10409,7 @@ trailing zero bytes and then display the resulting \mbox{UTF-8} string to the re where applicable. Incorrect UTF-8-encoded byte sequences \SHOULD be displayed as replacement characters (\ReplacementCharacter). -In other cases, the contents of the \memo{} \SHOULDNOT be displayed unless otherwise specified +In other cases, the contents of the \memo \SHOULDNOT be displayed unless otherwise specified by \cite{ZIP-302}. } @@ -10201,7 +10417,7 @@ Other fields are as defined in \crossref{notes}. \vspace{1ex} \introlist -The encoding of a \SproutOrNothing{} \notePlaintext consists of: +The encoding of a \Sprout \notePlaintext consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.029em]{1672} @@ -10217,7 +10433,7 @@ The encoding of a \SproutOrNothing{} \notePlaintext consists of: \begin{itemize} \changed{ \item A byte, $\hexint{00}$, indicating this version of the - encoding of a \SproutOrNothing{} \notePlaintext. + encoding of a \Sprout \notePlaintext. } \item $8$ bytes specifying $\Value$. \item $32$ bytes specifying $\NoteUniqueRand$. @@ -10229,7 +10445,7 @@ The encoding of a \SproutOrNothing{} \notePlaintext consists of: \sapling{ \introlist -The encoding of a \Sapling{} \notePlaintext consists of: +The encoding of a \Sapling \notePlaintext consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.029em]{1672} @@ -10243,7 +10459,7 @@ The encoding of a \Sapling{} \notePlaintext consists of: \begin{itemize} \item A byte\notcanopy{, $\hexint{01}$,} indicating this version of the - encoding of a \Sapling{} \notePlaintext. \canopy{This will be $\hexint{01}$ before + encoding of a \Sapling \notePlaintext. \canopy{This will be $\hexint{01}$ before activation of the \Canopy \networkUpgrade, and $\hexint{02}$ afterward.} \item $11$ bytes specifying $\Diversifier$. \item $8$ bytes specifying $\Value$. @@ -10343,11 +10559,11 @@ These are encoded in the same way as in \Bitcoin \cite{Bitcoin-Base58}, for both \Mainnet and \Testnet. -\lsubsubsection{\SproutOrNothingText{} Payment Addresses}{sproutpaymentaddrencoding} +\lsubsubsection{\SproutText{} Payment Addresses}{sproutpaymentaddrencoding} Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}. -A \SproutOrNothing{} \defining{\paymentAddress} consists of $\AuthPublic \typecolon \PRFOutputSprout$ +A \Sprout{} \defining{\paymentAddress} consists of $\AuthPublic \typecolon \PRFOutputSprout$ and $\TransmitPublic \typecolon \KAPublic{Sprout}$. $\AuthPublic$ is a \shaCompress output. @@ -10356,7 +10572,7 @@ $\TransmitPublic$ is a $\KAPublic{Sprout}$ key, for use with the encryption sche \crossref{sproutkeycomponents}. \introlist -The \rawEncoding of a \SproutOrNothing{} \paymentAddress consists of: +The \rawEncoding of a \Sprout \paymentAddress consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{520} @@ -10371,7 +10587,7 @@ The \rawEncoding of a \SproutOrNothing{} \paymentAddress consists of: \begin{itemize} \changed{ \item Two bytes $[\PaymentAddressLeadByte, \PaymentAddressSecondByte]$, - indicating this version of the \rawEncoding of a \SproutOrZcash{} \paymentAddress + indicating this version of the \rawEncoding of a \Sprout \paymentAddress on \Mainnet. (Addresses on \Testnet use $[\PaymentAddressTestnetLeadByte, \PaymentAddressTestnetSecondByte]$ instead.) @@ -10403,7 +10619,7 @@ $\KAPublicPrimeSubgroup{Sapling}$, for use with the encryption scheme defined in These components are derived as described in \crossref{saplingkeycomponents}. \introlist -The \rawEncoding of a \Sapling{} \paymentAddress consists of: +The \rawEncoding of a \Sapling \paymentAddress consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{344} @@ -10446,7 +10662,7 @@ $\Diversifier$~is a sequence of $11$ bytes. These components are derived as desc \crossref{orchardkeycomponents}. \introlist -The \rawEncoding of an \Orchard{} \paymentAddress consists of: +The \rawEncoding of an \Orchard \paymentAddress consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{344} @@ -10470,7 +10686,7 @@ For addresses on \Testnet, the \humanReadablePart is \ascii{ztestorchard}. } %orchard -\lsubsubsection{\SproutOrNothingText{} Incoming Viewing Keys}{sproutinviewingkeyencoding} +\lsubsubsection{\SproutText{} Incoming Viewing Keys}{sproutinviewingkeyencoding} \changed{ Let $\KA{Sprout}$ be as defined in \crossref{concretesproutkeyagreement}. @@ -10503,7 +10719,7 @@ The \rawEncoding of \sprout{an}\notsprout{a \Sprout} \incomingViewingKey consist \vspace{-1ex} \begin{itemize} \item Three bytes $[\InViewingKeyLeadByte, \InViewingKeySecondByte, \InViewingKeyThirdByte]$, - indicating this version of the \rawEncoding of a \Zcash{} \incomingViewingKey + indicating this version of the \rawEncoding of a \Zcash \incomingViewingKey on \Mainnet. (Addresses on \Testnet use $[\InViewingKeyTestnetLeadByte, \InViewingKeyTestnetSecondByte, \InViewingKeyTestnetThirdByte]$ instead.) @@ -10513,7 +10729,7 @@ The \rawEncoding of \sprout{an}\notsprout{a \Sprout} \incomingViewingKey consist \end{itemize} $\TransmitPrivate$ \MUST be ``clamped'' using $\KAFormatPrivate{Sprout}$ as specified -in \crossref{sproutkeycomponents}. That is, a decoded \incomingViewingKey{} \MUST be +in \crossref{sproutkeycomponents}. That is, a decoded \incomingViewingKey \MUST be considered invalid if $\TransmitPrivate \neq \KAFormatPrivate{Sprout}(\TransmitPrivate)$. $\KAFormatPrivate{Sprout}$ is defined in \crossref{concretesproutkeyagreement}. @@ -10532,14 +10748,14 @@ Let $\KA{Sapling}$ be as defined in \crossref{concretesaplingkeyagreement}. Let $\InViewingKeyLength{Sapling}$ be as defined in \crossref{constants}. -A \Sapling{} \defining{\incomingViewingKey} consists of $\InViewingKey \typecolon \InViewingKeyType{Sapling}$. +A \Sapling{} \defining{\incomingViewingKey} consists of $\InViewingKey \typecolon \InViewingKeyTypeSapling$. $\InViewingKey$ is a $\KAPrivate{Sapling}$ key (restricted to $\InViewingKeyLength{Sapling}$ bits), derived as described in \crossref{saplingkeycomponents}. It is used with the encryption scheme defined in \crossref{saplinginband}. \introlist -The \rawEncoding of a \Sapling{} \incomingViewingKey consists of: +The \rawEncoding of a \Sapling \incomingViewingKey consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{256} @@ -10553,8 +10769,8 @@ The \rawEncoding of a \Sapling{} \incomingViewingKey consists of: significant bits. \end{itemize} -$\InViewingKey$ \MUST be in the range $\InViewingKeyType{Sapling}$ as specified -in \crossref{saplingkeycomponents}. That is, a decoded \incomingViewingKey{} \MUST be +$\InViewingKey$ \MUST be in the range $\InViewingKeyTypeSapling$ as specified +in \crossref{saplingkeycomponents}. That is, a decoded \incomingViewingKey \MUST be considered invalid if $\InViewingKey$ is not in this range. For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zivks}. @@ -10567,14 +10783,14 @@ For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zivktests Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}. -An \Orchard{} \defining{\incomingViewingKey} consists of $\InViewingKey \typecolon \InViewingKeyType{Orchard}$. +An \Orchard{} \defining{\incomingViewingKey} consists of $\InViewingKey \typecolon \InViewingKeyTypeOrchard$. $\InViewingKey$ is a $\KAPrivate{Orchard}$ key (restricted to the range $\range{0}{\ParamP{q}-1}$), derived as described in \crossref{orchardkeycomponents}. It is used with the encryption scheme defined in \crossref{saplingandorchardinband}. \introlist -The \rawEncoding of an \Orchard{} \incomingViewingKey consists of: +The \rawEncoding of an \Orchard \incomingViewingKey consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{256} @@ -10588,8 +10804,8 @@ The \rawEncoding of an \Orchard{} \incomingViewingKey consists of: significant bits. \end{itemize} -$\InViewingKey$ \MUST be in the range $\InViewingKeyType{Orchard}$ as specified -in \crossref{orchardkeycomponents}. That is, a decoded \incomingViewingKey{} \MUST be +$\InViewingKey$ \MUST be in the range $\InViewingKeyTypeOrchard$ as specified +in \crossref{orchardkeycomponents}. That is, a decoded \incomingViewingKey \MUST be considered invalid if $\InViewingKey$ is not in this range. For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zivko}. @@ -10609,7 +10825,46 @@ $\AuthSignPublic$ and $\NullifierKey$ are points on the \jubjubCurve (see \crossref{jubjub}). They are derived as described in \crossref{saplingkeycomponents}. \introlist -The \rawEncoding of a \Sapling{} \fullViewingKey consists of: +The \rawEncoding of a \Sapling \fullViewingKey consists of: +\vspace{1ex} +\begin{equation*} +\begin{bytefield}[bitwidth=0.05em]{512} + \sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignPublic}\kern 0.05em}$} + \sbitbox{256}{$\LEBStoOSPOf{256}{\reprJ\Of{\NullifierKey}\kern 0.05em}$} + \sbitbox{256}{$32$-byte $\OutViewingKey$} +\end{bytefield} +\end{equation*} + +\vspace{-1ex} +\begin{itemize} + \item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\AuthSignPublic$ + (see \crossref{jubjub}). + \item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\NullifierKey$. + \item $32$ bytes specifying the \outgoingViewingKey $\OutViewingKey$. +\end{itemize} + +When decoding this representation, the key \MUST be considered invalid if $\abstJ$ returns $\bot$ +for either $\AuthSignPublic$ or $\NullifierKey$, or if $\AuthSignPublic \notin \SubgroupJstar$, +or if $\NullifierKey \notin \SubgroupJ$. + +For \incomingViewingKeys on \Mainnet, the \humanReadablePart is \ascii{zviews}. +For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtestsapling}. +} + + +\sapling{ +\lsubsubsection{\OrchardText{} Full Viewing Keys}{orchardfullviewingkeyencoding} + +Let $\KA{Orchard}$ be as defined in \crossref{concreteorchardkeyagreement}. + +An \Orchard{} \defining{\fullViewingKey} consists of $\AuthSignPublic \typecolon \GroupPstar$, +$\NullifierKey \typecolon \NullifierKeyTypeOrchard$, and $\OutViewingKey \typecolon \byteseq{\OutViewingKeyLength/8}$. + +$\AuthSignPublic$ and $\NullifierKey$ are points on the \jubjubCurve +(see \crossref{jubjub}). They are derived as described in \crossref{saplingkeycomponents}. + +\introlist +The \rawEncoding of a \Sapling \fullViewingKey consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.05em]{512} @@ -10637,13 +10892,13 @@ For \incomingViewingKeys on \Testnet, the \humanReadablePart is \ascii{zviewtest \introsection -\lsubsubsection{\SproutOrNothingText{} Spending Keys}{sproutspendingkeyencoding} +\lsubsubsection{\SproutText{} Spending Keys}{sproutspendingkeyencoding} -A \SproutOrNothing{} \defining{\spendingKey} consists of $\AuthPrivate$, which is a sequence of +A \Sprout{} \defining{\spendingKey} consists of $\AuthPrivate$, which is a sequence of \changed{$252$} bits (see \crossref{sproutkeycomponents}). \introlist -The \rawEncoding of a \SproutOrNothing{} \spendingKey consists of: +The \rawEncoding of a \Sprout \spendingKey consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{264} @@ -10658,7 +10913,7 @@ The \rawEncoding of a \SproutOrNothing{} \spendingKey consists of: \begin{itemize} \changed{ \item Two bytes $[\SpendingKeyLeadByte, \SpendingKeySecondByte]$, - indicating this version of the \rawEncoding of a \Zcash{} \spendingKey + indicating this version of the \rawEncoding of a \Zcash \spendingKey on \Mainnet. (Addresses on \Testnet use $[\SpendingKeyTestnetLeadByte, \SpendingKeyTestnetSecondByte]$ instead.) @@ -10692,7 +10947,7 @@ A \Sapling{} \defining{\spendingKey} consists of $\SpendingKey \typecolon \Spend (see \crossref{saplingkeycomponents}). \introlist -The \rawEncoding of a \Sapling{} \spendingKey consists of: +The \rawEncoding of a \Sapling \spendingKey consists of: \vspace{1ex} \begin{equation*} \begin{bytefield}[bitwidth=0.07em]{256} @@ -10712,7 +10967,7 @@ For \spendingKeys on \Testnet, the \humanReadablePart is \ascii{secret-spending- \introlist \lsubsection{\BCTVText{} zk-SNARK Parameters}{bctvparameters} -The \shaHash hashes of the \provingKey and \verifyingKey for the \SproutOrZcash{} \joinSplitCircuit, +The \shaHash hashes of the \provingKey and \verifyingKey for the \Sprout \joinSplitCircuit, encoded in \libsnark format, are: \begin{lines} @@ -10733,8 +10988,8 @@ stop using them in protocols other than \Zcash where they are currently used. \bellman \cite{Bowe-bellman} encodes the \provingKey and \verifyingKey for a \zkSNARKCircuit in a single parameters file. The $\BlakeTwob{512}$ hashes of this file -for the \Sapling{} \spendCircuit and \outputCircuit, and for the implementation of -the \Sprout{} \joinSplitCircuit used after \Sapling activation, are respectively: +for the \Sapling \spendCircuit and \outputCircuit, and for the implementation of +the \Sprout \joinSplitCircuit used after \Sapling activation, are respectively: \begin{lines} \item[] \texttt{8270785a1a0d0bc77196f000ee6d221c9c9894f55307bd9357c3f0105d31ca63} \\ @@ -10966,14 +11221,14 @@ Note that the \valueBalance{Sapling} field is always present for these \transact } %sapling \sprout{\vspace{3ex}} -\orchard{ +%\orchard{ \introlist The \Zcash{} \defining{\transaction} format for \transactionVersion 5 is as follows (this should be read in the context of consensus rules later in the section): \vspace{-1ex} \begin{center} -\scalebox{0.8}{ +%\scalebox{0.8}{ \notsprout{\renewcommand{\arraystretch}{1.3}} \hbadness=10000 \begin{tabularx}{1.21\textwidth}{|c|c|l|p{10em}|L|} @@ -11003,42 +11258,6 @@ $\geq 5$ & \Varies & $\txOutCount$ & \type{compactSize} & Number of \transparent $\geq 5$ & \Varies & $\txOut$ & $\txOut$ & \xTransparent outputs, encoded as in \Bitcoin. \\ \hline -$\geq 5$ & \Varies & $\nShieldedSpend$ & \type{compactSize} & -The number of \spendDescriptions in $\vShieldedSpend$. \\ \hline - -$\geq 5$ & \Longunderstack{$362 \mult$ \\$\!\nShieldedSpend\!$} & $\vShieldedSpend$ & \type{SpendDescriptionV5} \type{[$\nShieldedSpend$]} & -A sequence of \spendDescriptions{}, encoded per \crossref{spendencodingandconsensus}. \\ \hline - -$\geq 5$ & \Varies & $\nShieldedOutput\!$ & \type{compactSize} & -The number of \outputDescriptions in $\vShieldedOutput$. \\ \hline - -$\geq 5$ & \Longunderstack{$948 \mult$ \\$\!\nShieldedOutput\!$} & $\vShieldedOutput\!$ & \type{OutputDescription} \type{[$\nShieldedOutput$]} & -A sequence of \outputDescriptions{}, encoded per \crossref{outputencodingandconsensus}. \\ \hline - -$\geq 5\;\mathsection$ & $8$ & $\valueBalance{Sapling}\!$ & \type{int64} & -The net value of \Sapling{} spends minus outputs. \\ \hline - -$\geq 5\;\mathsection$ & $32$ & $\anchorField{Sapling}$ & \type{byte[32]} & -A \merkleRoot of the \Sapling{} \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Sapling}\big)$. \\ \hline - -$\geq 5\;\mathsection$ & $64$ & $\bindingSig{Sapling}$ & \type{byte[64]} & -A \saplingBindingSignature on the \sighashTxHash, to be verified as specified in \crossref{concretebindingsig}. \\ \hline - -$\geq 5$ & \Varies &\setorchard $\nShieldedAction\!$ & \type{compactSize} & -The number of \actionDescriptions in $\vShieldedAction$. \\ \hline - -$\geq 5$ & \Longunderstack{$884 \mult$ \\$\!\nShieldedAction\!$} & $\vShieldedAction\!$ & \type{ActionDescription} \type{[$\nShieldedAction$]} & -A sequence of \actionDescriptions{}, encoded per \crossref{actionencodingandconsensus}. \\ \hline - -$\geq 5\;\mathsection$ & $8$ & $\valueBalance{Orchard}\!$ & \type{int64} & -The net value of \Orchard{} spends minus outputs. \\ \hline - -$\geq 5\;\mathsection$ & $32$ & $\anchorField{Orchard}$ & \type{byte[32]} & -A \merkleRoot of the \Orchard{} \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Orchard}\big)$. \\ \hline - -$\geq 5\;\mathsection$ & $64$ & $\bindingSig{Orchard}$ & \type{byte[64]} & -An \orchardBindingSignature on the \sighashTxHash, to be verified as specified in \crossref{concretebindingsig}. \\ \hline - $\geq 5$ & \Varies & $\nJoinSplit$ & \type{compactSize} & The number of \joinSplitDescriptions in $\vJoinSplit$. \\ \hline @@ -11052,9 +11271,60 @@ $\geq 5\;\dagger$ & $64$ & $\joinSplitSig$ & \type{byte[64]} & A signature on a prefix of the \transaction encoding, to be verified using $\joinSplitPubKey$ as specified in \crossref{sproutnonmalleability}. \\ \hline +$\geq 5$ & \Varies & $\nSpendsSapling$ & \type{compactSize} & +The number of \spendDescriptions in $\vSpendsSapling$. \\ \hline + +$\geq 5$ & \Longunderstack{$362 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendsSapling$ & \type{SpendDescriptionV5} \type{[$\nSpendsSapling$]} & +A sequence of \spendDescriptions{}, encoded per \crossref{spendencodingandconsensus}. \\ \hline + +$\geq 5$ & \Varies & $\nOutputsSapling\!$ & \type{compactSize} & +The number of \outputDescriptions in $\vOutputsSapling$. \\ \hline + +$\geq 5$ & \Longunderstack{$948 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputsSapling\!$ & \type{OutputDescription} \type{[$\nOutputsSapling$]} & +A sequence of \outputDescriptions{}, encoded per \crossref{outputencodingandconsensus}. \\ \hline + +$\geq 5\;\mathsection$ & $8$ & $\valueBalance{Sapling}\!$ & \type{int64} & +The net value of \Sapling{} spends minus outputs. \\ \hline + +$\geq 5\;\mathsection$ & $32$ & $\anchorField{Sapling}$ & \type{byte[32]} & +A \merkleRoot of the \Sapling \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Sapling}\big)$. \\ \hline + +%$\geq 5$ & \Longunderstack{$192 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendProofsSapling$ & \type{byte[$192 \mult \nSpendsSapling$]} & +%Encodings of the \zkSNARKProofs for each \Sapling \spendDescription. \\ \hline + +%$\geq 5$ & \Longunderstack{$64 \mult$ \\$\!\nSpendsSapling\!$} & $\vSpendAuthSigsSapling$ & \type{byte[$64 \mult \nSpendsSapling$]} & +%Authorizing signatures for each \Sapling \outputDescription. \\ \hline + +%$\geq 5$ & \Longunderstack{$192 \mult$ \\$\!\nOutputsSapling\!$} & $\vOutputProofsSapling$ & \type{byte[$192 \mult \nOutputsSapling$]} & +%Encodings of the \zkSNARKProofs for each \Sapling \outputDescription. \\ \hline + +%$\geq 5\;\mathsection$ & $64$ & $\bindingSig{Sapling}$ & \type{byte[64]} & +%A \saplingBindingSignature on the \sighashTxHash, to be verified as specified in \crossref{concretebindingsig}. \\ \hline + +%$\geq 5$ & \Varies &\setorchard $\nActionsOrchard\!$ & \type{compactSize} & +%The number of \actionDescriptions in $\vActionsOrchard$. \\ \hline + +%$\geq 5$ & \Longunderstack{$884 \mult$ \\$\!\nActionsOrchard\!$} & $\vActionsOrchard\!$ & \type{ActionDescription} \type{[$\nActionsOrchard$]} & +%A sequence of \actionDescriptions{}, encoded per \crossref{actionencodingandconsensus}. \\ \hline + +%$\geq 5\;\mathsection$ & $8$ & $\valueBalance{Orchard}\!$ & \type{int64} & +%The net value of \Orchard{} spends minus outputs. \\ \hline + +%$\geq 5\;\mathsection$ & $32$ & $\anchorField{Orchard}$ & \type{byte[32]} & +%A \merkleRoot of the \Orchard \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSP{256}\big(\rt{Orchard}\big)$. \\ \hline + +%$\geq 5\; & \Varies & $\nProofsOrchard$ & \type{compactSize} & The length of the aggregated \zkSNARKProof +%$\ProofAction$ (see \crossref{halo2}). \\ \hline + +%$\geq 5\; & $2208$ & $\vProofsOrchard$ & \type{byte[2208]} & An encoding of the aggregated \zkSNARKProof +%$\ProofAction$ (see \crossref{halo2}). \\ \hline + +%$\geq 5\;\mathsection$ & $64$ & $\bindingSig{Orchard}$ & \type{byte[64]} & +%An \orchardBindingSignature on the \sighashTxHash, to be verified as specified in \crossref{concretebindingsig}. \\ \hline + \end{tabularx} \renewcommand{\arraystretch}{\defaultarraystretch} -} %scalebox +%} %scalebox \end{center} \vspace{-2ex} @@ -11066,32 +11336,32 @@ $\ddagger$ & The \valueBalance{Sapling}, \anchorField{Sapling}, and \bindingSig{ are present if and only if $\nShieldedSpend + \nShieldedOutput > 0$. If \valueBalance{Sapling} is not present, then $\vBalance{Sapling}$ is defined to be $0$. \\ -$\mathsection$ & The \valueBalance{Orchard}, \anchorField{Orchard}, and \bindingSig{Orchard} fields -are present if and only if $\nShieldedAction > 0$. If \valueBalance{Orchard} is not present, then -$\vBalance{Orchard}$ is defined to be $0$. +$\mathsection$ & The \valueBalance{Orchard}, \anchorField{Orchard}, \bindingSig{Orchard}, +\sizeProofsOrchard, and \proofsOrchard fields are present if and only if $\nActionsOrchard > 0$. +If \valueBalance{Orchard} is not present, then $\vBalance{Orchard}$ is defined to be $0$. \end{tabularx} Note that several fields are reordered relative to prior \transactionVersions. -} %orchard +%} %orchard \begin{consensusrules} \item The \defining{\transactionVersionNumber} \MUST be greater than or equal to $1$. \preoverwinteritem{The \fOverwintered{} flag \MUSTNOT be set\sprout{ in the protocol version described by this document}.} \overwinteronwarditem{The \fOverwintered{} flag \MUST be set.} - \overwinteronwarditem{The \versionGroupID{} \MUST be recognized.} - \overwinteronlyitem{The \transactionVersionNumber{} \MUST be $3$, and the \versionGroupID{} \MUST + \overwinteronwarditem{The \versionGroupID \MUST be recognized.} + \overwinteronlyitem{The \transactionVersionNumber \MUST be $3$, and the \versionGroupID \MUST be $\hexint{03C48270}$.} \saplingonwarditem{\;The\, \transactionVersionNumber\kern0.25em \MUST\, be\, $4$,\; and\, the\, \versionGroupID\kern0.25em \MUST\, be\, $\hexint{892F2085}$.} - \orchardonwarditem{The \transactionVersionNumber{} \MUST be $4$ or $5$. - If the \transactionVersionNumber{} is $4$ then the \versionGroupID{} \MUST be $\hexint{892F2085}$. - If the \transactionVersionNumber{} is $5$ then the \versionGroupID{} \MUST be $\hexint{26A7270A}$.} - \presaplingitem{The encoded size of the \transaction{} \MUST be less than or equal to + \orchardonwarditem{The \transactionVersionNumber \MUST be $4$ or $5$. + If the \transactionVersionNumber{} is $4$ then the \versionGroupID \MUST be $\hexint{892F2085}$. + If the \transactionVersionNumber{} is $5$ then the \versionGroupID \MUST be $\hexint{26A7270A}$.} + \presaplingitem{The encoded size of the \transaction \MUST be less than or equal to $100000$ bytes.} - \presaplingitem{If $\effectiveVersion = 1$ or $\nJoinSplit = 0$, then both \txInCount{} and \txOutCount{} \MUST be nonzero.\!} + \presaplingitem{If $\effectiveVersion = 1$ or $\nJoinSplit = 0$, then both \txInCount{} and \txOutCount \MUST be nonzero.\!} \saplingonwarditem{At least one of \txInCount, \nShieldedSpend, and \nJoinSplit{} \MUST be nonzero.} \saplingonwarditem{At least one of \txOutCount, \nShieldedOutput, and \nJoinSplit{} \MUST be nonzero.} - \item A \transaction with one or more \transparent inputs from \coinbaseTransactions{} \MUST have no + \item A \transaction with one or more \transparent inputs from \coinbaseTransactions \MUST have no \transparent outputs (i.e.\ \txOutCount{} \MUST be $0$). Inputs from \coinbaseTransactions include \foundersReward outputs\canopy{ and \fundingStream outputs}. \item If $\effectiveVersion \geq 2$ and $\nJoinSplit > 0$, then: @@ -11109,28 +11379,32 @@ Note that several fields are reordered relative to prior \transactionVersions. \item \bindingSig{Sapling} \MUST represent a valid signature under the \txBindingValidatingKey $\BindingPublic{Sapling}$ of $\SigHash$ --- i.e.\ $\BindingSigValidate{Sapling}{\BindingPublic{Sapling}}(\SigHash, \bindingSig{Sapling}) = 1$. + \orchardonward{As specified in \crossref{concretereddsa}, the validation of the $\RedDSAReprR{}$ + component of the signature changes to prohibit \nonCanonicalPoint encodings.} \end{itemize}} \vspace{-1ex} \saplingonwarditem{If $\effectiveVersion = 4$ and there are no \spendDescriptions or \outputDescriptions, then $\valueBalance{Sapling}$ \MUST be $0$.} - \orchardonwarditem{If $\effectiveVersion \geq 5$ and $\nShieldedAction > 0$, + \orchardonwarditem{If $\effectiveVersion \geq 5$ and $\nActionsOrchard > 0$, then: \begin{itemize} \item let $\BindingPublic{Orchard}$ and $\SigHash$ be as defined in \crossref{orchardbalance}; \item \bindingSig{Orchard} \MUST represent a valid signature under the \txBindingValidatingKey $\BindingPublic{Orchard}$ of $\SigHash$ --- i.e.\ $\BindingSigValidate{Orchard}{\BindingPublic{Orchard}}(\SigHash, \bindingSig{Orchard}) = 1$. + As specified in \crossref{concretereddsa}, validation of the $\RedDSAReprR{}$ component + of the signature prohibits \nonCanonicalPoint encodings. \end{itemize}} \vspace{-1ex} \item The total value in \zatoshi of \transparentOutputs from a \coinbaseTransaction\heartwood{, minus $\vBalance{Sapling}$,}\orchard{ minus $\vBalance{Orchard}$,} \MUSTNOT be greater than the value in \zatoshi of \minerSubsidy plus the \transactionFees paid by \transactions in this \block. \notheartwood{ - \item A \coinbaseTransaction{} \MUSTNOT have any + \item A \coinbaseTransaction \MUSTNOT have any \joinSplitDescriptions\sapling{, \spendDescriptions, or \outputDescriptions}. } \notbeforeheartwood{ - \item A \coinbaseTransaction{} \MUSTNOT have any + \item A \coinbaseTransaction \MUSTNOT have any \joinSplitDescriptions\sapling{ or \spendDescriptions}. \preheartwooditem{\sapling{A \coinbaseTransaction also \MUSTNOT have any \outputDescriptions.}} } @@ -11142,16 +11416,16 @@ Note that several fields are reordered relative to prior \transactionVersions. encoding used by \Bitcoin in the implementation of \cite{BIP-34} (but the description here is to be considered normative). \item %\consensuslink{bad-txns-premature-spend-of-coinbase} - A \transaction{} \MUSTNOT spend a \transparent output of a \coinbaseTransaction + A \transaction \MUSTNOT spend a \transparent output of a \coinbaseTransaction from a \block less than 100 \blocks prior to the spend. Note that \transparent outputs of \coinbaseTransactions include \foundersReward outputs \canopy{and \transparent \fundingStream outputs}. - \item A \transaction{} \MUSTNOT spend an output of the \genesisBlock{} \coinbaseTransaction. (There is one + \item A \transaction \MUSTNOT spend an output of the \genesisBlock \coinbaseTransaction. (There is one such zero-valued output, on each of \Testnet and \Mainnet.) \overwinteronwarditem{\nExpiryHeight{} \MUST be less than or equal to 499999999.} \overwinteronwarditem{If a \transaction is not a \coinbaseTransaction and its \nExpiryHeight{} field is nonzero, then it \MUSTNOT be mined at a \blockHeight greater than its \nExpiryHeight.} \saplingonwarditem{\valueBalance{} \MUST be in the range $\range{-\MAXMONEY}{\MAXMONEY}$.} - \heartwoodonwarditem{All \SaplingAndOrchard outputs in \coinbaseTransactions{} \MUST decrypt to a + \heartwoodonwarditem{All \SaplingAndOrchard outputs in \coinbaseTransactions \MUST decrypt to a \notePlaintext, i.e.\ the procedure in \crossref{decryptovk} does not return $\bot$, using a sequence of $32$ zero bytes as the \outgoingViewingKey.} \canopyonwarditem{Any \SaplingOrOrchard output of a \coinbaseTransaction decrypted to a \notePlaintext according @@ -11193,7 +11467,7 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notorchard{ and} \versionGroupID}. It is likely that an upgrade that changes the \transactionVersionNumber\overwinter{ or \versionGroupID} will also change the \transaction format, and software that parses - \transactions{} \SHOULD take this into account. + \transactions \SHOULD take this into account. \overwinteronwarditem{The purpose of \defining{\versionGroupID} is to allow unambiguous parsing of \quotedtermnoindex{loose} \transactions, independent of the context of a \blockChain. Code that parses \transactions is likely to be reused between \defining{\blockChainBranches} @@ -11211,7 +11485,7 @@ each \spendDescription (\crossref{spendencodingandconsensus}),\notorchard{ and} \orchardonwarditem{As a consequence of \todo{} (which has the effect of disabling \Orchard spends), the $\valueBalance{Orchard}$ field of a \coinbaseTransaction must have a negative or zero value.} \heartwood{ - \item Prior to the \Heartwood{} \networkUpgrade, it was not possible for \coinbaseTransactions + \item Prior to the \Heartwood \networkUpgrade, it was not possible for \coinbaseTransactions to have \shielded outputs, and therefore the ``coinbase maturity'' rule and the requirement to spend coinbase outputs only in \transactions with no \transparent outputs, applied to \emph{all} coinbase outputs. @@ -11235,7 +11509,10 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B \overwinteronwarditem{The $\nVersionGroupId$ field has been added.} \saplingonwarditem{The $\nShieldedSpend$, $\vShieldedSpend$, $\nShieldedOutput$, $\vShieldedOutput$, and $\bindingSig{Sapling}$ fields have been added.} - \orchardonwarditem{The $\nShieldedAction$, $\vShieldedAction$, and $\bindingSig{Orchard}$ fields + \orchardonwarditem{In version 5 \transactions, the $\nShieldedSpend$, $\vShieldedSpend$, $\nShieldedOutput$, + and $\vShieldedOutput$ fields are renamed to $\nSpendsSapling$, $\vSpendsSapling$, $\nOutputsSapling$, + and $\vOutputsSapling$ respectively.} + \orchardonwarditem{The $\nActionsOrchard$, $\vActionsOrchard$, and $\bindingSig{Orchard}$ fields have been added.} \sprout{ \item In \Zcash it is permitted for a \transaction to have no \transparent inputs provided @@ -11244,14 +11521,14 @@ The changes relative to \Bitcoin version 1 \transactions as described in \cite{B \notsprout{ \item In \Zcash it is permitted for a \transaction to have no \transparent inputs, provided at least one of $\nJoinSplit$\sapling{, $\nShieldedSpend$,\notorchard{ and} - $\nShieldedOutput$}\orchard{, and $\nShieldedAction$} are nonzero. + $\nShieldedOutput$}\orchard{, and $\nActionsOrchard$} are nonzero. } %notsprout \item A consensus rule limiting \transaction size has been added. In \Bitcoin there is a corresponding standard rule but no consensus rule. \end{itemize} \preoverwinter{ -Software that creates \transactions{} \SHOULD use version 1 for \transactions with no +Software that creates \transactions \SHOULD use version 1 for \transactions with no \joinSplitDescriptions. } @@ -11274,7 +11551,7 @@ A value $\vpubOld$ that the \joinSplitTransfer removes from the \transparentTxVa $8$ & $\vpubNewField$ & \type{uint64} & A value $\vpubNew$ that the \joinSplitTransfer inserts into the \transparentTxValuePool. \\ \hline -$32$ & $\anchorField{}$ & \type{byte[32]} & A \merkleRoot $\rt{Sprout}$ of the \SproutOrNothing{} +$32$ & $\anchorField{}$ & \type{byte[32]} & A \merkleRoot $\rt{Sprout}$ of the \Sprout{} \noteCommitmentTree at some \blockHeight in the past, or the \merkleRoot produced by a previous \joinSplitTransfer in this \transaction. \\ \hline @@ -11346,7 +11623,7 @@ Bytes & \heading{Name} & \heading{Data Type} & \heading{Description} \\ $32$ & $\cvField$ & \type{byte[32]} & A \valueCommitment to the value of the input \note, $\LEBStoOSPOf{256}{\reprJ\Of{\cv}}$. \\ \hline -$32\orchard{\;\dagger}$ & $\anchorField{}$ & \type{byte[32]} & A \merkleRoot of the \Sapling{} \noteCommitmentTree +$32\orchard{\;\dagger}$ & $\anchorField{}$ & \type{byte[32]} & A \merkleRoot of the \Sapling \noteCommitmentTree at some \blockHeight in the past, $\LEBStoOSPOf{256}{\rt{Sapling}}$. \\ \hline $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline @@ -11452,13 +11729,13 @@ minus the output \note, $\LEBStoOSPOf{256}{\reprP\Of{\cv}}$. \\ \hline $32$ & $\nullifierField$ & \type{byte[32]} & The \nullifier of the input \note, $\nf$. \\ \hline $32$ & $\rkField$ & \type{byte[32]} & The randomized \validatingKey for $\spendAuthSig$, -$\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline +$\LEBStoOSPOf{256}{\reprP\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline -$32$ & $\cmuField$ & \type{byte[32]} & The $u$-coordinate of the \noteCommitment for the output \note, -$\LEBStoOSPOf{256}{\cmU}$ where $\cmU = \ExtractJ(\cm)$. \\ \hline +$32$ & $\cmxField$ & \type{byte[32]} & The $x$-coordinate of the \noteCommitment for the output \note, +$\LEBStoOSPOf{256}{\cmX}$ where $\cmU = \ExtractJ(\cm)$. \\ \hline $32$ & $\ephemeralKey$ & \type{byte[32]} & An encoding of an ephemeral \Jubjub \publicKey, -$\LEBStoOSPOf{256}{\reprJ\Of{\EphemeralPublic}}$. \\ \hline +$\LEBStoOSPOf{256}{\reprP\Of{\EphemeralPublic}}$. \\ \hline $580$ & $\encCiphertext$ & \type{byte[580]} & A ciphertext component for the encrypted output \note, $\TransmitCiphertext{}$. \\ \hline @@ -11466,9 +11743,6 @@ encrypted output \note, $\TransmitCiphertext{}$. \\ \hline $80$ & $\outCiphertext$ & \type{byte[80]} & A ciphertext component for the encrypted output \note, $\OutCiphertext{}$. \\ \hline -$2208$ & $\zkproof$ & \type{byte[2208]} & An encoding of the \zkSNARKProof -$\ProofAction$ (see \crossref{halo2}). \\ \hline - $64$ & $\spendAuthSig$ & \type{byte[64]} & A signature authorizing this Spend. \\ \hline \end{tabularx} @@ -11516,7 +11790,7 @@ $32$ & \sprout{$\hashReserved$} \type{byte[32]} & \presapling{A reserved field which should be ignored.} \saplingandblossom{The \merkleRoot $\LEBStoOSPOf{256}{\rt{Sapling}}$ of the \Sapling{} -\noteCommitmentTree corresponding to the final \Sapling{} \treestate of this \block.} +\noteCommitmentTree corresponding to the final \Sapling \treestate of this \block.} \heartwoodonward{The $\hashChainHistoryRoot$ of this \block.} \\ \hline $4$ & $\nTimeField$ & \type{uint32} & The \defining{\blockTimestamp} is a Unix epoch time (UTC) @@ -11552,33 +11826,33 @@ preceding \blocks if there are fewer than $\PoWMedianBlockSpan$). The \medianTim \vspace{2ex} \begin{consensusrules} - \item The \blockVersionNumber{} \MUST be greater than or equal to $4$. + \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 The \block \MUST pass the difficulty filter defined in \crossref{difficulty}. \item $\solution$ \MUST represent a \validEquihashSolution as defined in \crossref{equihash}. \item For each \block other than the \genesisBlock, $\nTimeField$ \MUST be strictly greater than the \medianTimePast of that \block. \item For each \block at \blockHeight $2$ or greater on \Mainnet, or \blockHeight $653606$ or greater on \Testnet, $\nTimeField$ \MUST be less than or equal to the \medianTimePast of that \block plus $90 \mult 60$ seconds. - \item The size of a \block{} \MUST be less than or equal to $2000000$ bytes. + \item The size of a \block \MUST be less than or equal to $2000000$ bytes. \notheartwood{ \saplingonwarditem{$\hashFinalSaplingRoot$ \MUST be $\LEBStoOSPOf{256}{\rt{Sapling}}$ where - $\rt{Sapling}$ is the \merkleRoot of the \Sapling{} \noteCommitmentTree for the final - \Sapling{} \treestate of this \block.} + $\rt{Sapling}$ is the \merkleRoot of the \Sapling \noteCommitmentTree for the final + \Sapling \treestate of this \block.} } \notbeforeheartwood{ \saplingandblossomitem{$\hashLightClientRoot$ \MUST be $\LEBStoOSPOf{256}{\rt{Sapling}}$ where - $\rt{Sapling}$ is the \merkleRoot of the \Sapling{} \noteCommitmentTree for the final - \Sapling{} \treestate of this \block.} + $\rt{Sapling}$ is the \merkleRoot of the \Sapling \noteCommitmentTree for the final + \Sapling \treestate of this \block.} \heartwoodonwarditem{$\hashLightClientRoot$ \MUST be set to the value of $\hashChainHistoryRoot$ for this \block, as specified in \cite{ZIP-221}.} } \item \todo{Other rules inherited from \Bitcoin.} \end{consensusrules} -In addition, a \fullValidator{} \MUSTNOT accept \blocks with $\nTimeField$ more than two hours +In addition, a \fullValidator \MUSTNOT accept \blocks with $\nTimeField$ more than two hours in the future according to its clock. This is not strictly a consensus rule because it is nondeterministic, and clock time varies between nodes. Also note that a \block that is rejected by this rule at a given point in time may later be accepted. @@ -11592,7 +11866,7 @@ rejected by this rule at a given point in time may later be accepted. Note that a future upgrade might use \blockVersionNumber{} either greater than or less than $4$. It is likely that such an upgrade will change the \block header and/or \transaction format, and software that - parses \blocks{} \SHOULD take this into account. + parses \blocks \SHOULD take this into account. \item The $\nVersion$ field is a signed integer. (It was specified as unsigned in a previous version of this specification.) A future upgrade might use negative values for this field, or otherwise change @@ -11923,7 +12197,7 @@ in its \blockHeader is defined as $\floor{\hfrac{2^{256}}{\ToTarget(\nBits) + 1} \introlist -\lsubsection{Calculation of Block Subsidy\canopy{, Funding Streams,} and Founders' Reward}{subsidies} +\lsubsection{Calculation of Block Subsidy\notbeforecanopy{, Funding Streams,} and Founders' Reward}{subsidies} \crossref{subsidyconcepts} defines the \blockSubsidy, \minerSubsidy,\notcanopy{ and} \foundersReward\canopy{, and \fundingStreams}. Their amounts in \zatoshi are calculated from the \blockHeight using @@ -12268,7 +12542,7 @@ The following BIPs apply, otherwise unchanged, to \Zcash: \cite{BIP-37}, \cite{BIP-61}. -The following BIPs apply starting from the \Zcash{} \genesisBlock, i.e.\ any activation +The following BIPs apply starting from the \Zcash \genesisBlock, i.e.\ any activation rules or exceptions for particular \blocks in the \Bitcoin \blockChain are to be ignored: \cite{BIP-16}, @@ -12315,7 +12589,7 @@ which is extended to contain a sequence of zero or more \Zcash-specific operations. This allows for the possibility of chaining transfers of \shielded -value in a single \Zcash{} \transaction, e.g.\ to spend a \shielded \note +value in a single \Zcash \transaction, e.g.\ to spend a \shielded \note that has just been created. (In \Zcash, we refer to value stored in UTXOs as \transparent, and value stored in output \notes of \joinSplitTransfers\sapling{ or \outputTransfers)} as \shielded.) @@ -12358,7 +12632,7 @@ In \Zcash, the sequence of operations added to a \transaction (see \crossref{trstructure}) consists only of \joinSplitTransfers. A \joinSplitTransfer is a Pour operation generalized to take a \transparent UTXO as input, allowing \joinSplitTransfers to subsume the functionality of -Mints. An advantage of this is that a \Zcash{} \transaction that takes +Mints. An advantage of this is that a \Zcash \transaction that takes input from an UTXO can produce up to $\NNew$ output \notes, improving the indistinguishability properties of the protocol. A related change conceals the input arity of the \joinSplitTransfer: an unused (zero-value) @@ -12519,7 +12793,7 @@ where $\NotePositionBaseSapling$ is a generator independent of the generators used in $\NoteCommitAlg{Sapling}$. Therefore, $\NoteUniqueRand$ commits uniquely to the \note and its position, and this commitment is \collisionResistant by the same argument used to prove \collisionResistance of \xPedersenHashes. -Note that it is possible for two distinct \Sapling{} \positionedNotes (having +Note that it is possible for two distinct \Sapling \positionedNotes (having different $\NoteUniqueRand$ values and \nullifiers, but different \notePositions) to have the same \noteCommitment, but this causes no security problem. Roadblock attacks are not possible because a given \notePosition @@ -12564,8 +12838,8 @@ evaluations needed to compute each \noteCommitment from three to two, saving a total of four \shaCompress evaluations in the \joinSplitStatement. \sproutspecificpnote{ -\notsprout{\Sprout{} \noteCommitments are not statistically hiding, so for \Sprout notes,} -\sprout{\Zcash{} \noteCommitments are not statistically hiding, so} +\notsprout{\Sprout \noteCommitments are not statistically hiding, so for \Sprout notes,} +\sprout{\Zcash \noteCommitments are not statistically hiding, so} \Zcash does not support the ``everlasting anonymity'' property described in \cite[section 8.1]{BCGGMTV2014}, even when used as described in that section. While it is possible to @@ -12732,7 +13006,7 @@ The motivations for this change were as follows: chosen-ciphertext attack without detection.} \sapling{(In \Sapling, there is no equivalent to $\hSig$, but the \bindingSignature and \spendAuthSignatures prevent such modifications.)} - \item \sproutspecific{The scheme used by \SproutOrZcash includes an optimization that reuses + \item \sproutspecific{The scheme used by \Sprout includes an optimization that reuses the same ephemeral key (with different nonces) for the two ciphertexts encrypted in each \joinSplitDescription.} \end{itemize} @@ -12788,7 +13062,7 @@ For the ``$\Adversary$ violates Condition I'' case, the proof says: \end{itemize} In fact the openings do not contain $\AuthPrivateOld{i}$; they contain -$\AuthEmphPublicOld{i}$. (In \SproutOrZcash $\cmOld{i}$ opens directly to +$\AuthEmphPublicOld{i}$. (In \Sprout $\cmOld{i}$ opens directly to $(\AuthEmphPublicOld{i}, \ValueOld{i}, \NoteUniqueRandOld{i})$, and in \Zerocash it opens to $(\ValueOld{i}, \Commit{\NoteCommitS}(\AuthEmphPublicOld{i}, \NoteUniqueRandOld{i})$.) @@ -12797,7 +13071,7 @@ A similar error occurs in the argument for the ``$\Adversary$ violates Condition II'' case. The flaw is not exploitable for the actual instantiations of $\PRFaddr{}$ -in \Zerocash and \SproutOrZcash, which \emph{are} \collisionResistant assuming +in \Zerocash and \Sprout, which \emph{are} \collisionResistant assuming that \shaCompress is. The proof can be straightforwardly repaired. The intuition is that we can rely @@ -12812,14 +13086,14 @@ distinct openings of the \noteCommitment when Condition I or II is violated. \begin{itemize} \item The paper defines a \note as $((\AuthPublic, \TransmitPublic), \Value, \NoteUniqueRand, \NoteCommitRand, \NoteCommitS, \cm)$, whereas this - specification defines \sprout{it}\notsprout{a \Sprout{} \note} as + specification defines \sprout{it}\notsprout{a \Sprout \note} as $(\AuthPublic, \Value, \NoteUniqueRand, \NoteCommitRand)$. The instantiation of $\Commit{\NoteCommitS}$ in section 5.1 of the paper did not actually use $\NoteCommitS$, and neither does the new - instantiation of $\NoteCommit{Sprout}{}$ in \SproutOrZcash. $\TransmitPublic$ is also + instantiation of $\NoteCommit{Sprout}{}$ in \Sprout. $\TransmitPublic$ is also not needed as part of a \note: it is not an input to $\NoteCommit{Sprout}{}$ nor is it constrained by the \Zerocash \POUR{} \statement or the - \Zcash{} \joinSplitStatement. $\cm$ can be computed from the other fields. + \Zcash \joinSplitStatement. $\cm$ can be computed from the other fields. \sapling{(The definition of \notes for \Sapling is different again.)} \item The length of proof encodings given in the paper is $288$ bytes. \sproutspecific{This differs from the $296$ bytes specified in \crossref{bctv}, @@ -12941,7 +13215,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. } %orchard \canopy{ \item In the consensus rule that a \transaction with one or more \transparent inputs from - \coinbaseTransactions{} \MUST have no \transparent outputs, explicitly say that inputs + \coinbaseTransactions \MUST have no \transparent outputs, explicitly say that inputs from \coinbaseTransactions include \fundingStream outputs. } %canopy \item The definition of an abstraction function in \crossref{abstractgroup} incorrectly @@ -13003,7 +13277,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \nonCanonicalPoint and need not be in the prime subgroup. \item Move checking of $\cmU$ in decryption with $\InViewingKey$ to the end of the algorithm, to more closely match the implementation. - \item The note about decryption of outputs in \mempool{} \transactions should have been + \item The note about decryption of outputs in \mempool \transactions should have been normative. \end{itemize} \vspace{-1.5ex} @@ -13154,7 +13428,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \canopy{ - \item Incorporate changes to \Sapling{} \note encryption from \cite{ZIP-212}. + \item Incorporate changes to \Sapling \note encryption from \cite{ZIP-212}. } %canopy \item Correct an error in the specification of \EdSpecific \validatingKeys: they should not have been specified to be checked against $\ExcludedPointEncodings$, @@ -13538,7 +13812,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. based on reduction to \keyPrivacy of ElGamal encryption, for which a security proof is given in \cite{BBDP2001}. (This argument has gaps which will be addressed in a future version.) - \item Add a reference to \cite{BGM2017} for the \Sapling{} \zkSNARK parameters. + \item Add a reference to \cite{BGM2017} for the \Sapling \zkSNARK parameters. \item Write \crossref{cctsaplingspend} (draft). \item Add a reference to the ristretto\_bulletproofs design notes \cite{Dalek-notes} for the synthetic blinding factor technique. @@ -13679,7 +13953,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Remove the consensus rule - ``If $\nJoinSplit > 0$, the \transaction{} \MUSTNOT use \sighashTypes other than $\SIGHASHALL$.'', + ``If $\nJoinSplit > 0$, the \transaction \MUSTNOT use \sighashTypes other than $\SIGHASHALL$.'', which was never implemented. \item Add section on signature hashing. \item Briefly describe the changes to computation of \sighashTxHashes\notsprout{ in \Sprout}. @@ -13926,7 +14200,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \sapling{ \item Add a section on re-randomizable signatures. \item Add definition of $\PRF{}{\mathsf{nr}}$. - \item Work-in-progress on \Sapling{} \statements. + \item Work-in-progress on \Sapling \statements. \item Rename \quotedtermnoindex{raw} to \quotedtermnoindex{homomorphic} \xPedersenCommitments. \item Add packing modulo the field size and range checks to Appendix A. \item Update the algorithm for variable-base scalar multiplication to @@ -13951,7 +14225,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \item Split the descriptions of \shaHash 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)}. + encoding the root of the \Sapling \noteCommitmentTree in \blockHeaders)}. \item Move bit/byte/integer conversion primitives into \crossref{endian}. \sapling{ \item Refer to \Overwinter and \Sapling just as ``upgrades'' in the abstract, not as @@ -14178,7 +14452,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. \begin{itemize} \item Specify a check on the order of $\Proof{B}$ in a \zkSNARKProof. - \item Note that due to an oversight, the \Zcash{} \genesisBlock does not + \item Note that due to an oversight, the \Zcash \genesisBlock does not follow \cite{BIP-34}. \end{itemize} diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 7066cc9b..134f6de5 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -480,6 +480,99 @@ Received March~20, 2012.} urldate={2016-08-14} } +@misc{GKRRS2019, + presort={GKRRS2019}, + author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger}, + title={Poseidon: A New Hash Function for Zero-Knowledge Proof Systems}, + url={https://eprint.iacr.org/2019/458}, + urldate={2021-02-28}, + howpublished={Cryptology ePrint Archive: Report 2019/458. +Last updated December~16, 2020.} +} + +@misc{BDPA2007, + presort={BDPA2007}, + author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, + title={Sponge functions}, + url={https://www.researchgate.net/publication/242285874_Sponge_Functions}, + urldate={2021-03-01}, + howpublished={ECRYPT Hash Workshop (May 2007), also available as a public comment to NIST +as part of the Hash Algorithm Requirements and Evaluation Criteria for the SHA-3 competition.} +} + +@misc{BDPA2011, + presort={BDPA2011}, + author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, + title={Cryptographic sponge functions}, + url={https://keccak.team/files/CSF-0.1.pdf}, + urldate={2021-03-01}, + howpublished={Team Keccak web page, \url{https://keccak.team/sponge\_duplex.html}. Version 0.1, January~14, 2011.} +} + +@misc{ADMA2015, + presort={ADMA2015}, + author={Elena Andreeva and Joan Daemen and Bart Mennink and Gilles {Van Assche}}, + title={Security of Keyed Sponge Constructions Using a Modular Proof Approach}, + url={https://keccak.team/files/ModularKeyedSponge.pdf}, + urldate={2021-03-01}, + howpublished={Team Keccak web page, \url{https://keccak.team/papers.html}.}, + addendum={Originally published in \textsl{Fast Software Encryption - Proceeedings of the 22nd International Workshop +(Istanbul, Turkey, March~8--11, 2015)}, pages 364--384; Springer, 2015. Note that the pre-proceedings version contained +an oversight in the analysis of the outer-keyed sponge.} +} + +@inproceedings{GPT2015, + presort={GPT2015}, + author={Peter Gazi and Krzysztof Pietrzak and Stefano Tessaro}, + title={The Exact {PRF} Security of Truncation: {T}ight Bounds for Keyed Sponges and Truncated {CBC}}, + booktitle={Advances in Cryptology - CRYPTO~2015. +Proceedings of the 35th Annual International Cryptology Conference +(Santa Barbara, California, USA, August~16--20, 2015), Part I}, + volume={9215}, + series={Lecture Notes in Computer Science}, + editor={Rosario Gennaro and Matthew Robshaw}, + pages={368--387}, + date={2015-08-01}, + publisher={Springer}, + isbn={978-3-662-47989-6}, + doi={10.1007/978-3-662-47989-6\_18}, + url={https://iacr.org/cryptodb/data/paper.php?pubkey=27279}, + urldate={2021-03-01} +} + +@misc{GG2015, + presort={GG2015}, + author={Shoni Gilboa and Shay Gueron}, + title={Distinguishing a truncated random permutation from a random function}, + url={https://eprint.iacr.org/2015/773}, + urldate={2021-03-01}, + howpublished={Cryptology ePrint Archive: Report 2015/773. +Received August~3, 2015.} +} + +@misc{KR2020, + presort={KR2020}, + author={Nathan Keller and Asaf Rosemarin}, + title={Mind the Middle Layer: {T}he {HADES} Design Strategy Revisited}, + url={https://eprint.iacr.org/2020/179}, + urldate={2021-03-01}, + howpublished={Cryptology ePrint Archive: Report 2020/179. +Received February~13, 2020.} +} + +@misc{BCD+2020, + presort={BCD+2020}, + author={Tim Beyne and Anne Canteaut and Itai Dinur and Maria Eichlseder and Gregor Leander and Gaëtan Leurent and +María Naya-Plasencia and Léo Perrin and Yu Sasaki and Yosuke Todo and Friedrich Wiemer}, + title={Out of Oddity --- New Cryptanalytic Techniques against Symmetric Primitives Optimized for Integrity Proof Systems}, + url={https://eprint.iacr.org/2020/188}, + urldate={2021-03-01}, + howpublished={Cryptology ePrint Archive: Report 2020/188. +Last revised November~11, 2020.}, + addendum={Originally published (with major differences) in \textsl{Advances in Cryptology - CRYPTO~2020}, Vol.~12172 pages 299--328; +Lecture Notes in Computer Science; Springer, 2020.} +} + @misc{AGRRT2017, presort={AGRRT2017}, author={Martin Albrecht and Lorenzo Grassi and Christian Rechberger and